fix(s3): mine first SHA in software to fix zero-shares (#28, #10, #5) - #36
Conversation
…#10, #5) The ESP32-S3 SHA peripheral cannot resume hashing from an externally written midstate: writing the SHA_H registers and issuing SHA_CONTINUE is ignored by the engine. The Core 1 hot loop (sha256_pipelined_mine_s3_v3) relied on exactly that "midstate restore + continue", so it computed the wrong first-SHA digest for every nonce. The candidate it flagged then failed the software re-verification gate, so the device submitted ZERO valid shares while reporting a high (but fake) ~270 KH/s hashrate. This matches the on-hardware diagnostics in PR #32 (hw_restore_iv_plus_continue=FAIL) and the field reports in #28/#10/#5. A host-side reference test confirms the SHA algorithm/endianness are correct, so the bug is purely the unsupported HW state injection. Fix: Core 1 now runs the same BitsyMiner software double-SHA256 + cached software midstate that Core 0 uses, scanning the upper half of the nonce range. Hashrate drops to a real ~50 KH/s (vs the fake 270) but shares are now valid and accepted by the pool. The software verify path is the only SHA path on S3, so a wrong hash can never be submitted. The unused sha256_pipelined_s3*/sha256_s3 HW-restore helpers are left in the tree for reference but are no longer on the mining hot path. Needs on-device confirmation on an ESP32-S3 board. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
d906816 to
814237e
Compare
|
Merging — it's sat 3.5 months waiting on a hardware test that can't be more conclusive than what we already have, and current main is strictly worse: ~270 KH/s on the counter, zero shares at the pool. Why I'm confident without another flash test:
One correction to my May analysis, because @muccapazza72's fork and espressif/esp-idf#12440 prove the point: the S3 SHA peripheral does not ignore written Follow-ups on my side: fix the README S3 hashrate table and strip the now-dead |
…se automation - Bump AUTO_VERSION to v2.9.6-pre across all envs - README: honest S3 (~50-55 KH/s, software-verified) and C3 (pending validation) numbers; old 280-400 KH/s figures were invalid shares - CHANGELOG entry for everything in this batch (SneezeGUI#36 SneezeGUI#37 SneezeGUI#38 SneezeGUI#39 SneezeGUI#44 SneezeGUI#45) - build.yml: upload factory-bin test builds on every PR - release.yml: tag-triggered build of all 17 targets + GitHub Release with factory/firmware bins (uses post_build_merge.py output) Co-Authored-By: Claude <noreply@anthropic.com>
1 participant
Problem
ESP32-S3 boards report a high hashrate (~270 KH/s) but submit zero valid shares (
SW verify=FAIL). Reported in #28, #10, #5.Root cause
Core 1's assembly hot loop (
sha256_pipelined_mine_s3_v3) writes a cached midstate into theSHA_Hregisters and issuesSHA_CONTINUE, expecting the engine to resume from it. The ESP32-S3 SHA peripheral ignores externally-writtenSHA_HonCONTINUE, so every first-SHA is computed from the wrong state, the 16-bit early-reject trips on garbage, and the software re-verify (correctly) rejects it. Confirmed by PR #32's on-hardware self-test (hw_restore_iv_plus_continue=FAIL) and a host-side reference test (algorithm/endianness are correct — the bug is purely the unsupported HW state injection).Fix
Core 1 now mines the first SHA in software using the same proven BitsyMiner midstate path Core 0 uses, over the upper half of the nonce range. The software-verify gate stays, so a wrong hash can never be submitted. Net −74 lines.
Trade-off
Real ~50 KH/s (both cores software) instead of the fake ~270 KH/s that produced no valid shares. Matches @trcjr's #32 result and @muccapazza72's working fork.
Closes #28. Related to #10, #5.