Der Newsletter dieser Woche fasst die Ergebnisse eines Tests zum Prefilling beim Compact-Block-Relay zusammen und verweist auf eine mempool-basierte Bibliothek zur Gebührenabschätzung. Wie gewohnt enthält der Newsletter unsere regelmäßigen Abschnitte mit Zusammenfassungen zu Diskussionen über Änderungen der Konsensregeln von Bitcoin, der Ankündigung neuer Releases und Release-Kandidaten sowie einer Übersicht wichtiger Änderungen an beliebter Bitcoin-Infrastruktur-Software.

Nachrichten

  • ● Test zu Compact-Block-Prefilling: David Gumberg antwortete in einem Delving-Bitcoin-Thread zur Effizienz der Compact-Block-Rekonstruktion (siehe auch Newsletter #315 und #339) mit einer Zusammenfassung seiner Testergebnisse zum Compact-Block-Relay und dem sogenannten Prefilling. Dabei sendet ein Knoten proaktiv einige oder alle Transaktionen eines neuen Blocks an seine Peers, wenn er annimmt, dass diese die Transaktionen noch nicht haben. Gumbergs Beitrag ist ausführlich und enthält einen Link zu einem Jupyter-Notebook, mit dem andere selbst experimentieren können. Die wichtigsten Erkenntnisse:

    • Unabhängig vom Netzwerktransport erhöhte eine einfache Regel zur Auswahl der zu prefillenden Transaktionen die Erfolgsrate der Blockrekonstruktion von etwa 62 % auf etwa 98 %.

    • Unter Berücksichtigung des Netzwerktransports führten einige Prefills zu einem zusätzlichen Roundtrip, was den Vorteil in diesen Fällen aufhob und die Leistung leicht verschlechterte. Viele Prefills hätten jedoch so konstruiert werden können, dass das Problem vermieden wird, wodurch die Rekonstruktionsrate auf etwa 93 % steigt und weitere Verbesserungen möglich bleiben.

  • ● Mempool-basierte Gebührenabschätzungs-Bibliothek: Lauren Shareshian kündigte auf Delving Bitcoin eine von Block entwickelte Bibliothek zur Gebührenabschätzung an. Im Gegensatz zu anderen Tools nutzt sie ausschließlich den Zufluss von Transaktionen in den Mempool eines Knotens als Grundlage für ihre Schätzungen. Im Beitrag wird die Bibliothek „Augur“ mit mehreren anderen Gebührenabschätzungsdiensten verglichen und festgestellt, dass Augur eine niedrige Fehlerrate (über 85 % der Transaktionen werden im gewünschten Zeitfenster bestätigt) und eine geringe durchschnittliche Überschätzung (Transaktionen zahlen im Schnitt nur etwa 16 % zu viel Gebühr) aufweist.

    Abubakar Sadiq Ismail antwortete im Delving-Thread und eröffnete zudem ein informatives Issue im Augur-Repository, um einige der in der Bibliothek verwendeten Annahmen zu untersuchen.

Konsensänderungen

Monatlicher Abschnitt mit Zusammenfassungen zu Vorschlägen und Diskussionen über Änderungen der Bitcoin-Konsensregeln.

  • ● Migration von quantenanfälligen Outputs: Jameson Lopp veröffentlichte in der Bitcoin-Dev-Mailingliste einen dreistufigen Vorschlag, um das Ausgeben von quantenanfälligen Outputs schrittweise zu beenden.

    • Drei Jahre nach der Konsensaktivierung des BIP360-Signaturschemas (oder eines alternativen quantenresistenten Schemas) würde ein Softfork Transaktionen mit Ausgaben an quantenanfällige Adressen ablehnen. Nur Ausgaben an quantenresistente Outputs wären dann erlaubt.

    • Zwei Jahre später würde ein zweiter Softfork das Ausgeben von quantenanfälligen Outputs vollständig verbieten. Alle verbleibenden Mittel auf solchen Outputs wären dann nicht mehr ausgebbar.

    • Optional könnte zu einem späteren, noch nicht definierten Zeitpunkt eine Konsensänderung das Ausgeben von quantenanfälligen Outputs mit einem quantenresistenten Nachweisverfahren erlauben (siehe Newsletter #361 für ein Beispiel).

    Ein Großteil der Diskussion im Thread wiederholte frühere Debatten darüber, ob es notwendig ist, das Ausgeben von quantenanfälligen Bitcoins zu verhindern, bevor sicher ist, dass ein ausreichend leistungsfähiger Quantencomputer existiert (siehe Newsletter #348). Für beide Seiten wurden nachvollziehbare Argumente vorgebracht, und es ist zu erwarten, dass diese Debatte weitergeführt wird.

  • ● Taproot-nativer OP_TEMPLATEHASH-Vorschlag: Greg Sanders veröffentlichte in der Bitcoin-Dev-Mailingliste einen Vorschlag, drei neue Opcodes zu Tapscript hinzuzufügen. Zwei davon sind die bereits vorgeschlagenen OP_CHECKSIGFROMSTACK und OP_INTERNALKEY (siehe Newsletter #285). Der dritte Opcode ist OP_TEMPLATEHASH, eine taproot-native Variante von OP_CHECKTEMPLATEVERIFY (OP_CTV) mit folgenden, von den Autoren hervorgehobenen Unterschieden:

    • Keine Änderungen an Legacy-Skripten (vor Segwit). Siehe Newsletter #361 für frühere Diskussionen zu dieser Alternative.

    • Die zu hashenden Daten (und deren Reihenfolge) ähneln stark denen, die für Signaturen in Taproot verwendet werden. Das vereinfacht die Implementierung für Software, die Taproot bereits unterstützt.

    • Es bindet den Taproot Annex ein, was OP_CTV nicht tut. Damit kann z.B. sichergestellt werden, dass bestimmte Daten als Teil einer Transaktion veröffentlicht werden – etwa für Protokolle, die einer Gegenpartei die Wiederherstellung nach der Veröffentlichung eines alten Zustands ermöglichen.

    • Es wird ein OP_SUCCESSx-Opcode statt eines OP_NOPx-Opcodes redefiniert. Softforks, die OP_NOPx-Opcodes neu belegen, müssen als VERIFY-Opcodes implementiert werden, die eine Transaktion bei Fehlschlag ungültig machen. Redefinitionen von OP_SUCCESSx können einfach 1 (Erfolg) oder 0 (Fehlschlag) auf den Stack legen. Dadurch können sie auch dort direkt verwendet werden, wo bei OP_NOPx-Redefinitionen zusätzliche Bedingungen wie OP_IF nötig wären.

    • „Es verhindert unerwartete Eingaben mit … scriptSig“ (siehe Newsletter #361).

    Brandon Black antwortete mit einem Vergleich des Vorschlags zu seinem früheren LNHANCE-Bundle-Vorschlag (siehe Newsletter #285) und stellte fest, dass beide in den meisten Punkten vergleichbar sind. Allerdings merkte er an, dass der neue Vorschlag für Congestion Control (eine Form des verzögerten Payment Batchings) weniger effizient im Onchain-Speicherbedarf ist.

  • ● Vorschlag für längere relative Timelocks: Entwickler Pyth schlug auf Delving Bitcoin vor, die BIP68-basierten relativen Timelocks von derzeit maximal etwa einem Jahr auf bis zu zehn Jahre zu verlängern. Dies würde einen Softfork und die Nutzung eines zusätzlichen Bits im sequence-Feld des Transaktionseingangs erfordern.

    Fabian Jahr antwortete mit dem Hinweis, dass zu weit in die Zukunft reichende Timelocks zu einem Verlust von Geldern führen könnten, etwa durch die Entwicklung von Quantencomputern (oder, ergänzen wir, durch die Einführung von Quantenabwehr-Protokollen wie dem weiter oben beschriebenen Vorschlag von Jameson Lopp). Steven Roose merkte an, dass weit in der Zukunft liegende Timelocks bereits heute mit anderen Mechanismen möglich sind (z.B. mit vorab signierten Transaktionen und BIP65 CLTV). Pyth ergänzte, dass der gewünschte Anwendungsfall ein Wallet-Wiederherstellungspfad sei, bei dem der lange Timelock nur genutzt würde, wenn der Hauptpfad nicht mehr verfügbar ist und die Alternative ohnehin der dauerhafte Verlust der Mittel wäre.

  • ● Sicherheit gegen Quantencomputer mit Taproot als Commitment-Schema: Tim Ruffing veröffentlichte einen Link zu einem Paper, in dem er die Sicherheit von Taproot-Commitments gegen Manipulation durch Quantencomputer analysiert. Er untersucht, ob Taproot-Commitments zu Tapleaves weiterhin die Bindungs- und Verbergungseigenschaften besitzen, die sie auch gegen klassische Computer haben. Sein Fazit:

    Ein Quantenangreifer müsste mindestens 2^81 SHA256-Auswertungen durchführen, um ein Taproot-Output zu erzeugen und es mit einer Wahrscheinlichkeit von 1/2 zu einem unerwarteten Merkle-Root öffnen zu können. Falls der Angreifer nur Quantenmaschinen besitzt, deren längste SHA256-Berechnungskette auf 2^20 begrenzt ist, benötigt er mindestens 2^92 solcher Maschinen, um eine Erfolgswahrscheinlichkeit von 1/2 zu erreichen.

    Wenn Taproot-Commitments gegen Manipulation durch Quantencomputer sicher sind, könnte Bitcoin quantenresistent gemacht werden, indem Keypath-Spends deaktiviert und quantenresistente Signatur-OpCodes zu Tapscript hinzugefügt werden. Ein aktuelles Update zu BIP360 pay-to-quantum-resistant-hash, das Ethan Heilman veröffentlichte, schlägt einen neuen Ausgabentyp vor, der P2TR ähnelt aber die Möglichkeit des Keypath-Spend entfernt.

Releases und Release-Kandidaten

Neue Releases und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie, auf neue Versionen zu aktualisieren oder bei der Testung von Release-Kandidaten zu helfen.

Bedeutende Code- und Dokumentationsänderungen

Bedeutende aktuelle Ä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.

  • ● Bitcoin Core #29954 erweitert das getmempoolinfo-RPC um zwei neue Relay-Policy-Felder: permitbaremultisig (ob der Knoten bare Multisig-Outputs weiterleitet) und maxdatacarriersize (maximale Gesamtanzahl an Bytes in OP_RETURN-Outputs pro Transaktion im Mempool). Andere Policy-Flags wie fullrbf und minrelaytxfee waren bereits verfügbar, sodass diese Ergänzungen nun eine vollständige Übersicht der Relay-Policy ermöglichen.

  • ● Bitcoin Core #33004 aktiviert die Option -natpmp standardmäßig, wodurch automatische Portweiterleitung über das Port Control Protocol (PCP) mit Fallback auf das NAT Port Mapping Protocol (NAT-PMP) ermöglicht wird (siehe Newsletter #323). Ein empfangender Knoten hinter einem Router, der PCP oder NAT-PMP unterstützt, wird dadurch ohne manuelle Konfiguration erreichbar.

  • ● LDK #3246 ermöglicht die Erstellung von BOLT12-Angeboten und Rückerstattungen ohne Blinded Path, indem der signing_pubkey des Angebots als Ziel verwendet wird. Die Funktionen create_offer_builder und create_refund_builder delegieren die Erstellung des Blinded Paths nun an MessageRouter::create_blinded_paths. Ein Aufrufer kann so einen kompakten Pfad mit DefaultMessageRouter, einen vollständigen Pubkey-Pfad mit NodeIdMessageRouter oder gar keinen Pfad mit NullMessageRouter erzeugen.

  • ● LDK #3892 macht die Merkle-Tree-Signatur von BOLT12-Rechnungen öffentlich zugänglich. Dadurch können Entwickler CLI-Tools oder andere Software bauen, um die Signatur zu überprüfen oder Rechnungen zu rekonstruieren. Außerdem wird mit diesem PR ein OfferId-Feld zu BOLT12-Rechnungen hinzugefügt, um das ursprüngliche Angebot nachzuverfolgen.

  • ● LDK #3662 implementiert BLIPs #55, auch bekannt als LSPS05. Damit können Clients sich über einen Endpunkt für Webhooks registrieren, um Push-Benachrichtigungen von einem LSP zu erhalten. Die API stellt zusätzliche Endpunkte bereit, mit denen Clients alle Webhook-Registrierungen auflisten oder eine bestimmte entfernen können. Das ist nützlich, um z.B. beim Empfang einer asynchronen Zahlung benachrichtigt zu werden.