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
|
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 0796EC0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Feb 2020 22:37:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id E47B6226B3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Feb 2020 22:37:33 +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 mbg-wbBvH99q
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Feb 2020 22:37: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 1A93D2262F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Feb 2020 22:37:33 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1j2jaV-00020s-IP; Fri, 14 Feb 2020 17:37:31 -0500
Date: Fri, 14 Feb 2020 16:36:42 -0600
From: "David A. Harding" <dave@dtrt.org>
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200214223642.djdvosj7t7e6nrdz@ganymede>
References: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
<CABaSBawPJnoxf+9A0ocG_yec2fga+e1w2tk8_Tr6oj+FomDZZQ@mail.gmail.com>
<d42234f4-411c-40a6-dcb8-b9408c21ef16@gmail.com>
<CAD5xwhh=71XDAcSCJL9AQhZOriWmdGq4C5xT34K5wjR_g7FDfA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="3mlhegkhxq5pnnfo"
Content-Disposition: inline
In-Reply-To: <CAD5xwhh=71XDAcSCJL9AQhZOriWmdGq4C5xT34K5wjR_g7FDfA@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: Fri, 14 Feb 2020 22:37:34 -0000
--3mlhegkhxq5pnnfo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Feb 14, 2020 at 12:07:15PM -0800, Jeremy via bitcoin-dev wrote:
> Is the same if Schnorr + Merkle Branch without Taproot optimization, unle=
ss
> I'm missing something in one of the cases?=20
That's fair. However, it's only true if everyone constructs their
merkle tree in the same way, with a single `<schnorr_pk> OP_CHECKSIG` as
one of the top leaves. Taproot effectively standardizes the position
of the all-parties-agree condition and so its anonymity set may contain
spends from scripts whose creators buried or excluded the the all-agree
option because they didn't think it was likely to be used.
More importantly, there's no incentive for pure single-sig users to use a
merkle tree, since that would make both the scriptPubKey and the witness
data are larger for them than just continuing to use v0 segwit P2WPKH.
Given that single-sig users represent a majority of transactions at
present (see AJ Towns's previous email in this thread), I think we
really want to make it as convenient as possible for them to participate
in the anonymity set.
(To be fair, taproot scriptPubKeys are also larger than P2WPKH
scriptPubKeys, but its witness data is considerably smaller, giving
receivers an incentive to demand P2TR payments even if spenders don't
like paying the extra 12 vbytes per output.)
Rough sums:
- P2WPKH scriptpubkey (22.00 vbytes): `OP_0 PUSH20 <hash160>`
- P2WPKH witness data (26.75): `size(72) <sig>, size(33) <pubkey>`
- P2TR scriptpubkey (34.00): `OP_1 PUSH32 <pubkey>`
- P2TR witness data (16.25): `size(64) <sig>`
- BIP116 MBV P2WSH scriptpubkey (34.00): `OP_0 PUSH32 <sha256>`
- BIP116 MBV P2WSH witness data (42.00): `size(64) <signature>, size(32)
<pubkey>, size(32) <inclusion_proof>, size(36) <PUSH1 <n> PUSH32
<merkle_root> OP_MBV>`
-Dave
P.S. I think this branch of the thread is just rehashing points that
were originally covered over two years ago and which haven't really
changed since then. E.g.:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/01=
5629.html
--3mlhegkhxq5pnnfo
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl5HIPoACgkQ2dtBqWwi
adOvcw/+PleosTlGWrutQICesye0+PmA6SphSY/yj84t5eeRBVer3SNMYKyB3AnD
xoEpxqkOWUwHtUlo1KTop+NbsZhdReJsm6xQ8/k3MLYXHkvsdRitGWNynF/AuYT+
wg5gO2/FOA36msg5tJFI2+L/6Q5RnVMXaoOGju/ltohdyQ+ZuHpJ8o6RCVYllHAs
TLT3wQCODBWb324tvbGM2ZxbPdLfZvFeABZlodcOmXtcfygQaB37pLVi6y4cJUD3
AQLk+uYVFWRmY9NIqjSZo5c5ewZdJi4hfNEiY2DayiJPrJneEeHn9BtRLRgesoJr
oTo7Gu9YTH21he/WU4gUOW7Oc91SYs+4qbkO/hswc/VGwewA+V8pDsRVpSfl1gjz
Fp1YzgDAclzC8RwKmJrmg8tf1NuoenOY2V8IODQIuQOBWRPg2Tsphbbo8qy3bWwk
RZcTRCvJhp3w7qZNYc6aXVeBzig7lk57IuLGRtrLvMlRdCuYVzvOT8+EWU0rDzAk
WlV/xn1MumQDz7x2MqKaHh+w6qSnmhG/Vxl1fGuffrcnC10gOO0NznUxyw3kAD2w
ZhRlX0J7n04Q1Y3B11D2+UicE4Tk+M/d14Fjpyw5KUqGptqW8RI4yTyPDCDhw/cO
CE2I9rU6//pc8RCoRHkd5PDZuvskqZ8BXgF5/S17XbK5WfL+ZJ4=
=oChn
-----END PGP SIGNATURE-----
--3mlhegkhxq5pnnfo--
|
