Der Newsletter dieser Woche enthält eine Analyse zum Synchronisieren von Full Nodes ohne alte Witness-Daten. Ebenfalls enthalten sind unsere regulären Abschnitte mit Beschreibungen von Diskussionen zu Konsensänderungen, Ankündigungen neuer Releases und Release-Kandidaten sowie Zusammenfassungen wichtiger Änderungen an populärer Bitcoin-Infrastruktur.

Nachrichten

  • ● Synchronisation von Full Nodes ohne Witness-Daten: Jose SK veröffentlichte auf Delving Bitcoin eine Zusammenfassung einer Analyse, in der er die Sicherheitsabwägungen untersucht, wenn neu gestartete Full Nodes mit einer bestimmten Konfiguration auf das Herunterladen einiger historischer Blockchain-Daten verzichten. Standardmäßig verwenden Bitcoin-Core-Knoten die assumevalid-Konfiguration. Diese überspringt die Validierung von Scripts in Blöcken, die mehr als ein oder zwei Monate vor der aktuell ausgeführten Version von Bitcoin Core erstellt wurden. Viele Nutzer aktivieren außerdem die prune-Option, die Blöcke nach der Validierung nach einer gewissen Zeit löscht. Wie lange Blöcke aufbewahrt werden, hängt von der Blockgröße und der gewählten Einstellung ab.

    SK argumentiert, dass Witness-Daten, die nur zur Script-Validierung benötigt werden, von geprunten Knoten für assumevalid-Blöcke nicht heruntergeladen werden sollten, da sie nicht zur Script-Validierung genutzt und später ohnehin gelöscht werden. Das Überspringen des Witness-Downloads „kann den Bandbreitenverbrauch um über 40 % reduzieren“, schreibt er.

    Ruben Somsen argumentiert, dass dies das Sicherheitsmodell in gewissem Maße verändert. Auch wenn Scripts nicht validiert werden, wird die heruntergeladene Datenmenge gegen das Commitment vom Blockheader-Merkel-Root zur Coinbase-Transaktion bis zu den Witness-Daten geprüft. Das stellt sicher, dass die Daten zum Zeitpunkt der ersten Synchronisation verfügbar und unverfälscht waren. Wenn jedoch niemand regelmäßig die Existenz dieser Daten prüft, könnten sie verloren gehen – wie es bei mindestens einem Altcoin bereits passiert ist.

    Die Diskussion war zum Zeitpunkt des Schreibens noch im Gange.

Änderungen am Konsens

