📅 Original date posted:2018-05-01
📝 Original message:Jim Posen <jim.posen at gmail.com> writes:
> 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?
That's a good point Jim. We need to make sure that the CLTVs are far
enough in the future for the CSV timeout to expire and to grab any
preimage downstream and insert it upstream. Overall this results in an
offset of all the CLTVs to (less than) the maximum CSV timeout along the
path. This would be a fixed offset for each channel and can be announced
using the gossip protocol, so senders can take it into consideration
when computing the routes. Notice that this is not really the CLTV
delta, which would accumulate along the path, but an offset on which the
CLTV deltas build on.
In today's network we have many nodes that have a CLTV delta of 144
blocks, which quickly results in HTLC funds unavailable for several days
depending on the route length, so I don't think that adding a fixed
offset is much worse. Once we have watch-towers we can reduce both the
offset as well as the CLTV deltas. Since eltoo makes watch-towers less
expensive, given the reduced storage costs, I'd argue that it's a net
positive for the Lightning network (but then again I'm biased) :-)
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 18:11:44
in reply to nevent1q…9w0u
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 18:11:44Event JSON
{
"id": "c4bfa44dd8aa4e7b6b619e9983c6647d2c70988979bfbd5a265c165d46508d36",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686161504,
"kind": 1,
"tags": [
[
"e",
"2b5f569a6db12d61b5297b9d591cbd4acdec1f505f1dfe9dc388fdb42d189c7f",
"",
"root"
],
[
"e",
"48bd349c2d0f0b6ba564c6bddbbf6b2538d16e0ca70d94d8a9659d9cb7ce3733",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-05-01\n📝 Original message:Jim Posen \u003cjim.posen at gmail.com\u003e writes:\n\u003e If my understanding is correct though, this construction would\n\u003e significantly increase the safe CLTV delta requirements because HTLCs\n\u003e cannot be timed out immediately on the settlement transaction. Consider a\n\u003e case where node B receives an HTLC from A and forwards to C. If the HTLC\n\u003e offered to C times out and C does not fail the HTLC off-chain, Lightning\n\u003e currently guarantees that the CLTV delta is sufficient that I may close the\n\u003e channel to C on-chain and claim the timed-out HTLC before my upstream HTLC\n\u003e to A times out. If the CLTV delta is too small, I may fail the upstream\n\u003e HTLC as soon as it times out, and then C may still claim the downstream\n\u003e HTLC with the preimage on-chain. With eltoo, when B closes the downstream\n\u003e channel on-chain, it must wait the CSV timeout on the update transaction\n\u003e before locking in the timed-out HTLC. This effectively means the CLTV delta\n\u003e has to be greater than the CSV timeout, plus some extra (whereas it is\n\u003e currently safe to make it significantly shorter). Is that true or am I\n\u003e missing something?\n\nThat's a good point Jim. We need to make sure that the CLTVs are far\nenough in the future for the CSV timeout to expire and to grab any\npreimage downstream and insert it upstream. Overall this results in an\noffset of all the CLTVs to (less than) the maximum CSV timeout along the\npath. This would be a fixed offset for each channel and can be announced\nusing the gossip protocol, so senders can take it into consideration\nwhen computing the routes. Notice that this is not really the CLTV\ndelta, which would accumulate along the path, but an offset on which the\nCLTV deltas build on.\n\nIn today's network we have many nodes that have a CLTV delta of 144\nblocks, which quickly results in HTLC funds unavailable for several days\ndepending on the route length, so I don't think that adding a fixed\noffset is much worse. Once we have watch-towers we can reduce both the\noffset as well as the CLTV deltas. Since eltoo makes watch-towers less\nexpensive, given the reduced storage costs, I'd argue that it's a net\npositive for the Lightning network (but then again I'm biased) :-)",
"sig": "20eac1bfba8417fec74cf8c6e028cfd6802b85f4846d7f89e1f3abcf10c9f1939551d86ab2ed49681761c72902becf88b344cdf22de90926d40bf5b60d3f4cd1"
}