Bitcoin Optech #157: Vorgeschlagene neue Opcodes und Wiki-Seiten

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 fasst eine Diskussion über einen vorgeschlagenen neuen Opcode und Links zu einer aktualisierten Wiki-Seite zum Verfolgen des bech32m-Supports zusammen. Ebenfalls enthalten sind unsere regelmäßigen Abschnitte mit Highlights aus einem Bitcoin Core PR Review Club-Meeting, Vorschlägen zur Vorbereitung auf Taproot und Beschreibungen bemerkenswerter Änderungen an beliebten Bitcoin-Infrastrukturprojekten.

Neuigkeiten

Anfrage zum OP_CHECKSIGFROMSTACK-Design Vorschläge: Jeremy Rubin gepostet an das Bitcoin-Dev-Mailing einen Spezifikationsentwurf für einen OP_CHECKSIGFROMSTACK-Opcode auflisten und um Feedback von Entwicklern bitten, die eine Alternative bevorzugen Design. Einige Alternativen wurden diskutiert, aber der Thread verzweigte sich auch in eine Diskussion darüber, ob ein OP_CAT Opcode sollte gleichzeitig eingeführt werden. OP_CAT und OP_CSFS würden eine willkürliche Transaktionsintrospektion ermöglichen – die Möglichkeit, Bitcoins an ein Skript zu empfangen, das fast jeden Teil der Transaktion überprüfen könnte, der später diese Bitcoins ausgibt. Dadurch können viele erweiterte Funktionen aktiviert werden (einschließlich Versionen1 anderer vorgeschlagene Upgrades wie SIGHASH_ANYPREVOUT und OP_CHECKTEMPLATEVERIFY), aber OP_CAT ermöglicht es auch, rekursive Verpflichtungen, die die Ausgabefähigkeit von Bitcoins, die an die Vereinbarung gebunden sind, dauerhaft einschränken könnten. Einige Leute haben Einwände dagegen, Covenants in Bitcoin zuzulassen, aber mehrere Argumente waren gemacht, dass die Worst-Case-Probleme rekursiver Covenants bereits heute in Bitcoin existieren, also haben wir sollte sich keine Sorgen machen, OP_CAT oder einen ähnlichen Opcode zu aktivieren. Trotz der Diskussion entschied Rubin, dass er seinen OP_CSFS-Vorschlag unabhängig von jedem Vorschlag zum Hinzufügen von OP_CAT halten wollte, Argumente, dass OP_CSFS allein schon nützlich genug ist.Bech32m-Unterstützung verfolgen: die Bitcoin-Wiki-Seite für bech32-Einführung wurde aktualisiert, um zu verfolgen, welche Software und Dienste Ausgaben unterstützen oder Empfangen an bech32m Adressen für taproot.Bitcoin Core PR Review Club
In diesem monatlichen Abschnitt fassen wir ein kürzlich durchgeführtes Bitcoin Core PR Review Club-Meeting zusammen und heben einige der wichtigen Fragen hervor und Antworten. Klicken Sie unten auf eine Frage, um eine Zusammenfassung der Antwort aus dem Meeting anzuzeigen.
Verwenden Sie script_util-Helfer zum Erstellen von P2{PKH,SH ,WPKH,WSH} scripts ist eine PR von Sebastian Falbesoner, die in Funktionstests die manuelle Skripterstellung durch Aufrufe von script_util-Hilfsfunktionen ersetzt und einen Fehler in der Funktion get_multisig() behebt. Das Review Club-Treffen brach die Terminologie und jeden der Skriptausgabetypen, die in der PR verwendet werden. Was tun key_to_p2pkh_script, script_to_p2sh_script, key_to_p2wpkh_scriptund script_to_p2wsh_script in script_util.py?
Dies sind Hilfsfunktionen zum Erstellen von CScript-Objekten für Pay to Public Key Hash , Pay-to-Script-Hash, Pay-to-Witness-Public-Key-Hash und Pay-to-Witness-Script-Hash-Skripte aus öffentlichen Schlüsseln und Skripten. ➚Definieren Sie scriptPubKey, scriptSig und Zeuge.
ScriptPubKey und scriptSig sind Felder in der Ausgabe bzw. Eingabe einer Transaktion zum Spezifizieren und Erfüllen von Ausgabebedingungen. Der Zeuge ist ein zusätzliches Feld für denselben Zweck, das mit Segregated Witness eingeführt wurde. Die Ausgabenanforderungen werden im scriptPubKey einer Ausgabe festgelegt, und die Eingabe, die sie ausgibt, muss von Daten begleitet werden, die diese Bedingungen in der scriptSig und/oder dem Zeugen erfüllen. ➚Definieren Sie das Einlöseskript und das Zeugenskript. Wie ist die Beziehung zwischen ihnen?
P2SH-und P2WSH-Ausgabetypen übergeben einen Skript-Hash im scriptPubKey. Wenn die Ausgabe ausgegeben wird, muss der Spender das Skript selbst bereitstellen, zusammen mit allen Signaturen oder anderen Daten, die erforderlich sind, damit es erfolgreich ist. Das Skript wird als Einlösungsskript bezeichnet, wenn es in der scriptSig enthalten ist, und als Zeugenskript, wenn es im Zeugen enthalten ist. In diesem Sinne sind sie analog; Ein Einlöseskript ist für eine P2SH-Ausgabe, was ein Witness-Skript für eine P2WSH-Ausgabe ist. Sie schließen sich jedoch nicht gegenseitig aus, da eine Transaktion, die eine P2SH-P2WSH-Ausgabe ausgibt, beides enthält. ➚Um Coins an jemanden zu senden, dessen Ausgabebedingungen in einem Skript kodiert sind, was im scriptPubKey von. enthalten ist die Ausgabe? Was muss in der Eingabe angegeben werden, wenn die Münze ausgegeben wird?
Der scriptPubKey enthält den Skript-Hash und die Opcodes, um eine Übereinstimmung zu überprüfen: OP_HASH160 OP_PUSHBYTES_20 <20B Skript-Hash> OP_EQUAL. Das scriptSig enthält das Skript selbst und den anfänglichen Stack. ➚Warum verwenden wir Pay-To-Script-Hash anstelle von Pay-To-Script?
Die Hauptmotivation, wie in BIP16 angegeben, ist die Erstellung eines generische Methode zur Finanzierung beliebig komplexer Transaktionen, während die Last der Bereitstellung von Ausgabebedingungen auf denjenigen übertragen wird, der die Gelder einlöst. Die Teilnehmer erwähnten auch, dass das Halten des Skripts von scriptPubKeys bedeutet, dass die damit verbundenen Gebühren nicht bis zur Einlösung bezahlt werden und zu einem kleineren UTXO-Satz führen. ➚Wenn ein Nicht-Segwit-Knoten eine P2SH-P2WSH-Eingabe validiert, was passiert dann? Was macht ein Segwit-aktivierter Knoten zusätzlich zu der Prozedur, die von einem Nicht-Segwit-Knoten durchgeführt wird?
Der Nicht-Segwit-Knoten sieht den Zeugen nie; es erzwingt einfach P2SH-Regeln, indem es überprüft, ob das replaceScript mit dem Hash übereinstimmt, dem im scriptPubKey festgeschrieben wurde. Ein Segwit-Knoten erkennt diese Daten als Zeugenprogramm und verwendet die Zeugendaten und den entsprechenden scriptCode, um Segwit-Regeln durchzusetzen. ➚Was ist mit dem P2SH-P2WSH-Skript im ursprünglichen get_multisig() Funktion?
Verwendet das Zeugenskript anstelle von seinen Hash im P2SH-P2WSH-Einlöseskript. ➚Vorbereitung für Taproot #4: von P2WPKH zu Single-Sig-P2TR
Eine wöchentliche Serie darüber, wie Entwickler und Dienstanbieter sich auf die bevorstehende Aktivierung vorbereiten können von taproot auf Blockhöhe 709.632.
Für Wallets, die bereits das Empfangen und Ausgeben von v0 segwit P2WPKH-Ausgaben unterstützen, sollte ein Upgrade auf v1 segwit P2TR für Single-Sig einfach sein. Hier sind die wichtigsten Schritte: Verwenden Sie einen neuen BIP32-Schlüsselableitungspfad: Sie müssen Ihr BIP32 Hierarchical Deterministic (HD)-Code und Ihre Benutzer müssen ihre Seeds nicht ändern.2 Es wird jedoch dringend empfohlen, einen neuen Ableitungspfad für Ihre öffentlichen P2TR-Schlüssel zu verwenden (wie z. B. durch BIP86); Wenn Sie dies nicht tun, gibt es einen möglichen Angriff Dies kann auftreten, wenn Sie dieselben Schlüssel mit ECDSA-und schnorr-Signaturen verwenden.Optimieren Sie Ihren öffentlichen Schlüssel anhand seines Hashs: Obwohl für Single-Sig technisch nicht erforderlich, insbesondere wenn alle Ihre Schlüssel von einem zufällig ausgewählten BIP32-Seed abgeleitet sind, BIP341 empfohlen, dass Ihr Schlüssel in einen nicht ausgebbaren Scripthash-Baum übertragen wird. Dies ist so einfach wie die Verwendung einer Elliptic Curve-Additionsoperation, die Ihren öffentlichen Schlüssel mit dem Kurvenpunkt des Hashs dieses Schlüssels summiert. Die Einhaltung dieser Empfehlung hat den Vorteil, dass Sie denselben Code verwenden können, wenn Sie später multisignature. hinzufügen Unterstützung oder wenn Sie Unterstützung für tr()-Deskriptoren.Erstellen Sie Ihre Adressen und überwachen Sie sie: Verwenden Sie bech32m, um Ihre Adressen zu erstellen. Zahlungen werden an scriptPubKey OP_1 gesendet. Sie können nach Transaktionen suchen, die das Skript bezahlen, und zwar mit jeder Methode, mit der Sie nach v0-Segwit-Adressen wie P2WPKH suchen. Erstellen einer Ausgabetransaktion: Alle Nicht-Zeugen-Felder für taproot sind die gleichen wie für P2WPKH, also brauchen Sie sich keine Sorgen zu machen über Änderungen an der Transaktionsserialisierung.Erstellen Sie eine Signaturnachricht: Dies ist eine Verpflichtung zu den Daten aus der Ausgabetransaktion. Die meisten Daten entsprechen denen, die Sie für eine P2WPKH-Transaktion unterschreiben, aber die Reihenfolge der Felder ist geändert und ein paar zusätzliche Dinge sind signiert. Um dies zu implementieren, müssen Sie nur verschiedene Daten serialisieren und hashen, daher sollte das Schreiben des Codes einfach sein. Einen Hash der Signaturnachricht signieren: Es gibt verschiedene Möglichkeiten, Schnorr-Signaturen zu erstellen. Am besten rollen Sie nicht Ihre eigene Kryptowährung, sondern nutzen die Funktion einer gut geprüften Bibliothek Ihres Vertrauens. Aber wenn Sie das aus irgendeinem Grund nicht tun können, BIP340 stellt einen Algorithmus bereit, der einfach zu implementieren sein sollte, wenn Sie bereits über die Primitive zum Erstellen von ECDSA-Signaturen verfügen. Wenn Sie Ihre Unterschrift haben, fügen Sie sie in die Zeugendaten für Ihre Eingabe ein und senden Sie Ihre Ausgabentransaktion. Noch bevor Taproot bei Block 709.632 aktiviert wird, können Sie Ihren Code mit Testnet testen, dem öffentlichen Standard signet oder der private Regtest-Modus von Bitcoin Core. Wenn Sie Ihrem Open-Source-Wallet Taproot-Unterstützung hinzufügen, empfehlen wir Ihnen, einen Link zu den PR(s) hinzuzufügen, die diese auf der taproot verwendet und bech32m-Adoption-Seiten des Bitcoin-Wikis, damit andere Entwickler Lernen Sie aus Ihrem Code.
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.1-beta.rc2 ist eine Wartungsversion mit kleineren Verbesserungen und Fehlerbehebungen für Funktionen, die in 0.13.0-beta eingeführt wurden.

