Bitcoin Optech #154: Universelle Transaktions-RBF und Taproot

Besuchen Sie den Originalartikel*

http://bitcoinmagazine.com/.image/c_limit,cs_srgb,fl_progressive,h_1200,q_auto:good,w_1200/MTc5Mjk3NzgyODU1NTc1MTkx/bitcoin-optech-bridges-gap-for-development.jpg

Der Newsletter dieser Woche behandelt den universellen Transaktionsersatz durch Gebühr und enthält den ersten Beitrag einer Taproot-Vorbereitungsserie.

Der Bitcoin Optech-Newsletter bietet den Lesern eine Zusammenfassung der wichtigsten technischen Neuigkeiten rund um Bitcoin sowie Ressourcen, die ihnen helfen, mehr zu erfahren. Um unseren Lesern zu helfen, über Bitcoin auf dem Laufenden zu bleiben, veröffentlichen wir unten die neueste Ausgabe dieses Newsletters. Denken Sie daran, sich zu abonnieren, um diesen Inhalt direkt in Ihren Posteingang zu erhalten.

Der Newsletter dieser Woche beschreibt einen Vorschlag, um einen universellen Transaktionsersatz durch Gebühr zu ermöglichen, und enthält den ersten Beitrag einer neuen wöchentlichen Serie über die Vorbereitung auf Taproot. Ebenfalls enthalten sind unsere regelmäßigen Abschnitte, in denen Updates für Kunden und Dienste, neue Versionen und Release-Kandidaten sowie bemerkenswerte Änderungen an beliebten Bitcoin-Infrastrukturprojekten beschrieben werden.

Nachrichten

• Ermöglichen des standardmäßigen Ersetzens von Transaktionen: Es wird angenommen, dass fast alle Bitcoin-Full-Nodes heute das BIP125-Opt-In-Replace By Fee (RBF) implementieren, das es ermöglicht, unbestätigte Transaktionen in Node-Mempools durch alternative Versionen zu ersetzen, die höhere Gebühren zahlen – aber nur, wenn der Ersteller der Transaktion setzt ein Signal in der ursprünglichen Transaktion. Dieses Opt-in-Verhalten wurde als Kompromiss zwischen Personen vorgeschlagen, die den Transaktionsersatz zulassen wollten, z. B. für Gebührenerhöhungen oder zusätzliche Zahlungsstapel, und Personen, die Einwände erhoben haben, weil die Ersetzung der Erstellung von Tools vereinfacht, die Händler betrügen, die unbestätigte Transaktionen als endgültig akzeptieren.
  Mehr als fünf Jahre später scheint es, dass heute nur noch sehr wenige Händler unbestätigte Transaktionen als endgültig akzeptieren, und es ist nicht klar, wie viele von ihnen tatsächlich auf das BIP125-Opt-in-Signal prüfen und diese Transaktionen anders behandeln. Wenn sich niemand auf BIP125-Signale verlässt, kann die Ersetzbarkeit jeder Transaktion einige Vorteile bieten, wie zum Beispiel:
• Vereinfachte Analyse für vorsignierte Transaktionsprotokolle (wie LN und Tresore), bei denen Ideen zur Verwendung von RBF-Gebührenerhöhungen die Fähigkeit einer böswilligen Gegenpartei berücksichtigen müssen, das Setzen des BIP125-Signals zu verhindern. Wenn jede Transaktion ersetzt werden könnte, wäre dies kein Problem.
• Reduzierung der Transaktionsanalysemöglichkeiten, da Transaktionen, die sich für RBF entscheiden, onchain anders aussehen als Transaktionen, die dies nicht tun. Da sich die meisten Wallets konsequent dafür entscheiden oder nicht, liefert dies Beweise dafür, dass Überwachungsunternehmen bei ihren Versuchen feststellen können, wer welche Bitcoins besitzt. Wenn jede Transaktion ersetzbar wäre, müsste das BIP125-Signal nicht gesetzt werden.
• Diese Woche hat Antoine Riard einen Vorschlag an die Bitcoin-Dev-Mailingliste gepostet, den Code von Bitcoin Core schließlich zu ändern, um RBF für alle Transaktionen zuzulassen, unabhängig davon, ob sie das BIP125-Opt-in-Signal gesetzt haben oder nicht. Die Idee wurde auch im ersten Transaktions-Relais-Workshop-Meeting diskutiert. Mehrere Sitzungsteilnehmer erwähnten Bitcoin Core PR #10823 als alternativen Ansatz – er ermöglicht das Ersetzen jeder Transaktion, jedoch erst nachdem die Transaktion eine bestimmte Zeit in einem Node-Mempool verbracht hatte (ursprünglich als 6 Stunden vorgeschlagen; später als 72 vorgeschlagen) Std).
  Sowohl die E-Mail von Riard als auch die Besprechungsteilnehmer weisen darauf hin, dass jeder Vorschlag zum Ersetzen von Transaktionen, die kein BIP125-Opt-in-Signal enthalten, Feedback von Händlern erfordert, die derzeit vom Verhalten von BIP125 abhängen. Optech ermutigt solche Händler, auf den Mailinglisten-Thread zu antworten.

