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
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
|
Return-Path: <laolu32@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 96DDB3EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 7 May 2018 23:47:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6B874F4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 7 May 2018 23:47:35 +0000 (UTC)
Received: by mail-wm0-f53.google.com with SMTP id t11so15993524wmt.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 07 May 2018 16:47:35 -0700 (PDT)
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=gXgh5yMwGPGhB/J0dzYQeaPSgk+yoORS5AHYVP79u7s=;
b=JkDYD8gTBHUvz84fEFXZ61ZUuNJK9SJ1i/mn7ZgnLMBrWoVYYZHH23gqyBRnxjzC5y
aGG1QQTqIBhCn0uxFmgsg2YjIGGQijiT2jAhz7ajqwOZh0ePXG7uTi+Os/XBy0d5msiK
JsScxEH4nvmYP0YAI4QLuSKp+tPoMHBUTk/ueda0orbZKVJedoMyn7oOEuw0pnV7khsx
E1xNi7NWIS7SvG1vxMaP7TYtfsrZrKDv49cP+FNmcoLp/dhiVcqUU9ExTtu/eZhNiyLG
W/elHho7PlFEq7rQnNfZGfdStefz5M7fyGgvx+5V9l1ZMBcBjkkCsHWz/8GOg7c8lc0F
IXGQ==
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=gXgh5yMwGPGhB/J0dzYQeaPSgk+yoORS5AHYVP79u7s=;
b=cJom6Js56iRHswnRLOoozvh0S1Qr6HSOh46ZJGi4ZN98M7cP063y7M0Hy4PBqHCbFR
uNGMOaDyv/r48pBjL3dEGVTKZV5UOnZXzHx593ki4eZ9jzgVmS9hRY1IR1ZChNV1zfUw
LK9F2sleho4yLg0FkoNp1ERifHNRZcgTugPYQt5tfCaJCoP5qTUQU29zxCWAMiU9MXet
gEaWQhmEui/UfuKUJsCIf6FjowhLpVqXZjzKQDLXjAL+ZMGKx9JpOJL2hMy4oYG0AE6I
J+Qfpqkye7ni/+uhXsSY77OtThTqH459GUZbeiWpcnM4pGTD5bL/CR2A8zOcRJv2vyKP
fADA==
X-Gm-Message-State: ALQs6tBpv21b5vxBL+IYY8VgbZqNnBK7WOnY7IS/WD1yZFIqys01SVjT
KO1ukb94+Hj6DUwsznq8U68eRyHZ9FKud/ZmJjY=
X-Google-Smtp-Source: AB8JxZpVjHU7MOfR45earP7nJaU9dZ4hO6D6fXAGUxFaiQgLlYHqwqD7n4N7vgcTupjp1z9b7yB718NimwBcNaiuYaM=
X-Received: by 2002:aa7:c2d0:: with SMTP id
m16-v6mr52608945edp.171.1525736853938;
Mon, 07 May 2018 16:47:33 -0700 (PDT)
MIME-Version: 1.0
References: <871sewirni.fsf@gmail.com>
In-Reply-To: <871sewirni.fsf@gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Mon, 07 May 2018 23:47:23 +0000
Message-ID: <CAO3Pvs-8cX2Gdgu0cb0LdkY6ErguKkzs8pLZapFTD5JdpGms2A@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003325da056ba64b0c"
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP sighash_noinput
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: Mon, 07 May 2018 23:47:36 -0000
--0000000000003325da056ba64b0c
Content-Type: text/plain; charset="UTF-8"
Super stoked to see that no_input has been resurrected!!! I actually
implemented a variant back in 2015 when Tadge first described the approach
to
me for both btcd [1], and bitcoind [2]. The version being proposed is
_slightly_ differ though, as the initial version I implemented still
committed
to the script being sent, while this new version just relies on
witness validity instead. This approach is even more flexible as the script
attached to the output being spent can change, without rendering the
spending
transaction invalid as long as the witness still ratifies a branch in the
output's predicate.
Given that this would introduce a _new_ sighash flag, perhaps we should also
attempt to bundle additional more flexible sighash flags concurrently as
well?
This would require a larger overhaul w.r.t to how sighash flags are
interpreted, so in this case, we may need to introduce a new CHECKSIG
operator
(lets call it CHECKSIG_X for now), which would consume an available noop
opcode. As a template for more fine grained sighashing control, I'll refer
to
jl2012's BIP-0YYY [3] (particularly the "New nHashType definitions"
section).
This was originally proposed in the context of his merklized script work as
it
more or less opened up a new opportunity to further modify script within the
context of merklized script executions. The approach reads in the
sighash flags as a bit vector, and allows developers to express things like:
"don't sign the input value, nor the sequence, but sign the output of this
input, and ONLY the script of this output". This approach is _extremely_
powerful, and one would be able to express the equivalent of no_input by
setting the appropriate bits in the sighash.
Looking forward in hearing y'alls thoughts on this approach, thanks.
[1]: https://github.com/Roasbeef/btcd/commits/SIGHASH_NOINPUT
[2]: https://github.com/Roasbeef/bitcoin/commits/SIGHASH_NOINPUT
[3]:
https://github.com/jl2012/bips/blob/vault/bip-0YYY.mediawiki#new-nhashtype-definitions
-- Laolu
On Mon, Apr 30, 2018 at 10:30 AM Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
> previous
> output. This was previously mentioned on the list by Joseph Poon [1], but
> was
> never formally proposed, so I wrote a proposal [2].
>
> We have long known that `SIGHASH_NOINPUT` would be a great fit for
> Lightning.
> They enable simple watch-towers, i.e., outsource the need to watch the
> blockchain for channel closures, and react appropriately if our
> counterparty
> misbehaves. In addition to this we just released the eltoo [3,4] paper
> which
> describes a simplified update mechanism that can be used in Lightning, and
> other
> off-chain contracts, with any number of participants.
>
> By not committing to the previous output being spent by the transaction,
> we can
> rebind an input to point to any outpoint with a matching output script and
> value. The binding therefore is no longer explicit through a reference, but
> through script compatibility, and the transaction ID reference in the
> input is a
> hint to validators. The sighash flag is meant to enable some off-chain
> use-cases
> and should not be used unless the tradeoffs are well-known. In particular
> we
> suggest using contract specific key-pairs, in order to avoid having any
> unwanted
> rebinding opportunities.
>
> The proposal is very minimalistic, and simple. However, there are a few
> things
> where we'd like to hear the input of the wider community with regards to
> the
> implementation details though. We had some discussions internally on
> whether to
> use a separate opcode or a sighash flag, some feeling that the sighash flag
> could lead to some confusion with existing wallets, but given that we have
> `SIGHASH_NONE`, and that existing wallets will not sign things with unknown
> flags, we decided to go the sighash way. Another thing is that we still
> commit
> to the amount of the outpoint being spent. The rationale behind this is
> that,
> while rebinding to outpoints with the same value maintains the value
> relationship between input and output, we will probably not want to bind to
> something with a different value and suddenly pay a gigantic fee.
>
> The deployment part of the proposal is left vague on purpose in order not
> to
> collide with any other proposals. It should be possible to introduce it by
> bumping the segwit script version and adding the new behavior.
>
> I hope the proposal is well received, and I'm looking forward to discussing
> variants and tradeoffs here. I think the applications we proposed so far
> are
> quite interesting, and I'm sure there are many more we can enable with this
> change.
>
> Cheers,
> Christian
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html
> [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki
> [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
> [4] https://blockstream.com/eltoo.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000003325da056ba64b0c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Super stoked to see that no_input has been resur=
rected!!! I actually</div><div>implemented a variant back in 2015 when Tadg=
e first described the approach to</div><div>me for both btcd [1], and bitco=
ind [2]. The version being proposed is</div><div>_slightly_ differ though, =
as the initial version I implemented still committed</div><div>to the scrip=
t being sent, while this new version just relies on</div><div>witness valid=
ity instead. This approach is even more flexible as the script</div><div>at=
tached to the output being spent can change, without rendering the spending=
</div><div>transaction invalid as long as the witness still ratifies a bran=
ch in the</div><div>output's predicate.</div><div><br></div><div>Given =
that this would introduce a _new_ sighash flag, perhaps we should also</div=
><div>attempt to bundle additional more flexible sighash flags concurrently=
as well?</div><div>This would require a larger overhaul w.r.t to how sigha=
sh flags are</div><div>interpreted, so in this case, we may need to introdu=
ce a new CHECKSIG operator</div><div>(lets call it CHECKSIG_X for now), whi=
ch would consume an available noop</div><div>opcode. As a template for more=
fine grained sighashing control, I'll refer to</div><div>jl2012's =
BIP-0YYY [3] (particularly the "New nHashType definitions" sectio=
n).</div><div>This was originally proposed in the context of his merklized =
script work as it</div><div>more or less opened up a new opportunity to fur=
ther modify script within the</div><div>context of merklized script executi=
ons.=C2=A0 The approach reads in the</div><div>sighash flags as a bit vecto=
r, and allows developers to express things like:</div><div>"don't =
sign the input value, nor the sequence, but sign the output of this</div><d=
iv>input, and ONLY the script of this output". This approach is _extre=
mely_</div><div>powerful, and one would be able to express the equivalent o=
f no_input by</div><div>setting the appropriate bits in the sighash.</div><=
div><br></div><div>Looking forward in hearing y'alls thoughts on this a=
pproach, thanks.</div><div><br></div><div>[1]: <a href=3D"https://github.co=
m/Roasbeef/btcd/commits/SIGHASH_NOINPUT">https://github.com/Roasbeef/btcd/c=
ommits/SIGHASH_NOINPUT</a></div><div>[2]: <a href=3D"https://github.com/Roa=
sbeef/bitcoin/commits/SIGHASH_NOINPUT">https://github.com/Roasbeef/bitcoin/=
commits/SIGHASH_NOINPUT</a></div><div>[3]: <a href=3D"https://github.com/jl=
2012/bips/blob/vault/bip-0YYY.mediawiki#new-nhashtype-definitions">https://=
github.com/jl2012/bips/blob/vault/bip-0YYY.mediawiki#new-nhashtype-definiti=
ons</a></div><div><br></div><div>-- Laolu</div></div><div><br></div><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr">On Mon, Apr 30, 2018 at 10:30 AM Chris=
tian Decker via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I'd like to pick up the discussion from a few months ago, and propose a=
new<br>
sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previou=
s<br>
output. This was previously mentioned on the list by Joseph Poon [1], but w=
as<br>
never formally proposed, so I wrote a proposal [2].<br>
<br>
We have long known that `SIGHASH_NOINPUT` would be a great fit for Lightnin=
g.<br>
They enable simple watch-towers, i.e., outsource the need to watch the<br>
blockchain for channel closures, and react appropriately if our counterpart=
y<br>
misbehaves. In addition to this we just released the eltoo [3,4] paper whic=
h<br>
describes a simplified update mechanism that can be used in Lightning, and =
other<br>
off-chain contracts, with any number of participants.<br>
<br>
By not committing to the previous output being spent by the transaction, we=
can<br>
rebind an input to point to any outpoint with a matching output script and<=
br>
value. The binding therefore is no longer explicit through a reference, but=
<br>
through script compatibility, and the transaction ID reference in the input=
is a<br>
hint to validators. The sighash flag is meant to enable some off-chain use-=
cases<br>
and should not be used unless the tradeoffs are well-known. In particular w=
e<br>
suggest using contract specific key-pairs, in order to avoid having any unw=
anted<br>
rebinding opportunities.<br>
<br>
The proposal is very minimalistic, and simple. However, there are a few thi=
ngs<br>
where we'd like to hear the input of the wider community with regards t=
o the<br>
implementation details though. We had some discussions internally on whethe=
r to<br>
use a separate opcode or a sighash flag, some feeling that the sighash flag=
<br>
could lead to some confusion with existing wallets, but given that we have<=
br>
`SIGHASH_NONE`, and that existing wallets will not sign things with unknown=
<br>
flags, we decided to go the sighash way. Another thing is that we still com=
mit<br>
to the amount of the outpoint being spent. The rationale behind this is tha=
t,<br>
while rebinding to outpoints with the same value maintains the value<br>
relationship between input and output, we will probably not want to bind to=
<br>
something with a different value and suddenly pay a gigantic fee.<br>
<br>
The deployment part of the proposal is left vague on purpose in order not t=
o<br>
collide with any other proposals. It should be possible to introduce it by<=
br>
bumping the segwit script version and adding the new behavior.<br>
<br>
I hope the proposal is well received, and I'm looking forward to discus=
sing<br>
variants and tradeoffs here. I think the applications we proposed so far ar=
e<br>
quite interesting, and I'm sure there are many more we can enable with =
this<br>
change.<br>
<br>
Cheers,<br>
Christian<br>
<br>
[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016=
-February/012460.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html</a><br>
[2] <a href=3D"https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawi=
ki" rel=3D"noreferrer" target=3D"_blank">https://github.com/cdecker/bips/bl=
ob/noinput/bip-xyz.mediawiki</a><br>
[3] <a href=3D"https://blockstream.com/2018/04/30/eltoo-next-lightning.html=
" rel=3D"noreferrer" target=3D"_blank">https://blockstream.com/2018/04/30/e=
ltoo-next-lightning.html</a><br>
[4] <a href=3D"https://blockstream.com/eltoo.pdf" rel=3D"noreferrer" target=
=3D"_blank">https://blockstream.com/eltoo.pdf</a><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></div>
--0000000000003325da056ba64b0c--
|