From 0a42a73173f1025974aec9af53d9cf36def24326 Mon Sep 17 00:00:00 2001 From: Antoine Riard Date: Thu, 9 Apr 2020 22:04:30 -0400 Subject: [PATCH] Sanitize outgoing HTLC cltv_value --- lightning/src/ln/channel.rs | 2 -- lightning/src/ln/channelmanager.rs | 7 +++++++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs index ffa652097..3da9999d3 100644 --- a/lightning/src/ln/channel.rs +++ b/lightning/src/ln/channel.rs @@ -3538,8 +3538,6 @@ impl Channel { return Err(ChannelError::Ignore("Cannot send value that would put us over their reserve value")); } - //TODO: Check cltv_expiry? Do this in channel manager? - // Now update local state: if (self.channel_state & (ChannelState::AwaitingRemoteRevoke as u32)) == (ChannelState::AwaitingRemoteRevoke as u32) { self.holding_cell_htlc_updates.push(HTLCUpdateAwaitingACK::AddHTLC { diff --git a/lightning/src/ln/channelmanager.rs b/lightning/src/ln/channelmanager.rs index 2ea6ff2b0..f12a260ce 100644 --- a/lightning/src/ln/channelmanager.rs +++ b/lightning/src/ln/channelmanager.rs @@ -1172,6 +1172,13 @@ impl ChannelMan if msg.cltv_expiry > cur_height + CLTV_FAR_FAR_AWAY as u32 { // expiry_too_far break Some(("CLTV expiry is too far in the future", 21, None)); } + // We should be safe against unintentional channel-closure by our onchain logic due to this later + // offering a LATENCY_GRACE_PERIOD_BLOCKS. But to make our policy coherent with reception, apply + // same delay. + if (*outgoing_cltv_value) as u64 <= (cur_height + CLTV_CLAIM_BUFFER + LATENCY_GRACE_PERIOD_BLOCKS) as u64 { + break Some(("Outgoing CLTV value is too close", 0x1000 | 14, Some(self.get_channel_update(chan).unwrap()))); + } + break None; } { -- 2.39.5