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
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C6D221986
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Jun 2019 06:43:37 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 091A8710
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Jun 2019 06:43:36 +0000 (UTC)
Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com
[209.85.208.51]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5N6hYuZ025774
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 23 Jun 2019 02:43:35 -0400
Received: by mail-ed1-f51.google.com with SMTP id z25so16390116edq.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 22 Jun 2019 23:43:35 -0700 (PDT)
X-Gm-Message-State: APjAAAXDfRsp20rOcT4G518h9yMpVtLIHJn5m0Gusp2NOOMqnRhYL9TT
41unDDmoPTrGpMBTJBvfX9NnNZ3J1DaOzCUTcsI=
X-Google-Smtp-Source: APXvYqx4WZYaBOZFCv6pz/C/ZR7IBcG3enMpdvjNuFcUCHSzvGoRuaBbGypbGuDN6COivZrJcNotrEwZo9qhcwdDZjc=
X-Received: by 2002:aa7:cfc3:: with SMTP id r3mr24135619edy.202.1561272213949;
Sat, 22 Jun 2019 23:43:33 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhjSj82YYuQHHbwgSLvUNV2RDY0b=yMYeLj-p6j7PpS9-Q@mail.gmail.com>
<20190605093039.xfo7lcylqkhsfncv@erisian.com.au>
<im0q8670MxshmvMLmoJU0dv4rFhwWZNvQeQYv7i4fBWJOx0ghAdH8fYuQSqNxO2z8uxXGV-kurinUDfl0FsLWD0knw_U_h3zVZ0xy7vmn8o=@protonmail.com>
<CAMZUoK=ZB06jwAbuX2D=aN8ztAqr_jSgEXS1z1ABjQYVawKCBQ@mail.gmail.com>
<20190620220552.metrqaul3iporwma@erisian.com.au>
In-Reply-To: <20190620220552.metrqaul3iporwma@erisian.com.au>
From: Jeremy <jlrubin@mit.edu>
Date: Sat, 22 Jun 2019 23:43:22 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgEQKdTCSLQn4-X_atT5_aE-1hEKk0xd1wm1m0qotwYXQ@mail.gmail.com>
Message-ID: <CAD5xwhgEQKdTCSLQn4-X_atT5_aE-1hEKk0xd1wm1m0qotwYXQ@mail.gmail.com>
To: Anthony Towns <aj@erisian.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b5d27a058bf80305"
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 23 Jun 2019 16:34:08 +0000
Subject: Re: [bitcoin-dev] OP_SECURETHEBAG (supersedes OP_CHECKOUTPUTSVERIFY)
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: Sun, 23 Jun 2019 06:43:37 -0000
--000000000000b5d27a058bf80305
Content-Type: text/plain; charset="UTF-8"
This is insufficient: sequences must be committed to because they affect
TXID. As with scriptsigs (witness data fine to ignore). NUM_IN too.
Any malleability makes this much less useful.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor wrote:
> > So with regards to OP_SECURETHEBAG, I am also "not really seeing any
> reason to
> > complicate the spec to ensure the digest is precommitted as part of the
> > opcode."
>
> Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT
> (NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if
> it's been spelled out anywhere); ie instead of constructing
>
> X = Hash_BagHash( version, locktime, [outputs], [sequences], num_in )
>
> and having the script be "<X> OP_SECURETHEBAG" you calculate an
> ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:
>
> Y = Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,
> amount, sequence)
>
> and calculate a signature sig = Schnorr(P,m) for some pubkey P, and
> make your script be "<sig> <P> CHECKSIG".
>
> That loses the ability to commit to the number of inputs or restrict
> the nsequence of other inputs, and requires a bigger script (sig and P
> are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much the
> same as far as I can tell. Both scripts are automatically satisfied when
> revealed (with the correct set of outputs), and don't need any additional
> witness data.
>
> If you wanted to construct "X" via script instead of hardcoding a value
> because it got you generalised covenants or whatever; I think you could
> get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much
> the same way you construct X, but you'd then need to turn that into a
> signature. You could do so by using pubkey P=G and nonce R=G, which
> means you need to calculate s=1+hash(G,G,Y)*1 -- calculating the hash
> part is easy, multiplying it by 1 is easy, and to add 1 you can probably
> do something along the lines of:
>
> OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT
>
> (ie, take the last 4 bytes, increment it using 4-byte arithmetic,
> then cat the first 28 bytes and the result. There's overflow issues,
> but I think they can be worked around either by allowing you to choose
> different locktimes, or by more complicated script)
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--000000000000b5d27a058bf80305
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">This is insufficient: seq=
uences must be committed to because they affect TXID. As with scriptsigs (w=
itness data fine to ignore). NUM_IN too.</div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:#000000">Any malleability makes this =
much less useful.<br></div><div><div dir=3D"ltr" class=3D"gmail_signature" =
data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https:=
//twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"htt=
ps://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br><=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Fri, Jun 21, 2019 at 10:31 AM Anthony Towns via bitcoin-dev <<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">On Tue, Jun 18, 2019 at 04:57:34PM -0400, Russell O'Connor =
wrote:<br>
> So with regards to OP_SECURETHEBAG, I am also "not really seeing =
any reason to<br>
> complicate the spec to ensure the digest is precommitted as part of th=
e<br>
> opcode."<br>
<br>
Also, I think you can simulate OP_SECURETHEBAG with an ANYPREVOUT<br>
(NOINPUT) sighash (Johnson Lau's mentioned this before, but not sure if=
<br>
it's been spelled out anywhere); ie instead of constructing<br>
<br>
=C2=A0 X =3D Hash_BagHash( version, locktime, [outputs], [sequences], num_i=
n )<br>
<br>
and having the script be "<X> OP_SECURETHEBAG" you calculat=
e an<br>
ANYPREVOUT sighash for SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_ALL:<br>
<br>
=C2=A0 Y =3D Hash_TapSighash( 0, 0xc1, version, locktime, [outputs], 0,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0amount, sequence)<br>
<br>
and calculate a signature sig =3D Schnorr(P,m) for some pubkey P, and<br>
make your script be "<sig> <P> CHECKSIG".<br>
<br>
That loses the ability to commit to the number of inputs or restrict<br>
the nsequence of other inputs, and requires a bigger script (sig and P<br>
are ~96 bytes instead of X's 32 bytes), but is otherwise pretty much th=
e<br>
same as far as I can tell. Both scripts are automatically satisfied when<br=
>
revealed (with the correct set of outputs), and don't need any addition=
al<br>
witness data.<br>
<br>
If you wanted to construct "X" via script instead of hardcoding a=
value<br>
because it got you generalised covenants or whatever; I think you could<br>
get the same effect with CAT,LEFT, and RIGHT: you'd construct Y in much=
<br>
the same way you construct X, but you'd then need to turn that into a<b=
r>
signature. You could do so by using pubkey P=3DG and nonce R=3DG, which<br>
means you need to calculate s=3D1+hash(G,G,Y)*1 -- calculating the hash<br>
part is easy, multiplying it by 1 is easy, and to add 1 you can probably<br=
>
do something along the lines of:<br>
<br>
=C2=A0 =C2=A0 OP_DUP 4 OP_RIGHT 1 OP_ADD OP_SWAP 28 OP_LEFT OP_SWAP OP_CAT<=
br>
<br>
(ie, take the last 4 bytes, increment it using 4-byte arithmetic,<br>
then cat the first 28 bytes and the result. There's overflow issues,<br=
>
but I think they can be worked around either by allowing you to choose<br>
different locktimes, or by more complicated script)<br>
<br>
Cheers,<br>
aj<br>
<br>
_______________________________________________<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>
--000000000000b5d27a058bf80305--
|
