-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
sweep: add wallet inputs to reach dust limit #3814
sweep: add wallet inputs to reach dust limit #3814
Conversation
We need it to be set in order to properly test the sweeper handling the dust limit on regtest.
bd3d6c8
to
215c322
Compare
26a6329
to
3dea473
Compare
Using a fee rate just as an identifier can be confusing.
Fixes a bug where bucket sizes were not the configured size, but the configured size plus the min relay fee.
3dea473
to
86121bb
Compare
c15f2ff
to
aa898b2
Compare
Prepares for adding more input-specific sweep parameters.
Get rid of needless referencing of the embedded object.
aa898b2
to
3db8d0b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good PR! Excellent commit structure, and a nice cleanup :)
d98a1d1
to
fb6377d
Compare
Unit test added |
fb6377d
to
b142690
Compare
2187e18
to
61bdf32
Compare
61bdf32
to
600e059
Compare
t.inputTotal = newInputTotal | ||
t.outputValue = newOutputValue | ||
t.inputs = append(t.inputs, input) | ||
t.weightEstimate = newWeightEstimate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like all these counters could be calculated on demand instead (just pointing it out, still up for discussion whether that is better than just keeping running counters).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In a later commit, i would also need the fromWallet
state. I am not too convinced of it. When you add 20 inputs, 200 (virtual) add operations will be executed. (1+2+3+...+20).
@wpaulino what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a new input would make us recalculate everything, but the performance impact is likely negligible unless there are lots of inputs. I'm fine with leaving things as is given that the code is already there.
|
||
// Retrieve wallet utxos. Only consider confirmed utxos to prevent | ||
// problems around RBF rules for unconfirmed inputs. | ||
utxos, err := t.wallet.ListUnspentWitness(1, math.MaxInt32) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to avoid having the wallet as a field on the input set, the list of utxos can be passed into this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, but then we'd always get utxos, even if the dust limit is already reached. could also move that out then. but not sure if it is better
600e059
to
997a67e
Compare
t.inputTotal = newInputTotal | ||
t.outputValue = newOutputValue | ||
t.inputs = append(t.inputs, input) | ||
t.weightEstimate = newWeightEstimate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a new input would make us recalculate everything, but the performance impact is likely negligible unless there are lots of inputs. I'm fine with leaving things as is given that the code is already there.
997a67e
to
e70fd44
Compare
A refactoring that introduces no functional changes. This prepares for the addition of wallet utxos to push the sweep tx above the dust limit. It also enabled access to input-specific sweep parameters during tx generation. This will be used in later commits to control the sweep process.
We need access to additional wallet functionality. This commit creates an interface to prevent passing in multiple function pointers.
Prepares for adding another level of nesting.
This commit allows sweeper to sweep inputs that on its own are not able to form a sweep transaction that meets the dust limit. This functionality is useful for sweeping small outputs. In the future, this will be particularly important to sweep anchors. Anchors will typically be spent with a relatively large fee to pay for the parent tx. It will then be necessary to attach an additional wallet utxo.
e70fd44
to
e01600f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
This PR enables the sweeper to sweep inputs that are positively-yielding, but by itself wouldn't reach the dust limit for the sweep transaction output value at the chosen fee rate.
They way to deal with this is to attach additional wallet input(s) to bring up the output value of the transaction.
This is a preparation for sweeping anchor outputs that are too small to reach the dust limit of the sweep tx output.
There are also a few commits in this PR that aren't strictly necessary for the functionality that this PR adds, but are included anyway to prevent touching the code again in the follow-up.
Next step after this PR is to add forced sweeping of negatively yielding inputs.