Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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 goes into a bit of detail on multisigs in script trees.
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.
