summaryrefslogtreecommitdiff
path: root/fd/c6da2ab6ce40cbe1f0902e99c4a231d6d2b901
blob: 1d6a4fc3ff1d0891cd8195a03ceee3e7706ebe4c (plain)
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
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
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 CB2DD7FC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  7 May 2018 23:26:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6CEB318A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  7 May 2018 23:26:17 +0000 (UTC)
Received: by mail-wm0-f41.google.com with SMTP id o78-v6so18296017wmg.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 07 May 2018 16:26:17 -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=RV6ZVL8ynyQ2L8ORsM9oEOWfKhAaI7Sjp1PgNEMX7V8=;
	b=PlGqRbpEOqd8VSMW5U0fhiSFj+mSPhPj1crbRLgtHyyzOgh/2S0jmO7qLDpDWyZS6n
	Q9GQDPXg5EqbHE2H3Xwh7ECk9w8c+7bl7nRDFYf9hetOpACk5cx2zVYxTsde9DhFDmDB
	bo4UOOXTmUvYYerImVXsg01galIbCFYg+K9miMB38iI5qleis0mUbXR5bQqX1oMpCyYB
	CnPOfxn0CC9Xos75wYzffLZmcPgrV4Awc+TLUSn/v2V9CmtHkj8wzwk/WqiCLEHcqixF
	TBFzNzg+LLxZybcWFfVBoHhEUCM6bH4p35b0+TfdnPAWswDqQK2ueOfBDpNGE3v628cm
	QZAA==
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=RV6ZVL8ynyQ2L8ORsM9oEOWfKhAaI7Sjp1PgNEMX7V8=;
	b=FYMzR7leSAypjIR2hQwj6HNc+LvF5K+4HBh6QLJ6jW8vxjfiRQGNP6DUDVtoyTO2J6
	21B05c1VAXWr/02Z45OaJWLpZQwKxeer+/4g1BhidRRmrl2LW1xtRugb8nxWOoVLS7Kq
	JV4f1sttTsUc45pE+8G7be8FGoLxGguoJGEhhqMrujYNJaXDyTVu8Rj+9sGEE2NLhCZI
	nNZmpQyZpCLes5I8GaZiluALrhOdACqQ+NDol1aWuUm2WTaPgMRja5iNggYfCWmuCH1F
	/p7m8DCvOuy7IhcFgioefFqx9hyj1IL7IcrP/RTJvDCYsxwHyuRNt38bbQ0aK+khMneD
	qL3A==
X-Gm-Message-State: ALQs6tBbkIt3nWeZ0dWUe54m4q2wUaz2O1sMQWDCkg9ETsDPDzoWVpFy
	AQWSNNrv/LkTYKkRs2Zb6aH+RxvJBXdjBSsHMmM=
X-Google-Smtp-Source: AB8JxZqP5GQPbXfa7yWQYmIrxEAr7tDUSAdtw27fQpesr1GUb9/NLs0mm9VJuZ0mTlVmrJ8ggsl56QydcUPOvqwTu5o=
X-Received: by 2002:a50:d311:: with SMTP id
	g17-v6mr17954750edh.160.1525735575953; 
	Mon, 07 May 2018 16:26:15 -0700 (PDT)
MIME-Version: 1.0
References: <874ljsitvx.fsf@gmail.com>
	<CADZtCSgSJsU+j1teT4A9+nc+cuzBz+dhL+sC3dyGniQAsxPUxw@mail.gmail.com>
	<87vac7hakf.fsf@gmail.com>
	<CADZtCShihv1PR4yD_xATD2mv5CSMqH385HWVLdZQSG_9ZyJ7Jw@mail.gmail.com>
	<87in87gx0q.fsf@gmail.com>
	<CADZtCShvsaUpHKqRkkDm1XEmiSgj4Aa_VPdFFhaMQd9fcvxyZA@mail.gmail.com>
	<87bmdzgu4v.fsf@gmail.com>
	<CADZtCSgHmyYbumDw6bwfYpoqc9b-0JmHM5-22=Y1FXNDiTghrA@mail.gmail.com>
