Open morehouse opened 4 months ago
There's a related issue #8736, that we think when bumping the fees of a given input, if it's already in a set, we would instead bump the whole set to avoid fee bumping races. In addition, there's a TODO in #8680 which aids this new behavior,
update PendingSweeps to return inputs in InputSet, which gives users more info about the sweeping tx, so better decisions can be made when calling BumpFee.
UtxoSweeper.UpdateParams
updates the parameters for a specified input and resets its state toInit
, after which the sweeper can create a new transaction for the input. ButUpdateParams
does not cancel any existing fee bumps for the input.Thus, we can end up with the fee bumper creating multiple conflicting transactions each block. The fee bumper will not notice the conflicting transactions until one of them confirms, at which point any unspent inputs are allowed to be batched again.
These rebatched inputs will not be swept for at least 1 block after the conflicting transaction confirms, potentially causing deadlines to be missed in some edge cases.
Example edge case
Tx1
.Tx1
still hasn't confirmed. The user increases the budget for input A usingBumpFee
. The sweeper creates a new transactionTx2
containing only input A.Tx2
confirms. Inputs B and C are rebatched into a new transactionTx3
.Tx3
now cannot confirm before the deadline.Solution
UpdateParams
should probably cancel any existing fee bump for the specified input. This would allow immediate rebatching of inputs in the original transaction using the updated parameters.