Änderungen an Diensten und Client-Software

In diesem monatlichen Feature stellen wir interessante Updates zu Bitcoin-Wallets und -Diensten vor.

Vorbereitung für taproot #1: bech32-Sendeunterstützung

Der erste Abschnitt einer wöchentlichen Serie darüber, wie sich Entwickler und Dienstleister auf die bevorstehende Aktivierung von taproot auf Blockhöhe 709.632 vorbereiten können.

Ab Block 709.632, der im November erwartet wird, können Bitcoin-Benutzer sicher Zahlungen an Taproot-Adressen empfangen. Angesichts der Begeisterung der Benutzer für Taproot und der fünf Monate, die Wallet-Entwickler für die Implementierung der Unterstützung benötigen, erwartet Optech, dass es mehrere beliebte Wallets geben wird, die es ihren Benutzern ermöglichen, zum frühestmöglichen Zeitpunkt Taproot-Adressen zu generieren.

Das bedeutet, dass jede andere Brieftasche oder jeder andere Dienst, der Bitcoins an vom Benutzer bereitgestellte Adressen sendet, in der Lage sein muss, bis zum Block 709.632 an Taproot-Adressen zu senden, oder riskiert, seine Benutzer zu verwirren und zu enttäuschen. Pay to TapRoot (P2TR)-Adressen verwenden bech32m wie in BIP350 angegeben, was sich geringfügig vom bech32-Algorithmus von BIP173 unterscheidet, der für segwit v0 P2WPKH- und P2WSH-Adressen verwendet wird. Bech32m verwendet die Konstante 0x2bc830a3 anstelle von bech32s 0x01 in der Prüfsummenfunktion.

Das Ändern dieser einzelnen Konstante bietet die Möglichkeit, bech32m-Prüfsummen zu überprüfen, aber der Code muss weiterhin die ursprüngliche Konstante für vorhandene P2WPKH- und P2WSH-Adressen verwenden. Der Code muss die Adresse decodieren, ohne die Prüfsumme zu überprüfen, bestimmen, ob er v0 segwit (bech32) oder v1+ segwit (bech32m) verwendet, und dann die Prüfsumme mit der entsprechenden Konstante validieren. Beispiele finden Sie in der PR, die die bech32-Referenzimplementierungen für C, C++, JS und Python aktualisiert hat. Wenn der Code bereits die Referenzbibliotheken verwendet, können sie auf den neuesten Code aus diesem Repository aktualisiert werden. Beachten Sie jedoch, dass einige der APIs geringfügige Änderungen aufweisen. BIP350 und die Referenzimplementierungen stellen Testvektoren bereit, die alle bech32m-Implementierungen verwenden sollten.

Obwohl Empfang Zahlungen an Taproot-Adressen sind bis Block 709.632 nicht sicher. senden Zahlungen sollten dem Absender keine Probleme bereiten. Bitcoin Core unterstützt seit Version 0.19 (veröffentlicht im November 2019) Relaying- und Mining-Transaktionen mit Taproot-Paying-Outputs. Optech ermutigt Entwickler von Wallets und Diensten, die Unterstützung für die Zahlung von bech32m-Taproot-Adressen jetzt zu implementieren, anstatt zu warten, bis taproot aktiviert wurde.

Releases und Release-Kandidaten

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

• LND 0.13.0-beta ist eine neue Hauptversion, die das Gebührenmanagement verbessert, indem Ankerausgaben zum Standardformat für Commitment-Transaktionen gemacht werden, die Unterstützung für die Verwendung eines beschnittenen Bitcoin-Vollknotens hinzugefügt, das Empfangen und Senden von Zahlungen mit Atomic MultiPath (AMP) ermöglicht und die LNDs . erhöht PSBT-Funktionen, neben vielen anderen Verbesserungen und Fehlerbehebungen.

Bemerkenswerte Code- und Dokumentationsänderungen

