Commit 781e3c3
perf: make LowestFee's BnB bound max_weight-aware
The bound was deliberately cap-blind (admissible but loose): it credited
improvements the weight budget can't actually afford. Tighten it in the
cap-binding regime by refusing those improvements:
- Not-funded ("slurp") branch: reaching the feerate needs a perfect input
weighing `scale * to_resize.weight`. `to_resize` is the best value-per-weight
input available, so if even that (fractionally) can't fit the remaining
weight budget, no within-cap selection down this branch reaches the target
-> prune. This is the fractional relaxation, so it never prunes a branch
that has an integer within-cap solution.
- Changeless "recover value by adding change" branch: only credit the
improvement if a change output fits the cap. Clearing the dust threshold
needs more (heavier) inputs and the change output adds weight, so if change
doesn't fit now it never will down this branch -> keep `current_score`.
Both terms stay admissible (validated by `ensure_bound_is_not_too_tight`) and
BnB still finds the optimum (`can_eventually_find_best_solution`). Only takes
effect when `max_weight` is set.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>1 parent ef8f37a commit 781e3c3
1 file changed
Lines changed: 24 additions & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
161 | 161 | | |
162 | 162 | | |
163 | 163 | | |
164 | | - | |
| 164 | + | |
| 165 | + | |
| 166 | + | |
| 167 | + | |
| 168 | + | |
| 169 | + | |
| 170 | + | |
| 171 | + | |
| 172 | + | |
| 173 | + | |
| 174 | + | |
165 | 175 | | |
166 | 176 | | |
167 | 177 | | |
| |||
243 | 253 | | |
244 | 254 | | |
245 | 255 | | |
| 256 | + | |
| 257 | + | |
| 258 | + | |
| 259 | + | |
| 260 | + | |
| 261 | + | |
| 262 | + | |
| 263 | + | |
| 264 | + | |
| 265 | + | |
| 266 | + | |
| 267 | + | |
| 268 | + | |
246 | 269 | | |
247 | 270 | | |
248 | 271 | | |
| |||
0 commit comments