feat(metrics): add ChangelessWaste for privacy-driven coin selection

[evanlinjin]

Summary

Adds ChangelessWaste, a BnB metric that minimises the waste metric subject to the constraint that the selection produces no change output.

The use case is privacy-driven coin selection — CoinJoin / PayJoin / send-to-one-shot addresses where the change output is itself a leak. This matches what Bitcoin Core's BnB-CB algorithm covers. We deliberately don't expose a cross-regime Waste metric (see Why no general Waste metric? below).

This branch is rebased onto the current master, which landed two breaking refactors the metric now conforms to:

• Target is passed to BnbMetric methods per-call instead of stored on the metric.
• Metrics decide their own change output (BnbMetric::drain) rather than taking a ChangePolicy.

Public additions

ChangelessWaste — like LowestFee, it owns its change decision instead of taking a ChangePolicy. Fields: long_term_feerate, dust_relay_feerate, drain_weights. It uses the same rule as LowestFee to decide whether a selection would have change (change is worthwhile when the recovered excess exceeds the future spend cost and clears the dust threshold), and rejects any such selection — only genuinely changeless selections are scored. drain() returns Drain::NONE by definition.

For a changeless selection the waste collapses to input_weight * (feerate - long_term_feerate) + max(0, excess), which (unlike the general with-change waste) is monotone, so the bound reduces to bounding D.input_weight for any target-meeting descendant D ⊇ cs:

• rate_diff >= 0: lower-bound D.input_weight — cs.input_weight() when the target is already met, otherwise the resize trick (below).
• rate_diff < 0: upper-bound D.input_weight via an LP-relaxed fractional knapsack over the positive-effective_value candidates that must be excluded to keep the selection changeless (i.e. to keep excess_with_drain_weight <= max(drain_spend_cost, dust_threshold - 1)).

Branches where every reachable descendant is forced to have change are pruned via change_unavoidable (the same heuristic Changeless uses).

Includes proptests can_eventually_find_best_solution (finds the true optimum) and ensure_bound_is_not_too_tight (the bound is a valid lower bound), plus two hand-written regime sanity checks.

Internal cleanup

LowestFee::bound and ChangelessWaste::bound shared the same "resize trick" — walk the value_pwu-sorted unselected list until the target is crossed, then fractionally resize the crossing input so the target is hit with zero excess. Extracted into a single private helper in src/metrics.rs:

• resize_bound returns a ResizeBound enum (Exact | Resize) so each caller keeps its own exact-match computation — LowestFee returns score, ChangelessWaste returns waste — while sharing the find + deselect + scale mechanism. No behavior change for LowestFee (verified by its existing proptests).

Bound tightening for ChangelessWaste (rate_diff < 0)

The consolidation case (rate_diff < 0) previously used a trivial all_selected.input_weight * rate_diff upper bound, which ignores that selecting every candidate would typically force a change output. The LP-relaxed knapsack UB is dramatically tighter:

n	scenario	trivial UB	LP knapsack
15	rate_diff_neg	3,590	415
20	rate_diff_neg	34,296	2,138
30	rate_diff_neg	2M (cap)	74,055

(round counts, BnB cap 2M). rate_diff >= 0 paths are unchanged.

Why no general Waste metric?

Earlier iterations included a cross-regime Waste metric scoring both changeless and with-change selections. It was dropped because:

• The bound is genuinely hard. With change allowed, waste is non-monotonic and discontinuous: adding inputs raises waste in the changeless regime (excess is burned to fee), then it drops when the excess crosses the threshold where a change output becomes worthwhile. A valid, tight BnB lower bound has to span both regimes and the flip between them. Constraining to changeless removes that discontinuity — which is the whole reason ChangelessWaste has a clean bound.
• It over-consolidates. When long_term_feerate > feerate (a common low-fee scenario) every input has negative waste contribution, so the unconstrained BnB optimum is "select every UTXO" — rarely what a caller wants.
• Core uses waste as a tiebreaker, not as the BnB objective. The legitimate use cases — tiebreaking equally-cheap fee solutions, and finding good changeless candidates — don't need the cross-regime bound; the latter is exactly ChangelessWaste.

Note ChangelessWaste is a standalone metric (not Changeless<Waste>) precisely because its value is the custom tight input_weight-based bound — composing a general Waste metric would mean building that hard cross-regime bound only to constrain it away.

Test plan

• cargo test --release — full suite passes (40 tests incl. lib + doctests), notably the ensure_bound_is_not_too_tight and can_eventually_find_best_solution proptests for both ChangelessWaste and LowestFee.
• cargo clippy --all-targets --all-features — clean.
• cargo fmt --all --check — clean.
• cargo doc --no-deps with -D warnings — clean.

🤖 Generated with Claude Code