perf: port Bitcoin Core's incumbent-free branch-and-bound prunes

[evanlinjin]

Important

Stacked on #64. This branch is two commits on top of that PR's head (7e965cf), and this repo doesn't carry #64's branch, so the diff below currently includes all of #64. Review after #64 merges, at which point this reduces to the two commits listed here. Draft until then.

Bitcoin Core's SelectCoinsBnB prunes a branch on four conditions, and three of them need no incumbent. Ours has exactly one prune, bound < best, which does nothing until a solution exists. For LowestFeeChangeless that is the whole problem: score returns None whenever change would be worthwhile, so the greedy descent lands on funded-but-changeful selections that score nothing, best stays None, and every node with a Some bound passes. Nothing is pruned until a changeless selection is found, which is the hard part.

This ports the two of Core's cuts that carry over.

86f64ec — hard-prune on a lookahead over the undecided candidates

Core's curr_value + curr_available_value < selection_target, as a running total the selection cache maintains rather than an O(n) rescan per node. The relaxation credits still-reachable ancestor surplus by relaxing to ancestor_bump_lower_bound instead of assuming monotonic funding, so unlike the existing None prunes it stays on when there are unconfirmed ancestors.

fb5a021 — cut changeless branches that have overshot their window

Core's defining cut, curr_value > selection_target + cost_of_change. The ceiling comes straight off LowestFee::drain_value, which is what already decides whether a selection counts as changeless here.

Two things stop it porting directly, and both are checked rather than assumed:

A candidate that costs more than it brings can be exactly what a changeless selection needs. Core's caller filters non-positive-effective-value coins from the pool and SelectCoinsBnB asserts the result; we cannot. Given c0 = (value 1000, weight 611), c1 = (value 35977, weight 372) and a target of 33719 at 9.716 sat/vb, {c1} alone overshoots and wants change, so it does not score — and it is the negative effective-value c0 that burns 484 sats of excess and lands the pair inside the changeless window, at the brute-force optimum. Core can filter because nothing in its objective wants such a coin; this metric does. So the cut runs only where the cache confirms every undecided candidate raises the excess. Covered by a_candidate_not_worth_selecting_can_still_be_needed.

Adding a candidate does not always raise the excess by its own effective value. Our weight model has count-dependent terms Core's GetSelectionAmount() has no equivalent of — the input-count varint grows, the first segwit input adds the witness header, and every legacy input in a segwit transaction serializes an empty witness — so max_future_input_overhead widens the ceiling by every weight unit the serialization could still gain. Covered by mixed_serialization_overhead_does_not_prune_exact_solution.

Unconfirmed ancestors and a Target::max_weight switch the cut off, both because they give a descendant a way back into the window. That is conservative and marked ponytail: in the source with the upgrade path: the ancestor gate wants an upper bound on the bump a descendant can still take on, mirroring the floor ancestor_bump_lower_bound already tracks.

Measured

coinselect-benchmark bench.py compare-revs, 126 fixture/track pairs against 7e965cf, 100,000-node budget:

	value
solutions lost	0
solutions gained	0
selections changed	0
scores changed	0
peak RSS	flat

Node counts on the kernel (LowestFeeChangeless) track, every fixture that finishes inside budget:

subsidizing_ancestry_20    886 ->   137  (6.5x)
nested_ancestry_20         200 ->    30  (6.7x)
smoke                      121 ->    42  (2.9x)
shared_ancestry_20         369 ->   225  (1.6x)
high_feerate_20             43 ->    32  (1.3x)
private_ancestry_20        207 ->   182  (1.1x)
no_ancestry_100           3211 ->  2827  (1.1x)
no_ancestry_50            4222 ->  3992  (1.1x)
nested_ancestry_50        3582 ->  3456  (1.0x)
...                       24/24 fixtures improved

Cheaper everywhere the search can finish; no help on the 11 fixtures that exhaust the budget, which are the ancestry families the window cut currently switches itself off for. The matrix aggregate therefore reads flat — the capped fixtures dominate the node total.

Attribution across the two commits is clean: 86f64ec does nearly all of it, including on the ancestry families. fb5a021 fires only on no_ancestry_*, exactly as its three gates predict.

Notes

• No public API change. An earlier revision of this branch added a BnbMetric::ignores_candidates_not_worth_selecting opt-in so a metric could take Core's pool filter; it changed no fixture in the matrix and the one metric that most looks like it wants it must answer false, so it was dropped.
• Both commits pass cargo fmt/check/clippy/doc/test and --no-default-features independently (bisect-checked).

🤖 Generated with Claude Code

https://claude.ai/code/session_019qxj8PzFNeqeKw7XkuzvK3