127 / 736WIT

Witness Data

Daten zum Nachweis der Ausgabeberechtigung

Das Netzwerk muss wissen, wohin Coins gehen und ob du sie ausgeben darfst. Witness liefert dafür etwa Signaturen. Diese Daten abzutrennen bedeutet nicht, sie aus Bitcoin zu entfernen.

Witness Data sind Daten an den Eingängen einer Transaktion, mit denen SegWit-Ausgabebedingungen geprüft werden. Ein Eingang verweist auf zuvor erhaltene Coins, die jetzt ausgegeben werden. Witness kann Signaturen, öffentliche Schlüssel oder ein Skript enthalten. Es gehört zur Transaktion und ist kein weiterer Aufbewahrungsort für Geld.

Anna hat Bitcoin erhalten und möchte damit Peter bezahlen. Die frühere Zahlung erzeugte einen Ausgang: einen Eintrag mit Betrag und Bedingungen für die spätere Ausgabe. Die neue Transaktion verweist mit einem Eingang darauf. Die bloße Behauptung, die Coins gehörten Anna, reicht nicht. Bei einer gewöhnlichen Zahlung erstellt die Wallet eine Signatur, die sich ohne Offenlegung des privaten Schlüssels prüfen lässt. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Der private Schlüssel ist ein geheimer Zahlenwert, mit dem eine solche Signatur erzeugt wird. Bei SegWit werden solche Daten als witness des Eingangs vorgelegt. Eine vorhandene Signatur ist aber noch keine gültige Signatur. [1] [4] [5]

Denke an den Unterschied zwischen „einen gültigen Ausweis vorlegen“ und dem tatsächlich vorgelegten Ausweis. Bei Bitcoin entscheidet kein Mensch; Regeln prüfen den Zusammenhang. Das witness program ist Teil der Bedingung im früheren Ausgang, und seine Version bestimmt die Auswertung. Erst die neue ausgebende Transaktion liefert witness. Technisch ist das eine geordnete Liste von Datenelementen je Eingang. Sie ist nicht automatisch ein ausführbares Programm oder eine Kopie aller ungenutzten Coins. [1] [7]

Witness kann eine Signatur, einen öffentlichen Schlüssel oder das verwendete Skript offenlegen, also das Programm mit den Ausgabebedingungen. Der öffentliche Schlüssel dient zur Prüfung von Signaturen und muss nicht geheim bleiben. Es ist kein verschlüsseltes Postfach. Dein privater Schlüssel bleibt bei dir: Er dient zum Signieren und wird nicht anstelle der Signatur ins Netzwerk gesendet. Weder witness noch eine veröffentlichte Signatur ersetzen die Seed Phrase, die Wörter zur Wiederherstellung der Wallet. Gehen Schlüssel und Sicherung verloren, stellt die öffentliche Zahlungshistorie allein die Fähigkeit zum Signieren nicht wieder her. [1] [3] [4]

Ein Blockexplorer ist eine Anwendung, mit der sich Transaktionen und Blöcke eines bestimmten Netzwerks nachschlagen lassen. Ein Explorer kann neben txid auch wtxid anzeigen. Beides sind Hashes, kurze Fingerabdrücke einer genauen Datendarstellung, berechnet durch zweimaliges Anwenden von SHA-256. txid verwendet die Darstellung ohne witness, wtxid die vollständige mit witness. Es sind weder Empfängeradressen noch zwei verschiedene Zahlungen. Ohne witness wird das ursprüngliche Format verwendet, und beide Kennungen stimmen überein. Bitcoin Core v29.0 gibt bei decoderawtransaction die vollständige Kennung im Feld hash aus; die witness-Daten eines Eingangs stehen in txinwitness. [1] [7] [8]

Eine weitere Transaktion kann schon vor der Bestätigung auf eine frühere verweisen. Könnte jemand deren Kennung allein durch eine Änderung der Signaturdaten verändern, würde der Verweis nicht mehr passen. Eine Änderung nur am witness verändert txid nicht. Das hilft Protokollen mit abhängigen Transaktionen, etwa Lightning Network. Die gesamte Transaktion wird dadurch aber nicht unveränderlich. Andere Felder oder ältere Eingänge ohne SegWit können txid weiterhin beeinflussen, und ein verändertes witness muss die geltenden Prüfregeln erfüllen. [1] [6]

