sweep+rpc: add support to bump fee of inputs/transactions#3140
sweep+rpc: add support to bump fee of inputs/transactions#3140wpaulino merged 6 commits intolightningnetwork:masterfrom wpaulino:sweeper-bumpfee
Conversation
wpaulino
added
cli
sweep/sweeper.go
Outdated
There was a problem hiding this comment.
So it's the job of the caller to compute the proper fee rate that'll cause the entire package to be bumped by a satisfactory amount?
There was a problem hiding this comment.
Yes. I'm not a fan of this, but from our previous discussions offline it seemed like this was the approach to take for now. We should be able to compute this quite easily for full nodes, but things get a bit trickier with light clients.
rpcserver.go
Outdated
There was a problem hiding this comment.
Validation here in case both or none are set?
There was a problem hiding this comment.
Validation is done within the UtxoSweeper.BumpFee call.
There was a problem hiding this comment.
Just checking that exactly one of those fields is set could may be done in a sweeper.NewFeePreference(confTarget, feeRate) constructor. It simplifies consumers of this struct, because they don't all need to do this check.
There was a problem hiding this comment.
Some other RPCs rely on a fee preference not being set to choose the default. Adding a constructor that applies additional validation checks would lead to some confusion IMO. Either we should unify the behavior of FeePreference all around, or we introduce a new SweepPreference type that applies the validation needed for sweeps only.
|
PTAL @joostjager @Roasbeef. |
|
PTAL @joostjager. |
|
Can be rebased now that #3089 is in. |
|
Rebased! |
lnrpc/walletrpc/walletkit_server.go
Outdated
There was a problem hiding this comment.
Don't we need to provide a more populated sign descriptor? At the very least, the pubkey information.
There was a problem hiding this comment.
The only field required seems to be the output. This is also what CraftSweepAllTx does.
sweep/sweeper.go
Outdated
There was a problem hiding this comment.
Still feels a bit strange that we validate against a moving fee rate here.
There was a problem hiding this comment.
The fee preference won't always map to a moving fee rate. I see this more as just a sanity check to ensure it respects the min and max fee rate we'll allow.
There was a problem hiding this comment.
I think I made the point before, but what I find strange is that we may reject an input here when the fee estimate (let's say X) exceeds the max. While if the fee estimate was below max, we would have added and when - later - the fee estimate would increase to X we would just wait until it goes down again. Seems inconsistent, but no blocker.
There was a problem hiding this comment.
I understand your point, but I see this more as a sanity check to ensure we don't ever see some kind of insane fee rate.
We want to make sure clients are aware of their own fee preferences, rather than relying on defaults.
In this commit, we introduce the ability to bump the fee of an input within the UtxoSweeper. Once its fee rate is bumped, a replacement transaction (RBF) will be broadcast with the newer fee rate (assuming the newer fee rate is high enough to be valid), replacing any conflicting lower fee rate transactions. Note that this currently doesn't validate the fee preference of the bump. This responsibility is delegated to the caller, so care must be taken to ensure the new fee preference is sufficient.
This RPC exposes the recently added BumpFee functionality to the UtxoSweeper in order to allow users of the RPC to manually bump fees of low fee inputs/transactions.
|
PTAL @Roasbeef @joostjager. |
| case nil: | ||
| return &BumpFeeResponse{}, nil | ||
| case lnwallet.ErrNotMine: | ||
| break |
3 participants
In this PR, we add support to the
UtxoSweeperto bump the fee of an input it's currently attempting to sweep and to bump the fee of a transaction through CPFP. We also add a new RPC and a correspondinglnclicommand to expose the functionality to users.This RPC takes a different approach than
bitcoind's bumpfee command.lndhas a central batching engine, known as theUtxoSweeper, in which inputs with similar fee rates are batched together to save on transaction fees. Due to this, we cannot rely on bumping the fee on a specific transaction, since transactions can change at any point with the addition of new inputs. The list of inputs that currently exist within theUtxoSweepercan be retrieved through thePendingSweepsRPC.When bumping the fee of an input that currently exists within the
UtxoSweeper, a higher fee transaction will be created that replaces the lower fee transaction through the Replace-By-Fee (RBF) policy.This RPC also serves useful when wanting to perform a Child-Pays-For-Parent (CPFP), where the child transaction pays for its parent's fee. This can be done by specifying an outpoint within the low fee transaction that is under the control of the wallet.
Note that this RPC currently doesn't perform any validation checks on the fee preference being provided. For now, the responsibility of ensuring that the new fee preference is sufficient is delegated to the user.
Depends on #3089.
Fixes #609.
Fixes #2977.