Standard-Scripts: P2PKH und P2SH

Neugier

1. Warum sperrt Bitcoin die Coins an einen Hash statt an den Schlüssel selbst?
2. Wie überprüft ein vierzeiliges Script in einer einzigen Ausführung sowohl das Eigentum als auch die Autorisierung?
3. Was machte P2PKH über mehr als acht Jahre der Netzwerkgeschichte zum Standard-Adressformat?

Erkunden

Teil IPay-to-Public-Key-Hash (P2PKH)

1. Der Genesis-Block enthielt ausschließlich Pay-to-Public-Key-Outputs (P2PK). Diese Scripts legten den vollständigen öffentlichen Schlüssel (2009 ein unkomprimierter Schlüssel mit 65 Bytes) direkt im Output ab, wo er schon vor jedem Ausgeben sichtbar war, und machten Outputs groß. P2PKH, das ebenfalls bereits in der ursprünglichen Software von 2009 enthalten war und für gewöhnliche Zahlungen an Adressen verwendet wurde, speichert stattdessen einen 20-Byte-Hash und hält den Schlüssel so verborgen, bis die Coins ausgegeben werden.
2. Das Locking-Script lautet `OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG`. Zu Beginn der Ausführung liegen die Daten des Ausgebenden auf dem Stack: die Signatur und darüber, ganz oben, der öffentliche Schlüssel. Die Engine dupliziert den Schlüssel, hasht ihn mit RIPEMD-160(SHA256(key)) und vergleicht das Ergebnis mit dem gespeicherten Hash. Stimmen beide überein, ist `OP_EQUALVERIFY` erfüllt; andernfalls bricht die Ausführung sofort ab.
3. Ist die Hash-Prüfung erfolgreich, verifiziert `OP_CHECKSIG` die ECDSA-Signatur anhand des offengelegten öffentlichen Schlüssels und der Transaktionsdaten. Dieser doppelte Mechanismus stellt sicher, dass nur der Inhaber des zugehörigen privaten Schlüssels die Mittel freigeben kann. Das Output-Script umfasst insgesamt 25 Bytes – eine kompakte Struktur, die zur Grundlage der mit „1“ beginnenden Legacy-Adressen wurde.
4. P2PKH war während des größten Teils der Geschichte von Bitcoin der gängigste Output-Typ für gewöhnliche Zahlungen und blieb es auch noch Jahre nach der Aktivierung von SegWit im August 2017 bei Block 481.824, da sich natives SegWit nur schrittweise durchsetzte. Sein Erfolg beruhte auf Einfachheit und Kompatibilität; über die ursprünglichen Protokollregeln hinaus waren keine Konsens-Upgrades nötig. Jeder Node konnte diese Scripts unabhängig und ohne komplexe Zustandsverfolgung validieren, was P2PKH in der frühen Wachstumsphase von Bitcoin zum robustesten Output-Typ für allgemeine Überweisungen machte.
5. Das Adressformat nutzt die Base58Check-Kodierung, die eine vier Byte lange Prüfsumme zur Erkennung von Tippfehlern enthält. Ein einziges falsch eingegebenes Zeichen lässt die Prüfsumme mit an Sicherheit grenzender Wahrscheinlichkeit scheitern, sodass die Wallet die Adresse ablehnt. Diese Redundanz machte P2PKH trotz seiner technischen Komplexität benutzerfreundlich und schlug eine Brücke zwischen kryptografischer Sicherheit und menschlicher Bedienbarkeit.
6. Öffnen Sie einen Block-Explorer und suchen Sie eine beliebige Transaktion mit einem Input, der auf eine mit „1“ beginnende Adresse verweist. Untersuchen Sie das Feld `scriptSig`: Es enthält die Signatur, gefolgt vom öffentlichen Schlüssel als Hex-String. Vergleichen Sie diesen öffentlichen Schlüssel mit dem 20-Byte-Hash im `scriptPubKey` des referenzierten Outputs. Wenden Sie auf diesen Schlüssel erst SHA-256 und dann RIPEMD-160 an, ergibt sich der gespeicherte Hash, was die Verknüpfung bestätigt.

