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
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
|
Return-Path: <roconnor@blockstream.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 41B9EC000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 18:21:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 2138140111
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 18:21:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key)
header.d=blockstream-com.20150623.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ferPn_fSUqtu
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 18:21:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com
[IPv6:2607:f8b0:4864:20::731])
by smtp2.osuosl.org (Postfix) with ESMTPS id A40774010D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 6 Jul 2021 18:21:45 +0000 (UTC)
Received: by mail-qk1-x731.google.com with SMTP id s4so2463259qkm.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 06 Jul 2021 11:21:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=7IDfU9QQjZIkJtaDXza29WWuVXEeRAsenSaF5MDBg+E=;
b=zAQ3SzpOZOZy6EFIUjzSbzfnkbABNluYMNHYGq2i18p5q4tjtA2o/pIz4nXJRY+CGB
6QC6dLkk8Y7iUeUcaXMXoisddkbw8jjhkGVvJgKMwDZIq8Fj7xqqCn/UdoQ8MOoCjfVn
EQB7kb39mEOR/vnMYkGwqV9OKXE5jA66cBJcyN7J0NpdPYHXs+SA4q5ANoaS5xB9P8Vz
5PG8onXRGN/kJVpVINdC+GzOhvzM8ufv8EJr81V/2UcI2clZTobSMOJZVnOiTavfs3aS
RDY0nA/gcFIGUVlWAI2bYd3GFXkwZ8XUq9qNHO81GYnT1q+0GAouz8H65Q8Wiu9BKaF/
GKAw==
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=7IDfU9QQjZIkJtaDXza29WWuVXEeRAsenSaF5MDBg+E=;
b=mCdf5Efm8gS4r3VhFsNUCirZisLgZztGpEZLmH7Ig0Ai2mq9q7znxSNoxBsknk6mHK
1gDmU6P6XLtxGrRg43jep97TV0nOjDyYgvDspco7d94yUveTu6V/EQJ8CgiMIdX0TIit
bcHmmGdLqfgxy5UwuKdG9BTRrg9ctxuvT4yve5fV1/TEETermO+Ii4qu/78aRvStjLOn
hzRnDfO8Zzex+UcxRnkGSLDf9zL8eVQduhlukGEiBsLwOLw33u1MBbgC62DfQNeZhb2W
Kz93jbuL2goQBcvt3GqktyUUhqxOdbxDDxlGEkpOsVo6YP0reffsqhSWtomF7any2JVx
iKjg==
X-Gm-Message-State: AOAM533Gj5N7oaZ6SbnAU1WVQE67Bf0/tWmJbOWeDHuKT7Nt4uM+uxeB
n7bV/naf7Akqufc02zxHsoBkWSxOm5R/mdb+ulEtEA==
X-Google-Smtp-Source: ABdhPJzgR4T0V9UnSIC0JmsuNUiS43t7MkZN0mXtcr3P+rsJDqKEt3z+3Sh+fVmJZ69459ZJHvBSwaisM6r2mFPXhXY=
X-Received: by 2002:a37:4685:: with SMTP id
t127mr21227488qka.384.1625595704477;
Tue, 06 Jul 2021 11:21:44 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjmu-Eee47Ho5eA6E6+aAdnchLU0OVZo=RTHaXnN17x8A@mail.gmail.com>
<CAMZUoK=-jrH+fr=tUTHmLojm2-Ff99KYm9H97yhd=7bcOVG=fg@mail.gmail.com>
<CAD5xwhg0N1byx-G2tk=jjmZSHSBirpaX6OHTnh_x9iDEVF8PrQ@mail.gmail.com>
<CAMZUoKnYAKum63fRUNJD-zAZX_p3MoFULGWRE7J2QkO69nOe8g@mail.gmail.com>
<CAD5xwhgtsqAX99NJRU6t-s14aF7frGZxFCL3-c9iBOYrkN_A_w@mail.gmail.com>
<CAMZUoKmWqSnWhTUmTXRuAsrgd0KsQ+XjPw1s+XsZWARhsDcGsA@mail.gmail.com>
<CAD5xwhhft7sKUS++LnS7-Fw37ovCioQWX3pV57JtTdDZ1MfzHg@mail.gmail.com>
In-Reply-To: <CAD5xwhhft7sKUS++LnS7-Fw37ovCioQWX3pV57JtTdDZ1MfzHg@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Tue, 6 Jul 2021 14:21:33 -0400
Message-ID: <CAMZUoKnhUoQGgpx_+keb_vpobKkaT2cbdZWib4oA+VytFwOsDA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000839d3c05c6787eab"
Subject: Re: [bitcoin-dev] CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
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: Tue, 06 Jul 2021 18:21:47 -0000
--000000000000839d3c05c6787eab
Content-Type: text/plain; charset="UTF-8"
If the main outstanding issue is whether to split R or S, I think as far as
Elements goes, I am inclined to go with the CAT option regardless of
whether Bitcoin chooses to split R/S or not (not that I'm necessarily a
decision maker here).
The issue here is that (a) Elements already has CAT, and (b) updating
CHECKSIGFROMSTACK is effectively a blocking issue for deploying Taproot on
Elements. I don't think we will be holding up CHECKSIGFROMSTACK for this
issue even if it risks being incompatible with an eventual Bitcoin
CHECKSIGFROMSTACK.
To be clear, I don't mean to prejudice this discussion by this statement.
This just happens to be what makes sense for the Elements project at this
time, and what makes sense for Elements may not necessarily make sense for
Bitcoin.
Of course, I think we should just go for CAT compatibility. Otherwise we
are just going to have a proliferation of trusted CAT oracles paid for with
lightning by people wanting to perform CAT operations.
On Tue, Jul 6, 2021 at 1:55 PM Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Re-threading Sanket's comment on split R value:
>
> I also am in general support of the `OP_CHECKSIGFROMSTACK` opcode. We
>> would need to update the suggestion to BIP340, and add it to sigops budget.
>> I have no strong preference for splitting R and s values or variable-length
>> messages.
>>
>
> Back to my comment:
>
>
> I see a few options:
>
> 1) Making a new 64 byte PK standard which is (R, PK)
> 2) Splitting (R,S)
> 3) Different opcodes
> 4) CAT
>
> The drawback of option 1 is that it's designed to support only very
> specific use cases. The main drawback of splitting via option 2 is that you
> entail an extra push byte for every use. Option 3 wastes opcodes. CAT has
> the general drawbacks of CAT, but worth noting that CAT will likely
> eventually land making the splitting feature redundant.
>
>
> Before getting too in the weeds, it might be worth listing out interesting
> script fragments that people are aware of with split R/S so we can see how
> useful it might be?
>
> Use a specific R Value
> - <S> <M> || <R> SWAP <PK> CSFS
>
> Reuse arbitrary R for a specific M (pay to leak key)
> - <R> <S1> <S2> || DUP2 EQUAL NOT VERIFY 2 PICK SWAP <M> DUP TOALTSTACK
> CSFSV FROMALTSTACK CSFS
>
> Verify 2 different messages reuse the same R.
> - <S1> <R> <M1> <S2> <M2> || 2 PICK EQUAL NOT VERIFY 3 PICK <PK> DUP
> TOALTSTACK CSFSV FROMALTSTACK CSFS
>
> Use a R Value signed by an oracle:
> - <S> <M> <S_oracle> <R_oracle> <R> || DUP TOALTSTACK <PK_oracle> CSFSV
> FROMALTSTACK SWAP <PK> CSFS
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000839d3c05c6787eab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>If the main outstanding issue is whether to split R o=
r S, I think as far as Elements goes, I am inclined to go with the CAT opti=
on regardless of whether Bitcoin chooses to split R/S or not (not that I=
9;m necessarily a decision maker here).<br></div><div><br></div><div>The is=
sue here is that (a) Elements already has CAT, and (b) updating CHECKSIGFRO=
MSTACK is effectively a blocking issue for deploying Taproot on Elements.=
=C2=A0 I don't think we will be holding up CHECKSIGFROMSTACK for this i=
ssue even if it risks being incompatible with an eventual Bitcoin CHECKSIGF=
ROMSTACK.</div><div><br></div><div>To be clear, I don't mean to prejudi=
ce this discussion by this statement.=C2=A0 This just happens to be what ma=
kes sense for the Elements project at this time, and what makes sense for E=
lements may not necessarily make sense for Bitcoin.</div><div><br></div><di=
v>Of course, I think we should just go for CAT compatibility.=C2=A0 Otherwi=
se we are just going to have a proliferation of trusted CAT oracles paid fo=
r with lightning by people wanting to perform CAT operations.<br></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Ju=
l 6, 2021 at 1:55 PM Jeremy via bitcoin-dev <<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>>=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">Re-threading Sanket's comment on =
split R value:</div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)"><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)">I also am in general support of=C2=A0the `OP_C=
HECKSIGFROMSTACK` opcode. We=20
would need to update the suggestion to BIP340, and add it to sigops=20
budget. I have no strong preference for splitting R and s values or=20
variable-length messages.=C2=A0</div></blockquote><div><br></div><div><div =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)">Back to my comment:</div><br></div><div>=C2=A0<br></div></div><div s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)">I see a few options:</div><div style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">1) Making=
a new 64 byte PK standard which is (R, PK)</div><div style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">2) Splitting (=
R,S)</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)">3) Different opcodes</div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">4) CAT<br></div=
><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)">The drawback of option 1 is that it'=
s designed to support only very specific use cases. The main drawback of sp=
litting via option 2 is that you entail an extra push byte for every use. O=
ption 3 wastes opcodes. CAT has the general drawbacks of CAT, but worth not=
ing that CAT will likely eventually land making the splitting feature redun=
dant.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,=
sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Before g=
etting too in the weeds, it might be worth listing out interesting script f=
ragments that people are aware of with split R/S so we can see how useful i=
t might be?</div><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)">Use a specific R Value<b=
r></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)">- <S> <M> || <R> SWAP <PK> CSFS=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)"><br></div><div style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">Reuse arbitrary R for a specific M =
(pay to leak key) <br></div><div style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">-=C2=A0 <R> <S1> <S2=
>=C2=A0 ||=C2=A0 DUP2 EQUAL NOT VERIFY 2 PICK SWAP <M> DUP TOALTST=
ACK CSFSV FROMALTSTACK CSFS<br></div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style=3D"fo=
nt-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Veri=
fy 2 different messages reuse the same R.<br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- <S1>=
<R> <M1> <S2> <M2> ||=C2=A0 2 PICK EQUAL NOT VERIF=
Y 3 PICK <PK> DUP TOALTSTACK CSFSV FROMALTSTACK CSFS</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:=
small;color:rgb(0,0,0)">Use a R Value signed by an oracle:</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">- <S> <M> <S_oracle> <R_oracle> <R> || DUP =
TOALTSTACK <PK_oracle> CSFSV FROMALTSTACK SWAP <PK> CSFS<br></d=
iv><br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
--000000000000839d3c05c6787eab--
|
