[bitcoin-dev] Taproot (and graftroot) complexity

[ZmnSCPxj]

Good morning The Group,

There are already many excellent arguments presented for Taproot, let me present a related one.

Notice your example MAST:

>
>       /\
>      /  \
>     /    \
>    /      \
>   /\      /\
>  /  \    /  \
> /\  /\  /\  /\
> a b c d e f g h

Of particular note is that the MAST has a predetermined set of scripts, `a` to `h`.

Now, practically speaking, each of these scripts `a`..`h` will be claimable by one or a number of known, pre-determined participants as well.
Scripts that do not have a pre-determined set of participants exist (e.g. a simple `OP_HASH160 <hash> OP_EQUAL` without any `OP_CHECKSIG` operations) but are generally not expected to actually be *useful* for a majority of use-cases (the above hash-only example could be double-spent by a majority miner, for example).
We expect a vast majority of scripts that will be in use will have a pre-determined fixed finitely-enumerable set of participants (so that miners cannot steal coins once the "solution" to the script puzzle is published in mempools), represented by pubkeys that are fed into `OP_CHECKSIG` operations in the script.

Since each script has (with high probability approaching 1.0) a pre-determined fixed finitely-enumerable set of participants within that script, and the entire MAST itself has a pre-determined fixed finitely-enumerable set of scripts, we can take the union of all sets of participants of all the scripts in the MAST.

Then we put the union of those sets as the signatories of a single Schnorr n-of-n multisignature, to be used as the Taproot keypath branch.

The advantage now is that with Taproot:

* If you can induce all participants to sign a transaction using the keypath spend, then you gain privacy (no part of the MAST is ever published, not even its root or the presence of the MAST!) *and* reduced onchain fees (because the MAST is not published and does not take up space on the blockchain).
  * You can incentivize cooperation (beyond just the incentive of improved privacy) by letting participants recover some of the saved onchain fees.
    Lightning does this, for example: the funder of the channel is the one paying for the closing fees, and the closing fee of the mutual close is almost always lower than the unilateral close case (or else is equal: the closing ritual has the unilateral close fee as the upper bound on whatever fee can be proposed at the mutual close ritual).
* Even if a participant does not cooperate (for example, it might have been hit by a rogue asteroid in the meantime) we still have the fallback of revealing the entire MAST.

(Just to be clear: I do not *currently* own any datacenters at locations that are likely to be hit by rogue asteroids.)

>From this, we can generally conclude that the Taproot assumption --- that there exists some finitely enumerable set of participants we can derive from the scripts needed to enforce a contract --- holds, at a probability near ~1.0, for almost all complicated contracts and protocols we would find useful.
Such contracts and protocols can then be Taproot-ized in order to gain some privacy and transaction size benefits.

Other optimizations, such as selecting k of the n participants as "key participants" who are the most likely to be online and interested in the conclusion of the contract, can then be used to reduce the n-of-n to k-of-n, but the basic Taproot "there exists some n-of-n" assumption still holds and this is just an optimization on top of that.

Regards,
ZmnSCPxj