<p>This is possible with every output type except for P2TR. Taproot introduced to the Bitcoin protocol Schnorr signatures and Merklized Alternative Script Trees, both of which can be used to hide the true number of participants in a multisig.</p>
<h2>Schnorr signatures</h2>
<p>Taproot uses a new signature scheme called Schnorr signatures, which allows key aggregation. A single public key can belong to one user or be aggregated from multiple users using an n-of-n scheme like MuSig2 or even a threshold m-of-n scheme like FROST/ROAST. This makes multisig transactions smaller and therefore cheaper, but it also means you cannot tell if a multisig even happened, let alone its size.</p>
<h2>Merklized Alternative Script Trees</h2>
<p>A P2TR output can optionally commit to a script tree (MAST). The key difference from previous output types is that you can now have many alternative spending conditions, and only reveal the one that you end up using.</p>
<p>Even without key aggregation, this allows you to obfuscate the actual size of your multisig. For example, if you want a 2-of-3 multisig, you can create a script tree with three different 2-of-2 multisigs: A&amp;B, B&amp;C and A&amp;C. Only one of these 2-of-2s will need to be revealed and nobody will be able to tell if the actual multisig was 2-of-2, 2-of-n for some higher n, or even a decoy multisig in which both keys were in fact owned by the same person.</p>
<p>You can use key aggregation in combination with script trees, for example to implement 2-of-3 using three different keys aggregated using 2-of-2 MuSig2. A <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-5" rel="nofollow noreferrer">footnote in BIP342</a> goes into a bit of detail on multisigs in script trees.</p>

