igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

Counter ASIC 3.0 status: the detector's two calibration findings answered (ba4a995 merged; max r 0.10)

Browse source
This commit is contained in:
igneum-labs 2026-10-06 08:29:28 +00:00
parent ea51a82d58
commit 881ae59779
1 changed files with 1 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/plans/counter-asic-3-status.md
View file

@ -75,7 +75,7 @@ Step cost per family on the M5 Max as a ratio to the add-xor-rotate chain (881 G
| Module | Reading | Consequence |
|---|---|---|
| Detector (window epochs 41 to 46, tip DAA 171,165, 20 ids) | network 125 to 152 MH/s per epoch, settled; bands from the fleet log 5090 99.4 / 115.6 / 123 MH/s (n 849), M5 Max 26.5 / 27.4 / 28.5 (n 586), Intel UHD 1.7 / 1.8 / 2.2 (n 758); correlation pairs 6, max r 0.94, edges 1 (the two 5090 ids, PC 1 back since 07:2x), groups none; alert inactive, held 0 of 6; events none | quiet on the devnet; two findings sent to the detector worker: two honest same-model cards cross the 0.8 edge (the group rule of 3 or more ids is what keeps the alert off; the edge may be a network-estimate artefact), and each 5090 id reads about 50 MH/s on chain against the 115 MH/s band (a factor of two to explain before an unknown miner is banded). Until both are answered the detector's alert is advisory, not a trigger |
| Detector (window epochs 41 to 46, tip DAA 171,165, 20 ids) | network 125 to 152 MH/s per epoch, settled; bands from the fleet log 5090 99.4 / 115.6 / 123 MH/s (n 849), M5 Max 26.5 / 27.4 / 28.5 (n 586), Intel UHD 1.7 / 1.8 / 2.2 (n 758); correlation pairs 6, max r 0.94, edges 1 (the two 5090 ids, PC 1 back since 07:2x), groups none; alert inactive, held 0 of 6; events none | quiet on the devnet; two findings sent to the detector worker: two honest same-model cards cross the 0.8 edge (the group rule of 3 or more ids is what keeps the alert off; the edge may be a network-estimate artefact), and each 5090 id reads about 50 MH/s on chain against the 115 MH/s band (a factor of two to explain before an unknown miner is banded). ANSWERED (ca3-detector 9c7838e, merged): the r 0.94 edge was an artefact of the epoch common factor (the mean over every present id let the paused-and-resumed Mac push the other residuals together); the factor is now the median over the steady core ids, and the same window reads max r 0.10, no edge, tests 7 of 7, the fabricated design still alerts. The factor of two is `identities=2` on PC 2's worker (2 x 50.4 = 100.8 MH/s on chain against the 115.6 band, 0.87x, the ratio the whole network shows: reds, pending blocks, template latency); the key count joins the coinbase tag with the card model (owed, 0.3.12). The devnet's max pairwise r over the windows run is 0.10 to 0.53 against the 0.8 edge; the alert stands as a trigger with the 3-id group rule |
| Vendor share (10-minute window, network 253 MH/s) | fleet-reported: NVIDIA 241.7 MH/s (2 workers, 0.920), AMD 18.8 (1, 0.072), Intel 2.2 (1, 0.008), Apple 0 (the Mac paused); chain-attributed: NVIDIA 0.914 (529 of 579 blue blocks, 10 ids), AMD 0.078 (45 blocks, 8 ids), Intel 0.009, unknown 0 (every id maps to a fleet key, 30 mapped) | the two readings agree within 1 percent; the devnet is a one-vendor fleet at 91 percent NVIDIA, which is what the metric is for: an AMD owner's share of income is 0.078 for 1 of 4 cards, an Apple owner's 0 while paused; the public testnet's number is the one that matters |
The live observer runs the shared checkout, which autosync fast-forwards from origin/master; new code reaches it only through a push to master, which is the project lead's call (CLAUDE.md: push only when the project lead asks). So the one restart main asked for waits on that push; the dry rows above are the evidence until then.