From 886bf7a430db706b483b7b02d64a82bf175c0b46 Mon Sep 17 00:00:00 2001 From: t-bast Date: Thu, 25 Jun 2020 11:56:15 +0200 Subject: [PATCH] More conservative cltv_expiry_delta recommendations 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. --- 02-peer-protocol.md | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 0a00ee9..00a9a9d 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -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