sweep+rpc+cmd/lncli: expose pending input sweeps over RPC + CLI #3089
Conversation
|
PTAL @joostjager. |
Looks pretty good, just a few cosmetics related comments
lnrpc/rpc.proto
Outdated
| sweep transaction of the output. | ||
| */ | ||
| uint32 next_broadcast_height = 6 [json_name = "next_broadcast_height"]; | ||
| } |
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{ |
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)
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.
Tested locally, works as advertised!
LGTM contingent in unifying the byte reversal (in lncli as we do elsewhere)
straightforward diff, some high level comments
|
@wpaulino needs rebase |
|
PTAL @Roasbeef @joostjager. |
Tested and found that it works. Only minor comment is that the field name sat_per_byte remains a little vague without reading the comment. But don't know if last_sat_per_byte would be any better.
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 |
wpaulino
force-pushed
the
pendingsweeps-rpc
branch
3 times, most recently
from
ebecc4f
to
ab1491f
LGTM
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.
The text was updated successfully, but these errors were encountered: