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
|
Return-Path: <jim.posen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 729864A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Apr 2018 23:00:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f169.google.com (mail-qt0-f169.google.com
[209.85.216.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 461AE148
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Apr 2018 23:00:57 +0000 (UTC)
Received: by mail-qt0-f169.google.com with SMTP id e8-v6so8044108qth.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Apr 2018 16:00:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=KB1whuGgKcjN30zeLkGVxRGGVqJHgR1HZCF0AngPti4=;
b=aLq2SV9csEkaMxY8oIm8X+jwM96Zaxly5V79e9rX9kTokIR578l8VnemeUBl6o1mK0
Sjnz413H8SwEM+dEa1Of0v+9E1wB1xVFkwJYl6XSWg0R6j4zlhVoiZmiE7LtO2OsQZ/v
dGuKbN9nnX3NKFvfgUnGHiXuhTRyrl3FHpXw4Ky6QwdNaHlQ2kRWiXs8AXJN9J4faymJ
2z7jMkixnzOyN8sYsF5R/QpAf7nlWhFaF+YeGxvUUQ+z7AEwpkyCJyL9enhSvQ9u89fG
E+cf06HAqKpRXTdksAuitdKcfr+gW0mDMywuPivgKuJ5GeB+huwDUBeZ4aYeAnlPEzRS
r6ZA==
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;
bh=KB1whuGgKcjN30zeLkGVxRGGVqJHgR1HZCF0AngPti4=;
b=sGNjdm+4RyaKDcIpFJqd8Le8YWH8ZSMUj4Q91g6Ma6F5TC5rBmfTD9G1Txm4oiuJI2
sdPEH7+clsSjRlAZ/Fs2Jwm39s+2FKhl3gPaQwsQ8baZSrp4mPtXmIyIczKXfqZ3WSDZ
Wa5pEWNsBlXvOfm630JUWv9MweToohnxP1JCDDsvVsROe4sEkqtXDqo5MGJkDafQyHkI
qsZTZ8jEXf4Q8Pd2vCERazBmAGTYHwrCMBAhhR8r+4uBXsuCLw2JREeqYeDojWeEMWnV
kLu3aHHvm5iA4QqAYf2cA2c+O8I5DEgLczHKtLYvQyKIrMElZwtw9QV08oiMWYiNYhaV
Pr6w==
X-Gm-Message-State: ALQs6tDRIJUtNPRsVmN5KvqunyyL2VNrnLDxU/lz6m2gyiOoWhiBGXnU
Fw8M5dwrB7pGcvW9SIkMK2IB5KafetwBxvvcf2k=
X-Google-Smtp-Source: AB8JxZobbkXisPvPw9I3zyEXwQZtKIhs6NCjEY6xO+cEYz+QD6A7bBfS6M3VqszVMjfDfHRyDdYsSbuqAxdEruDQbpY=
X-Received: by 2002:a0c:946c:: with SMTP id
i41-v6mr12026528qvi.139.1525129256140;
Mon, 30 Apr 2018 16:00:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.50.92 with HTTP; Mon, 30 Apr 2018 16:00:55 -0700 (PDT)
In-Reply-To: <874ljsitvx.fsf@gmail.com>
References: <874ljsitvx.fsf@gmail.com>
From: Jim Posen <jim.posen@gmail.com>
Date: Mon, 30 Apr 2018 16:00:55 -0700
Message-ID: <CADZtCSgSJsU+j1teT4A9+nc+cuzBz+dhL+sC3dyGniQAsxPUxw@mail.gmail.com>
To: Christian Decker <decker.christian@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000008c8363056b18d320"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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
X-Mailman-Approved-At: Tue, 01 May 2018 04:00:08 +0000
Subject: Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for
Lightning and Off-Chain Contracts
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, 30 Apr 2018 23:00:58 -0000
--0000000000008c8363056b18d320
Content-Type: text/plain; charset="UTF-8"
This construction is pretty neat and seems to solve a lot of problems. I
find the use of CLTV with past timestamps to provide ordering in particular
to be quite clever.
If my understanding is correct though, this construction would
significantly increase the safe CLTV delta requirements because HTLCs
cannot be timed out immediately on the settlement transaction. Consider a
case where node B receives an HTLC from A and forwards to C. If the HTLC
offered to C times out and C does not fail the HTLC off-chain, Lightning
currently guarantees that the CLTV delta is sufficient that I may close the
channel to C on-chain and claim the timed-out HTLC before my upstream HTLC
to A times out. If the CLTV delta is too small, I may fail the upstream
HTLC as soon as it times out, and then C may still claim the downstream
HTLC with the preimage on-chain. With eltoo, when B closes the downstream
channel on-chain, it must wait the CSV timeout on the update transaction
before locking in the timed-out HTLC. This effectively means the CLTV delta
has to be greater than the CSV timeout, plus some extra (whereas it is
currently safe to make it significantly shorter). Is that true or am I
missing something?
On Mon, Apr 30, 2018 at 8:41 AM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> (cross-posting to bitcoin-dev since this serves as motivation behind the
> sighash_noinput proposal)
>
> > TL;DR: we announce a new, simple, update mechanism for off-chain
> protocols,
> > see the announcement [1] and the paper [2] :-)
>
> A little over a year ago, the three Lightning Network implementation
> teams joined forces to work on a common specification for the protocol
> stack. Now that both that specification and our three implementations
> are becoming stable and usable, it is time to look forward: to further
> improve the protocol, to add new features, to simplify, and to fix
> downsides.
>
> One of the core innovations that enabled Lightning in the first place was
> an
> off-chain update mechanism to renegotiate a new state and ensure that the
> old
> state can not be settled on-chain. Today, we're excited to release our
> latest
> research paper on a new, simplified, update mechanism for layer 2
> protocols,
> called eltoo.
>
> eltoo is a drop-in replacement for the penalty based invalidation
> mechanism that is used today in the Lightning specification. It is
> similar in many ways to the sequence number mechanism that was already
> present in the original Bitcoin implementation. But, while sequence
> numbers were unenforceable on the blockchain, eltoo is enforceable by
> overriding subsequent states on-chain.
>
> Unlike the current mechanism used in Lightning so far, it is not penalty
> based, i.e., publishing an old state does not result in the faulty node
> to automatically lose funds, and is most similar to the duplex
> micropayment channels construction. It is a symmetric scheme, i.e., all
> participants share an identical set of transactions, and it ensures that
> the
> last agreed upon state is settled on-chain, with similar tradeoffs as
> today's Lightning (timelock vs. online requirement).
>
> eltoo addresses some of the issues we encountered while speficying and
> implementing the Lightning Network. For example outsourcing becomes very
> simple since old states becoming public can't hurt us anymore. We
> completely remove the need to estimate fees ahead of time. The
> construction allows us to attach fees when settling, and even allows for
> fees to be bumped using CPFP or RBF.
>
> Beyond Lightning, eltoo can be used as a generic update mechanism for an
> off-chain contract, for a larger number of participants. This was not
> possible in the current update mechanism since reactions to a
> misbehaving participant needed to be tailore to that participant. This
> enables other protocols such as the channel factories, and in
> combination with Schnorr signatures allows for very large off-chain
> contracts with minimal on-chain footprint.
>
> Before we can implement eltoo, we need a minor change to Bitcoin: the
> introduction of the SIGHASH_NOINPUT flag for signatures. This was first
> discussed a few months ago in the context of watchtowers to help secure
> Lightning channels, but was not formally proposed. A formal proposal may
> now be found in the eltoo paper.
>
> We invite the community to consider our proposal and to participate in
> its discussion. We hope to arrive at a consensus for the usage of
> SIGHASH_NOINPUT, so that it can be accepted and included in a future
> soft fork of Bitcoin Script. Doing so will put us on the road to a more
> reliable and simpler Lightning Network, incorporating a new update
> mechanism that can also be used for many other applications.
>
> The full official announcement can be found at [1] and the paper with the
> full
> details can be found at [2].
>
> Looking forward to the communities feedback,
> Christian
>
> [1] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
> [2] https://blockstream.com/eltoo.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000008c8363056b18d320
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This construction is pretty neat and seems to solve a lot =
of problems. I find the use of CLTV with past timestamps to provide orderin=
g in particular to be quite clever.<div><br></div><div>If my understanding =
is correct though, this construction would significantly increase the safe =
CLTV delta requirements because HTLCs cannot be timed out immediately on th=
e settlement transaction. Consider a case where node B receives an HTLC fro=
m A and forwards to C. If the HTLC offered to C times out and C does not fa=
il the HTLC off-chain, Lightning currently guarantees that the CLTV delta i=
s sufficient that I may close the channel to C on-chain and claim the timed=
-out HTLC before my upstream HTLC to A times out. If the CLTV delta is too =
small, I may fail the upstream HTLC as soon as it times out, and then C may=
still claim the downstream HTLC with the preimage on-chain. With eltoo, wh=
en B closes the downstream channel on-chain, it must wait the CSV timeout o=
n the update transaction before locking in the timed-out HTLC. This effecti=
vely means the CLTV delta has to be greater than the CSV timeout, plus some=
extra (whereas it is currently safe to make it significantly shorter). Is =
that true or am I missing something?</div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Mon, Apr 30, 2018 at 8:41 AM, Christian D=
ecker via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundati=
on.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(cross-posti=
ng to bitcoin-dev since this serves as motivation behind the<br>
sighash_noinput proposal)<br>
<br>
> TL;DR: we announce a new, simple, update mechanism for off-chain proto=
cols,<br>
> see the announcement [1] and the paper [2] :-)<br>
<br>
A little over a year ago, the three Lightning Network implementation<br>
teams joined forces to work on a common specification for the protocol<br>
stack. Now that both that specification and our three implementations<br>
are becoming stable and usable, it is time to look forward: to further<br>
improve the protocol, to add new features, to simplify, and to fix<br>
downsides.<br>
<br>
One of the core innovations that enabled Lightning in the first place was a=
n<br>
off-chain update mechanism to renegotiate a new state and ensure that the o=
ld<br>
state can not be settled on-chain. Today, we're excited to release our =
latest<br>
research paper on a new, simplified, update mechanism for layer 2 protocols=
,<br>
called eltoo.<br>
<br>
eltoo is a drop-in replacement for the penalty based invalidation<br>
mechanism that is used today in the Lightning specification. It is<br>
similar in many ways to the sequence number mechanism that was already<br>
present in the original Bitcoin implementation. But, while sequence<br>
numbers were unenforceable on the blockchain, eltoo is enforceable by<br>
overriding subsequent states on-chain.<br>
<br>
Unlike the current mechanism used in Lightning so far, it is not penalty<br=
>
based, i.e., publishing an old state does not result in the faulty node<br>
to automatically lose funds, and is most similar to the duplex<br>
micropayment channels construction. It is a symmetric scheme, i.e., all<br>
participants share an identical set of transactions, and it ensures that th=
e<br>
last agreed upon state is settled on-chain, with similar tradeoffs as<br>
today's Lightning (timelock vs. online requirement).<br>
<br>
eltoo addresses some of the issues we encountered while speficying and<br>
implementing the Lightning Network. For example outsourcing becomes very<br=
>
simple since old states becoming public can't hurt us anymore. We<br>
completely remove the need to estimate fees ahead of time. The<br>
construction allows us to attach fees when settling, and even allows for<br=
>
fees to be bumped using CPFP or RBF.<br>
<br>
Beyond Lightning, eltoo can be used as a generic update mechanism for an<br=
>
off-chain contract, for a larger number of participants. This was not<br>
possible in the current update mechanism since reactions to a<br>
misbehaving participant needed to be tailore to that participant. This<br>
enables other protocols such as the channel factories, and in<br>
combination with Schnorr signatures allows for very large off-chain<br>
contracts with minimal on-chain footprint.<br>
<br>
Before we can implement eltoo, we need a minor change to Bitcoin: the<br>
introduction of the SIGHASH_NOINPUT flag for signatures. This was first<br>
discussed a few months ago in the context of watchtowers to help secure<br>
Lightning channels, but was not formally proposed. A formal proposal may<br=
>
now be found in the eltoo paper.<br>
<br>
We invite the community to consider our proposal and to participate in<br>
its discussion. We hope to arrive at a consensus for the usage of<br>
SIGHASH_NOINPUT, so that it can be accepted and included in a future<br>
soft fork of Bitcoin Script. Doing so will put us on the road to a more<br>
reliable and simpler Lightning Network, incorporating a new update<br>
mechanism that can also be used for many other applications.<br>
<br>
The full official announcement can be found at [1] and the paper with the f=
ull<br>
details can be found at [2].<br>
<br>
Looking forward to the communities feedback,<br>
Christian<br>
<br>
[1] <a href=3D"https://blockstream.com/2018/04/30/eltoo-next-lightning.html=
" rel=3D"noreferrer" target=3D"_blank">https://blockstream.com/2018/<wbr>04=
/30/eltoo-next-lightning.<wbr>html</a><br>
[2] <a href=3D"https://blockstream.com/eltoo.pdf" rel=3D"noreferrer" target=
=3D"_blank">https://blockstream.com/eltoo.<wbr>pdf</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</blockquote></div><br></div>
--0000000000008c8363056b18d320--
|