Date: Mon, 10 Feb 2020 06:27:24 +0000
To: Bryan Bishop <kanzure@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <kdXmg-OpLQd2lmvvnukHEtQubIxp4RpJoAxM69NwRVPBXq2R6V3u31NpELB0o1PIviryWIaZ_tjZAnpmTFZm8syyQOkQeR1mHDexzoAuOoE=@protonmail.com>
In-Reply-To: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
References: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity
Precedence: list

Good morning The Group,

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

Notice your example MAST:

>
> =C2=A0 =C2=A0 =C2=A0 /\
> =C2=A0 =C2=A0 =C2=A0/=C2=A0 \
> =C2=A0 =C2=A0 /=C2=A0 =C2=A0 \
> =C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 \
> =C2=A0 /\=C2=A0 =C2=A0 =C2=A0 /\
> =C2=A0/=C2=A0 \=C2=A0 =C2=A0 /=C2=A0 \
> /\=C2=A0 /\=C2=A0 /\=C2=A0 /\
> 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 us=
e-cases (the above hash-only example could be double-spent by a majority mi=
ner, for example).
We expect a vast majority of scripts that will be in use will have a pre-de=
termined fixed finitely-enumerable set of participants (so that miners cann=
ot steal coins once the "solution" to the script puzzle is published in mem=
pools), represented by pubkeys that are fed into `OP_CHECKSIG` operations i=
n the script.

Since each script has (with high probability approaching 1.0) a pre-determi=
ned fixed finitely-enumerable set of participants within that script, and t=
he 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 scri=
pts 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 keypat=
h 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 (bec=
ause 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 alm=
ost always lower than the unilateral close case (or else is equal: the clos=
ing 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 rev=
ealing the entire MAST.

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

From this, we can generally conclude that the Taproot assumption --- that t=
here 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 usef=
ul.
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 part=
icipants" who are the most likely to be online and interested in the conclu=
sion 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 thi=
s is just an optimization on top of that.

Regards,
ZmnSCPxj