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
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
Return-Path: <dave@dtrt.org>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id E2B4FC0171
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Feb 2020 00:17:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id D7FCD20110
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Feb 2020 00:17:34 +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 6Sr2ozi7DoKy
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Feb 2020 00:17:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by silver.osuosl.org (Postfix) with ESMTPS id 5205D20104
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Feb 2020 00:17:33 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>) id 1j0wlX-0002yl-SJ
for bitcoin-dev@lists.linuxfoundation.org; Sun, 09 Feb 2020 19:17:31 -0500
Date: Sun, 9 Feb 2020 18:15:54 -0600
From: "David A. Harding" <dave@dtrt.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200210001554.dafhn5ppakcmsj4f@ganymede>
References: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
<CABaSBawPJnoxf+9A0ocG_yec2fga+e1w2tk8_Tr6oj+FomDZZQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="4ah4jcfub2ot2nmx"
Content-Disposition: inline
In-Reply-To: <CABaSBawPJnoxf+9A0ocG_yec2fga+e1w2tk8_Tr6oj+FomDZZQ@mail.gmail.com>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)
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 00:17:35 -0000
--4ah4jcfub2ot2nmx
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 09, 2020 at 02:47:29PM -0600, Anon via Bryan Bishop via bitcoin=
-dev wrote:
> 1) Is Taproot actually more private than bare MAST and Schnorr separately?
Yes.
> What are the actual anonymity set benefits compared to doing the separate=
ly?
When schnorr and taproot are done together, all of the following
transaction types can be part of the same set:
- single-sig spends (similar to current use of P2PKH and P2WPKH)
- n-of-n spends with musig or equivalent (similar to current use of
P2SH and P2WSH 2-of-2 multisig without special features as used by
Blockstream Green and LN mutual closes)
- k-of-n (for low values of n) using the most common k signers
(similar to BitGo-style 2-of-3 where the keys involved are
alice_hot, alice_cold, and bob_hot and almost all transactions are
expected to be signed by {alice_hot, bob_hot}; that common case
can be the key-path spend and the alternatives {alice_hot,
alice_cold} and {alice_cold, bob_hot} can be script-path spends)
- contract protocols that can sometimes result in all parties
agreeing on an outcome (similar to LN mutual closes, cross-chain
atomic swaps, and same-chain coinswaps)
The four cases above represent an overwhelming percentage of the spends
seen on the block chain today and throughout Bitcoin's entire history to
date, so optimizing to include them in the anonymity set presents a huge
benefit.
> 2) Is Taproot actually cheaper than bare MAST and Schnorr separately?=20
Earlier in y'alls email, you claim that the difference between the two
approaches for a particular example is 67 bytes. I haven't checked that
calculation, but it seems you're talking entirely about bytes that could
appear in the witness data and so would only represent 16.75 vbytes.
Compare that to the size of the other elements which would need to be
part of a typical input:
- (36 vbytes) outpoint
- (1) scriptSig compactSize uint
- (4) nSequence=20
- (16.25) schnorr signature (includes size byte)
That's 57.25 vbytes exclusive of your example data or 74.00 vbytes
inclusive. That means the overhead you're concerned about adds only
about 23% to the size of the input (or 30% on an exclusive basis).
That's definitely worth considering optimizations for, but I'm
personally ok with requiring users of advanced scripts (who can't manage
to produce mutual closes) pay an extra 23% for their inputs in order to
allow the creation of the large anonymity set described above for all
the other cases.
If, subsequent to deployment, large numbers of users do end up using
taproot script-path spends and we want to make things more fair, we can
even out the weighting, perhaps by simply increasing the weight of
key-path spends by 16.75 vbytes (though that would, of course,
proportionally lower the capacity of the block chain). As mentioned in
a separate email by Matt Corallo, it seems worthwhile to optimize for
the case where script-path spenders are encouraged to look for
mutually-agreed contract resolutions in order to both minimize block
chain use and increase the size of the anonymity set.
> What evidence do we have that the assumption it will be more common to
> use Taproot with a key will outweigh Script cases?
The evidence that current users of single-sig, n-of-n, and k-of-n (for
small n) with a default k-set, and mutual-agreed contract protocol
outcomes vastly outweigh all other transaction inputs today and for all
of Bitcoin's history to date.
-Dave
--4ah4jcfub2ot2nmx
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl5AoLoACgkQ2dtBqWwi
adMFzBAAj9l5U1T0pnRrA8/2LWQLmuETF4kaNEcM294nkIfk18MivBIxFjiAjPwn
mRciyGTPYktSkU2/gbvaGTnGejkI2MH+LpIDlxw79xvKrrOw+ozYMFUzvTSRQRY8
O4jmXFSzUTKJbMLfQgfPSZk/ut+wQ2gUI9ZUiiFpPzqUCKlZ4+/HOYNnXimcBjXz
I4uDGMcQp27GL9/5rOBc7zBMekg3TczQbrlZaVYbLCr0Gwa+RJaj05EasAFpej2c
YPhfMORfslw7fBww+Xsllre3wOF1TpBllBJ9uenI2ZDB8xmEU+oITtwSVrMbVo9C
yEIS4wTpvUAAHqhHckTpScU3eXCGSmM5Y4ktI6pNDBM6hBAI6xVsrutp0Tdxwacd
vN5u+rsWVJJ891gOFR0l33z32XvEza4p7LF34b0CXSo4U7KBzzDOK0pxJYidyMob
7u5xTiV3ue8su3EQXV4S9YrfLBMiH/Xxt3t2wDPASloO5HhGOBscmB2tCX0h6i59
cfrGOsNjDBbg1pl9RkTex7VviVkG9n8J9renPPPUGkeK0LAfpJ1csvtSkx/1Sq1e
YeLo1fNsEhwdWY4wexoOkAZ5czBodgY9UZjCqVLCogt5rlXNJqUz7xP/O09izAjm
tufZvMEwmhRiYIglzI4yF4D5LzeIryyJxTQ2KJeqftsUtvckZNM=
=FApq
-----END PGP SIGNATURE-----
--4ah4jcfub2ot2nmx--
|