In-Reply-To: <CADZtCSgHmyYbumDw6bwfYpoqc9b-0JmHM5-22=Y1FXNDiTghrA@mail.gmail.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Mon, 07 May 2018 23:26:05 +0000
Message-ID: <CAO3Pvs8mf-X4T7fJOgZ9L8uSS3vKhZyvJ1SxL=gbk6b96QuMow@mail.gmail.com>
To: Jim Posen <jim.posen@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000006a58a056ba5ff04"
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] 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, 07 May 2018 23:26:18 -0000

--00000000000006a58a056ba5ff04
Content-Type: text/plain; charset="UTF-8"

Hi Jimpo,

You're correct that the introduction of symmetric state now re-introduces
the
dependency between the CSV value of the commitment, and the HTLC timeouts.
It's
worth nothing that this issue existed in an earlier version of the BOLT
spec,
this was pointed out by Mats in the past: [1][2]. The dependency meant that
if
we wanted to allow very long CSV time outs (like 1 month +), then this would
have the adverse effect of increasing the total CLTV timeout along the
entire
route. As a result, we moved to the 2-stage HTLC scheme which is now
implemented and deployed as a part of BOLT 1.0. It may be the case that in
the
mid to near future, most implementations aren't concerned about long time
locks
due to the existence of robust and reliable private outsourcers.

