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
wallet: add coin selection parameter add_excess_to_recipient_position
for changeless txs with excess that would be added to fees
#30080
base: master
Are you sure you want to change the base?
Conversation
Add a coin control rpc parameter to optionally force a particular change target for coin selection algorithms that result in a change output.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process. |
add_excess_to_recipient_position
for changeless txs with excess that would be added to fees add_excess_to_recipient_position
for changeless txs with excess that would be added to fees
🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the Possibly this is due to a silent merge conflict (the changes in this pull request being Leave a comment here, if you need help tracking down a confusing failure. |
From CI:
|
Here are my initial thoughts on each of the options individually
It seems like what you really want is to search for a changeless solution in a given target range. And then if failed to fallback to a solution with change. |
Thanks for the feedback! I agree that it is worth considering how to make these parameters more useful for general users.
Always having a change output would be a problem because we always prefer a changeless tx if the excess is not too large. But when that is not possible the change should be large enough to potentially spend later as a changeless tx. A possible alternative would be to add a setting for CHANGE_LOWER rather than always use the hard coded value of 50,000 sats. It is probably not necessary for my use case to set the
I agree that generally it's too in the weeds for most users. I'll move it to settings.
Good point. The maximum excess currently built into BnB is
Exactly! I believe that is how CS works now. If no set of inputs are found with excess in the range from zero to From the perspective of not over complicating the coin selection options, do you think it would be better to have two new options: |
25bc04f
to
6342865
Compare
A new rpc option to specify a list of enabled coin selection algorithms. If not set, then by default all algorithms are enabled.
6342865
to
8734434
Compare
If this coin selection RPC option is set, then the excess value for a changeless BnB tx will be added to the selected recipient output position instead of added to fees.
8734434
to
6f594a7
Compare
I changed |
🚧 At least one of the CI tasks failed. Make sure to run all tests locally, according to the Possibly this is due to a silent merge conflict (the changes in this pull request being Leave a comment here, if you need help tracking down a confusing failure. |
If set, excess from changeless spends can not exceed this amount, otherwise use cost_of_change by default
fc9c153
to
1307d1f
Compare
This PR replaces draft PR 29442 as a simpler alternative that only adds new coin selection parameters, primarily
add_excess_to_recipient_position
.I am opening this PR as a draft to get feedback and suggestions on the concept and my implementation.
I have also included two additional coin selection parameters to this PR for specifying the target change amount and for disabling different coin selection algorithms. I can break them out into individual PRs if the primary excess amount coin selection option would be easier to review on its own. These additional parameters can also help lower fees for the LSP liquidity provider use case.
motivation
A changeless transaction may select inputs with excess value over what is needed to reach the desired fee rate and output targets. Currently that excess value is considered waste and burned as fees. In some situations you may prefer to add any excess value to an output you control. When fees are high the cost of adding a change output increases and so does the amount of potential excess value spent as fees. One example of a situation where excess value should be added to the output amount is when splicing in value to a Lightning channel because the excess value is retained off-chain.