Bemerkenswerte Änderungen diese Woche in Bitcoin-Kern, C-Blitz, Eclair, LND, Rost-Blitz, libsecp256k1, Hardware-Wallet-Schnittstelle (HWI), Rost Bitcoin, BTCPay-Server, Verbesserungsvorschläge für Bitcoin (BIPs), und Blitzbolzen.

• Bitcoin Core #21365 fügt der Wallet die Möglichkeit hinzu, Signaturen für Taproot-Ausgaben zu erstellen – sowohl Keypath-Ausgaben nur mit dem öffentlichen P2TR-Schlüssel als auch scriptpath-Ausgaben mit Tapscript. Das Wallet kann auch für Taproot-Ausgaben von PSBTs signieren, jedoch nur, wenn das Wallet bereits alle benötigten Schlüsselpfad- oder Skriptpfadinformationen enthält. Die etwas verwandte zusammengeführte PR #22156 erlaubt nur das Importieren dieser Schlüsselpfad- und Skriptpfadinformationen, nachdem Taproot aktiv ist (Block 709,632 im Mainnet, aber in Testnetzwerken, in denen Taproot bereits aktiviert ist, kann das Importieren jetzt verwendet werden).
• Bitcoin Core #22144 randomisiert die Reihenfolge, in der Peers im Nachrichtenverarbeitungs-Thread bedient werden, der für das Parsen und Verarbeiten von P2P-Nachrichten von Peers und für das Senden von Nachrichten an diese Peers verantwortlich ist. Zuvor bediente der Nachrichtenverarbeitungs-Thread jeden Peer-Round-Robin in der Reihenfolge, in der die Verbindungen zu diesen Peers zuerst hergestellt wurden. Dieser PR ändert die Logik, so dass bei jeder Iteration der Nachrichtenverarbeitungsschleife die Reihenfolge, in der Peers bedient werden, zufällig ist. Peers werden immer noch mit der gleichen Häufigkeit bedient (jeder Peer wird einmal pro Iteration bedient), aber alle Schwächen oder Exploits, die auf einer deterministischen Reihenfolge der bedienenden Peers beruhen, werden vermieden.
• Bitcoin Core #21261 erleichtert die Ausweitung des Schutzes für eingehende Verbindungen auf weitere Netzwerke und verwendet dann dieses Framework, um I2P zur Liste der geschützten Netzwerke hinzuzufügen. Der Diversity-Schutz (oft als Räumungsschutz bezeichnet) ermöglicht es einigen Peers mit wünschenswerten Eigenschaften, verbunden zu bleiben, wenn Bitcoin Core anderweitig Verbindungen mit hoher Latenz löscht. Es ist sehr wünschenswert, einige Verbindungen zu Peers in Anonymitätsnetzwerken aufrechtzuerhalten, da es Transaktionserstellern ermöglicht, diese Netzwerke zu verwenden, um ihre Netzwerkidentität zu verbergen, und weil die Möglichkeit, Blöcke über diese Netzwerke zusätzlich zum regulären Internetprotokoll zu empfangen, einige Arten von Sonnenfinsternis verhindern kann Anschläge.
• Rust Bitcoin #601 fügt Unterstützung für das Parsen von bech32m-Adressen hinzu und erfordert, dass v1+ native Segwit-Adressen mit bech32m und nicht mit bech32 codiert werden.
• BTCPay Server #2450 macht das Erstellen von Payjoin-kompatiblen Rechnungen zum Standard, wenn der Benutzer sich für die Verwendung einer Hot Wallet zum Empfangen von Zahlungen entscheidet. Eine Schaltfläche auf dem Bildschirm „Wallet erstellen“ ermöglicht es dem Benutzer, diese Standardeinstellung zu deaktivieren.
• BTCPay Server #2559 fügt einen separaten Bildschirm hinzu, der den Benutzer durch seine Auswahlmöglichkeiten zum Signieren von Transaktionen führt, die er aus seiner Brieftasche ausgibt. Bei Hot Wallets kann der Server nur signieren, aber bei Wallets, bei denen die Schlüssel woanders gespeichert sind, führt eine attraktive und informative Benutzeroberfläche den Benutzer jetzt durch Signieroptionen wie die Eingabe seiner Wiederherstellungs-Mnemonik, die Verwendung eines Hardware-Signaturgeräts oder das Generieren eines PSBT für auf eine Signier-Wallet übertragen.

Den Originalbeitrag finden Sie hier.

Bitte abonnieren Sie den Bitcoin Optech Newsletter direkt, um diese Inhalte jeden Monat direkt in Ihren Posteingang zu erhalten.