BOLT4: Specify max HTLC nLocktime for expiry_too_far#1086
BOLT4: Specify max HTLC nLocktime for expiry_too_far#1086Roasbeef merged 1 commit intolightning:masterfrom
Conversation
|
Implementations should specify what parameters they currently use for this: @rustyrussell @TheBlueMatt @t-bast @Roasbeef |
|
Eclair has increased its default to 2016 recently (ACINQ/eclair#2677) to match LND and CLN. So now I believe all implementations use 2016 by default. |
|
This appears to be 2016 in LND |
|
LDK is also 2016. |
|
Spec meeting notes (#1098): should update 4032 to 2016. |
|
OK, propose 2016 and everyone is happy. |
04-onion-routing.md
Outdated
| A common value between implementations allow forwarding nodes to increase their `cltv_expiry_delta` | ||
| without reducing the payers ability to route along the network. | ||
|
|
||
| This new common value `max_htlc_cltv` is suggested to be 4032 blocks. |
There was a problem hiding this comment.
Looks like we all do 2016 today, so let's stick with that as the recommendation?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
This should become a one liner. Change: to: |
This comment was marked as abuse.
This comment was marked as abuse.
04-onion-routing.md
Outdated
| - MAY use the data specified in the various failure types for debugging | ||
| purposes. | ||
|
|
||
| <<<<<<< HEAD |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
|
@ariard spec feedback is that we should make this change a one-liner instead of defining a new section. |
This comment was marked as abuse.
This comment was marked as abuse.
04-onion-routing.md
Outdated
| channel. | ||
| - return an `incorrect_cltv_expiry` error. | ||
| - if the `cltv_expiry` is unreasonably near the present: | ||
| - if the `cltv_expiry` is more than `max_htlc_cltv` near the present: |
There was a problem hiding this comment.
I think this should be modifying the line below?
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
Currently BOLT#4 recommends to forwarding node to reject HTLC with
nLocktimefield to far in the future from chain tip height (type 21:expiry_too_far). This recommendation is reasonable to avoid liquidity griefing where a HTLC would be send so far in the future (e.g 20 000 blocks from chain tip), than in case of on-chain force-closure of the link, the forwarding node cannot confirm the HTLC-timeout and therefore recover the satoshis locked.I think this recommendation is implemented by all the main Lightning implementations. For e.g, for LDK will reject HTLC more than 2016 block in the future (
CLTV_FAR_FAR_AWAY). This comes with few downsides, a) a payer cannot build payment path with more than 14 hops requesting at least acltv_expiry_deltaof 144 blocks, such path while onerous in term of off-chain fees could be done for privacy purpose and b) the forwarding nodes are limited in the selection of their owncltv_expiry_deltaand as such the level of safety they wish for the HTLC forward (e.g in protection against time-dilation attacks).This proposal suggests to adopt a common value between all implementations, dubbed
max_htlc_cltv. A default value of 4032 blocks (4 weeks) is proposed (though I didn’t check what is selected by LND/CLN/Eclair currently and if it makes sense to adapt in consequence). If adopted, suchmax_htlc_cltvwill improve the safety of routing nodes network-wide and allow more advanced rebalancing like #780.Beyond, a new option could be introduced
option_shrekand a correspondingchannel_updatemessage bit where routing hops are announcing they accept “unsafe” packets beyond 4032 blocks. This level of flexibility can be used by use-cases like multi-hop submarine swaps.cc lightningdevkit/rust-lightning#2250