<p><strong>No, you can only determine the output type, but not the encoded spending conditions from another user's address. Whether a *SH output is committing funds to a multisig script only becomes knowable once the corresponding p2sh/witness script is published per a corresponding input.</strong></p>
<p>Native segwit outputs encode an amount, a witness version and a witness program. For <em>Pay to Witness Public Key Hash (P2WPKH)</em> the witness version is 0, and the witness program is a 20-byte hash of a public key. For <em>Pay to Witness Script Hash (P2WSH)</em> the witness version is also 0, and the witness program is a 32-byte hash of a witness script. The length is used to distinguish which rules to apply to these two different output types that share the same witness version.</p>
<p>As pointed out, P2WSH outputs commit funds to the hash of a witness script in the output script. Since sha256, the cryptographic hash function used here, produces fixed-length random-looking digests for data inputs of any length, the observer cannot learn anything about the content of the preimage by inspecting the hash. Thus, it's not possible to determine whether a P2WSH output encodes a multisig spending condition or another script¹ until the receiver reveals the script in a corresponding transaction input.</p>
<p>For Pay to Taproot (P2TR), the output script is composed of a witness version 1 followed by a 32-byte witness program that encodes a public key. Here, it's even more difficult to determine whether the output “is multisig” as the use of the Schnorr signature scheme drastically simplifies the implementation of key aggregation. This feature of P2TR outputs allows outputs to be controlled by multiple parties under the hood, but when all of them collaborate, to still be spent using an input that is indistinguishable from a single-sig input to third parties.</p>
<hr />
<sub>
¹ Bitcoin's _Script_ is a bonafide programming language, and P2WSH outputs permit a receiver to code-up any sort of spending conditions in their witness script. While many smartcontracts may be broadly about determining how to assign funds among multiple parties, I would consider “multisig” to refer to a simple “m-of-n multisig”. Other popular applications include e.g. the scripts used to facilitate Lightning Network channels, escrow services, or encoding multiple different spending conditions in one output of which some become available only after an extended wait-time.</sub>

CC BY-SA 4.0
2022-08-05T13:46:59.407Z
2022-08-17T20:27:26.513Z
2022-08-17T20:27:26.513Z
Murch
<p>A hashed script with multisig in it is the same length as a hashed script without multisig in it. So it is only revealed that it was a multisig when the script is revealed at spending time.</p>
<p>As you say the address type is revealed by its length or its prefix before spending time.</p>

CC BY-SA 4.0
2022-08-04T16:23:08.923Z
Interesting… are there any other significant use cases for using hashed scripts when receiving Bitcoin? “revealed at spending time” Can you please elaborate on this? Would you happen to have an example that illustrates multisig being revealed? Is this something we can see on https://blockstream.info?
sunknudsen
CC BY-SA 4.0
2022-08-04T16:43:20.340Z
@sunknudsen: The output of a hash is the same length regardless of the length of its input. From a privacy perspective it is clearly better that the script is only revealed when Bitcoin are spent from that address rather than being visible on the blockchain as soon as that address receives Bitcoin. Fees for revealing a long script are also charged to the eventual spender rather than the sender. The sender is just sending Bitcoin to the address they were asked to by the eventual spender.
Michael Folkson
CC BY-SA 4.0
2022-08-04T16:43:44.120Z
Re blockstream.info yeah there are lots of examples. The first Taproot multisig spend is here: https://blockstream.info/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530
Michael Folkson
CC BY-SA 4.0
2022-08-04T16:49:26.503Z
Note Taproot is a little different in that the entire script doesn't need to be revealed on spending, only the particular spending condition it is meeting. But that's a different question
Michael Folkson
CC BY-SA 4.0
2022-08-05T13:51:57.793Z
@MichaelFolkson I don't think there is much of a privacy benefit to hiding policies just at output time, if they get revealed at spending time anyway. The point of hashing scripts (or any kind of commitment) is so the sender doesn't need to know/care about what kind of policy the recipient is using. If you want a privacy gain, you need a way to not reveal the policy at all (which to some extent TR does, by only revealing the actually used branch).
Pieter Wuille
CC BY-SA 4.0
2022-08-05T13:55:41.277Z
In an attack scenario it is easier for the attacker to steal the funds if he knows the script pre spending time than if he doesn't :) I get your general point though.
Michael Folkson
CC BY-SA 4.0
2022-08-05T15:37:01.727Z
That would be a security benefit, not a privacy benefit, though.
Murch
CC BY-SA 4.0
2022-08-04T16:13:23.683Z
2022-08-04T16:13:23.683Z
Michael Folkson
<p>Studying privacy and security implications of revealing if a bc1 address belongs to a multisig wallet vs a regular wallet.</p>
<p>I do <a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#examples" rel="nofollow noreferrer">notice</a> that multisig bc1 addresses are longer than regular ones… P2WSH (62 characters long) vs P2WPKH (42 characters long).</p>
<p>So length reveals an instance of “Pay-to-Witness-Script-Hash”, but what about multisig specifically?</p>

