Bitcoin Core 32: Schnellere Validierung und Änderungen bei den Gebühren

Bitcoin Core 32.0 ist in seine letzte Release-Candidate-Testphase eingetreten, nachdem Entwickler am 14. September v32.0rc1 getaggt haben, wodurch Gebührenschätzung, Blockvalidierungsleistung und Sicherheitskorrekturen einem geplanten Release am 10. Oktober näher kommen.

Die offizielle GitHub-Veröffentlichung des Bitcoin-Core-Projekts zeigt v32.0rc1 bei Commit d0231bb, signiert mit einer verifizierten Maintainer-Signatur am 14. September um 12:58 UTC. Der Veröffentlichungsplan des Projekts sieht weiterhin den 10. Oktober für das endgültige v32.0-Tag vor, obwohl das Datum weiterhin von Tests und weiteren Korrekturen abhängt.

Version 32 konzentriert sich auf das Verhalten der Node-Software, Wallet-Schnittstellen, Gebührenberechnung, Netzwerk und Leistung. Die Entwurfsversionshinweise listen keine Änderung an Bitcoins Konsensregeln auf, was bedeutet, dass das Update nicht neu definiert, welche Transaktionen oder Blöcke das Netzwerk als gültig betrachtet.

Bitcoin Core 32 zielt nach RC1-Tag auf den 10. Oktober

Entwickler traten am 20. August in den Feature-Freeze ein und beschränkten die Arbeit auf Korrekturen, die vor der Veröffentlichung erforderlich sind. Am 14. September spalteten sie den 32.x-Zweig vom Hauptentwicklungszweig ab und starteten den Release-Candidate-Zyklus, während die Entwicklungsarbeit für Version 33 separat wieder aufgenommen wurde.

Der erste Kandidat ist für Node-Betreiber, Wallet-Entwickler und andere Benutzer gedacht, um ihn zu testen, bevor Entwickler entscheiden, ob der Code für eine stabile Veröffentlichung bereit ist. Bitcoin Core eröffnete am 15. September, einen Tag nach dem Tagging von RC1, ein dediziertes Feedback-Problem zum Test des 32.0-Release-Candidates.

Das Projekt bittet Tester, den Testleitfaden für RC-spezifische Überprüfungen zu verwenden und Softwareprobleme über separate GitHub-Probleme zu melden. Bis zum 16. September wurde keine endgültige v32.0-Binärdatei veröffentlicht.

Bitcoin Core aktualisiert sich nicht automatisch. Betreiber entscheiden, wann sie neue Versionen installieren, was bedeutet, dass ältere Releases aktiv bleiben können, nachdem neuere Software verfügbar wird.

Dieses manuelle Upgrade-Modell war bei früheren Sicherheitsoffenlegungen von Bedeutung. Wie crypto.news zuvor berichtete, offenbarte Bitcoin Core im Mai CVE-2024-52911, nachdem der anfällige 28.x-Zweig das Ende seiner Lebensdauer erreicht hatte. Der Fehler war bereits in Bitcoin Core 29.0 behoben worden, bevor technische Details öffentlich wurden.

Neuer Gebührenschätzer kombiniert Mempool und Blockhistorie

Eine der sichtbareren benutzerorientierten Änderungen von Bitcoin Core 32 betrifft estimatesmartfee, das RPC, das von Wallets und Anwendungen zur Berechnung von Transaktionsgebühren verwendet wird.

Bisher hat sich der Hauptschätzer von Bitcoin Core auf beobachtetes Bestätigungsverhalten von Transaktionen in vergangenen Blöcken verlassen. Version 32 fügt einen separaten Schätzer hinzu, der auf Transaktionen basiert, die derzeit im Mempool des Nodes warten.

Der neue Mempool-Schätzer erzeugt sowohl sparsame als auch konservative Schätzungen aus den aktuellen Bedingungen der ausstehenden Transaktionen. Bitcoin Core prüft die jüngste Blockaktivität, bevor er ihn verwendet, und kann die Schätzung ablehnen, wenn der Mempool zu dünn besetzt oder ungesund erscheint.

Wenn beide Systeme gültige Ergebnisse liefern, gibt estimatesmartfee die niedrigere Gebührenschätzung zurück. Die neue Methode kann die bestehende Block-Policy-Empfehlung im kombinierten Standardmodus daher nicht nach oben treiben; ihre Rolle besteht darin, die Empfehlung zu senken, wenn die aktuellen Mempool-Bedingungen dies unterstützen.

Dieses Design kann schneller reagieren, nachdem eine Phase teuren Blockspeicherplatzes endet. Ein Block-Historien-Schätzer kann weiterhin kürzlich bestätigte Transaktionen mit hohen Gebühren einbeziehen, während der Mempool bereits weniger Transaktionen anzeigen kann, die um eine Bestätigung konkurrieren.