Witness wird mit der vollständigen Transaktionsdarstellung übertragen und gehört nach der Aufnahme zu den Blockdaten. Es ist kein kostenloser Speicher außerhalb der Kette. Ein durch die witness-Serialisierung hinzugefügtes Byte zählt 1 WU, ein Basisbyte 4 WU; WU bedeutet Gewichtseinheit. Ein Full Node prüft Regeln selbstständig und benötigt die betreffenden Daten zur Ausgabeprüfung. Weniger Gewicht erlaubt weder das Auslassen erforderlicher Prüfungen noch bedeutet es, dass die Daten keinen Speicher belegen. [1] [7]

Im älteren Format standen Ausgabenachweise in scriptSig. Natives SegWit der Version 0 verlangt ein leeres Feld: Die Nachweise stehen in witness. Daneben gibt es die in P2SH eingebettete Variante. P2SH ist die ältere Zahlungsform für eine durch einen Skript-Hash bestimmte Bedingung. Dabei darf scriptSig genau das Einfügen des betreffenden witness program enthalten, keine beliebigen zusätzlichen Anweisungen. Die Nachweise bleiben in witness. Derselbe Zweck kann somit unterschiedlich kodiert sein; allein der Feldname erklärt die Bedeutung nicht. [1] [5]

P2WPKH legt eine Signatur und einen öffentlichen Schlüssel vor. Der Knoten prüft, ob dessen Hash zur ursprünglichen Bedingung passt und die Signatur gültig ist. P2WSH ermöglicht eine durch den Hash eines ganzen Skripts bestimmte Bedingung. Das letzte witness-Element heißt witnessScript; sein Hash muss zum Programm im Ausgang passen. Die vorherigen Elemente liefern die Anfangsdaten für die Skriptausführung, etwa Signaturen. BIP 143 definiert die signierte Nachricht für diese Version einschließlich des Werts des ausgegebenen Ausgangs. Lesbare Daten allein belegen noch keine erfüllte Bedingung. [1] [2] [5]

Taproot nutzt natives witness der Version 1 und unterscheidet Schlüssel- und Skriptpfad. Vor dieser Entscheidung wird ein eventuell vorhandenes annex, ein besonderes Zusatzfeld, beiseitegenommen; seine Daten zählen weiterhin zum Gewicht und werden von der Signatur erfasst. Bleibt ein Element, wird es als Signatur des Schlüsselpfads interpretiert. Der Skriptpfad legt das verwendete Skript und einen control block offen: Daten zum Nachweis der Verbindung mit dem früheren Ausgang, keinen neuen Blockchain-Block. Vorherige Elemente liefern gegebenenfalls Skriptdaten. Die Regeln der Version 0 lassen sich nicht einfach übertragen. [3] [5]

Ein kryptografisches Commitment ist ein Fingerabdruck, der Daten an ihren konkreten Inhalt bindet. Wenn ein solches Commitment zu witness-Daten erforderlich ist, verknüpft BIP 141 die witness-Daten mit dem restlichen Block. Dazu dient die Coinbase Transaction, die erste Transaktion für die Miner-Belohnung. Ein Baum aus wtxid-Hashes ergibt eine Wurzel, die die Daten zusammenfasst. Für die Belohnungstransaktion wird darin ein Nullwert als wtxid verwendet. Die Wurzel wird mit einem reservierten Wert von 32 Bytes kombiniert und zweimal gehasht; das Ergebnis wird als Commitment in ihrem Ausgang festgehalten. Hat keine Transaktion witness, ist dieses Commitment optional. Es verbindet öffentliche Nachweise, sichert aber keine Schlüssel und ersetzt keine Prüfung. [1]

Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit SegWit, Block Weight, Bitcoin Script, Taproot, Bitcoin, Seed Phrase. Auf diesen Eintrag verweisen außerdem Block Weight, Miniscript, Compact Block Filters.

DOC · 001BIP 141 — Segregated WitnessSpezifikation DOC · 002BIP 143 — SegWit signature hashingSpezifikation DOC · 003BIP 341 — TaprootSpezifikation DOC · 004Bitcoin Developer Reference — TransactionsDokumentation DOC · 005Bitcoin Core v29.0 — Script interpreterDokumentation DOC · 006Bitcoin Core — Segregated Witness benefitsDokumentation DOC · 007BIP 144 — Segregated Witness Peer ServicesSpezifikation DOC · 008Bitcoin Core v29.0 — decoderawtransactionDokumentation
Überarbeitet: Quellenbasiert · Keine Anlageberatung