Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature]: Add Flag to BumpFee RPC and CLI to prevent batching #9505

Open
starius opened this issue Feb 11, 2025 · 1 comment
Open

[feature]: Add Flag to BumpFee RPC and CLI to prevent batching #9505

starius opened this issue Feb 11, 2025 · 1 comment
Labels
enhancement Improvements to existing features / behaviour utxo sweeping

Comments

@starius
Copy link
Collaborator

starius commented Feb 11, 2025

Is your feature request related to a problem? Please describe.

When using the BumpFee RPC, I calculate the feerate based on the parent transaction's feerate and the desired effective feerate for a group of two transactions. Currently, the batcher may combine my input with another input in a batch CPFP (resulting in a 2:1 transaction), making it impossible to achieve the intended effective feerate.

Describe the solution you'd like

I propose adding an additional flag to BumpFee that forces the sweeper to assign the input to an exclusive group, ensuring it produces only a 1:1 child transaction (no batching).

I noticed that the sweeper already has an internal field called ExclusiveGroup. Would it be worth making this field public?

Describe alternatives you've considered

  • If #5432 is implemented, I could use it to specify the desired effective feerate.
  • Alternatively, I could perform CPFP manually instead of using the BumpFee RPC.
@starius starius added the enhancement Improvements to existing features / behaviour label Feb 11, 2025
@yyforyongyu
Copy link
Member

I think you can already do that by specifying a unique deadline, plus budget, then this would be managed by the sweeper,

&walletrpc.BumpFeeRequest{
	Outpoint: op,
	Immediate:  true,
	Budget: xxx,
	DeadlineDelta: xxx
}

calculate the feerate based on the parent transaction's feerate and the desired effective feerate for a group of two transactions.

Based on the description here I think you want to bypass the sweeper and manage the feerate manually - in that case we might as well add a new RPC that does one thing - create the tx with the desired feerate and publish it. There's no need to let it be managed by the sweeper since there's no aggregation or fee bumping involved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvements to existing features / behaviour utxo sweeping
Projects
None yet
Development

No branches or pull requests

3 participants