Multisignatur

Neugier

1. Warum nimmt ein Script, das zwei Signaturen erfordert, drei Elemente vom Stack?
2. Wie kann ein leerer Byte-String eine Konsensregel sein und nicht bloß eine Konvention?
3. Was ändert sich, wenn zehn Schlüssel zu einer Signatur zusammengefasst werden, die nicht von der eines einzelnen Unterzeichners zu unterscheiden ist?

Erkunden

1. Multisignatur-Scripts verlangen, dass mindestens m Signaturen gegen n aufgeführte öffentliche Schlüssel gültig sind. Das Locking-Script führt m, die n öffentlichen Schlüssel und n auf; OP_CHECKMULTISIG nimmt n, die n Schlüssel, m und anschließend m Signaturen vom Stack, die in der aufgeführten Reihenfolge zu den Schlüsseln passen müssen. Werden weniger als m gültige Signaturen geliefert, ist das Ausgeben ungültig.
2. Ein Programmierfehler in der ursprünglichen Implementierung führt dazu, dass OP_CHECKMULTISIG über die erforderlichen Signaturen hinaus ein zusätzliches Element vom Stack nimmt. Dieses „Dummy“-Element wird bei der kryptografischen Verifizierung ignoriert, muss aber vorhanden sein; fehlt es, läuft der Stack leer (Stack-Underflow) und die Transaktion scheitert. Frühe Ausgebende verwendeten OP_0 als Platzhalter – eine Konvention, die sich jahrelang hielt, weil Nodes an dieser Stelle jeden Wert akzeptierten.
3. BIP147 (NULLDUMMY), im August 2017 zusammen mit SegWit aktiviert, machte aus diesem Malleability-Vektor eine Konsensregel. Das Dummy-Element muss nun ein leeres Byte-Array sein. Jeder nicht leere Wert, selbst ein einzelnes Null-Byte, lässt das Script fehlschlagen. Damit entfiel die Möglichkeit, Transaktions-IDs durch Austauschen des Dummy-Inhalts zu verändern, und der Transaktionshash wurde für alle nachfolgenden Bestätigungen stabil.
4. Standardness-Regeln bestimmen, welche Multisig-Scripts Nodes weiterleiten. Bare-Multisig-Outputs sind nach der Standard-Policy von Bitcoin Core auf drei Schlüssel beschränkt. In P2SH verpackt kann Multisig bis zu 15 Schlüssel verwenden (begrenzt durch das 520-Byte-Redeem-Script), in P2WSH bis zu 20. Diese Unterscheidung ermöglicht komplexe Treasury-Setups von Unternehmen, ohne die Basis-Transaktionsebene aufzublähen.
5. Zwei neuere Werkzeuge lösen die herkömmlichen Multisig-Muster ab. MuSig2 (BIP327, 2023), ein eigenständiges Protokoll auf Basis der Schnorr-Signaturen von Taproot, aggregiert mehrere öffentliche Schlüssel zu einem einzigen Schlüssel und erzeugt eine gewöhnliche Schnorr-Signatur; on-chain ist das Ausgeben nicht von einem normalen Taproot-Ausgeben mit einem einzigen Schlüssel zu unterscheiden. Tapscript, Teil von Taproot selbst, fügt OP_CHECKSIGADD hinzu, das eine schrittweise Signaturprüfung ohne den Stack-Pop-Bug und ohne das 20-Schlüssel-Limit der Legacy-Opcodes ermöglicht.
6. Um diese Mechanik zu untersuchen, öffnen Sie einen Block-Explorer und suchen Sie eine Bare-Multisig-Transaktion aus der Zeit vor SegWit. Betrachten Sie das scriptSig: Es beginnt mit OP_0, gefolgt von Signaturen. Vergleichen Sie es mit dem Ausgeben eines P2WSH-Multisig-Outputs, bei dem der Witness einen leeren Eintrag, die Signaturen und das Witness-Script mit der Schlüsselliste enthält. Beachten Sie, wie sich die Byte-Zahlen unterscheiden – darin spiegeln sich die Kosten wider, die vollständige Schlüsselliste im Output statt im Input unterzubringen.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 7
• BIP147: Dealing with dummy stack element malleability
• BIP327: MuSig2 for BIP340-compatible Multi-Signatures
• BIP342: Validation of Taproot Scripts