Correct confirmation target constant definitions

`CLTV_CLAIM_BUFFER`'s definition stated "this is an upper bound on
how many blocks we think it can take us to get a transaction
confirmed". This was mostly okay for pre-anchor channels, where we
broadcasted HTLC claim transactions at the same time as the
commitment transactions themselves, but for anchor channels we can
no longer do that - HTLC transactions are always CSV 1'd.

Further, when we do go to broadcast HTLC transactions, we start
the feerate estimate for them back at the users' feerate estimator,
rather than whatever feerate we ended up using to get the
commitment transaction confirmed. While we should maybe consider
changing that, for now that means that we really need to run the
whole "get a transaction confirmed" process from start to finish
*twice* in order to claim an HTLC.

Thus, `CLTV_CLAIM_BUFFER` is here redefined to be two times "the
upper bound on how many blocks we think it can take for us to get
a transaction confirmed", with a new `MAX_BLOCKS_FOR_CONF` constant
defining the expected max blocks.

Author: TheBlueMatt

lightning/src/chain/channelmonitor.rs

@@ -227,11 +227,15 @@ pub(crate) const COUNTERPARTY_CLAIMABLE_WITHIN_BLOCKS_PINNABLE: u32 = 12;
 /// expiring at the same time.
 const _: () = assert!(CLTV_CLAIM_BUFFER > COUNTERPARTY_CLAIMABLE_WITHIN_BLOCKS_PINNABLE);
 
+/// The upper bound on how many blocks we think it can take for us to get a transaction confirmed.
+pub(crate) const MAX_BLOCKS_FOR_CONF: u32 = 9;
+
 /// If an HTLC expires within this many blocks, force-close the channel to broadcast the
 /// HTLC-Success transaction.
-/// In other words, this is an upper bound on how many blocks we think it can take us to get a
-/// transaction confirmed (and we use it in a few more, equivalent, places).
-pub(crate) const CLTV_CLAIM_BUFFER: u32 = 18;
+///
+/// This is two times [`MAX_BLOCKS_FOR_CONF`] as we need to first get the commitment transaction
+/// confirmed, then get an HTLC transaction confirmed.
+pub(crate) const CLTV_CLAIM_BUFFER: u32 = MAX_BLOCKS_FOR_CONF * 2;
 /// Number of blocks by which point we expect our counterparty to have seen new blocks on the
 /// network and done a full update_fail_htlc/commitment_signed dance (+ we've updated all our
 /// copies of ChannelMonitors, including watchtowers). We could enforce the contract by failing

lightning/src/ln/channelmanager.rs

@@ -40,7 +40,7 @@ use crate::blinded_path::payment::{AsyncBolt12OfferContext, BlindedPaymentPath,
 use crate::chain;
 use crate::chain::{Confirm, ChannelMonitorUpdateStatus, Watch, BestBlock};
 use crate::chain::chaininterface::{BroadcasterInterface, ConfirmationTarget, FeeEstimator, LowerBoundedFeeEstimator};
-use crate::chain::channelmonitor::{Balance, ChannelMonitor, ChannelMonitorUpdate, WithChannelMonitor, ChannelMonitorUpdateStep, HTLC_FAIL_BACK_BUFFER, CLTV_CLAIM_BUFFER, LATENCY_GRACE_PERIOD_BLOCKS, ANTI_REORG_DELAY, MonitorEvent};
+use crate::chain::channelmonitor::{Balance, ChannelMonitor, ChannelMonitorUpdate, WithChannelMonitor, ChannelMonitorUpdateStep, HTLC_FAIL_BACK_BUFFER, MAX_BLOCKS_FOR_CONF, CLTV_CLAIM_BUFFER, LATENCY_GRACE_PERIOD_BLOCKS, ANTI_REORG_DELAY, MonitorEvent};
 use crate::chain::transaction::{OutPoint, TransactionData};
 use crate::events::{self, Event, EventHandler, EventsProvider, InboundChannelFunds, MessageSendEvent, MessageSendEventsProvider, ClosureReason, HTLCDestination, PaymentFailureReason, ReplayEvent};
 // Since this struct is returned in `list_channels` methods, expose it here in case users want to
@@ -2843,15 +2843,14 @@ pub const MIN_FINAL_CLTV_EXPIRY_DELTA: u16 = HTLC_FAIL_BACK_BUFFER as u16 + 3;
 // Check that our MIN_CLTV_EXPIRY_DELTA gives us enough time to get everything on chain and locked
 // in with enough time left to fail the corresponding HTLC back to our inbound edge before they
 // force-close on us.
-// ie that if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
+// In other words, if the next-hop peer fails the HTLC LATENCY_GRACE_PERIOD_BLOCKS after our
 // CLTV_CLAIM_BUFFER (because that's how many blocks we allow them after expiry), we'll still have
-// CLTV_CLAIM_BUFFER + ANTI_REORG_DELAY left to get two transactions on chain and the second
-// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BOLOCKS before the
+// 2*MAX_BLOCKS_FOR_CONF + ANTI_REORG_DELAY left to get two transactions on chain and the second
+// fully locked in before the peer force-closes on us (LATENCY_GRACE_PERIOD_BLOCKS before the
 // expiry, i.e. assuming the peer force-closes right at the expiry and we're behind by
 // LATENCY_GRACE_PERIOD_BLOCKS).
-// second fully locked in before the peer force-closes on us.
 const _CHECK_CLTV_EXPIRY_SANITY: () = assert!(
-	MIN_CLTV_EXPIRY_DELTA as u32 >= 2*LATENCY_GRACE_PERIOD_BLOCKS + CLTV_CLAIM_BUFFER + ANTI_REORG_DELAY
+	MIN_CLTV_EXPIRY_DELTA as u32 >= 2*LATENCY_GRACE_PERIOD_BLOCKS + 2*MAX_BLOCKS_FOR_CONF + ANTI_REORG_DELAY
 );
 
 // Check that our MIN_CLTV_EXPIRY_DELTA gives us enough time to get the HTLC preimage back to our