From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Bryan Bishop <kanzure@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity
Date: Mon, 10 Feb 2020 06:27:24 +0000 [thread overview]
Message-ID: <kdXmg-OpLQd2lmvvnukHEtQubIxp4RpJoAxM69NwRVPBXq2R6V3u31NpELB0o1PIviryWIaZ_tjZAnpmTFZm8syyQOkQeR1mHDexzoAuOoE=@protonmail.com> (raw)
In-Reply-To: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
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
next prev parent reply other threads:[~2020-02-10 6:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-09 20:19 Bryan Bishop
2020-02-09 20:22 ` [bitcoin-dev] An alternative deployment path for taproot technology (Re: Taproot (and graftroot) complexity) Bryan Bishop
2020-02-09 20:24 ` [bitcoin-dev] Taproot public NUMS optimization " Bryan Bishop
2020-02-14 21:21 ` Jeremy
2020-02-09 20:40 ` [bitcoin-dev] Taproot (and graftroot) complexity Matt Corallo
2020-02-09 22:32 ` Antoine Riard
2020-02-09 20:47 ` [bitcoin-dev] Taproot (and graftroot) complexity (reflowed) Bryan Bishop
2020-02-10 0:15 ` David A. Harding
2020-02-10 16:28 ` Jonas Nick
2020-02-14 20:07 ` Jeremy
2020-02-14 22:36 ` David A. Harding
2020-02-18 23:29 ` Pieter Wuille
2020-02-10 0:20 ` [bitcoin-dev] Taproot (and graftroot) complexity Anthony Towns
2020-02-10 6:27 ` ZmnSCPxj [this message]
[not found] <<20200210002011.lelhcdmjejmoh6xv@erisian.com.au>
2020-09-19 7:13 ` Jay Berg
2020-09-19 8:46 ` Jay Berg
2020-09-19 12:52 Jay Berg
2020-09-20 3:23 ` Lloyd Fournier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='kdXmg-OpLQd2lmvvnukHEtQubIxp4RpJoAxM69NwRVPBXq2R6V3u31NpELB0o1PIviryWIaZ_tjZAnpmTFZm8syyQOkQeR1mHDexzoAuOoE=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=kanzure@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox