Die BIP173- Spezifikation definiert, wie native Bech32-Segwit-Adressen erstellt werden.
Im Beispielabschnitt wird ein öffentlicher Schlüssel angegeben: 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798.
Basierend auf diesem Schlüssel ist es ziemlich einfach, eine P2WPKH-Adresse zu generieren, man hasht den Schlüssel mit SHA256, dann mit RIPEMD160 und verwendet das hex-decodierte Ergebnis als Zeugenprogramm (die ersten beiden Befehle sind einfache CLI und der letzte stammt aus der Dart bech32- Bibliothek ):
$ echo 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 | xxd -r -p | openssl sha256
(stdin)= 0f715baf5d4c2ed329785cef29e562f73488c8a2bb9dbc5700b361d54b9b0554
$ echo 0f715baf5d4c2ed329785cef29e562f73488c8a2bb9dbc5700b361d54b9b0554 | xxd -r -p | openssl ripemd160
(stdin)= 751e76e8199196d454941c45d1b3a323f1433bd
Segwit('bc', 0, HEX.decode("751e76e8199196d454941c45d1b3a323f1433bd"))
// bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3
Das Generieren eines P2WSH beinhaltet das Skript key OP_CHECKSIG, gefolgt von einem einmaligen SHA256-Hashing. Ich bin ratlos, wie ich das Skript konstruieren soll. Der Opcode OP_CHECKSIGist codiert als 0xac. Aber das Anhängen an den Schlüssel erscheint albern (und funktioniert nicht). Außerdem CHECKSIGbenötigt der Opcode zwei Parameter. Was hashe ich?
Wenn Sie Elemente auf den Stapel verschieben, müssen Sie einen Opcode verwenden, um anzugeben, wie lang das Element ist, das Sie verschieben. In diesem Fall möchten Sie 33 Bytes verschieben, also OP_PUSH33
Ihr Skript wäre:
OP_PUSH33 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 OP_CHECKSIG
oder
210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac.
Dann wird Ihr Zeugenprogramm zu witprog = sha256(script)oder1863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262
Dann bech32 encodest du und du bekommstbc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3
Außerdem erfordert der CHECKSIG-Opcode zwei Parameter.
Der andere Parameter ist die Signatur und wird von der Person bereitgestellt, die die Coins als Teil ihrer scriptSig ausgibt. Ihr scriptPubkey ist nur die zweite Hälfte des Skripts, die erste Hälfte kommt aus der Eingabe.
Zunächst einmal, was versuchst du zu tun? Warum brauchen Sie eine P2WSH-Adresse?
Eine P2WSH-Adresse (und frühere P2SH-Adressen) senden Coins an ein Skript , das dieses Skript zum Decodieren erfüllen muss. Ein Skript des Formulars <key> CHECKSIGist verschwenderisch – Sie sollten stattdessen P2WPKH verwenden. Im Allgemeinen verwenden Sie P2WSH, wenn Sie komplexere Ausgabenanforderungen als einen einzelnen Schlüssel haben. Dies geschieht meistens, wenn Sie Multisig benötigen (mehrere Geräte oder Personen müssen sich für eine Ausgabe abmelden).
All dies liegt nun außerhalb des Geltungsbereichs von BIP173, das nur spezifiziert, wie Segwit-Ausgaben in für Menschen lesbare Zeichenfolgen und zurück codiert werden.
Eine Segwit-Ausgabe ist eine Ausgabe, deren scriptPubKey mit OP_0, OP_1, ..., OP_16 beginnt und von einem Push von 2 bis 40 Bytes gefolgt wird. Das war's, und BIP173 kann jedes davon codieren.
Nun, seit der Aktivierung von BIP141 in Bitcoin, wurde einer kleinen Teilmenge von Segwit-Ausgaben eine Bedeutung gegeben:
Alle anderen Arten von Segwit-Ausgaben sind derzeit bedeutungslos (nicht standardisiert und für jedermann verwendbar), aber das könnte sich in Zukunft ändern. Sie alle können jedoch mit BIP173 in Bech32 codiert werden. Es ist egal, was der Kontext oder die Bedeutung ist; es codiert nur die Versionsnummer (der OP_n-Opcode am Anfang) und die Datenbytes (was danach geschoben wird).
Vielleicht kommt Ihre Verwirrung daher, dass die BIP173-Testvektoren in ihren Beispielen "key + OP_CHECKSIG" verwenden. Das war nur eine einfache Art, Beispiele zu konstruieren, die reproduzierbar sind. Sie sind nicht repräsentativ für die tatsächliche Verwendung.
Schaden
OP_PUSH33war für mich beim Lesen von en.bitcoin.it/wiki/Script überhaupt nicht ersichtlich . Danke!