[epic] sweeper: improve sweeper with defined responsibility and functionalities #8042
Labels
brainstorming
Long term ideas/discussion/requests for feedback
design review
enhancement
Improvements to existing features / behaviour
epic
Issues created to track large feature development
P1
MUST be fixed or reviewed
utxo sweeping
Ever since sweeper being introduced a few years ago, we've had a better understanding of this subsystem's responsibilities and functionalities. On a high level, our sweeper is responsible for,
In details, the sweeper will,
And it is NOT responsible for waiting for locktime to expire. The spending condition of the input should be met when it's received, in other words, this input should be immediately spendable. It's the other subsystem's responsibility to watch for the locktime expiration.
Bug Fixes
Before attempting to improve the sweeper, there are few bugs we need to fix first,
Simplification of Clustering Rules
Our current clustering rules make it very difficult to control the fee rate accurately by the caller. For any given input, it's categorized based on whether it has a locktime or not. Within each category, we then create clusters and average the fee rates in each cluster. Then the two categories are merged, which always lift the fee rate for timelock clusters if the non-timelock clusters have a higher one. This clustering logic is unnecessary as,
Thus, we should remove the cluster by locktime logic, and only keep the fee rate bucket logic - we still need the fee rate bucket because we want to support users to specify an inputs fee rate for compatibility.
A New Way to Specify Fee Preference
Instead of specifying fee rate or conf targets to express the urgency of the sweep, we will support specifying the fee by proportion. In details,
MaxFeeRatio
instead to tell the sweeper the max allowed fee it can use when sweeping this transaction.MaxFeeRatio
is the max value proportional to the value of the input.MaxFeeRatio
, inputs with different fee rates which cannot be swept together previously can now be put in the same transaction.Note that fee rate already implicitly expresses the max fee ratio, and this implicitly makes the fee bumper implementation more difficult.
Fee Bumper
A subservice that's responsible for bumping the fee rate when the deadline is approaching. More details in #4215 and #7549.
With this new service, we'd solve the following issues,
New RPC and Configs
We'd also want to provide more config options and RPC endpoints for users to interact with the sweeper.
We may further add
RemoveInput
andAddInput
, which requires much more work so won't happen in the near future.Other Improvements
Each input should have a state that's used to track its lifecycle. We may want to persist it on disk to solve the restart issue found in [bug]: Channel is stuck in pending state. #8028.
remove the logic that we retry the failed broadcasts, instead, implement
testmempoolaccept
inbtcd
, and use this check to increase the success rate of the broadcast. Our current logic retries the inputs in a failed transaction, which may end up in an RBF situation that the sweeper is not able to handle.utxonursery: delete #3688
The text was updated successfully, but these errors were encountered: