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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
