📅 Original date posted:2018-05-01
📝 Original message:Jim Posen <jim.posen at 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
```
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 18:11:45
in reply to nevent1q…s4tp
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 18:11:45Event JSON
{
"id": "861793dedd46bb0bbca7bcfb6e2198b7b066c9cabced79e52647fd7430a920c3",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686161505,
"kind": 1,
"tags": [
[
"e",
"2b5f569a6db12d61b5297b9d591cbd4acdec1f505f1dfe9dc388fdb42d189c7f",
"",
"root"
],
[
"e",
"9e86250eaba2dd919e27cdcb0591e71a0f57df34300650272308a0a5acc1de42",
"",
"reply"
],
[
"p",
"9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1"
]
],
"content": "📅 Original date posted:2018-05-01\n📝 Original message:Jim Posen \u003cjim.posen at gmail.com\u003e writes:\n\u003e I'm still not following why this doesn't accumulate.\n\u003e\n\u003e In the example route, let's look at it from the point of view of C. C sees\n\u003e the following regardless of whether D or E or someone behind E is the last\n\u003e hop in the route:\n\u003e\n\u003e B -\u003e HTLC(expire = X + delta) -\u003e C -\u003e HTLC(expire = X) -\u003e D\n\u003e\n\u003e So D is not required to reveal the preimage before time X, and in the case\n\u003e of an on-chain settle, C needs to be able to redeem the HTLC output through\n\u003e the timeout clause before time X + delta. C can't redeem the HTLC (with\n\u003e sufficient confirmations) at least until the settlement transaction is\n\u003e confirmed. So it seems to me that regardless of the overall route and the\n\u003e maximum CSV on it, the delta for the C hop has to be greater than the CSV\n\u003e delay on the update transaction. And that this must be true at every hop\n\u003e for the same reason.\n\nThat'd be a purely reactionary behavior, i.e., chosing the delta in such\na way that I can both settle the channel and have enough time to react\nto turn around and reveal the preimage. So with the assumptions we had\nbefore (CSV = 144 and CLTV delta = 144) you'd have an effective delta of\n288 on each hop, yes. That's basically the case in which each channel\nreacts serially.\n\nYou can trivially parallelize these closures by looking ahead and\nnoticing that each hop really just cares about its own closure deadline,\ni.e., each node just cares to close 288 blocks before the CLTV expires,\nnot that its delta w.r.t. to the downstream channel is that far in the\nfuture. So all we care about is that once we are due to give the\nupstream hop the preimage we've already closed the downstream channel\nand can now read the HTLC preimage from that channel.\n\nThe CSV timeout isn't part of the delta on each hop, but we need to\nimplement the deadline computation as:\n\n```\nCLTV - CLTV delta - CSV\n```\n\ninstead of LN-penaltiy's\n\n```\nCLTV - CLTV delta\n```",
"sig": "eac02c2a514f1594568cde3c1ea417c5380d60c67271260131f306052bd8b6837d08b887708a1e7604ff0817530fb7b8ca770bea21a68b3f12c768c2c6645e37"
}