BOLT #2: Swap cltv_expiry_delta values on open/accept for channel.

There's a mistake in the spec, where we were using the outgoing side of
a channel to control the CTLV delta.  But it's the receipient which is
vulnerable if it's too low, so the recipient should set it.

This exchanges values at channel open, and relies on the counterparty
to advertize it correctly in its `channel_update` messages.

There's another patch which changes the "Risks With HTLC Timeouts"
section to cover the setting of cltv_expiry_delta in detail, but
that's not ready yet.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

02-peer-protocol.md

@@ -99,6 +99,7 @@ desire to set up a new channel.
    * [`33`:`payment_basepoint`]
    * [`33`:`delayed_payment_basepoint`]
    * [`33`:`first_per_commitment_point`]
+   * [`4`:`cltv_expiry_delta`]
    * [`1`:`channel_flags`]
 
 
@@ -114,6 +115,9 @@ The `temporary_channel_id` is used to identify this channel until the funding tr
 
 `feerate_per_kw` indicates the initial fee rate by 1000-weight (ie. 1/4 the more normally-used 'feerate per kilobyte') which this side will pay for commitment and HTLC transactions as described in [BOLT #3](03-transactions.md#fee-calculation) (this can be adjusted later with an `update_fee` message).  `to_self_delay` is the number of blocks that the other nodes to-self outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this is how long it will have to wait in case of breakdown before redeeming its own funds.
 
+`cltv_expiry_delta` indicates the CLTV timeout requirement for HTLCs
+offered into this channel.
+
 Only the least-significant bit of `channel_flags` is currently
 defined: `announce_channel`.  This indicates whether the initiator of the
 funding flow wishes to advertise this channel publicly to the network
@@ -141,6 +145,8 @@ compressed secp256k1 pubkeys. The sender SHOULD set `feerate_per_kw`
 to at least the rate it estimates would cause the transaction to be
 immediately included in a block.
 
+The sender MUST set `cltv_expiry_delta` to the number of blocks it will
+subtract from an incoming HTLCs `cltv_expiry`.
 
 The sender SHOULD set `dust_limit_satoshis` to a sufficient value to
 allow commitment transactions to propagate through the Bitcoin
@@ -213,6 +219,7 @@ acceptance of the new channel.
    * [`33`:`payment_basepoint`]
    * [`33`:`delayed_payment_basepoint`]
    * [`33`:`first_per_commitment_point`]
+   * [`4`:`cltv_expiry_delta`]
 
 #### Requirements
 
@@ -508,7 +515,7 @@ the incoming HTLC has been irrevocably committed.
 A node MUST NOT fail an incoming HTLC (`update_fail_htlc`) for which it has committed 
 to an outgoing HTLC, until the removal of the outgoing HTLC is irrevocably committed, or the outgoing on-chain HTLC output has been spent via the HTLC-timeout transaction with sufficient depth.
 
-A node MUST fail an incoming HTLC (`update_fail_htlc`) once its `cltv_expiry` has been reached.
+A node MUST fail an incoming HTLC (`update_fail_htlc`) once its `cltv_expiry` has been reached, or if its `ctlv_expiry` is within `cltv_expiry_delta` (as this node sent in `open_channel` or `accept_channel`) of the current block height.
 
 A node MUST fulfill an incoming HTLC for which it has committed to an outgoing HTLC,
 as soon as it receives `update_fulfill_htlc` for the outgoing HTLC, or has discovered the `payment_preimage` from an on-chain HTLC spend.

07-routing-gossip.md

@@ -329,7 +329,7 @@ A subsequent `channel_update` with the `disable` bit unset MAY re-enable the cha
 
 The creating node MUST set `timestamp` to greater than zero, and MUST set it to greater than any previously-sent `channel_update` for this `short_channel_id`.
 
-It MUST set `cltv_expiry_delta` to the number of blocks it will subtract from an incoming HTLCs `cltv_expiry`.  It MUST set `htlc_minimum_msat` to the minimum HTLC value it will accept, in millisatoshi.  It MUST set `fee_base_msat` to the base fee it will charge for any HTLC, in millisatoshi, and `fee_proportional_millionths` to the amount it will charge per transferred satoshi in millionths of a satoshi.
+It MUST set `cltv_expiry_delta` to value received in the `open_channel` or `accept_channel` message.  It MUST set `htlc_minimum_msat` to the minimum HTLC value it will accept, in millisatoshi.  It MUST set `fee_base_msat` to the base fee it will charge for any HTLC, in millisatoshi, and `fee_proportional_millionths` to the amount it will charge per transferred satoshi in millionths of a satoshi.
 
 The receiving nodes MUST ignore the `channel_update` if it does not correspond to one of its own channels, if the `short_channel_id` does not match a previous `channel_announcement`, or the channel has been closed in the meantime.
 It SHOULD accept `channel_update`s for its own channels in order to learn the other end's forwarding parameters, even for non-public channels.
@@ -431,6 +431,13 @@ need to be considered: the `cltv_expiry_delta` contributes to the time that fund
 will be unavailable on worst-case failure.  The tradeoff between these
 two is unclear, as it depends on the reliability of nodes.
 
+Note that the `cltv_expiry_delta` is a requirement ultimately set by
+the receiving end of each channel, whereas fees are set by the sending
+end.  This matters, because it means that adding the
+`cltv_expiry_delta` to the HTLC timeout is required for the every
+channel in a route, whereas a node doesn't charge itself fees for
+using (its own) first channel.
+
 If a route is computed by simply routing to the intended recipient, summing up the `cltv_expiry_delta`s, then nodes along the route may guess their position in the route.
 Knowing the CLTV of the HTLC and the surrounding topology with the `cltv_expiry_delta`s gives an attacker a way to guess the intended recipient.
 Therefore it is highly suggested to add a random offset to the CLTV that the intended recipient will receive, bumping all CLTVs along the route.