Was sind die Standardformate für Transaktionsausgaben?

Eine Transaktionsausgabe kann den Typ haben

  • Pay-to-Public-Key-Hash, P2PKH, wobei das ScriptPubKey-Feld das folgende Format hat:

    76 a9 14 <20-Byte-Hash des Pubkey> 88 ac

  • Bezahlen Sie den Skript-Hash, P2SH, der z. B. für Multisig verwendet wird:

    a9 14 <20-Byte-Hash des Skripts> 87

Es gibt auch etwas namens P2WPKH und P2WSH. Können Sie mir zeigen, wie diese Ausgaben formatiert sind, und gibt es noch mehr mögliche Ausgabeformate als diese vier?

die SegWit-Formate: en.bitcoin.it/wiki/Segregated_Witness , oder hier: bitcoincore.org/en/segwit_wallet_dev . Und dann gab es in früheren Zeiten "Pay to Public Key" und die alten "Multisig"-Typen (nicht-P2SH). Ich bin mir nicht sicher, ob sie heute noch gültig sind.
Ich kannte das Pay-to-Public-Key-Format nicht. Interessant! Ich hatte vom "Multisig"-Typ gehört, bin aber nie darauf oder einer Beschreibung davon gestoßen.
Ich glaube, es hieß Bare Multisig. Und war BIP0011. Eine schnelle Suche im Forum: bitcoin.stackexchange.com/questions/29708/…

Antworten (1)

AFAIK gibt es 5 verschiedene Standard-Nicht-SegWit-Transaktionstypen und 4 SegWit-Transaktionstypen.

Nicht-SegWit:

Pay-to-Public-Key (P2PK)

PUSH (1 byte) + <compressed/uncompressed_pk> (33/65 bytes) + OP_CHECKSIG (1 byte)

Pay-to-Public-Key-Hash (P2PKH)

OP_DUP (1 byte) + OP_HASH160 (1 byte) + PUSH (1 byte) + <hash_160(PK)> (20 bytes) + OP_EQUALVERIFY (1 byte) + OP_CHECKSIG (1 byte)

Multisig (P2MS)

<number_of_PKs> (1 byte) PUSH (1 byte) <PK_0> (33/65 bytes) PUSH (1 byte) <PK_1> (33/65 bytes)  ... PUSH (1 byte) <PK_n-1> (33/65 bytes) OP_CHECKMULTISIG (1 byte)

P2MS erlaubt bis zu 15-15 Skripte, jedoch sind nur bis zu 3-3 Standard.

Pay-to-Script-Hash (P2SH)

OP_HASH160 (1 byte) + PUSH (1 byte) + <hash160(redeem_script)> (20 bytes) + OP_EQUAL (1 byte)

OP_Rückkehr

OP_RETURN (1 byte) PUSH (1 byte) <0 to 83 bytes of data>

SegWit:

In Bezug auf Segwit-Typen gibt es zwei nicht-native und zwei native.

Native Pay, um den Hash des öffentlichen Schlüssels zu bezeugen (P2WPKH)

OP_0 (1 byte) PUSH (1 byte) <hash 160(PK*)> (20 bytes)

Native Pay-to-Witness-Script-Hash (P2WSH)

OP_0 (1 byte) PUSH (1 byte) <script_hash> (32 bytes)

Pay-to-Witness-Public-Key-Hash, gekapselt in einem Pay-to-Script-Hash (P2SH-P2WPKH)

Das Redeem-Skript folgt der gleichen Struktur wie das native P2WPKH:

redeem_script = OP_0 (1 byte) PUSH (1 byte) <hash_160(PK*)> (20 bytes)

Während die externe Struktur des Skripts ( scriptPubKey) wie bei jedem anderen P2SH ist:

OP_HASH160 (1 byte) + PUSH (1 byte) + <hash_160(redeeem_script)> (20 bytes) + OP_EQUAL (1 byte)

Pay-to-Witness-Skript-Hash, gekapselt in einem Pay-to-Script-Hash (P2SH-P2WSH)

Das Redeem-Skript folgt der gleichen Struktur wie das native P2WSH:

redeem_script = OP_0 (1 byte) PUSH (1 byte) <script_hash> (32 bytes)

Während die externe Struktur des Skripts ( scriptPubKey) wie bei jedem anderen P2SH ist:

OP_HASH160 (1 byte) + PUSH (1 byte) + <hash_160(redeeem_script)> (20 bytes) + OP_EQUAL (1 byte)

*In P2WPKH-Skripten sollte der Hash 160 einem komprimierten öffentlichen Schlüssel entsprechen, da sonst das Geld verloren geht.

Danke dir. Aber ich verstehe Ihren letzten Satz nicht: "Nicht nativer Pay-to-Witness-Skript-Hash, der in einem Pay-to-Script-Hash (P2SH-P2WPKH) gekapselt ist, hat dieselbe Struktur." Können Sie das näher erläutern? Soweit ich verstanden habe, sind nicht-native Segwit-Ausgaben nicht von P2SH-Ausgaben zu unterscheiden.
Was ich meine ist, dass in P2SH-P2WPKH das Einlöseskript der Struktur des nativen P2WPKH folgt und in P2SH-P2WSH das Einlöseskript der Struktur des nativen P2WSH folgt. Ich werde es zur Klarstellung bearbeiten.
Beim Überprüfen der Antwort stellte ich fest, dass das OP_Return-Skript nicht auf dem neuesten Stand war. Die maximale zu übertragende Datenmenge beträgt seit Bitcoin Core 0.12 83 Bytes. Ich habe die Antwort aktualisiert, um sie zu korrigieren.
Könnte diese Antwort mit P2TR-Ausgängen aktualisiert werden?