fixup! Add CounterpartyForwardingInfo field to channel.

Author: valentinewallace

lightning/src/ln/channel.rs

@@ -288,8 +288,9 @@ pub struct CounterpartyForwardingInfo {
 	pub fee_base_msat: u32,
 	/// Amount in millionths of a satoshi the channel will charge per transferred satoshi.
 	pub fee_proportional_millionths: u32,
-	/// The number of blocks we'll add to an outgoing HTLC's cltv_expiry before forwarding.
-	/// See `msgs::ChannelUpdate`'s `cltv_expiry_delta` for more details.
+	/// The minimum difference in cltv_expiry between an ingoing HTLC and its outgoing counterpart,
+	/// such that the outgoing HTLC is forwardable to this counterparty. See `msgs::ChannelUpdate`'s
+	/// `cltv_expiry_delta` for more details.
 	pub cltv_expiry_delta: u16,
 }
 

lightning/src/ln/msgs.rs

@@ -544,11 +544,13 @@ pub struct UnsignedChannelUpdate {
 	/// Channel flags
 	pub flags: u8,
 	/// The number of blocks such that if:
-	/// `htlc.cltv_expiry - current_block_height <= cltv_expiry_delta`
-	/// then we need to fail the HTLC backwards. When forwarding an HTLC, cltv_expiry_delta is used to
-	/// calculate the outgoing HTLC's cltv_expiry value -- so, if an incoming HTLC comes in with a
+	/// `incoming_htlc.cltv_expiry < outgoing_htlc.cltv_expiry + cltv_expiry_delta`
+	/// then we need to fail the HTLC backwards. When forwarding an HTLC, cltv_expiry_delta determines
+	/// the outgoing HTLC's minimum cltv_expiry value -- so, if an incoming HTLC comes in with a
 	/// cltv_expiry of 100000, and the node we're forwarding to has a cltv_expiry_delta value of 10,
-	/// then we'll set the outgoing HTLC's cltv_expiry value to 100010.
+	/// then we'll check that the outgoing HTLC's cltv_expiry value is at least 100010 before
+	/// forwarding. Note that the HTLC sender is the one who originally sets this value when
+	/// constructing the route.
 	pub cltv_expiry_delta: u16,
 	/// The minimum HTLC size incoming to sender, in milli-satoshi
 	pub htlc_minimum_msat: u64,