mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-02-22 14:22:46 +01:00
Code Issues Projects Releases Wiki Activity

More conservative cltv_expiry_delta recommendations

Browse source 
Many channels use a value below 6, which is really insecure (there are
more than 2k such channels on mainnet).

While less risky, there are more than 7k channels with a value below 12.

This indicates that the spec should probably make the risks a bit more
clear to help guide node operators.
This commit is contained in:
t-bast 2020-06-25 11:56:15 +02:00 • committed by Rusty Russell
parent c053ce7afb
commit 886bf7a430
1 changed files with 18 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
02-peer-protocol.md
View file

@ -741,31 +741,33 @@ the longest possible time to redeem it on-chain:
Thus, the worst case is `3R+2G+2S`, assuming `R` is at least 1. Note that the
chances of three reorganizations in which the other node wins all of them is
low for `R` of 2 or more. Since high fees are used (and HTLC spends can use
almost arbitrary fees), `S` should be small; although, given that block times are
irregular and empty blocks still occur, `S=2` should be considered a
minimum. Similarly, the grace period `G` can be low (1 or 2), as nodes are
required to timeout or fulfill as soon as possible; but if `G` is too low it increases the
risk of unnecessary channel closure due to networking delays.
almost arbitrary fees), `S` should be small during normal operation; although,
given that block times are irregular, empty blocks still occur, fees may vary
greatly, and the fees cannot be bumped on HTLC transactions, `S=12` should be
considered a minimum. `S` is also the parameter that may vary the most under
attack, so a higher value may be desirable when non negligible amounts are at
risk. The grace period `G` can be low (1 or 2), as nodes are required to timeout
or fulfill as soon as possible; but if `G` is too low it increases the risk of
unnecessary channel closure due to networking delays.
There are four values that need be derived:
1. the `cltv_expiry_delta` for channels, `3R+2G+2S`: if in doubt, a
`cltv_expiry_delta` of 12 is reasonable (R=2, G=1, S=2).
`cltv_expiry_delta` of at least 34 is reasonable (R=2, G=2, S=12).
2. the deadline for offered HTLCs: the deadline after which the channel has to be failed
and timed out on-chain. This is `G` blocks after the HTLC's
`cltv_expiry`: 1 block is reasonable.
2. the deadline for offered HTLCs: the deadline after which the channel has to
be failed and timed out on-chain. This is `G` blocks after the HTLC's
`cltv_expiry`: 1 or 2 blocks is reasonable.
3. the deadline for received HTLCs this node has fulfilled: the deadline after which
the channel has to be failed and the HTLC fulfilled on-chain before its
`cltv_expiry`. See steps 4-7 above, which imply a deadline of `2R+G+S`
blocks before `cltv_expiry`: 7 blocks is reasonable.
3. the deadline for received HTLCs this node has fulfilled: the deadline after
which the channel has to be failed and the HTLC fulfilled on-chain before
its `cltv_expiry`. See steps 4-7 above, which imply a deadline of `2R+G+S`
blocks before `cltv_expiry`: 18 blocks is reasonable.
4. the minimum `cltv_expiry` accepted for terminal payments: the
worst case for the terminal node C is `2R+G+S` blocks (as, again, steps
1-3 above don't apply). The default in
[BOLT #11](11-payment-encoding.md) is 9, which is slightly more
conservative than the 7 that this calculation suggests.
1-3 above don't apply). The default in [BOLT #11](11-payment-encoding.md) is
9, which is less conservative than the 18 that this calculation suggests.
#### Requirements