Der Newsletter dieser Woche beschreibt kurz eine neue Bibliothek, die es ermöglicht, Output-Script-Deskriptoren für die Verwendung in QR-Codes zu komprimieren. Ebenfalls enthalten sind unsere regulären Abschnitte mit einer Zusammenfassung eines Bitcoin Core PR Review Club Meetings, der Ankündigung neuer Releases und Release-Kandidaten und der Beschreibung wichtiger Änderungen an beliebter Bitcoin-Infrastruktursoftware.

Nachrichten

  • ● Komprimierte Deskriptoren: Josh Doman postete auf Delving Bitcoin, um eine Bibliothek anzukündigen, die er geschrieben hat und die Output-Script-Deskriptoren in ein binäres Format kodiert, das ihre Größe um etwa 40% reduziert. Dies kann besonders nützlich sein, wenn Deskriptoren mittels QR-Codes gesichert werden. Sein Beitrag erläutert die Details der Kodierung und erwähnt, dass er plant, die Komprimierung in seine Bibliothek für verschlüsselte Deskriptor-Backups zu integrieren (siehe Newsletter #358).

Bitcoin Core PR Review Club

In diesem monatlichen Abschnitt fassen wir ein kürzliches Bitcoin Core PR Review Club Meeting zusammen und heben einige der wichtigen Fragen und Antworten hervor. Klicken Sie auf eine Frage unten, um eine Zusammenfassung der Antwort aus dem Meeting zu sehen.

Improve TxOrphanage denial of service bounds ist ein PR von glozow, der die TxOrphanage-Eviction-Logik ändert, um jedem Peer die Ressourcen für mindestens 1 Paket maximaler Größe für die Orphan-Auflösung zu garantieren. Diese neuen Garantien verbessern die 1-parent-1-child opportunistische Paket-Weiterleitung erheblich, insbesondere (aber nicht nur) unter widrigen Bedingungen, wenn Angreifer versuchen, das System zu stören.

Der PR modifiziert bestehende globale Orphanage-Limits und führt neue Per-Peer-Limits ein. Zusammen schützen sie sowohl vor übermäßiger Speichernutzung als auch vor rechnerischer Erschöpfung. Der PR ersetzt auch den zufälligen Eviction-Ansatz durch einen algorithmischen und berechnet einen Per-Peer-DoS-Score.

Hinweis: Der PR hat einige bedeutende Änderungen seit dem Review Club durchlaufen, wobei die wichtigste in der Verwendung eines Latenz-Score-Limits anstelle eines Announcement-Limits besteht.

  • Warum ist das aktuelle globale TxOrphanage-Maximum von 100 Transaktionen mit zufälliger Eviction problematisch?

    Es ermöglicht einem bösartigen Peer, einen Knoten mit Orphan-Transaktionen zu überlasten und schließlich alle legitimen Transaktionen anderer Peers zu verdrängen. Dies kann genutzt werden, um die opportunistische 1-parent-1-child-Transaktions-Weiterleitung am Erfolg zu hindern, da die Kind-Transaktion nicht lange im temporären Speicher (Orphanage) bleiben könnte. ➚

  • Wie funktioniert der Eviction-Algorithmus auf hoher Ebene?

    Eviction ist nicht mehr zufällig. Der Algorithmus identifiziert den “schlechtesten” Peer basierend auf einem “DoS-Score” und verdrängt die älteste Transaktionsankündigung von diesem Peer. Dies schützt wohlverhaltende Peers davor, dass ihre Transaktions-Kinder von einem fehlverhaltenden Peer verdrängt werden. ➚

  • Warum ist es wünschenswert, Peers zu erlauben, ihre individuellen Limits zu überschreiten, während die globalen Limits nicht erreicht sind?

    Peers verwenden möglicherweise mehr Ressourcen, einfach weil sie ein hilfreicher Peer sind, der nützliche Transaktionen wie CPFPs weiterleitet. ➚

  • Der neue Algorithmus verdrängt Ankündigungen anstelle von Transaktionen. Was ist der Unterschied und warum ist das wichtig?

    Eine Ankündigung ist ein Paar aus einer Transaktion und dem Peer, der sie gesendet hat. Durch das Verdrängen von Ankündigungen kann ein bösartiger Peer keine Transaktion verdrängen, die auch von einem ehrlichen Peer gesendet wurde. ➚

  • Was ist der “DoS-Score” eines Peers und wie wird er berechnet?

    Der DoS-Score eines Peers ist das Maximum seines “Speicher-Scores” (verwendeter Speicher / reservierter Speicher) und “CPU-Scores” (Anzahl der gesendeten Ankündigungen / Ankündigungslimit). Die Verwendung eines einzigen kombinierten Scores vereinfacht die Eviction-Logik zu einer einzigen Schleife, die den Peer anvisiert, der am aggressivsten eines seiner Limits überschreitet. ➚

Releases und Release-Kandidaten

Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Releases oder helfen Sie beim Testen von Release-Kandidaten.

Wichtige Code- und Dokumentationsänderungen

Wichtige kürzliche Änderungen in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, und BINANAs.

  • ● Core Lightning #8377 verschärft die BOLT11-Invoice-Parsing-Anforderungen, indem es vorschreibt, dass Sender eine Invoice nicht bezahlen, wenn ein Payment Secret fehlt oder wenn ein Pflichtfeld wie p (Payment Hash), h (Description Hash) oder s (Secret) eine falsche Länge hat. Diese Änderungen werden vorgenommen, um sich an die kürzlichen Spezifikations-Updates anzupassen (siehe Newsletter #350 und #358).

  • ● BDK #1957 führt RPC-Batching für Transaktionshistorie, Merkle-Beweise und Block-Header-Anfragen ein, um die Full-Scan- und Sync-Performance mit einem Electrum-Backend zu optimieren. Dieser PR fügt auch Anchor-Caching hinzu, um Simple Payment Verification (SPV) (siehe Newsletter #312) Revalidierung während eines Syncs zu überspringen. Mit Beispieldaten beobachtete der Autor Performance-Verbesserungen von 8,14 Sekunden auf 2,59 Sekunden mit RPC-Call-Batching bei einem Full Scan und von 1,37 Sekunden auf 0,85 Sekunden mit Caching während eines Syncs.

  • ● BIPs #1888 entfernt H als Hardened-Path-Marker aus BIP380 und lässt nur das kanonische h und die Alternative ' übrig. Der kürzliche Newsletter #360 hatte angemerkt, dass die Grammatik klargestellt wurde, um alle drei Marker zu erlauben, aber da wenige (wenn überhaupt) Deskriptor-Implementierungen dies tatsächlich unterstützen (weder Bitcoin Core noch rust-miniscript tun es), wird die Spezifikation verschärft, um dies zu verbieten.