0

Using bitcoind rpc, I have been looking at the content of 'vout' records for a few (coinbase) transactions and don't understand the difference between them.

Looking at block 710000, the coinbase transaction has 4 outputs. The first has a 'type' of 'pubkeyhash', the remainder have a type of 'nulldata'

Looking at block 176001, the coinbase transaction has 1 output with a 'type' of 'pubkey'.

Can you point me to a reference that lists and distinguishes the possible output types?

Is 'nulldata' because of the OP_RETURN? So is it true to say that any non-zero 'value' here would be burnt?

How should I interpret the data associated with 'pubkey'? It seems as though the actual address is not in the record. But if I look at a web-based blockchain explorer, it identifies the address. How is this done?

2 Answers 2

1

Is 'nulldata' because of the OP_RETURN?

Yes, I guess "nulldata" is just the name given to OP_RETURN scripts by the particular software you were using.

So is it true to say that any non-zero 'value' here would be burnt?

Yes.

It seems as though the actual address is not in the record.

Addresses are just a convenient human-readable abstract of a Bitcoin script, usually based on the hash of a public key (in the case of what has historically been the most common type of transaction output). As you noticed the script is present in the network message but the address is only derived from it by software presenting it to people.

1

Can you point me to a reference that lists and distinguishes the possible output types?

The Bitcoin Core software (as of version 22.0 (source)) will report one of the following names under "type" for each output:

  • pubkey: a script that pays to a public key directly (P2PK, <pubkey> OP_CHECKSIG); it has no corresponding address.
  • pubkeyhash: a script that pays to a public key's hash (P2PKH, OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG), corresponding to a 1... address.
  • scripthash: a script that pays to a script hash as defined by BIP16 (P2SH, OP_HASH160 <scripthash> OP_EQUAL), corresponding to a 3... address (defined in BIP13)
  • multisig: a (bare) k-of-n multisig script of the form <k> <pubkey1> <pubkey2> <pubkey3> ... <pubkey_n> <n> OP_CHECKMULTISIG; it has no correspondign address, and is very uncommon now.
  • witness_v0_keyhash: a native P2WPKH output defined in BIP141 (OP_0 <pubkeyhash>), corresponding to a 42-character bc1p... address (defined in BIP173).
  • witness_v0_scripthash: a native P2WSH output defined in BIP141 (OP_0 <scripthash>) corresponding to a 62-character bc1p... address (defined in BIP173).
  • witness_v1_taproot: a P2TR output defined in BIP341 (OP_1 <tweaked pubkey>) corresponding to a 62-character bc1q... address (defined in BIP350).
  • witness_unknown: a native segwit output that isn't P2WPKH, P2WSH, or P2TR (OP_<n> <payload>, for n=1..17 and payload between 2 and 40 characters), corresponding any other BIP350 address.
  • nulldata: an OP_RETURN output, burning coins.
  • nonstandard: anything not in the list above

Is 'nulldata' because of the OP_RETURN? So is it true to say that any non-zero 'value' here would be burnt?

Indeed.

How should I interpret the data associated with 'pubkey'? It seems as though the actual address is not in the record. But if I look at a web-based blockchain explorer, it identifies the address. How is this done?

Short answer: the blockchain explorer is wrong; this output has no address.

Longer answer: the term "address" has shifted meaning over time. Historically (pre 2012), address was a synonym for "public key identifier". The more modern meaning for address is "human-readable string that uniquely corresponds to a particular output script". There is no way in typical wallet software to construct payment to a "pubkey" (P2PK) script, and thus there is no address for it. However, one can take the public key in such a script, compute its public key hash, and then report the P2PKH address corresponding to that public key hash - resulting in a P2PKH that's in theory spendable by the same party as that address. That is what the explorer you're looking at is doing, and what lots of software historically used to do. It is now considered misleading at best, because sending to that address will not result in an output with the same script, and uses a practice of "converting" from one output type to another that is not generally possible (e.g. there is no obvious way to do the same for multisig addresses). Furthermore, it is dangerous, as the receiver may not be able to sign for outputs that use an unexpected script (e.g. if they are using an HSM with well-controlled signing logic that cannot be updated for security reasons).

1
  • I don't have a good enough reputation to upvote, but thank you
    – andrewr
    Mar 5 at 15:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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