Dont forget RBF previous-feerate info if tx size changed.

While our fee may change wildly (or even go down), the previous
fee *rate* is still valid, and we should use that as the basis for
our RBF.

diff --git a/lightning/src/ln/channelmonitor.rs b/lightning/src/ln/channelmonitor.rs
index e17111256ea016ae6df06abaa22fcb5b846f8043..ed532e1f025e0a5e6355bbc4585de507449e3a35 100644 (file)
--- a/lightning/src/ln/channelmonitor.rs
+++ b/lightning/src/ln/channelmonitor.rs
@@ -2421,8 +2421,6 @@ impl ChannelMonitor {
                                                                        claimed_input_material.push(input_material);
                                                                }
                                                        }
-                                                       // Avoid bump engine using inaccurate feerate due to new transaction size
-                                                       claim_material.feerate_previous = 0;
                                                        //TODO: recompute soonest_timelock to avoid wasting a bit on fees
                                                        bump_candidates.push((ancestor_claimable_txid.0.clone(), claim_material.clone()));
                                                }
@@ -2519,8 +2517,6 @@ impl ChannelMonitor {
                                        OnchainEvent::ContentiousOutpoint { outpoint, input_material } => {
                                                if let Some(ancestor_claimable_txid) = self.claimable_outpoints.get(&outpoint) {
                                                        if let Some(claim_material) = self.pending_claim_requests.get_mut(&ancestor_claimable_txid.0) {
-                                                               // Avoid bump engine using inaccurate feerate due to new transaction size
-                                                               claim_material.feerate_previous = 0;
                                                                claim_material.per_input_material.insert(outpoint, input_material);
                                                                // Using a HashMap guarantee us than if we have multiple outpoints getting
                                                                // resurrected only one bump claim tx is going to be broadcast