Ein monatlicher Abschnitt mit Zusammenfassungen von Vorschlägen und Diskussionen zu Änderungen der Bitcoin-Konsensregeln.

  • ● Bericht zu Quantencomputing: Clara Shikhelman veröffentlichte auf Delving Bitcoin die Zusammenfassung eines Berichts, den sie gemeinsam mit Anthony Milton verfasst hat. Darin geht es um Risiken für Bitcoin-Nutzer durch schnelle Quantencomputer, einen Überblick über verschiedene Wege zur Quantenresistenz und eine Analyse der Abwägungen bei einer Protokollumstellung. Die Autoren schätzen, dass 4 bis 10 Millionen BTC potenziell durch Quantenangriffe gefährdet sind, einige Maßnahmen bereits jetzt möglich sind, Bitcoin-Mining kurzfristig und mittelfristig aber nicht bedroht ist und ein Upgrade breite Zustimmung erfordert.

  • ● Transaktionsgewicht-Limit mit Ausnahme zur Vermeidung von Konfiskation: Vojtěch Strnad schlug auf Delving Bitcoin eine Konsensänderung vor, die das maximale Gewicht der meisten Transaktionen in einem Block begrenzt. Die einfache Regel: Nur wenn eine Transaktion (außer der Coinbase) die einzige im Block ist, darf sie größer als 400.000 Weight Units (100.000 vbytes) sein. Strnad und andere nannten folgende Gründe für diese Begrenzung:

    • Einfachere Blocktemplate-Optimierung: Je kleiner die einzelnen Transaktionen im Vergleich zum Gesamtlimit sind, desto leichter lässt sich eine nahezu optimale Lösung für das Knapsack-Problem finden. Dadurch bleibt weniger Platz ungenutzt.

    • Einfachere Relay-Policy: Die Policy für das Weiterleiten unbestätigter Transaktionen zwischen Knoten sagt vorher, welche Transaktionen gemined werden. Sehr große Transaktionen erschweren diese Vorhersage, da schon kleine Änderungen an der Top-Feerate zu Verzögerungen oder zum Entfernen führen können.

    • Vermeidung von Mining-Zentralisierung: Wenn relayende Full Nodes fast alle Transaktionen weiterleiten können, müssen Nutzer spezieller Transaktionen keine Out-of-Band-Fees zahlen, was Mining-Zentralisierung verhindern hilft.

    Gregory Sanders merkte an, dass es auch sinnvoll sein könnte, einfach per Soft Fork ein maximales Gewichtslimit ohne Ausnahmen einzuführen, da Bitcoin Core seit 12 Jahren eine konsistente Relay-Policy hat. Gregory Maxwell fügte hinzu, dass Transaktionen, die nur UTXOs ausgeben, die vor dem Soft Fork entstanden sind, eine Ausnahme erhalten könnten, um Konfiskation zu verhindern. Ein transitorischer Soft Fork könnte die Einschränkung zudem automatisch auslaufen lassen, falls die Community sie nicht verlängern möchte.

    Weitere Diskussionen befassten sich mit den Bedürfnissen von Nutzern großer Transaktionen, insbesondere BitVM, und möglichen Alternativen.

  • ● Entfernen von Outputs aus dem UTXO-Set basierend auf Wert und Zeit: Robin Linus schlug auf Delving Bitcoin einen Soft Fork vor, um Outputs mit geringem Wert nach einer gewissen Zeit aus dem UTXO-Set zu entfernen. Diskutiert wurden zwei Hauptvarianten:

    • Alte, unwirtschaftliche Funds zerstören: Kleine Outputs, die lange nicht ausgegeben wurden, werden unspendable.

    • Alte, unwirtschaftliche Funds nur mit Existenzbeweis ausgeben: utreexo oder ein ähnliches System könnte genutzt werden, damit Transaktionen beweisen können, dass die ausgegebenen Outputs Teil des UTXO-Sets sind. Alte und unwirtschaftliche Outputs müssten diesen Beweis liefern, neuere und höherwertige Outputs würden weiterhin im UTXO-Set gespeichert.

    Beide Lösungen würden die maximale Größe des UTXO-Sets effektiv begrenzen (bei Mindestwert und 21 Millionen Bitcoin). Es wurden verschiedene technische Aspekte und Alternativen zu utreexo-Proofs für diesen Anwendungsfall diskutiert.

Releases und Release-Kandidaten

Neue Releases und Release-Kandidaten für populäre Bitcoin-Infrastrukturprojekte. Bitte erwäge, auf neue Releases zu aktualisieren oder Release-Kandidaten zu testen.

  • ● Core Lightning 25.05rc1 ist ein Release-Kandidat für die nächste Hauptversion dieser beliebten LN-Knoten-Implementierung.

  • ● LND 0.19.1-beta.rc1 ist ein Release-Kandidat für eine Wartungsversion dieser beliebten LN-Knoten-Implementierung.

Wichtige Code- und Dokumentationsänderungen

Bemerkenswerte 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 #32582 fügt neues Logging hinzu, um die Performance der Compact-Block-Rekonstruktion zu messen: Es werden die Gesamtgröße der von Peers angeforderten Transaktionen (getblocktxn), die Anzahl und Gesamtgröße der an Peers gesendeten Transaktionen (blocktxn) sowie ein Timestamp am Start von PartiallyDownloadedBlock::InitData() geloggt, um die Dauer des Mempool-Lookups zu messen (sowohl im High- als auch im Low-Bandwidth-Modus). Siehe Newsletter #315 für einen früheren Statistikbericht zur Compact-Block-Rekonstruktion.

  • ● Bitcoin Core #31375 fügt ein neues CLI-Tool bitcoin -m hinzu, das die Multiprozess-Binaries bitcoin node (bitcoind), bitcoin gui (bitcoinqt), bitcoin rpc (bitcoin-cli -named) kapselt und ausführt. Aktuell funktionieren diese wie die monolithischen Binaries, unterstützen aber die Option -ipcbind (siehe Newsletter #320). Zukünftige Verbesserungen werden es ermöglichen, Knoten-Komponenten unabhängig auf verschiedenen Maschinen und Umgebungen zu starten und zu stoppen. Siehe Newsletter #353 für einen Bitcoin Core PR Review Club zu diesem PR.

  • ● BIPs #1483 merged BIP77, das Payjoin v2 vorschlägt – eine asynchrone, serverlose Variante, bei der Sender und Empfänger ihre verschlüsselten PSBTs an einen Payjoin-Directory-Server übergeben, der nur Nachrichten speichert und weiterleitet. Da das Directory die Payloads weder lesen noch verändern kann, muss keine Wallet einen öffentlichen Server betreiben oder gleichzeitig online sein. Siehe Newsletter #264 für weitere Informationen zu Payjoin v2.