CC BY-SA 4.0
2022-10-21T14:59:53.657Z
Thanks Vojtěch! So if I understand correctly, Schnorr signatures would completely obfuscate the multisig status. For MASTs however, would I be able to at least perform a binary check on whether there is/isn't a multisig present?
Bryan Oliveira
CC BY-SA 4.0
2022-10-21T15:08:30.080Z
Not exactly, because a single key present in a leaf script could still be an aggregated key from any number of users, or belong to a 1-of-n multisig construction. There's just no way to tell what the underlying contract looks like.
Vojtěch Strnad
CC BY-SA 4.0
2022-10-21T15:39:47.927Z
I see. Thanks for the excellent response Vojtěch.
Bryan Oliveira
CC BY-SA 4.0
2022-10-20T23:16:37.850Z
2022-10-20T23:16:37.850Z
Vojtěch Strnad
<p>If the multisig was implemented through a script that involves multiple signature checks, then yes. Taproot script path spends reveal the full script used, so a technique very similar to P2WSH could be used (the script is the penultimate script stack element rather than the last one, but other than that, it's pretty much the same).</p>
<p>However, that is not the only means of implementing multisig policies, and the other ones aren't as recognizable.</p>
<p>A possibility is that the k-of-n multisig is implemented using several disjoint leaves in the taproot script tree, each script implementing a different k-of-k subset of the k-of-n. In this case you can see there are at least k keys, and based on the depth of the tree you may be able to estimate n, but it very much depends on guessing correctly that this is even what's going on.</p>
<p>It gets even harder if the multisig policy is implemented through MuSig key aggregation (a single key that represents a k-of-k agreement of multisig signers), or FROST native threshold signing (a single key that represents a whole k-of-n policy). These may be entirely indistinguishable on chain from simple single key policies.</p>

CC BY-SA 4.0
2022-10-21T16:40:43.913Z
Thanks Pieter. For the Taproot script path spend, the technique (similar to P2WSH) you mention, is it checking if the last byes of the penultimate entry in the witness script stack are 'ae' of 'af'? Or what would that look like?
Bryan Oliveira
CC BY-SA 4.0
2022-10-21T16:47:46.533Z
(1) drop the annex (if the last witness stack element starts with byte 0x50, drop it) (2) if the (remaining) stack has only 1 element, it's a key path spend and not a script (3) check if it's a tapscript (identified by the final remaining start element starting with 0xc0 or 0xc1); if not, you know nothing. (4) analyze the script; CHECKMULTISIG(VERIFY) don't exist in tapscript, so the script will likely be "key1 CHECKSIGVERIFY key2 CHECKSIGVERIFY ... keyn CHECKSIG" (for n-of-n) or "key1 CHECKSIG key2 CHECKSIGADD ... keyn CHECKSIGADD k NUMEQUAL" for k-of-n.
Pieter Wuille
CC BY-SA 4.0
2022-10-20T23:05:21.543Z
2022-10-20T23:05:21.543Z
Pieter Wuille
<p>Given raw transaction input/output data, is it possible to know if a Taproot output is multisig or not?</p>
<p>I'm getting raw block data from a bitcoin node, and want to classify each spend according to the script (P2PKH, P2SH, P2WSH, P2WPKH, P2MS and P2TR).</p>
<p>I want to be able to tell if an output represents a multisig spend, in particular for Taproot (P2TR).</p>
<p>Furthermore, if multisig, would it be possible to infer M and N?</p>

<multi-signature><p2tr>
Can one infer the multisig status of a P2TR spend?
Bryan Oliveira
# Can one infer the multisig status of a P2TR spend?

(Asked by: username_0 on 2022-10-20)

Given raw transaction input/output data, is it possible to know if a Taproot output is multisig or not?

I'm getting raw block data from a bitcoin node, and want to classify each spend according to the script (P2PKH, P2SH, P2WSH, P2WPKH, P2MS and P2TR).

I want to be able to tell if an output represents a multisig spend, in particular for Taproot (P2TR).

Furthermore, if multisig, would it be possible to infer M and N?

**Tags:** multi-signature, p2tr


---

## 2 answers

### Answer by username_1 on 2022-10-20. Score: 1 | Accepted answer

This is possible with every output type except for P2TR. Taproot introduced to the Bitcoin protocol Schnorr signatures and Merklized Alternative Script Trees, both of which can be used to hide the true number of participants in a multisig.

## Schnorr signatures

Taproot uses a new signature scheme called Schnorr signatures, which allows key aggregation. A single public key can belong to one user or be aggregated from multiple users using an n-of-n scheme like MuSig2 or even a threshold m-of-n scheme like FROST/ROAST. This makes multisig transactions smaller and therefore cheaper, but it also means you cannot tell if a multisig even happened, let alone its size.

## Merklized Alternative Script Trees

A P2TR output can optionally commit to a script tree (MAST). The key difference from previous output types is that you can now have many alternative spending conditions, and only reveal the one that you end up using.

Even without key aggregation, this allows you to obfuscate the actual size of your multisig. For example, if you want a 2-of-3 multisig, you can create a script tree with three different 2-of-2 multisigs: A&B, B&C and A&C. Only one of these 2-of-2s will need to be revealed and nobody will be able to tell if the actual multisig was 2-of-2, 2-of-n for some higher n, or even a decoy multisig in which both keys were in fact owned by the same person.

You can use key aggregation in combination with script trees, for example to implement 2-of-3 using three different keys aggregated using 2-of-2 MuSig2. A [footnote in BIP342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-5) goes into a bit of detail on multisigs in script trees.

> **Comments:**
> **username_0**: Thanks username_1! So if I understand correctly, Schnorr signatures would completely obfuscate the multisig status. For MASTs however, would I be able to at least perform a binary check on whether there is/isn't a multisig present?  
> **username_1**: Not exactly, because a single key present in a leaf script could still be an aggregated key from any number of users, or belong to a 1-of-n multisig construction. There's just no way to tell what the underlying contract looks like.  
> **username_0**: I see. Thanks for the excellent response username_1.  

---

### Answer by username_2 on 2022-10-20. Score: 0

If the multisig was implemented through a script that involves multiple signature checks, then yes. Taproot script path spends reveal the full script used, so a technique very similar to P2WSH could be used (the script is the penultimate script stack element rather than the last one, but other than that, it's pretty much the same).

However, that is not the only means of implementing multisig policies, and the other ones aren't as recognizable.

A possibility is that the k-of-n multisig is implemented using several disjoint leaves in the taproot script tree, each script implementing a different k-of-k subset of the k-of-n. In this case you can see there are at least k keys, and based on the depth of the tree you may be able to estimate n, but it very much depends on guessing correctly that this is even what's going on.

It gets even harder if the multisig policy is implemented through MuSig key aggregation (a single key that represents a k-of-k agreement of multisig signers), or FROST native threshold signing (a single key that represents a whole k-of-n policy). These may be entirely indistinguishable on chain from simple single key policies.

> **Comments:**
> **username_0**: Thanks username_2. For the Taproot script path spend, the technique (similar to P2WSH) you mention, is it checking if the last byes of the penultimate entry in the witness script stack are 'ae' of 'af'? Or what would that look like?  
> **username_2**: (1) drop the annex (if the last witness stack element starts with byte 0x50, drop it) (2) if the (remaining) stack has only 1 element, it's a key path spend and not a script (3) check if it's a tapscript (identified by the final remaining start element starting with 0xc0 or 0xc1); if not, you know nothing. (4) analyze the script; CHECKMULTISIG(VERIFY) don't exist in tapscript, so the script will likely be "key1 CHECKSIGVERIFY key2 CHECKSIGVERIFY ... keyn CHECKSIG" (for n-of-n) or "key1 CHECKSIG key2 CHECKSIGADD ... keyn CHECKSIGADD k NUMEQUAL" for k-of-n.  

---

