1

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

Image 2:

Image 2

1 Answer 1

5

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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