1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id A82C1C0171
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Feb 2020 06:27:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id A21EF20104
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Feb 2020 06:27:35 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id obMYzjZlj5eO
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Feb 2020 06:27:33 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by silver.osuosl.org (Postfix) with ESMTPS id 5DAD32001A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Feb 2020 06:27:33 +0000 (UTC)
Date: Mon, 10 Feb 2020 06:27:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1581316050;
bh=t8khOVJ6mqPpXFbpSF5UyuJp7XkICQiauuwKc2Hid28=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=x8NW8pXFHqYECq0DOnC0ohpn3BCdBpyAkFGklUhgjQFYoMuGPMl5OTPQXa62pWGhb
xmyDq/60Odf/2XqYUDiC41kaDQVz2uWibnCZPiswActiVxx5EoqnTuarLVelG4rUli
V4+QAa5XaIt++gOxzr7ptq9O2CN+45N14m8VQ+r4=
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2020 06:27:35 -0000
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
|