Teil IIPay-to-Script-Hash (P2SH)

7. Vor 2012 musste für ein komplexes Script wie ein 5-of-5-Multisig der gesamte Locking-Code direkt in den Output geschrieben werden. Dadurch wurde der Output groß, und der Sender zahlte die Gebühr dafür. Zudem wurden die öffentlichen Schlüssel aller Beteiligten und die konkreten Signaturanforderungen für jeden sichtbar, der die Blockchain beobachtete. Der Sender musste vor dem Senden die genaue Struktur des Ziels kennen – ein Hindernis für Unternehmens-Treasuries oder Börsen, die flexible Sicherheitskonfigurationen benötigten.
8. Gavin Andresen schlug Anfang 2012 BIP16 vor, um dieses Problem zu lösen. Damit konnte ein Output statt des Scripts selbst nur noch dessen HASH160-Digest enthalten. Das Output-Script schrumpfte auf 23 Bytes, etwas weniger als die 25 Bytes von P2PKH. Der Sender musste die Ausgabebedingungen nicht mehr kennen; er zahlte einfach an einen Hash. Die Komplexität verlagerte sich vollständig auf denjenigen, der die Coins ausgibt.
9. Die Aktivierung von BIP16 im April 2012 war umstritten. Luke Dashjr schlug mit BIP17 eine Alternative vor, die einen anderen Opcode und ein anderes Kodierungsschema verwendete. Die Debatte darüber, welcher Vorschlag übernommen werden sollte, heizte sich in der Entwicklergemeinschaft erheblich auf. Nachdem die Miner ihre Unterstützung signalisiert hatten, wurde BIP16 im April 2012 aktiviert und zum Standardverfahren, um komplexe Scripts zu verpacken.
10. Das Ausgeben eines Pay-to-Script-Hash-Outputs ist ein zweistufiger Prozess. Zunächst legt der Ausgebende sein vollständiges Redeem-Script auf den Stack. Der Node prüft, ob der HASH160 dieses Scripts mit dem Hash im Output übereinstimmt. Stimmt er nicht überein, schlägt die Ausführung sofort fehl. Stimmt er überein, führt der Node anschließend das offengelegte Redeem-Script mit den übrigen Daten auf dem Stack aus, um die eigentlichen Ausgabebedingungen zu prüfen.
11. Das Design hat einen Haken: Niemand kann das Redeem-Script vor der Zahlung prüfen, da nur sein Hash on-chain liegt. Hat die Software des Empfängers ein fehlerhaftes Script erstellt oder geht das Script verloren, können an diese Adresse gezahlte Coins für immer unausgebbar sein.
12. Als SegWit im August 2017 aktiviert wurde, diente P2SH als Kompatibilitätsbrücke. Nutzer konnten neue Witness-Scripts in eine P2SH-Hülle einbetten und so „verschachtelte“ (nested) Adressen erzeugen, die weiterhin mit „3“ begannen. Alte Wallets, die mit den neueren bech32-Adressen nicht umgehen konnten, konnten so dennoch an SegWit-Nutzer senden, während die SegWit-fähigen Empfänger beim Ausgeben den Gebührenrabatt erhielten. Heute wird aus Effizienzgründen natives SegWit bevorzugt, doch P2SH bleibt ein wichtiger Mechanismus für komplexe Verträge und die Kompatibilität mit Legacy-Systemen.

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
• Bitcoin Developer Guide, 'Transactions' documentation (bitcoin.org)
• Satoshi Nakamoto, original Bitcoin client source code (2009-2010 commits)
• Gavin Andresen, BIP16: Pay to Script Hash (2012)
• Luke Dashjr, BIP17: OP_CHECKHASHVERIFY (CHV) (2012)
• Bitcoin Developer Guide: Transactions and Scripts