Die Software bewahrt eine Möglichkeit für Anwendungen, die vorherige Methode zu verwenden. Eine hinzugefügte Option fee_rate_estimator ermöglicht es Benutzern, block_policy, mempool_policy oder das kombinierte Standardverhalten anzufordern. Bitcoin Core speichert die Statistiken des neuen Mempool-Schätzers in einer separaten Datendatei, damit sie nach einem Neustart neu geladen werden können.

Wallet-Gebührenberechnungen verwenden den kombinierten Standard-Schätzer. Die Antwort kann angeben, welcher Schätzer die ausgewählte Gebühr erzeugt hat, während höhere Ausführlichkeitsstufen Mempool-Gesundheitsstatistiken für Anwendungen offenlegen, die mehr Details benötigen.

Blockvalidierung erhält paralleles Disk-Prefetching

Bitcoin Core 32 ändert, wie Knoten Transaktionsdaten abrufen, während sie Blöcke verbinden, insbesondere wenn die benötigten Informationen aus dem Speicher gelesen werden müssen.

Die Software kann nun frühere Transaktionsausgaben, bekannt als Prevouts, aus der Chainstate-Datenbank über mehrere Worker-Threads vorab laden, während die Blockvalidierung weiterläuft. Der Standard sind acht Prefetch-Threads, wobei Betreiber die Einstellung auf 16 erhöhen oder das parallele Abrufen deaktivieren können, indem sie sie auf null setzen.

Prevouts identifizieren die Coins, die von Transaktionseingaben ausgegeben werden. Knoten benötigen diese Informationen, um zu prüfen, ob Eingaben existieren, noch nicht ausgegeben wurden und die geltenden Validierungsregeln erfüllen.

Die Verbesserung soll die Zeit verkürzen, die mit dem Warten auf Festplattenlesevorgänge verbracht wird, wenn ein Knoten Blöcke verarbeitet, die Eingaben enthalten, die noch nicht in schnelleren Speicher-Caches verfügbar sind. Der Effekt wird je nach Speicherhardware, Cache-Verhalten und Knotenkonfiguration variieren.

Bitcoin Core 32 legt die Einstellung über -prevoutfetchthreads=<n> offen und gibt Betreibern Kontrolle darüber, wie viele Threads teilnehmen. Die Entwurfsnotizen beschreiben die Funktion speziell als eine Leistungsverbesserung der Blockvalidierung.

Separate RPC-Änderungen geben Betreibern mehr Informationen während der AssumeUTXO-Hintergrundvalidierung. Nachdem ein snapshot-basierter Knoten die Chain-Spitze erreicht hat, kann getblockchaininfo nun den Fortschritt der historischen Chain-Validierung melden, die noch hinter dem aktiven Knotenzustand läuft.

Sicherheitsfixes schließen Wallet- und HTTP-Speicherfehler

Bitcoin Core 32 behebt einen Wallet-Benachrichtigungsfehler, der Nicht-Windows-Systeme unter einer engen Reihe von Bedingungen betrifft.

Die Entwurfsnotizen geben an, dass ein authentifizierter RPC-Benutzer mit der Berechtigung, Wallets zu erstellen, einen Wallet-Namen mit speziellen Ersatzzeichen erstellen könnte, wenn der Knoten mit -walletnotify konfiguriert war. Unter diesen Bedingungen könnte der Name die Ausführung beliebiger Befehle mit den Privilegien des Bitcoin-Core-Prozesses verursachen.

Version 32 ändert die Ersetzung von Platzhaltern in Wallet-Benachrichtigungen, sodass Wallet-Namen als wörtlicher Text behandelt werden. Das Release verschärft auch die Wallet-Benennung, indem bestimmte relative Pfadnamen mit .- oder ..-Pfadelementen abgelehnt werden.

Ein zweites Problem trat während der Überprüfung des neu geschriebenen HTTP-Servers von Bitcoin Core auf, der in Version 32 libevent ersetzt.

Der Entwickler Matthew Zipkin reichte Pull Request #36123 ein, nachdem ein Audit unter Verwendung von Moonshot AIs Kimi K3-Modell einen Pfad zur Speichererschöpfung identifiziert hatte. Während der Server eine Anfrage bearbeitete, konnte er weiterhin Daten lesen und in die Warteschlange stellen, die von derselben Verbindung gesendet wurden, ohne wirksame Größenbeschränkung.