As a side effect of the way the symmetric state changes the strategy around
breach attempts, we may see more breach attempts (and therefore update
transactions) on the chain since attempting to cheat w/ vanilla symmetric
state
is now "costless" (worst case we just use the latest state, best case I can
commit the state better for me. This is in stark contrast to
punishment/slashing based approaches where a failed breach attempt results
in
the cheating party losing all their funds.

However, with a commitment protocol that uses symmetric state. The 2-stage
HTLC
scheme doesn't actually apply. Observe that with Lighting's current
asymmetric
state commitment protocol, the "clock" starts ticking as soon as the
commitment
hits the chain, and we follow the "if an output pays to me, it must be
delayed
as I may be attempting a breach". With symmetric state this no longer
applies,
the clock instead starts "officially" ticking after the latest update
transaction has hit the chain, and there are no further challenges. As a
result
of this, the commitment transaction itself doesn't need to have any CSV
delays
within the Script branches of the outputs it creates. Instead, each of those
outputs can be immediately be spent as the challenge period has already
elapsed,
and from the PoV of the chain, this is now the "correct" commitment. Due to
this, the HTLC outputs would now be symmetric themselves, and look very much
like an HTLC output that one would use in a vanilla on-chain cross-chain
atomic
swap.

[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000182.html
[2]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000339.html


On Tue, May 1, 2018 at 6:15 PM Jim Posen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> OK, I see what you are saying. You are effectively suggesting pipelining
> the broadcasts of the update transactions. I think this introduces a
> problem that a node in the circuit that withholds the preimage for too long
> can force all upstream channels to be closed, at only the expense of their
> one upstream channel being closed. I believe such an attack could
> significantly disrupt the network.
>
> Let me elaborate on the way I'm thinking about this:
>
> So say I'm a routing node with an upstream HTLC with CLTV = X. I need to
> ensure that if I learn the preimage, that I have time to broadcast and
> confirm an HTLC-success transaction before height X. We'll call this number
> of blocks D_success. So if I know the preimage, let's say X - D_success is
> the latest height that I can safely broadcast the HTLC-success transaction,
> assuming the settlement transaction is already final (ie. the update
> transaction is confirmed and the CSV delay has passed). So now I also need
> to know when to close the channel with the update transaction. I'll assume
> it will take at most D_update blocks from the time I broadcast the update
> transaction for it to be mined. So unless the downstream HTLC is already
> failed, I should always close the upstream channel at height X - D_success
> - CSV_update - D_update.
>
> Now we'll look at the downstream HTLC with CLTV = Y. In order to minimize
> the safe delta between the upstream and downstream CLTVs, I will want to
> broadcast and confirm an HTLC-timeout transaction as soon after height Y as
> possible. So assuming that the downstream settlement transaction is final
> at height Y and it takes at most D_timeout blocks for the HTLC timeout
> transaction to confirm once it is final assuming no double spends, then Y +
> D_timeout is very latest I might learn the payment preimage from the
> downstream channel on-chain. So I should be safe as long as X - D_success >
> Y + D_timeout. This assumes that the update transaction for the downstream
> channel is already mined and the CSV has passed. However, we know from
> above that I had to close the upstream channel at time X - D_success -
> CSV_update - D_update, which may very well be before Y. So if the
> downstream hop waits until just before Y to publish the preimage, they can
> force me to close my upstream channel. This applies transitively for
> further upstream hops, assuming a large enough CSV value.
>
> Granted, upstream hops can watch the blockchain for preimage reveals in
> other closings transaction and perhaps fulfill off-chain if there is
> sufficient time. This would not be possible with payment decorrelation
> through scriptless scripts or the like.
>
> Does that logic sound right to you?
>
> On Tue, May 1, 2018 at 10:31 AM, Christian Decker <
> decker.christian@gmail.com> wrote:
>
>> Jim Posen <jim.posen@gmail.com> writes:
>> > I'm still not following why this doesn't accumulate.
>> >
>> > In the example route, let's look at it from the point of view of C. C
>> sees
>> > the following regardless of whether D or E or someone behind E is the
>> last
>> > hop in the route:
>> >
>> > B -> HTLC(expire = X + delta) -> C -> HTLC(expire = X) -> D
>> >
>> > So D is not required to reveal the preimage before time X, and in the
>> case
>> > of an on-chain settle, C needs to be able to redeem the HTLC output
>> through
>> > the timeout clause before time X + delta. C can't redeem the HTLC (with
>> > sufficient confirmations) at least until the settlement transaction is
>> > confirmed. So it seems to me that regardless of the overall route and
>> the
>> > maximum CSV on it, the delta for the C hop has to be greater than the
>> CSV
>> > delay on the update transaction. And that this must be true at every hop
>> > for the same reason.
>>
>> That'd be a purely reactionary behavior, i.e., chosing the delta in such
>> a way that I can both settle the channel and have enough time to react
>> to turn around and reveal the preimage. So with the assumptions we had
>> before (CSV = 144 and CLTV delta = 144) you'd have an effective delta of
>> 288 on each hop, yes. That's basically the case in which each channel
>> reacts serially.
>>
>> You can trivially parallelize these closures by looking ahead and
>> noticing that each hop really just cares about its own closure deadline,
>> i.e., each node just cares to close 288 blocks before the CLTV expires,
>> not that its delta w.r.t. to the downstream channel is that far in the
>> future. So all we care about is that once we are due to give the
>> upstream hop the preimage we've already closed the downstream channel
>> and can now read the HTLC preimage from that channel.
>>
>> The CSV timeout isn't part of the delta on each hop, but we need to
>> implement the deadline computation as:
>>
>> ```
>> CLTV - CLTV delta - CSV
>> ```
>>
>> instead of LN-penaltiy's
>>
>> ```
>> CLTV - CLTV delta
>> ```
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000006a58a056ba5ff04
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Jimpo,=C2=A0</div><div><br></div><div>You&#39;re c=
orrect that the introduction of symmetric state now re-introduces the</div>=
<div>dependency between the CSV value of the commitment, and the HTLC timeo=
uts. It&#39;s</div><div>worth nothing that this issue existed in an earlier=
 version of the BOLT spec,</div><div>this was pointed out by Mats in the pa=
st: [1][2]. The dependency meant that if</div><div>we wanted to allow very =
long CSV time outs (like 1 month +), then this would</div><div>have the adv=
erse effect of increasing the total CLTV timeout along the entire</div><div=
>route. As a result, we moved to the 2-stage HTLC scheme which is now</div>=
<div>implemented and deployed as a part of BOLT 1.0. It may be the case tha=
t in the</div><div>mid to near future, most implementations aren&#39;t conc=
erned about long time locks</div><div>due to the existence of robust and re=
liable private outsourcers.=C2=A0</div><div><br></div><div>As a side effect=
 of the way the symmetric state changes the strategy around</div><div>breac=
h attempts, we may see more breach attempts (and therefore update</div><div=
>transactions) on the chain since attempting to cheat w/ vanilla symmetric =
state</div><div>is now &quot;costless&quot; (worst case we just use the lat=
est state, best case I can</div><div>commit the state better for me. This i=
s in stark contrast to</div><div>punishment/slashing based approaches where=
 a failed breach attempt results in</div><div>the cheating party losing all=
 their funds.</div><div><br></div><div>However, with a commitment protocol =
that uses symmetric state. The 2-stage HTLC</div><div>scheme doesn&#39;t ac=
tually apply. Observe that with Lighting&#39;s current asymmetric</div><div=
>state commitment protocol, the &quot;clock&quot; starts ticking as soon as=
 the commitment</div><div>hits the chain, and we follow the &quot;if an out=
put pays to me, it must be delayed</div><div>as I may be attempting a breac=
h&quot;. With symmetric state this no longer applies,</div><div>the clock i=
nstead starts &quot;officially&quot; ticking after the latest update</div><=
div>transaction has hit the chain, and there are no further challenges. As =
a result</div><div>of this, the commitment transaction itself doesn&#39;t n=
eed to have any CSV delays</div><div>within the Script branches of the outp=
uts it creates. Instead, each of those</div><div>outputs can be immediately=
 be spent as the challenge period has already elapsed,</div><div>and from t=
he PoV of the chain, this is now the &quot;correct&quot; commitment. Due to=
</div><div>this, the HTLC outputs would now be symmetric themselves, and lo=
ok very much</div><div>like an HTLC output that one would use in a vanilla =
on-chain cross-chain atomic</div><div>swap.</div><div><br></div><div>[1]: <=
a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-Se=
ptember/000182.html">https://lists.linuxfoundation.org/pipermail/lightning-=
dev/2015-September/000182.html</a></div><div>[2]: <a href=3D"https://lists.=
linuxfoundation.org/pipermail/lightning-dev/2015-November/000339.html">http=
s://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000339.=
html</a></div><div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
">On Tue, May 1, 2018 at 6:15 PM Jim Posen via bitcoin-dev &lt;<a href=3D"m=
ailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">OK, I see what you are saying. You are effectively suggesting pipelini=
ng the broadcasts of the update transactions. I think this introduces a pro=
blem that a node in the circuit that withholds the preimage for too long ca=
n force all upstream channels to be closed, at only the expense of their on=
e upstream channel being closed. I believe such an attack could significant=
ly disrupt the network.<div><br></div><div>Let me elaborate on the way I&#3=
9;m thinking about this:<br><div><br></div><div>So say I&#39;m a routing no=
de with an upstream HTLC with CLTV =3D X. I need to ensure that if I learn =
the preimage, that I have time to broadcast and confirm an HTLC-success tra=
nsaction before height X. We&#39;ll call this number of blocks D_success. S=
o if I know the preimage, let&#39;s say X - D_success is the latest height =
that I can safely broadcast the HTLC-success transaction, assuming the sett=
lement transaction is already final (ie. the update transaction is confirme=
d and the CSV delay has passed). So now I also need to know when to close t=
he channel with the update transaction. I&#39;ll assume it will take at mos=
t D_update blocks from the time I broadcast the update transaction for it t=
o be mined. So unless the downstream HTLC is already failed, I should alway=
s close the upstream channel at height X - D_success - CSV_update - D_updat=
e.</div></div><div><br></div><div>Now we&#39;ll look at the downstream HTLC=
 with CLTV =3D Y. In order to minimize the safe delta between the upstream =
and downstream CLTVs, I will want to broadcast and confirm an HTLC-timeout =
transaction as soon after height Y as possible. So assuming that the downst=
ream settlement transaction is final at height Y and it takes at most D_tim=
eout blocks for the HTLC timeout transaction to confirm once it is final as=
suming no double spends, then Y + D_timeout is very latest I might learn th=
e payment preimage from the downstream channel on-chain. So I should be saf=
e as long as X - D_success &gt; Y + D_timeout. This assumes that the update=
 transaction for the downstream channel is already mined and the CSV has pa=
ssed. However, we know from above that I had to close the upstream channel =
at time X - D_success - CSV_update - D_update, which may very well be befor=
e Y. So if the downstream hop waits until just before Y to publish the prei=
mage, they can force me to close my upstream channel. This applies transiti=
vely for further upstream hops, assuming a large enough CSV value.</div><di=
v><br></div><div>Granted, upstream hops can watch the blockchain for preima=
ge reveals in other closings transaction and perhaps fulfill off-chain if t=
here is sufficient time. This would not be possible with payment decorrelat=
ion through scriptless scripts or the like.</div><div><br></div><div>Does t=
hat logic sound right to you?</div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Tue, May 1, 2018 at 10:31 AM, Christian Decker <=
span dir=3D"ltr">&lt;<a href=3D"mailto:decker.christian@gmail.com" target=
=3D"_blank">decker.christian@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><span>Jim Posen &lt;<a href=3D"mailto:jim.posen@gmail.c=
om" target=3D"_blank">jim.posen@gmail.com</a>&gt; writes:<br>
&gt; I&#39;m still not following why this doesn&#39;t accumulate.<br>
&gt;<br>
&gt; In the example route, let&#39;s look at it from the point of view of C=
. C sees<br>
&gt; the following regardless of whether D or E or someone behind E is the =
last<br>
&gt; hop in the route:<br>
&gt;<br>
&gt; B -&gt; HTLC(expire =3D X + delta) -&gt; C -&gt; HTLC(expire =3D X) -&=
gt; D<br>
&gt;<br>
&gt; So D is not required to reveal the preimage before time X, and in the =
case<br>
&gt; of an on-chain settle, C needs to be able to redeem the HTLC output th=
rough<br>
&gt; the timeout clause before time X + delta. C can&#39;t redeem the HTLC =
(with<br>
&gt; sufficient confirmations) at least until the settlement transaction is=
<br>
&gt; confirmed. So it seems to me that regardless of the overall route and =
the<br>
&gt; maximum CSV on it, the delta for the C hop has to be greater than the =
CSV<br>
&gt; delay on the update transaction. And that this must be true at every h=
op<br>
&gt; for the same reason.<br>
<br>
</span>That&#39;d be a purely reactionary behavior, i.e., chosing the delta=
 in such<br>
a way that I can both settle the channel and have enough time to react<br>
to turn around and reveal the preimage. So with the assumptions we had<br>
before (CSV =3D 144 and CLTV delta =3D 144) you&#39;d have an effective del=
ta of<br>
288 on each hop, yes. That&#39;s basically the case in which each channel<b=
r>
reacts serially.<br>
<br>
You can trivially parallelize these closures by looking ahead and<br>
noticing that each hop really just cares about its own closure deadline,<br=
>
i.e., each node just cares to close 288 blocks before the CLTV expires,<br>
not that its delta w.r.t. to the downstream channel is that far in the<br>
future. So all we care about is that once we are due to give the<br>
upstream hop the preimage we&#39;ve already closed the downstream channel<b=
r>
and can now read the HTLC preimage from that channel.<br>
<br>
The CSV timeout isn&#39;t part of the delta on each hop, but we need to<br>
implement the deadline computation as:<br>
<br>
```<br>
CLTV - CLTV delta - CSV<br>
```<br>
<br>
instead of LN-penaltiy&#39;s<br>
<br>
```<br>
CLTV - CLTV delta<br>
```<br>
</blockquote></div><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>

--00000000000006a58a056ba5ff04--