<blockquote>
<p><strong>Is 'nulldata' because of the OP_RETURN?</strong></p>
</blockquote>
<p>Yes, I guess &quot;nulldata&quot; is just the name given to OP_RETURN scripts by the particular software you were using.</p>
<blockquote>
<p><strong>So is it true to say that any non-zero 'value' here would be burnt?</strong></p>
</blockquote>
<p><a href="https://en.bitcoin.it/wiki/OP_RETURN" rel="nofollow noreferrer">Yes</a>.</p>
<blockquote>
<p><strong>It seems as though the actual address is not in the record.</strong></p>
</blockquote>
<p>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.</p>

CC BY-SA 4.0
2022-02-28T19:05:30.337Z
2022-02-28T19:05:30.337Z
RedGrittyBrick
<blockquote>
<p>Can you point me to a reference that lists and distinguishes the possible output types?</p>
</blockquote>
<p>The Bitcoin Core software (as of version 22.0 <a href="https://github.com/bitcoin/bitcoin/blob/v22.0/src/script/standard.cpp#L52L61" rel="nofollow noreferrer">(source)</a>) will report one of the following names under &quot;type&quot; for each output:</p>
<ul>
<li><strong><code>pubkey</code></strong>: a script that pays to a public key directly (P2PK, <code>&lt;pubkey&gt; OP_CHECKSIG</code>); it has no corresponding address.</li>
<li><strong><code>pubkeyhash</code></strong>: a script that pays to a public key's hash (P2PKH, <code>OP_DUP OP_HASH160 &lt;pubkeyhash&gt; OP_EQUALVERIFY OP_CHECKSIG</code>), corresponding to a <code>1...</code> address.</li>
<li><strong><code>scripthash</code></strong>: a script that pays to a script hash as defined by <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="nofollow noreferrer">BIP16</a> (P2SH, <code>OP_HASH160 &lt;scripthash&gt; OP_EQUAL</code>), corresponding to a <code>3...</code> address (defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki" rel="nofollow noreferrer">BIP13</a>)</li>
<li><strong><code>multisig</code></strong>: a (bare) k-of-n multisig script of the form <code>&lt;k&gt; &lt;pubkey1&gt; &lt;pubkey2&gt; &lt;pubkey3&gt; ... &lt;pubkey_n&gt; &lt;n&gt; OP_CHECKMULTISIG</code>; it has no corresponding address, and is very uncommon now.</li>
<li><strong><code>witness_v0_keyhash</code></strong>: a native P2WPKH output defined in BIP141 (<code>OP_0 &lt;pubkeyhash&gt;</code>), corresponding to a 42-character <code>bc1p...</code> address (defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP173</a>).</li>
<li><strong><code>witness_v0_scripthash</code></strong>: a native P2WSH output defined in BIP141 (<code>OP_0 &lt;scripthash&gt;</code>) corresponding to a 62-character <code>bc1p...</code> address (defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="nofollow noreferrer">BIP173</a>).</li>
<li><strong><code>witness_v1_taproot</code></strong>: a P2TR output defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">BIP341</a> (<code>OP_1 &lt;tweaked pubkey&gt;</code>) corresponding to a 62-character <code>bc1q...</code> address (defined in <a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki" rel="nofollow noreferrer">BIP350</a>).</li>
<li><strong><code>witness_unknown</code></strong>: a native segwit output that isn't P2WPKH, P2WSH, or P2TR (<code>OP_&lt;n&gt; &lt;payload&gt;</code>, for n=1..17 and payload between 2 and 40 characters), corresponding any other <a href="https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki" rel="nofollow noreferrer">BIP350</a> address.</li>
<li><strong><code>nulldata</code></strong>: an OP_RETURN output, burning coins.</li>
<li><strong><code>nonstandard</code></strong>: anything not in the list above</li>
</ul>
<blockquote>
<p>Is 'nulldata' because of the OP_RETURN? So is it true to say that any non-zero 'value' here would be burnt?</p>
</blockquote>
<p>Indeed.</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>Short answer: the blockchain explorer is wrong; this output <em>has no</em> address.</p>
<p>Longer answer: the term &quot;address&quot; has shifted meaning over time. Historically (pre 2012), address was a synonym for &quot;public key identifier&quot;. The more modern meaning for address is &quot;human-readable string that uniquely corresponds to a particular output script&quot;. There is no way in typical wallet software to construct payment to a &quot;pubkey&quot; (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 &quot;converting&quot; 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).</p>

CC BY-SA 4.0
2022-03-05T15:55:33.123Z
I don't have a good enough reputation to upvote, but thank you
andrewr
CC BY-SA 4.0
2022-02-28T19:29:29.593Z
2023-03-08T23:36:22.840Z
2023-03-08T23:36:22.840Z
Pieter Wuille
<p>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.</p>
<p>Looking at block 710000, the coinbase transaction has 4 outputs. The first has a 'type' of 'pubkeyhash', the remainder have a type of 'nulldata'</p>
<p>Looking at block 176001, the coinbase transaction has 1 output with a 'type' of 'pubkey'.</p>
<p>Can you point me to a reference that lists and distinguishes the possible output types?</p>
<p>Is 'nulldata' because of the OP_RETURN? So is it true to say that any non-zero 'value' here would be burnt?</p>
<p>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?</p>

<transactions><bitcoind>
different 'vout' formats
andrewr
# different 'vout' formats

(Asked by: username_0 on 2022-02-28)

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?

**Tags:** transactions, bitcoind


---

## 2 answers

### Answer by username_1 on 2022-02-28. Score: 2

> **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](https://en.bitcoin.it/wiki/OP_RETURN).

> **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.


---

### Answer by username_2 on 2022-02-28. Score: 2

> 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)](https://github.com/bitcoin/bitcoin/blob/v22.0/src/script/standard.cpp#L52L61)) 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](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki) (P2SH, `OP_HASH160 <scripthash> OP_EQUAL`), corresponding to a `3...` address (defined in [BIP13](https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki))
* **`multisig`**: a (bare) k-of-n multisig script of the form `<k> <pubkey1> <pubkey2> <pubkey3> ... <pubkey_n> <n> OP_CHECKMULTISIG`; it has no corresponding 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](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)).
* **`witness_v0_scripthash`**: a native P2WSH output defined in BIP141 (`OP_0 <scripthash>`) corresponding to a 62-character `bc1p...` address (defined in [BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)).
* **`witness_v1_taproot`**: a P2TR output defined in [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) (`OP_1 <tweaked pubkey>`) corresponding to a 62-character `bc1q...` address (defined in [BIP350](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki)).
* **`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](https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) 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).

> **Comments:**
> **username_0**: I don't have a good enough reputation to upvote, but thank you  

---

