user96549: Studying privacy and security implications of revealing if a bc1 address belongs to a multisig wallet vs a regular wallet.
I do notice 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?

user47827: 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.

user5406: 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.

96549: <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>
 47827: <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>
 5406: <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>
