This amends the sorting operator for SelectionResults to prefer
The reasoning is that all other things equal, we want to send less funds into unconfirmed state and tell counter-parties less about the value in our wallet.
Builds on #25647. If you're interested in this change, please review that PR first.
SelectionResult::m_target should be equal to actual selection target.
Selection target is the sum of all recipient amounts plus non input fees.
So we need to remove change_fee from the m_target. It's safe because change
target is always greater than the change fee, so we can always cover fees
if change output is created.
When we have preselected inputs the coin selection search target is reduced
by the sum of (effective) values. This causes incorrect m_target value.
Create separate instance of SelectionResult for all the preselected inputs and
set the target equal to the sum of (effective) values. Target for preselected
SelectionResult is equal to the delta for the search target. To get the final
SelectionResult with accurate m_target we merge both SelectionResult instances.
Requires #25647
<!--cf906140f33d8803c4a75a2196329ecb-->
🐙 This pull request conflicts with the target branch and needs rebase.
<sub>Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".</sub>
Doesn't a change bias tell third-parties more about our wallet? There's a slightly higher probability the lowest output is change, right?
Thank you for your comment. While preparing a response, I realized that the order in which results are collected and compared already results in something even better than what I was trying to achieve.
The tiebreaker would only affect situations in which multiple SelectionResults were tied for best waste score and had the same input count. This should only occur when we have two solutions with change that spend the same output types, which probably is most likely on single-input solutions and might occur a bit more often after #24584.
My motivation was that if SRD e.g. proposed a change of ₿15 and Knapsack found a solution with ₿0.2, it would be preferable to not reveal the large amount to the recipient and to assign less rather than more funds to an unconfirmed output. My proposed change could have caused that the unnecessary input heuristic were accurate slightly more often if a tie occurred with multiple inputs when additionally the SRD change amount ended up being smaller than the min_change randomly picked for Knapsack (see #24494).
It turns out that due to the order in which SelectionResults are collected and compared, we always prefer the Knapsack solution on ties, which mitigates my concern regarding an unnecessary large change. I don't think your concern applies for the current behavior though, because we generate min_change that is up to 2× the recipient amount since #24494 with a maximum of 1,000,000 sats (which was the fixed min_change before). So at least it's not worse than the behavior we had for the prior decade.