sweep+rpc+cmd/lncli: expose pending input sweeps over RPC + CLI - #3089
Conversation
wpaulino
added
utxo sweeping
cli
|
PTAL @joostjager. |
Roasbeef
left a comment
Roasbeef
left a comment
There was a problem hiding this comment.
Looks pretty good, just a few cosmetics related comments
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.
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.
Roasbeef
left a comment
Roasbeef
left a comment
There was a problem hiding this comment.
Tested locally, works as advertised!
LGTM contingent in unifying the byte reversal (in lncli as we do elsewhere) 🌊
cfromknecht
left a comment
cfromknecht
left a comment
There was a problem hiding this comment.
straightforward diff, some high level comments
|
@wpaulino needs rebase |
|
PTAL @Roasbeef @joostjager. |
joostjager
left a comment
joostjager
left a comment
There was a problem hiding this comment.
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 |
4 participants
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.