Merge bitcoin/bitcoin#25495: Revert "bnb: exit selection when best_waste is 0"

af56d63eca8a246c02506c2aef7ea8a22e2d07bb Revert "bnb: exit selection when best_waste is 0" (Murch)

Pull request description:

  This reverts commit 9b5950db8683f9b4be03f79ee0aae8a780b01a4b.

  Waste can be negative. At feerates lower than long_term_feerate this
  means that a waste of 0 may be a suboptimal solution and this causes the
  search to exit prematurely.
  Only when the feerate is equal to the long_term_feerate would achieving
  a waste of 0 indicate that we have achieved an optimal solution,
  because it would mean that the excess is 0. It seems unlikely
  that this would ever occur outside of test cases, and even then we
  should prefer solutions with more inputs over solutions with fewer
  according to previous decisions—but solutions with more inputs are found
  later in the branch exploration.

  The "optimization" described in #18257 and implemented in #18262 is
  therefore a premature exit on a suboptimal solution and should be reverted.

ACKs for top commit:
  sipa:
    utACK af56d63eca8a246c02506c2aef7ea8a22e2d07bb
  S3RK:
    utACK af56d63eca8a246c02506c2aef7ea8a22e2d07bb
  achow101:
    ACK af56d63eca8a246c02506c2aef7ea8a22e2d07bb
  glozow:
    utACK af56d63eca8a246c02506c2aef7ea8a22e2d07bb, agree it is incorrect to stop here unless we could rule out the possibility of a better solution with negative waste. `SelectCoinsBnB` doesn't know what long term feerate and effective feerate are (and probably shouldn't) so it's better to have no exit early condition at all.

Tree-SHA512: 470f1a49041a0042cb69d239fccac7512ace79871d43508b6e7f7a2f3aca3523930b16e00c5513b816d5fe078d9ab53e42b0a80fd3c3d48e6434f24c2b009077

0 files changed, 0 insertions, 0 deletions