A transaction output can have the type

  • Pay to public key hash, P2PKH, where the ScriptPubKey field has the format:

    76 a9 14 <20-byte hash of pubkey> 88 ac

  • Pay to script hash, P2SH, used for e.g. multisig:

    a9 14 <20-byte hash of script> 87

There is also something called P2WPKH and P2WSH. Can you show me how these outputs are formatted, and are there any more possible output formats than these four?

up vote 5 down vote accepted

AFAIK there are 5 different standard non-SegWit transaction types, and 4 SegWit ones.

Non-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 allow up to 15-15 scripts, however only up to 3-3 are standard.

Pay to script hash (P2SH)

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

OP_Return

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

SegWit:

Regarding segwit types, there are two non-native and two native ones.

Native Pay to witness public key hash (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 encapsulated in a pay to script hash (P2SH-P2WPKH)

The redeem script follows the same structure than native P2WPKH:

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

While the external structure of the script (scriptPubKey) is as any other P2SH:

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

Pay to witness script hash encapsulated in a pay to script hash (P2SH-P2WSH)

The redeem script follows the same structure than native P2WSH:

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

While the external structure of the script (scriptPubKey) is as any other P2SH:

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

*In P2WPKH scripts the hash 160 should correspond to a compressed public key, otherwise the funds will be lost.

  • Thank you. But I do not understand your last sentence: "Non-native pay to witness script hash encapsulated in a pay to script hash (P2SH-P2WPKH) have the same structure." Can you elaborate on that? As far as I understood, non-native segwit outputs are indistinguishable from P2SH-outputs. – Thorkil Værge Apr 11 at 16:42
  • What I ment is that in P2SH-P2WPKH the redeem script follows the structure of the native P2WPKH and in the P2SH-P2WSH the redeem script follows the structure of the native P2WSH. I'll edit it for clarification. – sr-gi Apr 11 at 19:43
  • 1
    Reviewing the answer I realized that the OP_Return script was not up to date. The max amount of data to be pushed is 83 bytes since Bitcoin Core 0.12. I've updated the answer to correct it. – sr-gi Apr 20 at 9:36

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.