Bemerkenswerte Änderungen an Code und Dokumentation

Bemerkenswerte Änderungen in dieser Woche in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay-Server, Bitcoin Improvement Proposals (BIPs) und Lightning BOLTs.C-Lightning #4625 aktualisiert seine LN-Angebote um mit den neuesten Spezifikationsänderungen übereinstimmen. Insbesondere müssen Angebote keine Unterschrift mehr enthalten. Dadurch wird die codierte Zeichenfolge für Angebote erheblich verkürzt und die Erkennbarkeit des QR-Codes verbessert.Eclair #1746 fügt Unterstützung hinzu zum Replizieren von Daten in eine PostsgreSQL-Datenbank parallel zur primären SQLite-Datenbank. Die Funktion soll das Testen von Servern erleichtern, die einen eventuellen Back-End-Umstieg durchführen möchten. Letztes Jahr beschrieb Suredbits-Ingenieur Roman Taranchenko die Anpassung von Eclair für den Unternehmenseinsatz mit einem PostgreSQL-Backend in einem Optech-Feld Bericht.LND #5447 fügt eine Dokument, das beschreibt, wie mehrere LND-Knoten in einem Cluster mit einer alternativen Datenbank eingerichtet werden, die zwischen den between Cluster-Knoten und ermöglicht ein automatisches Failover. Interessierte Leser möchten dies vielleicht dem Ansatz von Eclair gegenüberstellen, der in described beschrieben ist Newsletter #128.Libsecp256k1 #844 nimmt mehrere Aktualisierungen der API vor für schnorr-Signaturen. Am bemerkenswertesten ist eincommit, das das Signieren und Verifizieren von Nachrichten jeglicher Art ermöglicht Länge. Alle aktuellen Verwendungen von Signaturen in Bitcoin signieren einen 32-Byte-Hash, aber das Signieren von Daten mit variabler Länge könnte für Anwendungen außerhalb von Bitcoin nützlich sein oder um einen neuen Opcode wie OP_CHECKSIGFROMSTACK an Signaturen überprüfen, die für Nicht-Bitcoin-Systeme erstellt wurden. Es wird erwartet, dass die BIP340-Spezifikation von Schnorr-Signaturen für Bitcoin aktualisiert, um das sichere Signieren von Daten mit variabler Länge zu beschreiben.BIPs #943 aktualisiert BIP118, um auf dem in Kürze aktivierten Taproot und Tapscript anstelle von SegWit v0 aufzubauen. Darüber hinaus benennt diese Überarbeitung den Titel von SIGHASH_NOINPUT in SIGHASH_ANYPREVOUT um, um widerzuspiegeln, dass die Sighash-Flagge jetzt verwendet wird als”ANYPREVOUT”zu bezeichnen, da zwar möglicherweise ein Prevout mit der Signatur verwendet werden kann, einige Aspekte der Eingabe jedoch weiterhin festgeschrieben sind.BTCPay-Server #2655 signalisiert Webbrowsern, dass sie das HTTP-Refererfeld nicht senden sollen, wenn der Benutzer auf einen Link zu einer Transaktion in einem Block-Explorer. Dadurch wird vermieden, dass dem Block-Explorer mitgeteilt wird, von welchem ​​BTCPay-Server der Benutzer stammt – diese Informationen sind ein starker Beweis dafür, dass der Server die Transaktion, die im Block-Explorer angezeigt wird, entweder erstellt oder empfangen hat. Trotz dieser Änderung sollten Nutzer, die einen strengen Datenschutz wünschen, es dennoch vermeiden, ihre eigenen Transaktionen in Block-Explorern von Drittanbietern nachzuschlagen.FußnotenVerwenden von OP_CHECKSIGFROMSTACK (OP_CSFS) zur Implementierung der Hauptfunktion von Angeboten wie BIP118s SIGHASH_ANYPREVOUT oder OP_CHECKTEMPLATEVERIFY von BIP119 würden mehr Blockspeicherplatz benötigen als diese optimierten Vorschläge, wenn Skriptpfadausgaben wird eingesetzt. Das Argument für OP_CSFS ist, dass es erlaubt Beginnen Sie mit einer generischen Konstruktion und beweisen Sie, dass die Benutzer die Funktion tatsächlich verwenden, bevor eine Konsensänderung verwendet wird, um eine effizientere Implementierung hinzuzufügen. Darüber hinaus kann mit der Einführung von Taproot-Schlüsselpfadausgaben jedes Skript mit minimalem Einsatz von Blockieren Sie in einigen Situationen Platz, was möglicherweise den Bedarf an spezifischen Konstruktionen verringert, die in nicht optimalen Situationen Platz sparen. ↩Als Electrum auf Segwit v0 aktualisiert wurde, musste jeder, der wollte bech32 adressen erhalten um neue Seeds zu generieren. Dies war technisch nicht erforderlich, aber es ermöglichte den Autoren von Electrum, einige neue Features in ihre benutzerdefinierte Seed-Ableitungsmethode. Eine dieser Funktionen war die Möglichkeit für eine Seed-Versionsnummer anzugeben, mit welchen Skripten ein Seed verwendet werden soll. Dies ermöglicht die sichere Einstellung alter Skripte (z. B. könnte eine zukünftige Version von Electrum veröffentlicht werden, die den Empfang an alte P2PKH-Adressen nicht mehr unterstützt). Verwenden von Ausgabe-Skript-Deskriptoren, um das gleiche Problem zu lösen, bei dem die Einstellung von Skripten zugelassen wird (zusätzlich andere Probleme zu lösen). Die folgende Tabelle vergleicht die versionierten Seeds von Electrum und die Deskriptoren von Bitcoin Core mit der Methode der impliziten Skripte, die zuvor von beiden Wallets verwendet wurde und immer noch von den meisten anderen Wallets verwendet wird.

Finden Sie die ursprünglicher Beitrag hier.

Bitte abonnieren Sie den Bitcoin Optech-Newsletter direkt, um diesen Inhalt jeden Monat direkt in Ihren Posteingang zu erhalten.