|
| 1 | +# PR #2188 — champion update (PREPARED, NOT PUSHED; loud event is the owner's to time) |
| 2 | + |
| 3 | +PR #2188 (`stratum-mining/stratum`, branch `feat/vardiff-ewma-adaptive`, by |
| 4 | +gimballock) is the **clean production extraction** meant to ship upstream — a flat |
| 5 | +single-struct replacement of `VardiffState`, distinct from #2154 (the research |
| 6 | +branch). It was opened **before** the decline-safety arc, so it ships the |
| 7 | +**superseded contender**, not the champion. This doc prepares the correction; the |
| 8 | +**force-push and the posted reply are the loud, outward-facing event** (a public |
| 9 | +upstream PR with two live named reviewers) — held for the owner's go. |
| 10 | + |
| 11 | +## VERIFIED against source (not memory) |
| 12 | + |
| 13 | +**#2188 currently ships (PR body + branch `5814cee1`):** |
| 14 | +EWMA **120s** / PoissonCI-below-**10** + **AsymmetricCUSUM**-at-10+ / AccelRetarget |
| 15 | +**0.2→0.4**. The body's Motivation #4 and Stage-2 bullet both carry the |
| 16 | +**"3× more evidence to tighten because tightening rejects in-flight shares"** |
| 17 | +framing. |
| 18 | + |
| 19 | +**The champion (shipped constructor `champion_composed`, composed.rs:261):** |
| 20 | +`EwmaEstimator::new(360)` / `AdaptiveSignPersist::sign_persist(SignPersistenceCusumBoundary::new(1.5,0.05,8.0,0.06,0.6), 6)` / `AcceleratingPartialRetarget::new(0.2,0.6,0.05)`. |
| 21 | + |
| 22 | +**Delta — all three stages differ; #2188 = `full_remedy`-adjacent, NOT champion:** |
| 23 | +| stage | #2188 (contender) | champion (corpus) | |
| 24 | +|---|---|---| |
| 25 | +| estimator | EWMA **120s** | EWMA **360s** (the τ-valley floor) | |
| 26 | +| boundary | PoissonCI<10 + **AsymmetricCUSUM** ≥10 | **AdaptiveSignPersist**: PoissonCI<**6** + **SignPersistenceCusum** ≥6 | |
| 27 | +| update | AccelRetarget 0.2→**0.4** | AccelRetarget 0.2→**0.6**, accel **0.05** | |
| 28 | + |
| 29 | +Architecturally the same SHAPE (adaptive boundary with a sparse/dense seam), so this |
| 30 | +is a parameter+boundary-variant correction, not a rewrite. But it is a **substantive |
| 31 | +algorithm change** (the shipping struct currently implements the superseded pick), |
| 32 | +plus a body rewrite, plus closing a public review thread. |
| 33 | + |
| 34 | +## The vnprc thread — TWO stale justifications, both now superseded (verified) |
| 35 | + |
| 36 | +vnprc (contributor) objected (June 11, TriangleBitDevs) to the asymmetric-cost |
| 37 | +"tightening rejects in-flight shares" rationale, citing the **exact** `job_id_to_target` |
| 38 | +source lines (target snapshotted at job creation; share validated against the per-job |
| 39 | +snapshot; `update_channel` mutates only `self.target`, never `job_id_to_target`; map |
| 40 | +wiped on new block) — i.e. **the same finding that became the corpus's §6(ii) |
| 41 | +retraction and the "no lost work" passage**. He also made the second half: rejected |
| 42 | +shares aren't lost value in aggregate (passing shares are worth proportionally more). |
| 43 | + |
| 44 | +gimballock replied (June 12): conceded the in-flight framing is wrong ("we'll fix |
| 45 | +it"), but **re-defended the asymmetry on the fitness sweep** (tighten_multiplier 3.0 |
| 46 | +won the 1000-trial sweep), transparently noting a balanced weighting might prefer |
| 47 | +1.5–2.0. |
| 48 | + |
| 49 | +**State now:** vnprc correctly killed justification #1 (in-flight shares); the arc has |
| 50 | +since killed justification #2 (fitness sweep) — the champion is selected by the |
| 51 | +**decline-safety minimax (a hard constraint)**, NOT by a weighted fitness score. So |
| 52 | +the asymmetry's *real* current justification is dangerous-direction protection (§6.1), |
| 53 | +which is **stronger** and directly answers vnprc's fitness-weighting concern: the |
| 54 | +asymmetry isn't there because stability was over-weighted in a fitness function — it's |
| 55 | +there because the controller must not spiral on a decline, full stop. |
| 56 | + |
| 57 | +## PREPARED — what goes in the update (held for owner go) |
| 58 | + |
| 59 | +### 1. Code (champion extraction into #2188's flat struct) |
| 60 | +Replace the EWMA(120)/AsymCUSUM-at-10/0.2→0.4 implementation with the champion |
| 61 | +composition: EWMA **360** / PoissonCI<**6** + SignPersistenceCusum(1.5,0.05,8.0,0.06,0.6) |
| 62 | +≥6 / AccelRetarget(0.2,**0.6**,0.05). **Cross-check before push (the load-bearing |
| 63 | +one):** the flat struct must produce the SAME composition `champion_composed` |
| 64 | +produces — i.e. it is the champion, not `full_remedy` a second time. Verify by the |
| 65 | +classic↔champion equivalence discipline (the shipped struct == what information-floor |
| 66 | +and the README specify), and regenerate #2188's Results table from the champion. |
| 67 | + |
| 68 | +### 2. PR body rewrite |
| 69 | +- Summary / "The algorithm": Stage 1 = EWMA **360s** (state the τ-valley rationale, |
| 70 | + not 120s); Stage 2 = **AdaptiveSignPersist**, seam at **6**, SignPersistenceCusum |
| 71 | + above (not AsymmetricCUSUM-at-10); Stage 3 = AccelRetarget to **0.6**. |
| 72 | +- Results table: regenerate with champion numbers (current table is the contender's). |
| 73 | +- **Selection rationale**: change from "highest fitness score" to "the gentlest config |
| 74 | + that clears the decline-safety gate" (how the champion was actually chosen). |
| 75 | +- **Motivation #4 + Stage-2 asymmetric-cost bullet**: REMOVE the "tightening rejects |
| 76 | + in-flight shares" framing (conceded wrong, and now corpus-retracted). Replace with |
| 77 | + the decline-safety framing (asymmetry = dangerous-direction protection), and state |
| 78 | + the **no-lost-work point as established** (crediting it's now understood — vnprc's |
| 79 | + catch, formalized in the paper). |
| 80 | + |
| 81 | +### 3. DRAFT vnprc reply (to post WITH the force-push, one coherent beat) |
| 82 | + |
| 83 | +> Following up on this — your correction is now fully incorporated, and it ended up |
| 84 | +> reshaping more than the wording. |
| 85 | +> |
| 86 | +> 1. **The in-flight-shares framing is retracted, not just patched.** You were right |
| 87 | +> on the mechanism (`job_id_to_target` snapshots the target at job creation; vardiff's |
| 88 | +> `update_channel` never touches it; the map only clears on a new block) and right on |
| 89 | +> the aggregate-value point (rejected-low shares aren't lost value — the shares that |
| 90 | +> clear the new target are worth proportionally more). That's now stated as established |
| 91 | +> in the writeup, not defended. |
| 92 | +> |
| 93 | +> 2. **The asymmetry's justification has itself changed since my June reply — and your |
| 94 | +> objection is what exposed that it needed to.** I defended it then on the fitness |
| 95 | +> sweep (multiplier 3.0 won), and flagged that the metric weighted stability heavily. |
| 96 | +> Since then the selection criterion changed: the shipped controller isn't the |
| 97 | +> fitness-pick anymore — it's selected by a **decline-safety constraint** (it must not |
| 98 | +> enter the over-difficulty death-spiral on a sustained decline; the earlier |
| 99 | +> fitness-pick, EWMA(120)/CUSUM, actually fails that gate). So the asymmetry isn't |
| 100 | +> there because stability was over-weighted in a fitness function — it's there because |
| 101 | +> tightening into a falling miner is the dangerous direction, and the controller has to |
| 102 | +> resist it as a hard constraint. That directly addresses your fitness-weighting |
| 103 | +> concern: it's no longer a weighting tradeoff, it's a safety floor. |
| 104 | +> |
| 105 | +> 3. **Consequently this PR's algorithm changed.** I've updated it to the |
| 106 | +> decline-safety-selected controller (EWMA 360 / adaptive sign-persistence boundary, |
| 107 | +> sparse/dense seam at 6 / accelerating partial retarget) — the same one the #2154 |
| 108 | +> writeup now derives. The previous version here was the pre-decline-safety contender. |
| 109 | +> Thanks again for the catch; it's a better PR for it. |
| 110 | +
|
| 111 | +## Sequencing (the discipline) |
| 112 | +Prepare all of the above as reviewable work (un-gated). The **force-push to #2188 + |
| 113 | +the posted reply are the loud event** — public PR, live reviewers — and go together |
| 114 | +on the owner's go, so the code and the explanation move in one beat rather than a |
| 115 | +force-push that silently invalidates the discussion above it. The owner times it. |
0 commit comments