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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
|
Return-Path: <kanzure@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id E2C7CC0171
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 20:24:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id D22CE83B2F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 20:24:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id zedWEzbCDuFE
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 20:24:45 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-vk1-f182.google.com (mail-vk1-f182.google.com
[209.85.221.182])
by whitealder.osuosl.org (Postfix) with ESMTPS id D027D84F12
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 9 Feb 2020 20:24:44 +0000 (UTC)
Received: by mail-vk1-f182.google.com with SMTP id i78so1247322vke.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 09 Feb 2020 12:24:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=LevkX+EEdvgCBfPhJyIEzJLd78OSv+Pu3/ykixnt2uw=;
b=ax5/xdZh+cfPoxDb/hJk3EP1OKEp2H2ykeywa1PTHGbqhtEB8CX47ZiMTulg4vh9F5
BQWB8mc4xT3ge+1VabmJ4+HLQmdiwMcDfAKo34U1fGtQnO0VM3CdsPxWQz3sVVmjP20j
rTY1dq03kZsGf51fklKI0RAPKDCVOTArKFh3BUtBXSDV31a1wEZGVynG1lzhT+u3TKm6
feIQIKokHX9q8gMzeaS52UCxl0gSPppqXiAflRYwmxuyR1lvxcpe5ZsH7nc3NmVRVAqy
GvG+b+e6vuL7yon4Uzx7pwzLXUYiyKqiKj8ZOJuwNK6vGUEzl/gPQRjKrXtFaXQnHZz9
06Uw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=LevkX+EEdvgCBfPhJyIEzJLd78OSv+Pu3/ykixnt2uw=;
b=PXsj7ubXZLdNnp3jkeTGyqM1YdGzTfFmUtHOZN/G/Ej+sLmzRHvXE9NuHoXzxvsIgU
MKLeg5Wg2jVC7Ud18slqdtcvVDd12jheYiYvt6I3SDt9z48HO13pTVd/bbAJ8VqefeZO
1bx8xJlk+qL3mdtPHVg+MhLiB/jg1JKgEnRXo4kzLkjz/2xmiHBncc537RXnZ2X7qTAl
6y5O4zyw8PpKbAsjjdK5D0AI0AduDPIoSEmqRXIYPicLsnjuIVD3g+u21JEDtDHaLa1E
cICXTSpCoowoPAwBuWgs7riKIFlldY1JRw/jnXXyXvVPyu2B0c28UVM5MH7id65t5PyT
ky+g==
X-Gm-Message-State: APjAAAVwMGD37Z9HBr26voETCzBhGL1qXebTkcA5mZCY9cGo5VrRUwYN
6seKjy/fgdgGMvt9W+8+yWXSmF3WNxMHlT/hrWl9kqST
X-Google-Smtp-Source: APXvYqwO0btEiT2iYtlyuzw6MPwJI3qr9Sf+Hb3hprcx2GYoD6f4Ph+KiIpF/SlaQ8Qvl8CJPXaXJfK790t6RxkcrBE=
X-Received: by 2002:a1f:434b:: with SMTP id q72mr4560850vka.53.1581279883487;
Sun, 09 Feb 2020 12:24:43 -0800 (PST)
MIME-Version: 1.0
References: <CABaSBaxgdfeyPrnaJD+Gs-5agV4sX+b66ZA6AfkjiHvuE0JSXA@mail.gmail.com>
<CABaSBazBAfWSBYygQL4QuBbWQ5ogxhMH36pvHQBNvoJMd6RtjA@mail.gmail.com>
In-Reply-To: <CABaSBazBAfWSBYygQL4QuBbWQ5ogxhMH36pvHQBNvoJMd6RtjA@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
Date: Sun, 9 Feb 2020 14:24:32 -0600
Message-ID: <CABaSBaycBpXVhh0q7hHe05_=4nsR0ExWgQOsGwmNWZJWyggBgg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Bryan Bishop <kanzure@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000beef85059e2a695a"
Subject: [bitcoin-dev] Taproot public NUMS optimization (Re: 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: Sun, 09 Feb 2020 20:24:46 -0000
--000000000000beef85059e2a695a
Content-Type: text/plain; charset="UTF-8"
The following is a message forwarded from an anonymous email that, for
whatever reason, couldn't be relayed through the mailing list without my
assistance. This is message (3/3).
This email is the third of a collection of sentiments from a group of
developers
who in aggregate prefer to remain anonymous. These emails have been sent
under a
pseudonym so as to keep the focus of discussion on the merits of the
technical
issues, rather than miring the discussion in personal politics. Our goal
isn't
to cause a schism, but rather to help figure out what the path forward is
with
Taproot. To that end, we:
1) Discuss the merits of Taproot's design versus simpler alternatives (see
thread subject, "Taproot (and Graftroot) Complexity").
2) Propose an alternative path to deploying the technologies described in
BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative
Deployment
Path for Taproot Technologies").
3) Suggest a modification to Taproot to reduce some of the overhead (see
thread
subject, "Taproot Public NUMS Optimization").
We propose to modify Taproot's specification in BIP-341 by adding the rule:
If there is one element on the witness stack:
1) Attempt hashing it to see if it's equal to the witness program. The
first
byte is the control byte for leaf versioning.
2) If it's not the witness program, and it's 65 bytes, try signature
validation
If there is more than one element on the witness stack:
If the control block is even, treat it as a non-Taproot MAST and get the
leaf
version as the last byte of the script (so you can pop it off before
hashing).
If greater anonymity is required, a NUMS point can still be used in
Taproot, at
the expense of the additional data. However, if NUMS points are just a
couple
well known constants this could actually decrease privacy as then the NUMS
points could differ from application to application fingerprinting wallets.
Instead, the NUMS point should only be used when a single use nonce can be
sent, so that NUMS cannot be distinguished from a normal Taproot to a third
party who doesn't know the setup (e.g., that the NUMS is H(X) for known X).
Great thanks,
The Group
- Bryan
http://heybryan.org/
1 512 203 0507
--000000000000beef85059e2a695a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">The following is a message forwarded from=
an anonymous email that, for whatever reason, couldn't be relayed thro=
ugh the mailing list without my assistance. This is message (3/3).<br></div=
><div><br></div>This email is the third of a collection of sentiments from =
a group of developers<br>who in aggregate prefer to remain anonymous. These=
emails have been sent under a<br>pseudonym so as to keep the focus of disc=
ussion on the merits of the technical<br>issues, rather than miring the dis=
cussion in personal politics. Our goal isn't<br>to cause a schism, but =
rather to help figure out what the path forward is with<br>Taproot. To that=
end, we:<br><br>1) Discuss the merits of Taproot's design versus simpl=
er alternatives (see<br>thread subject, "Taproot (and Graftroot) Compl=
exity").<br>2) Propose an alternative path to deploying the technologi=
es described in<br>BIP-340, BIP-341, and BIP-342 (see thread subject, "=
;An Alternative Deployment<br>Path for Taproot Technologies").<br>3) S=
uggest a modification to Taproot to reduce some of the overhead (see thread=
<br>subject, "Taproot Public NUMS Optimization").<br><br>We propo=
se to modify Taproot's specification in BIP-341 by adding the rule:<br>=
<br>If there is one element on the witness stack:<br><br>1) Attempt hashing=
it to see if it's equal to=C2=A0 the witness program. The first<br>byt=
e is the control byte for leaf versioning.<br>2) If it's not the witnes=
s program, and it's 65 bytes, try signature validation<br><br>If there =
is more than one element on the witness stack:<br><br>If the control block =
is even, treat it as a non-Taproot MAST and get the leaf<br>version as the =
last byte of the script (so you can pop it off before hashing).<br><br><br>=
If greater anonymity is required, a NUMS point can still be used in Taproot=
, at<br>the expense of the additional data. However, if NUMS points are jus=
t a couple<br>well known constants this could actually decrease privacy as =
then the NUMS<br>points could differ from application to application finger=
printing wallets.<br>Instead, the NUMS point should only be used when a sin=
gle use nonce can be<br>sent, so that NUMS cannot be distinguished from a n=
ormal Taproot to a third<br>party who doesn't know the setup (e.g., tha=
t the NUMS is H(X) for known X).<br><br><br>Great thanks,<br><br>The Group<=
br><br><br><div dir=3D"ltr" class=3D"gmail_signature">- Bryan<br><a href=3D=
"http://heybryan.org/" target=3D"_blank">http://heybryan.org/</a><br>1 512 =
203 0507</div></div>
--000000000000beef85059e2a695a--
|
