Der Newsletter dieser Woche beschreibt einen Vorschlag zur Beschleunigung des Initial Block Download (IBD) von Bitcoin Core, mit einer Proof-of-Concept-Implementierung, die etwa eine 5-fache Beschleunigung gegenüber den Standard-Einstellungen von Bitcoin Core zeigt. Ebenfalls enthalten sind unsere regulären Abschnitte mit einer Zusammenfassung eines Bitcoin Core PR Review Club Meetings, Ankündigungen neuer Releases und Release-Kandidaten sowie Beschreibungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur.

Nachrichten

  • ● SwiftSync-Beschleunigung für Initial Block Download: Sebastian Falbesoner veröffentlichte auf Delving Bitcoin eine Beispielimplementierung und Performance-Ergebnisse für SwiftSync, eine Idee, die von Ruben Somsen während eines kürzlichen Bitcoin Core Entwicklermeetings vorgeschlagen und später auf der Mailingliste gepostet wurde. Die aktuellsten Ergebnisse im Thread zeigen eine 5,28-fache Beschleunigung des Initial Block Downloads (IBD) gegenüber den Standard-IBD-Einstellungen von Bitcoin Core (die assumevalid aber nicht assumeUTXO verwenden), wodurch die anfängliche Synchronisationszeit von etwa 41 Stunden auf etwa 8 Stunden reduziert wird.

    Vor der Verwendung von SwiftSync erstellt jemand, der seinen Knoten bereits bis zu einem aktuellen Block synchronisiert hat, eine Hints-Datei, die angibt, welche Transaktionsausgänge im UTXO-Set zu diesem Block enthalten sein werden (d.h. welche Ausgänge unspent sind). Diese Datei kann für die aktuelle UTXO-Set-Größe effizient auf einige hundert Megabyte komprimiert werden. Die Datei gibt auch an, bei welchem Block sie generiert wurde, den wir als terminalen SwiftSync-Block bezeichnen.

    Der Nutzer, der SwiftSync durchführt, lädt die Hints-Datei herunter und verwendet sie beim Verarbeiten jedes Blocks vor dem terminalen SwiftSync-Block, um nur solche Outputs in der UTXO-Datenbank zu speichern, die laut Hints-Datei im UTXO-Set verbleiben werden, wenn der terminale SwiftSync-Block erreicht ist. Dadurch wird die Anzahl der Einträge, die während des IBD in die UTXO-Datenbank eingefügt und später wieder entfernt werden, massiv reduziert.

    Um sicherzustellen, dass die Hints-Datei korrekt ist, wird jeder erzeugte Output, der nicht in der UTXO-Datenbank gespeichert wird, zu einem kryptographischen Akkumulator hinzugefügt. Jeder ausgegebene Output wird aus dem Akkumulator entfernt. Wenn der Knoten den terminalen SwiftSync-Block erreicht, stellt er sicher, dass der Akkumulator leer ist, was bedeutet, dass jeder gesehene Output später ausgegeben wurde. Falls das nicht zutrifft, war die Hints-Datei fehlerhaft und der IBD muss ohne SwiftSync erneut durchgeführt werden. So müssen Nutzer dem Ersteller der Hints-Datei nicht vertrauen – eine bösartige Datei kann keinen falschen UTXO-Zustand erzeugen, sondern nur einige Stunden Rechenzeit verschwenden.

    Eine zusätzliche Eigenschaft von SwiftSync, die noch nicht implementiert ist, ist die parallele Validierung von Blöcken während des IBD. Dies ist möglich, weil assumevalid die Skripte älterer Blöcke nicht prüft, Einträge vor dem terminalen SwiftSync-Block nie aus der UTXO-Datenbank entfernt werden und der verwendete Akkumulator nur die Nettoeffekte von hinzugefügten (erzeugten) und entfernten (ausgegebenen) Outputs verfolgt. Dadurch entfallen Abhängigkeiten zwischen Blöcken vor dem terminalen SwiftSync-Block. Parallele Validierung während des IBD ist auch ein Feature von Utreexo aus ähnlichen Gründen.

    Die Diskussion beleuchtete mehrere Aspekte des Vorschlags. Falbesoners ursprüngliche Implementierung nutzte den MuHash-Akkumulator (siehe Newsletter #123), der als resistent gegen den generalisierten Geburtstagsangriff gilt. Somsen beschrieb einen alternativen Ansatz, der schneller sein könnte. Falbesoner zweifelte an der kryptographischen Sicherheit des alternativen Ansatzes, implementierte ihn aber dennoch aufgrund seiner Einfachheit und stellte fest, dass SwiftSync dadurch weiter beschleunigt wurde.

    James O’Beirne fragte, ob SwiftSync sinnvoll ist, da assumeUTXO eine noch größere Beschleunigung bietet. Somsen antwortete, dass SwiftSync die Hintergrundvalidierung von assumeUTXO beschleunigt und somit eine sinnvolle Ergänzung für assumeUTXO-Nutzer ist. Außerdem merkt er an, dass jeder, der die für assumeUTXO benötigten Daten (die UTXO-Datenbank zu einem bestimmten Block) herunterlädt, keine separate Hints-Datei benötigt, wenn er denselben Block als terminalen SwiftSync-Block verwendet.

    Vojtěch Strnad, 0xB10C und Somsen diskutierten die Komprimierung der Hints-Datei, mit einer erwarteten Einsparung von etwa 75 %, wodurch die Testdatei (für Block 850.900) auf etwa 88 MB schrumpft.

    Die Diskussion war zum Zeitpunkt des Schreibens noch im Gange.

Bitcoin Core PR Review Club

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

Add Fee rate Forecaster Manager ist ein PR von ismaelsadeeq, der die Logik zur Transaktionsgebühr-Vorhersage (auch Schätzung genannt) verbessert. Es führt eine neue ForecasterManager-Klasse ein, bei der mehrere Forecaster registriert werden können. Der bestehende CBlockPolicyEstimator (der nur bestätigte Transaktionen betrachtet) wird zu einem solchen Forecaster umgebaut, aber insbesondere wird ein neuer MemPoolForecaster eingeführt. MemPoolForecaster berücksichtigt unbestätigte Transaktionen im Mempool und kann daher schneller auf Änderungen der Feerate reagieren.

  • Warum heißt das neue System „Forecaster“ und „ForecasterManager“ statt „Estimator“ und „Fee Estimation Manager“?

    Das System zeigt an, was in Zukunft passieren wird. Dafür benutzt es aktuelle und vergangene Daten. Ein Forecaster ist anders als ein Estimator. Ein Forecaster zeigt zukünftige Ereignisse an. Das ist die prädiktive Natur dieses Systems. Und es zeigt Unsicherheits-/Risikolevels an. Im Gegensatz zu einem Estimator, der aktuelle Bedingungen mit Zufall approximiert, projiziert ein Forecaster zukünftige Ereignisse, was der prädiktiven Natur dieses Systems und seiner Ausgabe von Unsicherheits-/Risikolevels entspricht. ➚

  • Warum wird CBlockPolicyEstimator nicht so geändert, dass er eine Referenz auf den Mempool hält, ähnlich wie in PR #12966? Was ist der aktuelle Ansatz und warum ist er besser als eine Referenz auf den Mempool zu halten? (Hinweis: siehe PR #28368)

    CBlockPolicyEstimator erbt von CValidationInterface und implementiert dessen virtuelle Methoden TransactionAddedToMempool, TransactionRemovedFromMempool und MempoolTransactionsRemovedForBlock. Das gibt CBlockPolicyEstimator alle nötigen Mempool-Informationen, ohne unnötig eng an den Mempool gekoppelt zu sein. ➚

  • Was sind die Vor- und Nachteile der neuen Architektur im Vergleich zu einer direkten Änderung von CBlockPolicyEstimator?

    Die neue Architektur mit einer FeeRateForecasterManager-Klasse, bei der mehrere Forecaster registriert werden können, ist modularer, besser testbar und erzwingt eine bessere Trennung der Verantwortlichkeiten. Sie ermöglicht es, später einfach neue Vorhersagestrategien einzubinden. Das geht auf Kosten von etwas mehr Code und potenziell verwirrten Nutzern bezüglich der zu verwendenden Schätzmethode. ➚

Veröffentlichungen und Release-Kandidaten

Neue Veröffentlichungen und Release-Kandidaten für beliebte Bitcoin-Infrastrukturprojekte. Bitte erwägen Sie ein Upgrade auf neue Versionen oder helfen Sie bei der Testung von Release-Kandidaten.

  • ● Core Lightning 25.02.1 ist ein Wartungsrelease für die aktuelle Hauptversion dieses beliebten LN-Knotens, das mehrere Fehlerbehebungen enthält.

  • ● Core Lightning 24.11.2 ist ein Wartungsrelease für eine frühere Hauptversion dieses beliebten LN-Knotens. Es enthält mehrere Fehlerbehebungen, einige davon sind die gleichen wie in Version 25.02.1.

  • ● BTCPay Server 2.1.0 ist ein Major Release dieser selbstgehosteten Zahlungsabwicklungssoftware. Es enthält Breaking Changes für Nutzer einiger Altcoins, Verbesserungen für RBF und CPFP Fee-Bumping sowie einen besseren Ablauf für Multisig, wenn alle Signierer BTCPay Server verwenden.

  • ● Bitcoin Core 29.0rc3 ist ein Release-Kandidat für die nächste Hauptversion des dominierenden Full Nodes im Netzwerk. Siehe den Version 29 Testleitfaden.

  • ● LND 0.19.0-beta.rc2 ist ein Release-Kandidat für diesen beliebten LN-Knoten. Eine der wichtigsten Verbesserungen, die getestet werden sollten, ist das neue RBF-basierte Fee-Bumping für kooperative Schließungen.

Wichtige Code- und Dokumentationsänderungen

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

  • ● LDK #2256 und LDK #3709 verbessern die Zuordenbarkeit von Fehlern (siehe Newsletter #224), wie in BOLTs #1044 spezifiziert, indem sie ein optionales attribution_data-Feld zur UpdateFailHTLC-Struktur und die AttributionData-Struktur einführen. In diesem Protokoll fügt jeder weiterleitende Knoten der Fehlermeldung ein hop_payload-Flag, ein Dauerfeld (wie lange der Knoten das HTLC gehalten hat) und HMACs für verschiedene angenommene Positionen in der Route hinzu. Wenn ein Knoten die Fehlermeldung beschädigt, hilft die Abweichung in der HMAC-Kette, das Knoten-Paar zu identifizieren, zwischen dem dies geschah.

  • ● LND #9669 stuft Simple Taproot Channels so zurück, dass immer der Legacy-Cooperative-Close-Flow verwendet wird, auch wenn der RBF Cooperative-Close-Flow (siehe Newsletter #347) konfiguriert ist. Zuvor konnte ein Knoten, bei dem beide Features konfiguriert waren, nicht starten.

  • ● Rust Bitcoin #4302 fügt der Script-Builder-API eine neue Methode push_relative_lock_time() hinzu, die einen relativen Timelock als Parameter nimmt, und depreziert push_sequence(), die eine rohe Sequenznummer als Parameter nimmt. Diese Änderung behebt eine potenzielle Verwirrung, bei der Entwickler versehentlich eine rohe Sequenznummer in Skripte einfügen, anstatt eines relativen Timelock-Wertes, der dann mit CHECKSEQUENCEVERIFY gegen die Sequenznummer eines Inputs geprüft wird.