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
184
185
186
187
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6F7E9F31
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 17:07:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com
[209.85.214.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 942A7319
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 17:07:46 +0000 (UTC)
Received: by mail-it0-f47.google.com with SMTP id k131so3831512ith.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jan 2018 09:07:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream.io; s=google;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=+bbNBuBCkzeLAnadFLZMoCVbD7CU+DxxSgA5IlCUKGM=;
b=SqULcC4B4Da6tEHLJNHDRM9RLBYAnY5EXsFRNJC1ZEDHh8KR5t5FSlH/ndtEsADlI0
JOYXDRLTNs9UeyWqgx7tmzbhVD850DjkTiO7HovBD8xXma6krjpqiUQt4BCAUTHoFIxZ
m02MWuCvdml/nEY4g5BIY77SCeGSPqO/tT6js=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=+bbNBuBCkzeLAnadFLZMoCVbD7CU+DxxSgA5IlCUKGM=;
b=Uw8f/CbxCqplxZiN8WPzS5ybHrdS0wsSJn3Qa/65HkcAckgk+yQtUhvdx3Fs9FJToI
k0pYF78E2xMjo+1QcJh1lX7eGK9vqZYCBspmc2H0rDww1t2VQEOsAr2QI7S39i4oLanL
rLvUCJMXAP4YGPCehgi56FDRQ8WyTV2ggoK1ErN7dyD5hznWqA/LDztoDGPTR6N3WkVY
5oNuqhJXh08vJMpQt+70DyUKSVfL1mP+JH6f8jQqW8KwP+8TJqUMqi3u+SixPiyctjLU
3Qz7LdSJkhRzEK5/tQMFrzppbm1VFKdfdtciaRVWRkm+D6CCrracM0EHhfBiS1y78zF6
o/sg==
X-Gm-Message-State: AKwxytdltitRam3b9IJrvB+t7iRTq680Lo7Z1AW2a+UlCKMNGJuwScQj
tKUCpa6uhVuaK8qwrNWGjytx5FEqdWIgiwRXLMUOpuyYc4g=
X-Google-Smtp-Source: AH8x225Zs6GgWn6OJ++AHNnR/Fgmaepcfk79Vo/ewcdD4bGXHr9Ld+ypfgFbeYxCmWmjuRP3bUM/oGvl5Ixh7tKgxNQ=
X-Received: by 10.36.86.20 with SMTP id o20mr21420978itb.53.1517072865854;
Sat, 27 Jan 2018 09:07:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.120.10 with HTTP; Sat, 27 Jan 2018 09:07:25 -0800 (PST)
In-Reply-To: <20180123064419.GA1296@erisian.com.au>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
<20180123064419.GA1296@erisian.com.au>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Sat, 27 Jan 2018 12:07:25 -0500
Message-ID: <CAMZUoKmfcmfgErhvAZUQgi8R7bzYCMotT7MMpqQrePej09NBmw@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1144d5ea44a05c0563c50d82"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Sat, 27 Jan 2018 17:07:47 -0000
--001a1144d5ea44a05c0563c50d82
Content-Type: text/plain; charset="UTF-8"
On Tue, Jan 23, 2018 at 1:44 AM, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tue, Jan 23, 2018 at 12:30:06AM +0000, Gregory Maxwell via bitcoin-dev
> wrote:
> > One point that comes up while talking about merkelized scripts is can
> > we go about making fancier contract use cases as indistinguishable as
> > possible from the most common and boring payments.
>
> > Now we tweak C to produce P which is the key we'll publish: P = C +
> H(C||S)G.
> > (This is the attack hardened pay-to-contract construction described in
> [2])
> > Then we pay to a scriptPubKey of [Taproot supporting version] [EC point
> P].
>
> Is this really intended as paying directly to a pubkey, instead of a
> pubkey hash?
>
> If so, isn't that a step backwards with regard to resistance to quantum
> attacks against ECC?
>
> Paying direct to pubkey doesn't seem quite enough to make pay-to-taproot
> cheaper than p2wpkh: the extra 12 bytes in the scriptPubKey would need
> you to reduce the witness by 48 bytes to maintain the weight, but I think
> you'd only be saving 33 bytes by not having to reveal the pubkey, and
> another 6-7 bytes by having a tighter signature encoding than DER. Still,
> that's pretty close with a difference of only a couple of vbytes per
> input by my count.
>
I've been thinking about your comment, and I think your concern can be
addressed. Taproot would almost certainly be deployed in conjunction with
cross-input signature aggregation. Because aggregation doesn't work with
ECDSA, only those signatures using Taproot and other Schnorr signatures
would be available for aggregation. Just having the ability to support
cross-input signature aggregation may be motivation enough for ordinary
pub-key users to switch to Taproot. However, there is more.
Cross-input signature aggregation probably requires a new field to be added
to the P2P transaction structure to hold the aggregated signature, since
there isn't really a good place to put it in the existing structure (there
are games you can play to make it fit, but I think it is worthwhile). The
obvious way add block commitments to a new tx field is via the witness
reserved value mechanism present in BIP 141. At this point I think there
will be some leeway to adjust the discount on the weight of this new
aggregated signature tx field so that even a single input taproot using the
aggregated signature system (here an aggregation of 1 signature) ends up no
more expensive than a single input segwit P2WPKH.
--001a1144d5ea44a05c0563c50d82
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jan 23, 2018 at 1:44 AM, Anthony Towns via bitcoin-dev <span di=
r=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmail-">=
On Tue, Jan 23, 2018 at 12:30:06AM +0000, Gregory Maxwell via bitcoin-dev w=
rote:<br>
> One point that comes up while talking about merkelized scripts is can<=
br>
> we go about making fancier contract use cases as indistinguishable as<=
br>
> possible from the most common and boring payments.<br>
<br>
</span><span class=3D"gmail-">> Now we tweak C to produce P which is the=
key we'll publish: P =3D C + H(C||S)G.<br>
> (This is the attack hardened pay-to-contract construction described in=
[2])<br>
> Then we pay to a scriptPubKey of [Taproot supporting version] [EC poin=
t P].<br>
<br>
</span>Is this really intended as paying directly to a pubkey, instead of a=
<br>
pubkey hash?<br>
<br>
If so, isn't that a step backwards with regard to resistance to quantum=
<br>
attacks against ECC?<br>
<br>
Paying direct to pubkey doesn't seem quite enough to make pay-to-taproo=
t<br>
cheaper than p2wpkh: the extra 12 bytes in the scriptPubKey would need<br>
you to reduce the witness by 48 bytes to maintain the weight, but I think<b=
r>
you'd only be saving 33 bytes by not having to reveal the pubkey, and<b=
r>
another 6-7 bytes by having a tighter signature encoding than DER. Still,<b=
r>
that's pretty close with a difference of only a couple of vbytes per<br=
>
input by my count.<br></blockquote><div><br></div><div>I've been thinki=
ng about your comment, and I think your concern can be addressed.=C2=A0 Tap=
root would almost certainly be deployed in conjunction with cross-input sig=
nature aggregation.=C2=A0 Because aggregation doesn't work with ECDSA, =
only those signatures using Taproot and other Schnorr signatures would be a=
vailable for aggregation.=C2=A0 Just having the ability to support cross-in=
put signature aggregation may be motivation enough for ordinary pub-key use=
rs to switch to Taproot.=C2=A0 However, there is more.</div><div><br></div>=
<div>Cross-input signature aggregation probably requires a new field to be =
added to the P2P transaction structure to hold the aggregated signature, si=
nce there isn't really a good place to put it in the existing structure=
(there are games you can play to make it fit, but I think it is worthwhile=
).=C2=A0 The obvious way add block commitments to a new tx field is via the=
witness reserved value mechanism present in BIP 141.=C2=A0 At this point I=
think there will be some leeway to adjust the discount on the weight of th=
is new aggregated signature tx field so that even a single input taproot us=
ing the aggregated signature system (here an aggregation of 1 signature) en=
ds up no more expensive than a single input segwit P2WPKH.<br></div></div><=
/div></div>
--001a1144d5ea44a05c0563c50d82--
|