<segregated-witness><multi-signature><bech32-address><address-format>
Can one infer that a bc1 address is multisig?
sunknudsen
# Can one infer that a bc1 address is multisig?

(Asked by: username_0 on 2022-08-04)

Studying privacy and security implications of revealing if a bc1 address belongs to a multisig wallet vs a regular wallet.

I do [notice](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#examples) that multisig bc1 addresses are longer than regular ones… P2WSH (62 characters long) vs P2WPKH (42 characters long).

So length reveals an instance of “Pay-to-Witness-Script-Hash”, but what about multisig specifically?

**Tags:** segregated-witness, multi-signature, bech32-address, address-format


---

## 2 answers

### Answer by username_1 on 2022-08-05. Score: 4

**No, you can only determine the output type, but not the encoded spending conditions from another user's address. Whether a \*SH output is committing funds to a multisig script only becomes knowable once the corresponding p2sh/witness script is published per a corresponding input.**

Native segwit outputs encode an amount, a witness version and a witness program. For *Pay to Witness Public Key Hash (P2WPKH)* the witness version is 0, and the witness program is a 20-byte hash of a public key. For *Pay to Witness Script Hash (P2WSH)* the witness version is also 0, and the witness program is a 32-byte hash of a witness script. The length is used to distinguish which rules to apply to these two different output types that share the same witness version.

As pointed out, P2WSH outputs commit funds to the hash of a witness script in the output script. Since sha256, the cryptographic hash function used here, produces fixed-length random-looking digests for data inputs of any length, the observer cannot learn anything about the content of the preimage by inspecting the hash. Thus, it's not possible to determine whether a P2WSH output encodes a multisig spending condition or another script¹ until the receiver reveals the script in a corresponding transaction input.

For Pay to Taproot (P2TR), the output script is composed of a witness version 1 followed by a 32-byte witness program that encodes a public key. Here, it's even more difficult to determine whether the output “is multisig” as the use of the Schnorr signature scheme drastically simplifies the implementation of key aggregation. This feature of P2TR outputs allows outputs to be controlled by multiple parties under the hood, but when all of them collaborate, to still be spent using an input that is indistinguishable from a single-sig input to third parties.

---

¹ Bitcoin's \_Script\_ is a bonafide programming language, and P2WSH outputs permit a receiver to code-up any sort of spending conditions in their witness script. While many smartcontracts may be broadly about determining how to assign funds among multiple parties, I would consider “multisig” to refer to a simple “m-of-n multisig”. Other popular applications include e.g. the scripts used to facilitate Lightning Network channels, escrow services, or encoding multiple different spending conditions in one output of which some become available only after an extended wait-time.


---

### Answer by username_2 on 2022-08-04. Score: 1

A hashed script with multisig in it is the same length as a hashed script without multisig in it. So it is only revealed that it was a multisig when the script is revealed at spending time.

As you say the address type is revealed by its length or its prefix before spending time.

> **Comments:**
> **username_0**: Interesting… are there any other significant use cases for using hashed scripts when receiving Bitcoin? “revealed at spending time” Can you please elaborate on this? Would you happen to have an example that illustrates multisig being revealed? Is this something we can see on https://blockstream.info?  
> **username_2**: @username_0: The output of a hash is the same length regardless of the length of its input. From a privacy perspective it is clearly better that the script is only revealed when Bitcoin are spent from that address rather than being visible on the blockchain as soon as that address receives Bitcoin. Fees for revealing a long script are also charged to the eventual spender rather than the sender. The sender is just sending Bitcoin to the address they were asked to by the eventual spender.  
> **username_2**: Re blockstream.info yeah there are lots of examples. The first Taproot multisig spend is here: https://blockstream.info/tx/905ecdf95a84804b192f4dc221cfed4d77959b81ed66013a7e41a6e61e7ed530  
> **username_2**: Note Taproot is a little different in that the entire script doesn't need to be revealed on spending, only the particular spending condition it is meeting. But that's a different question  
> **username_3**: @username_2 I don't think there is much of a privacy benefit to hiding policies just at output time, if they get revealed at spending time anyway. The point of hashing scripts (or any kind of commitment) is so the sender doesn't need to know/care about what kind of policy the recipient is using. If you want a privacy gain, you need a way to not reveal the policy at all (which to some extent TR does, by only revealing the actually used branch).  
> **username_2**: In an attack scenario it is easier for the attacker to steal the funds if he knows the script pre spending time than if he doesn't :) I get your general point though.  
> **username_1**: That would be a security benefit, not a privacy benefit, though.  

---

