Commit 78fda32
perf: make LowestFee's BnB bound max_weight-aware
The bound was cap-blind: admissible but loose, crediting improvements the
weight budget can't actually afford. Tighten it in the cap-binding regime:
- 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 can't fit the remaining budget, nothing down
this branch reaches the target within the cap -> prune. It's a fractional
relaxation, so it never prunes a branch with an integer solution.
- Changeless "recover value by adding change" branch: only credit the
improvement if a change output fits the cap. Clearing dust needs heavier
inputs and the change output adds weight, so if change doesn't fit now it
never will -> keep `current_score`.
Both stay admissible (`ensure_bound_is_not_too_tight`) and BnB still finds the
optimum (`can_eventually_find_best_solution`). No effect unless `max_weight`
is set.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>1 parent e378e88 commit 78fda32
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