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

@@ -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
+almost arbitrary fees), `S` should be small during normal operation; although,
-irregular and empty blocks still occur, `S=2` should be considered a
+given that block times are irregular, empty blocks still occur, fees may vary
-minimum. Similarly, the grace period `G` can be low (1 or 2), as nodes are
+greatly, and the fees cannot be bumped on HTLC transactions, `S=12` should be
-required to timeout or fulfill as soon as possible; but if `G` is too low it increases the
+considered a minimum. `S` is also the parameter that may vary the most under
-risk of unnecessary channel closure due to networking delays.
+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
+2. the deadline for offered HTLCs: the deadline after which the channel has to
-   and timed out on-chain. This is `G` blocks after the HTLC's
+   be failed and timed out on-chain. This is `G` blocks after the HTLC's
-   `cltv_expiry`: 1 block is reasonable.
+   `cltv_expiry`: 1 or 2 blocks is reasonable.
 
-3. the deadline for received HTLCs this node has fulfilled: the deadline after which
+3. the deadline for received HTLCs this node has fulfilled: the deadline after
-the channel has to be failed and the HTLC fulfilled on-chain before its
+   which the channel has to be failed and the HTLC fulfilled on-chain before
-   `cltv_expiry`. See steps 4-7 above, which imply a deadline of `2R+G+S`
+   its `cltv_expiry`. See steps 4-7 above, which imply a deadline of `2R+G+S`
-   blocks before `cltv_expiry`: 7 blocks is reasonable.
+   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
+   1-3 above don't apply). The default in [BOLT #11](11-payment-encoding.md) is
-   [BOLT #11](11-payment-encoding.md) is 9, which is slightly more
+   9, which is less conservative than the 18 that this calculation suggests.
-   conservative than the 7 that this calculation suggests.
 
 #### Requirements