Skip to content

Commit e78d43a

Browse files
committed
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.
1 parent d87972a commit e78d43a

File tree

1 file changed

+0
-4
lines changed

1 file changed

+0
-4
lines changed

lightning/src/ln/channelmonitor.rs

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -2421,8 +2421,6 @@ impl ChannelMonitor {
24212421
claimed_input_material.push(input_material);
24222422
}
24232423
}
2424-
// Avoid bump engine using inaccurate feerate due to new transaction size
2425-
claim_material.feerate_previous = 0;
24262424
//TODO: recompute soonest_timelock to avoid wasting a bit on fees
24272425
bump_candidates.push((ancestor_claimable_txid.0.clone(), claim_material.clone()));
24282426
}
@@ -2519,8 +2517,6 @@ impl ChannelMonitor {
25192517
OnchainEvent::ContentiousOutpoint { outpoint, input_material } => {
25202518
if let Some(ancestor_claimable_txid) = self.claimable_outpoints.get(&outpoint) {
25212519
if let Some(claim_material) = self.pending_claim_requests.get_mut(&ancestor_claimable_txid.0) {
2522-
// Avoid bump engine using inaccurate feerate due to new transaction size
2523-
claim_material.feerate_previous = 0;
25242520
claim_material.per_input_material.insert(outpoint, input_material);
25252521
// Using a HashMap guarantee us than if we have multiple outpoints getting
25262522
// resurrected only one bump claim tx is going to be broadcast

0 commit comments

Comments
 (0)