<p>This is unrelated to taproot.</p>
<p>The &quot;addresses&quot; field in Bitcoin Core's RPC output was historical legacy that was at best outdated, and at worst confusing. Since 22.0 the field has been deprecated entirely, for all types of transaction outputs. It can (temporarily) be re-enabled using <code>-deprecatedrpc=addresses</code>, but in 23.0 it will be gone entirely. My suggestion is not to use it, because even when it works, it probably doesn't mean what you think it does.</p>
<p>In the modern interpretation, an &quot;address&quot; is a human-readable shorthand notation for a specific &quot;locking script&quot; (scriptPubKey) that can be placed in transaction outputs. Even when the output encodes a multisig policy, there is just one locking script, and thus just one address.</p>
<p>The historical interpretation (before the introduction of BIP16 in 2012, but it lingered on much longer) was that an address is an identifier for a public key. This interpretation is what led to having an &quot;addresses&quot; field in the RPC output; whenever there is a locking script with multiple public keys in it, the &quot;address&quot; identifier of each would be reported in that RPC field.</p>
<p>This historical interpretation is meaningless now, and has been for a long time. The reason is that multisig outputs today don't put multiple keys in the scriptPubKey. Instead they use P2SH (BIP16) or P2WSH (BIP141) to only put a <em>hash</em> of the script that includes all the public keys in the scriptPubKey. This is cheaper, simpler, and somewhat more private. From such outputs, despite being a multisig policy, the RPC output cannot infer the individual public keys, because they are only revealed by the spender at spending time, and for such outputs, the RPC would still only report 1 address.</p>
<p>It is no different for P2TR (taproot) outputs. There are no individual public keys that can be learned from the scriptPubKey, and thus the RPC output would only report a single &quot;address&quot; (the P2TR address).</p>

CC BY-SA 4.0
2021-11-19T14:03:45.680Z
2021-11-19T14:03:45.680Z
Pieter Wuille
<p>Before taproot when we had a multisig transaction the vout had an array of addresses(Image 1). Now, this multisig transaction in Bitcoin core v22.0 is represented only as a multisig type without the address field(Image 2). From my basic understanding, taproot improves the way multisig transactions are signed using Schnorr's signature. How are the addresses in vout represented? Are they abstracted in the same way(hiding the address field) as done for pre-taproot multisig transactions? Thanks in advance.</p>
<p>Image 1:</p>
<p><a href="https://i.sstatic.net/2RP9x.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/2RP9x.png" alt="Image 1" /></a></p>
<p>Image 2:</p>
<p><a href="https://i.sstatic.net/r4H3u.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/r4H3u.png" alt="Image 2" /></a></p>

<bitcoin-core-development><multi-signature><taproot>
Multisig transactions after taproot
Jithin Zachariah
# Multisig transactions after taproot

(Asked by: username_0 on 2021-11-19)

Before taproot when we had a multisig transaction the vout had an array of addresses(Image 1). Now, this multisig transaction in Bitcoin core v22.0 is represented only as a multisig type without the address field(Image 2). From my basic understanding, taproot improves the way multisig transactions are signed using Schnorr's signature. How are the addresses in vout represented? Are they abstracted in the same way(hiding the address field) as done for pre-taproot multisig transactions? Thanks in advance.

Image 1:

[![Image 1](https://i.sstatic.net/2RP9x.png)](https://i.sstatic.net/2RP9x.png)

Image 2:

[![Image 2](https://i.sstatic.net/r4H3u.png)](https://i.sstatic.net/r4H3u.png)

**Tags:** bitcoin-core-development, multi-signature, taproot


---

## 1 answers

### Answer by username_1 on 2021-11-19. Score: 5 | Accepted answer

This is unrelated to taproot.

The "addresses" field in Bitcoin Core's RPC output was historical legacy that was at best outdated, and at worst confusing. Since 22.0 the field has been deprecated entirely, for all types of transaction outputs. It can (temporarily) be re-enabled using `-deprecatedrpc=addresses`, but in 23.0 it will be gone entirely. My suggestion is not to use it, because even when it works, it probably doesn't mean what you think it does.

In the modern interpretation, an "address" is a human-readable shorthand notation for a specific "locking script" (scriptPubKey) that can be placed in transaction outputs. Even when the output encodes a multisig policy, there is just one locking script, and thus just one address.

The historical interpretation (before the introduction of BIP16 in 2012, but it lingered on much longer) was that an address is an identifier for a public key. This interpretation is what led to having an "addresses" field in the RPC output; whenever there is a locking script with multiple public keys in it, the "address" identifier of each would be reported in that RPC field.

This historical interpretation is meaningless now, and has been for a long time. The reason is that multisig outputs today don't put multiple keys in the scriptPubKey. Instead they use P2SH (BIP16) or P2WSH (BIP141) to only put a *hash* of the script that includes all the public keys in the scriptPubKey. This is cheaper, simpler, and somewhat more private. From such outputs, despite being a multisig policy, the RPC output cannot infer the individual public keys, because they are only revealed by the spender at spending time, and for such outputs, the RPC would still only report 1 address.

It is no different for P2TR (taproot) outputs. There are no individual public keys that can be learned from the scriptPubKey, and thus the RPC output would only report a single "address" (the P2TR address).


---

