2

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?

2 Answers 2

3

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

7
  • 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 blockstream.info?
    – sunknudsen
    Aug 4 at 16:23
  • @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. Aug 4 at 16:43
  • Re blockstream.info yeah there are lots of examples. The first Taproot multisig spend is here: blockstream.info/tx/… Aug 4 at 16:43
  • 2
    @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). Aug 5 at 13:51
  • 1
    That would be a security benefit, not a privacy benefit, though.
    – Murch
    Aug 5 at 15:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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