Die erste Analyse legte nahe, dass die Bedingung hauptsächlich einen authentifizierten Client erforderte, der eine Anfrage beschäftigt halten konnte. Weitere Tests ergaben, dass REST-Verkehr ein ähnliches Problem ohne Authentifizierung verursachte.

Ein Prüfer berichtete, dass 16 nicht authentifizierte REST-Verbindungen einen Testprozess in etwa einer Minute von 46 MB Speicher auf ungefähr 3 GB trieben. Nach dem überarbeiteten Fix erhöhte derselbe Test die Speichernutzung um ungefähr 3 MB über 90 Sekunden, verglichen mit 3,2 GB vor dem Patch.

Der Patch wurde am 5. September zusammengeführt, bevor v32.0rc1 getaggt wurde. Da der neu geschriebene HTTP-Server neu in Version 32 ist, wurde der spezifische Fehler erkannt, bevor der Server in einer stabilen Bitcoin-Core-Version erschien.

Die Verwendung von Kimi K3 passt zu einem jüngsten Muster KI-gestützter Sicherheitsüberprüfungen in Bitcoin-Software. Wie crypto.news im August berichtete, hatte das Bitcoin Red Team nach dem Scannen von Hunderten Bitcoin-bezogener Open-Source-Projekte 7.958 potenzielle Befunde protokolliert, obwohl viele eine menschliche Überprüfung erforderten, bevor sie als bestätigte Schwachstellen behandelt werden konnten.

Probleme mit der Ressourcenerschöpfung sind in diesem Jahr in anderer Bitcoin-Software aufgetreten. In verwandter Berichterstattung berichtete crypto.news, dass Core Lightning Sicherheitsmängel bestätigte, nachdem KI-generierte Berichte überprüft wurden, und Betreiber warnte, ein Upgrade durchzuführen oder vorübergehend den Offline-Modus zu verwenden.

PSBT Version 2 wird zum Standard für vier RPCs

Bitcoin Core 32 ändert das Standardformat, das von vier Befehlen erstellt wird, die mit teilweise signierten Bitcoin-Transaktionen verwendet werden.

createpsbt, walletcreatepsbt, converttopsbt und psbtbumpfee erzeugen standardmäßig PSBT Version 2. Entwickler fügten ein optionales Argument psbt_version hinzu, damit Anwendungen bei Bedarf explizit eine andere unterstützte Version anfordern können.

PSBTs ermöglichen es mehreren Wallets, Anwendungen oder Hardware-Signaturgeräten, Transaktionsinformationen auszutauschen, bevor die fertiggestellte Bitcoin-Transaktion gesendet wird. Die Umstellung des Standards auf Version 2 kann Tests durch Software erfordern, die davon ausgeht, dass die RPC-Ausgabe von Core das ältere Format verwendet.

Das Update entfernt nicht die Möglichkeit, die vorherige Version anzufordern. Anwendungen, die um die betroffenen RPC-Befehle herum entwickelt wurden, können das Format explizit festlegen, während sie die Kompatibilität mit Version 2 testen.

Wallet-Tooling erhält in derselben Version weitere Änderungen. Ein neuer RPC exportwatchonlywallet erstellt eine Deskriptor-Wallet-Datei, die öffentliche Deskriptoren, Transaktionsverlauf und Adressbuchdaten ohne private Schlüssel enthält. Das Offline-Signierungs-Tutorial von Bitcoin Core verwendet nun diesen Befehl zum Erstellen einer Online-Watch-Only-Wallet.

Ein weiterer neuer Befehl, derivehdkey, ermöglicht es einer Wallet, einen erweiterten öffentlichen oder privaten Schlüssel über einen Pfad abzuleiten, der mindestens einen gehärteten Schritt enthält, während addhdkey es ermöglicht, einen BIP32-erweiterten Schlüssel hinzuzufügen, ohne ihn sofort zur Generierung von Ausgabeskripten zu verwenden.

PrivateBroadcast erhält ebenfalls fortlaufende Wartung. Crypto.news berichtete im Juni, dass Bitcoin Core 31.1rc1 eine Netzwerkbedingung behob, die eine ursprüngliche IP-Adresse offenlegen konnte, wenn PrivateBroadcast verwendet wurde. Version 32 enthält weitere PrivateBroadcast-RPC- und Transaktionsrelais-Änderungen, die in den Entwurfsversionshinweisen dokumentiert sind.

Der aktuelle Bitcoin-Core-Zeitplan listet weiterhin den 10. Oktober als Ziel für das Tagging von v32.0 auf. Der am 15. September eröffnete RC-Testfeedback-Thread bleibt aktiv, wobei Entwickler Tester, die tatsächliche Defekte in Bitcoin Core finden, anweisen, vor der endgültigen Veröffentlichung separate Issues einzureichen.