sweep+rpc+cmd/lncli: expose pending input sweeps over RPC + CLI #3089
Conversation
wpaulino
added
utxo sweeping
cli
|
PTAL @joostjager. |
lnrpc/rpc.proto
Outdated
| sweep transaction of the output. | ||
| */ | ||
| uint32 next_broadcast_height = 6 [json_name = "next_broadcast_height"]; | ||
| } |
There was a problem hiding this comment.
Once we circle back and add retargeting, it may be useful to expose what the next fee rate would be.
sweep/sweeper.go
Outdated
| for _, pendingInput := range s.pendingInputs { | ||
| // Only the exported fields are set, as we expect the response | ||
| // to only be consumed externally. | ||
| pendingInputs = append(pendingInputs, &PendingInput{ |
There was a problem hiding this comment.
I had the same thing with creating a snapshot in mission control and introduced separate exported structs for the snapshot. I think it is cleaner. (non blocking)
There was a problem hiding this comment.
Yeah that was how the initial design of the PR approached it, but I opted for reusing the same struct to result in less code, though the difference is not much.
|
@wpaulino needs rebase |
|
PTAL @Roasbeef @joostjager. |
This will serve useful when exposing the pending inputs over RPC, since we currently don't keep track of the last fee rate used for an input.
Agreed. This is why Rebased to address a |
In this PR, we expose the set of pending inputs that the UtxoSweeper is currently attempting to sweep. This will serve as preparatory work for allowing users to perform fee bumps. Due to the UtxoSweeper's asynchronous nature, we are not able to quickly report on whether a fee bump succeeded or not, so we resort towards exposing its internal fee rate bucketing system over RPC to give users an indication of what's currently being swept and with what fee rate.
I opted to only expose the sweeping fee rate for each bucket, along with all of the inputs within each bucket and their individual fee rates for now. Looking for feedback on whether we could be exposing this information better.
Depends on #3026.