Litepaper and evidence: the hash's reads stated as measured (8 October 2026, lane D's family harness at 2^20 over 4,900 drawn eras and adv-cache-2's reading): "dependent reads spread over a multi-gigabyte dataset" in the lead, the measured clause after the chain-of-random-reads sentence (the 0.995 floor on every accepted program; about half of epochs with one biased address bit at the era's stride rotation; about 1.6 percent of a hash's reads to a chip storing half the dataset, nothing to a full store; the fold in the next class), evidence row 18 with its sources; ledger AP-F8-7 (Open, priced), the public ledger and the ledger page regenerated. Bench table: class v4 watts rows 7 to 10 (RTX 3070 196.4 W under a 193 W cap, +28 percent; RTX 3070 Ti 267.6 W uncapped, +48 percent; RTX 4060 no watts on any rented host; the 3080 Ti's deep-capped pair in its note, the first cap that costs rate, the uncapped rate standing)
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs
parent
0defaba741
commit
6d0a52ea03
8 changed files with 47 additions and 34 deletions
|
|
@ -42,7 +42,7 @@ Versions in the table: `igneum-pow` is the Rust crate at `igneum-pow/Cargo.toml`
|
|||
| 15 | Every block is proven, with the proof landing within about a minute at launch | Homepage stats ("~60 s to a proof"); litepaper Proving; roadmap phase 3 gate | implemented | repo `d7e1f89` (GPU proof), `e01a3cc`, `292e800`, `eedd136` (`proving/igneum-prove`: shard cutter, MPT witnesses, shard and aggregator guests); SP1 6.8.1; spec 7.2, 7.6 | `proving/windows-wsl2` (SETUP-PROVER, PROVE-BLOCK) on the RTX 5090; `igneum-prove-host --mode block` on `proving/fixtures/`; bench-log "proving v0 on the RTX 5090" and "proving: devnet v4 shards" | First GPU proof of an Igneum block, 4 October 2026, RTX 5090 (WSL2, SP1 cuda, mining paused): fixture `block-78-increment` (2 transactions), core proof 1.4 s (7.3 MB, verify 0.221 s), compressed proof 2.7 s (1.27 MB, verify 0.038 s), post-state and receipts roots identical to the node's; 15.7x and 20.6x faster than a loaded M5 Max CPU. The same day on that CPU (load 38 to 47): a three-shard block proved shard by shard and aggregated by recursion, 19 min (1,139 s) end to end, 245 to 337 s per compressed shard proof, every proof verified. What is not there: no proof is produced, carried or checked on the chain (the devnet prover is a stub that signs claims), the proving pool pays nobody (row 21), the block proven is far below one shard, and the 60-second figure remains a design target; the pass mark is the standard in `docs/benchmarks/proving-e2e.md`. Second RTX 5090 run, 4 October 2026 evening (job run-20261004-173115): a full shard at the provisional S_p (6.75 M pgas, 60.8 M cycles) executed in 1.63 s, core proof 8.3 s (18.1 MB), compressed proof 10.9 s (1.27 MB, verify 0.040 s); a two-shard block (13.5 M pgas) proved shard by shard (11.7 s and 10.0 s) and aggregated in 2.2 s, 24 s of GPU stages end to end, every proof verified, six tampered witnesses rejected. The two host defects (an abort after the upload, an idle wait that turned out to be an unbuffered 18 MB proof save through the WSL2 file bridge, 24 minutes) are fixed (ledger P20) 5 October 2026, live devnet with real transactions (bench-log "real transactions, the first non-empty shard proven and paid"): block 72704 shard 0, 29 transfers, 5,800 pgas, proven on PC 2 in 34 s, verified on the Mac in 0.297 s and paid 1.7623 IGN, 53 s after the chain block executed; of about 1,400 blocks in the 20-minute window 36 were proven (the one prover takes the newest shard assigned to it), so "every block" is not yet true; a second content shard (72803, all copies skipped) failed the native-execution veto on the exporter's block structure, fixed with fixtures the same day, the node side pending the 0.3.9 rollout 5 October 2026, evening (bench-log "proving v1"): the aggregated segment record, the chain rule and the unproven rule are implemented behind `proving_v1_activation_daa` (branch proving-v1, not on the devnet before 0.3.11); on the RTX 5090 a chain of 8 consecutive live blocks proved and aggregated by recursion in 135.6 s with the miner on the card (17 s a block, one proof of 1,272,909 bytes attesting all 8, verified in 0.04 s); the 3-node fast-time harness paid a segment record 1.0 s after submission and refused a late one after its deadline (21 checks); the devnet itself, with one prover, carried proofs for 2.4% of blocks over 30 minutes at a block-to-record latency p50 44 s, p99 52 s. The "within about a minute" holds per proven block; "every block" needs 18 mining 5090s or 6 proving-only cards at empty blocks on the measured rates, and the mandatory rule stays off until the share is one | none yet |
|
||||
| 16 | A 12 GB card proves one shard in about 20 s (WITHDRAWN 5 October 2026: a 24 GB card proves a full shard at the adopted size in 4.3 s; 32 GB mines and proves) | Litepaper Proving ("The proving budget"); roadmap gate 2 | designed | spec 5.1 (Target), 7.6 (`S_p` provisional, 7,500,000 pgas = `B_p` / 4) | `PROVE-SHARD.bat` on the RTX 5090 (pending); the end-to-end standard in `docs/benchmarks/proving-e2e.md`; bench-log "proving: devnet v4 shards" | Measured on a 32 GB card, not yet on a 12 GB card. A shard at the provisional `S_p` is 60.8 M SP1 cycles on the prototype pgas table (9 cycles per pgas, 44 per EVM gas; the modexp entry about 100x its SP1 cost); on an RTX 5090 (4 October 2026 evening, job run-20261004-173115) it executed in 1.63 s and its compressed proof took 10.9 s, verified in 0.040 s, so the 32 GB card is inside the 20 s target with margin. Whether a 12 GB card proves it at all, and in what time, is the next measurement (an RTX 3060 and an RTX 5060 Ti 16 GB are on order). A per-shard time can be met by shrinking the shard, so the project does not use it as a pass mark 5 October 2026, evening (bench-log "proving v1", the S_p curve): measured on the RTX 5090 with SP1 6.8.1's GPU prover, the card to itself, 1-s nvidia-smi samples: an empty shard 13,874 MiB and 2.2 s; a full shard at the ADOPTED v1 budget (30,000 pgas, 4.7 M cycles) 20,434 MiB and 4.3 s; the full prototype shard (6.75 M pgas, 60 M cycles) 28,307 MiB and 10.8 s; beside the miner 15,670 and 30,039 MiB. No environment knob of SP1 moves the 13.9 GB floor and the GPU server has no options of its own, so on this build a 12 GB card proves nothing, a 16 GB card only empty shards, a 24 GB card the adopted full shard alone and beside the miner (22,210 MiB and 13.2 s, measured on the 32 GB card: the 5090's allocation pattern, not yet a run on a 24 GB card) and a 32 GB card the prototype shard beside the miner with 2.5 GB spare. The litepaper line now says so; the 12 GB gate returns when a prover build with a smaller floor is measured on a 12 GB card | none yet |
|
||||
| 17 | The chip resistance claim: at launch the strongest chip in the public model reaches 2.1x (a core as good as a GPU lane, k = 1) to 3.4x (a core three times better, k about 0.33) per joule against an RTX 5090 under class v4, live from genesis on the testnet and the mainnet; the ladder's second rung brings it to about 2.8x; class v5 makes the dataset the chain's state so a stateless or stale chip is wrong on every item; the hot-set cache is bounded at 1.067x at the ceiling and the weak-day FPGA at 12 percent on 15 days a century, both routed to the next class; datacentre silicon does not change the question; a stored-dataset chip pays for itself only at about USD 100 M of market cap in two years; without class v4 the same chip would reach 5x to 9x (the class v3 baseline, the devnet's starting state, never the launch state) | the home page's chip line, the litepaper's chip section (/litepaper#chip-model), the miner page's line | tested by the team (every card, the verifier, the two attack-pass bounds, the H100), the chip itself modelled, class v5 and the ladder designed, the X9 figure claimed against a CPU core and never measured | `docs/analysis/chip-model-v3.md` 5 and 6; `docs/analysis/latency-shadow-2026-10-06.md`; `docs/plans/counter-asic-3-status.md`; `docs/analysis/attack-pass/f8-uniform.md`, `f4-weakday.md`, `docs/analysis/ca3-v4-uniform.md`; `docs/design/class-v5-stored-state.md`; the H100 and market-cap rows of 7 October; `docs/plans/cryptanalysis/in-house-pass.md` (the internal adversarial pass) | the chip model's arithmetic in its file; the card rows by the benchmark package; the attack-pass harnesses `tools/attack/f8-uniform` and the F4 census; the verifier by `igneum-pow bench` | 136 MH/s at 350 W (5090, bench) and 290 W (app); the class v4 efficiency passes (bench log "7 to 8 October 2026, the class v4 efficiency passes: the core clock lock on the RTX 5090 and the RTX 5080", measured): the 5090 at 136.84 MH/s and 475.5 W unlocked, 134.98 at 316.3 W at a 1,400 MHz core lock, the best points class v4 at 1,200 MHz (133.80 MH/s, 305.1 W, 0.439 MH/W) and class v3 at 1,300 MHz (134.62, 223.3 W, 0.603), the premium 145 W unlocked and 82 W at the best points, the knee 1,300 MHz; the RTX 5080 (8 October 2026, the dock card of the three-card Windows rig) at 71.41 MH/s and 253.1 W unlocked under class v4 against 71.28 at 169.7 W under class v3, the best points class v4 at 1,100 MHz (71.20 MH/s, 146.6 W, 0.486 MH/W) and class v3 at 1,000 MHz (71.11, 103.7 W, 0.686), the premium 83.4 W unlocked and 41 W at the best points, the knee between 1,000 and 900 MHz; per tier: a 5080 owner on class v4 locked near 1,100 MHz pays 147 W instead of 253 for 0.3 percent less rate, MH per watt up 72 percent, the lever Ember Tune's core-clock knob in 0.3.24; 27 MH/s at 21 W (M5 Max); 249 MH/s (H100 SXM) at 98 percent of its read ceiling, 1.78x hash, 1.15x MH/W, a third per rented dollar; 2.33 ms per warp; 2.1x, 3.4x, 2.8x at launch; the shadow's premium on a 5090 81.8 W at its knee (class v4 at the 1,200 MHz lock 133.80 MH/s at 305.1 W; class v3 at 1,300 MHz 134.62 at 223.3 W; 7 October 2026); 1.067x at the ceiling; 12 percent on 15 days a century; 10.85 ms at rung 3; USD 100 M; 5.1x to 9.2x the class v3 baseline; 6 and 7 October 2026, the M5 Max, PC 2's RTX 5090, PC 1's RX 9070 XT and RTX 4070, a rented H100 SXM, igneum-build-1 The k about 0.33 bound is the implied core of Bitmain's Antminer X9 (RandomX; 1,000 KH/s, 2,472 W, 2.47 J per KH, USD 5,600; pre-orders 26 December 2025), withdrawn in mid-May 2026 with buyers refunded before any unit shipped, no independent benchmark, commodity Sophgo SG2044 server SoCs with an AES accelerator, no tapeout: a claimed, unmeasured figure carried as the pessimistic bound, not a calibration point (attack pass AP-F5-1, 7 October 2026). | none yet; the next test is the internal adversarial pass (three lanes new to the hash code, outsider inputs only, reports published whole), whose floor reading is in (measured, 8 October 2026; ledger AP-F8-1 and AP-F8-6): nine of nine hot sets refused; the diffuse era-stride excess, bounded under 0.1 percent of a hash's reads per site, is not caught by the floor and is the next class's test, and no outside review has run yet |
|
||||
| 18 | The chip resistance measurements: the program is latency-bound (random reads), not bandwidth-bound, on every card we own, and sits beyond a card's on-chip cache | Litepaper Mining ("waits on memory latency, not on maths or bandwidth"), vs RandomX; the numbers page | tested by the team | readwidth e752fc7 (`docs/plans/read-width.md`), ca2-era 78c0ee4, ca2-cache 2de19e5 (`docs/plans/hot-table.md`) | The dependent-read probes at 32 to 1,024 MiB and the hash rate per class on the three cards; the latency-bound share = rate over the probe ceiling per load | Latency-bound share at the 1 GiB dataset: RTX 5090 0.96 (v2) and 1.01 (v3), RX 9070 XT 0.87 and 0.95, M5 Max 1.01 and 1.06; wider reads do not close the AMD gap (the 9070 XT does 2.4 G dependent reads per second at every width; the 5090 goes bandwidth-bound at 64 B, share 0.58); a 32 to 96 MiB hot table is not kept resident by any card while the dataset streams (g 0.80 to 0.87 in the added form). 5 October 2026 | none yet |
|
||||
| 18 | The chip resistance measurements: the program is latency-bound (dependent reads spread over the whole dataset), not bandwidth-bound, on every card we own, and sits beyond a card's on-chip cache; measured 8 October 2026: the distinct-index floor holds at 0.995 on every accepted program, about half of epochs carry one load site with a biased address bit at the era's stride rotation, priced at about 1.6 percent of a hash's reads to a chip storing half the dataset and nothing to one storing all of it (`docs/analysis/class-v6/family-gate.md`, lane D; adv-cache-2's `report-chained-cache-2.md` section 2.3 on its branch; ledger AP-F8-7) | Litepaper Mining ("waits on memory latency, not on maths or bandwidth"), vs RandomX; the numbers page | tested by the team | readwidth e752fc7 (`docs/plans/read-width.md`), ca2-era 78c0ee4, ca2-cache 2de19e5 (`docs/plans/hot-table.md`) | The dependent-read probes at 32 to 1,024 MiB and the hash rate per class on the three cards; the latency-bound share = rate over the probe ceiling per load | Latency-bound share at the 1 GiB dataset: RTX 5090 0.96 (v2) and 1.01 (v3), RX 9070 XT 0.87 and 0.95, M5 Max 1.01 and 1.06; wider reads do not close the AMD gap (the 9070 XT does 2.4 G dependent reads per second at every width; the 5090 goes bandwidth-bound at 64 B, share 0.58); a 32 to 96 MiB hot table is not kept resident by any card while the dataset streams (g 0.80 to 0.87 in the added form). 5 October 2026 | none yet |
|
||||
| 19 | The lottery hash is sound as a hash: uniform output, deterministic, no out-of-bounds read, fuzzed; class v3 bit-exact on the three vendors | Litepaper vs RandomX ("Every number above is measured and logged"), the numbers page | tested by the team | ca2-mixer 1ab8b21 (`tests/mixer.rs`, `tests/scratch.rs`), ca2-era 78c0ee4, ca2-soundness a465881 (`docs/analysis/scratch-soundness.md`), `igneum-pow/tests/packs.rs` | The crate suite (53 + 4 + 19 + 7), the Metal fuzz, edge, stats and determinism runs on the v3 construction, the pack vectors and 2^24 fingerprints on Metal, Apple OpenCL, the RTX 5090 and the RX 9070 XT, the 1,024-hash CPU re-check per card | Class v3 (mixer x8 + era): 200-program fuzz 200 of 200 on Metal, every tenth on Apple OpenCL; the pinned v3 packs 3/3 + 3/3 and 96 of 96 lanes on Metal and Apple OpenCL; the six era packs' fingerprints equal on the three vendors (PC 1 job run-ca2-era-pc1-20261005, 5 October 2026); the v2 exports byte-identical on the v3 crate; the final-class PC rows and the G2 re-check: job run-ca2-era-pc1b-20261005 (pending at the time of writing) | none yet |
|
||||
| 20 | No premine, no pre-sale, no allocation: every coin is minted by the schedule and every coin goes to the block producer (80%) and the proving pool (20%) | Homepage stats and Economics tiles; litepaper Supply, Economics | implemented | repo `6ac80a3`; fork "igneum-node devnet v0"; `consensus/core/src/igneum.rs`, `coinbase.rs` | `cargo test -p kaspa-consensus-core igneum` (8 pass: subsidy table, ramp, split, cap) and `cargo test -p kaspa-consensus coinbase` (8 pass); `igneum-miner inspect 40`; bench-log "igneum-node devnet v0" | Coinbases on the devnet: 80/20 exact on 39 of 39 single-payee blocks, the 20% to the `igneum-proving-pool-v0` output; the per-second schedule sums to under the 4,000,000,000 cap by less than 100 coins; 3,168,808,781 units per DAA second in years 0 to 2, halving at 63,115,200 DAA s. 3 October 2026, Apple M5 Max. The devnet genesis carries no allocation; the mainnet genesis does not exist yet, so the claim is about the code and the stated rule, not a launch that has happened | none yet |
|
||||
| 21 | The proving pool's 20% reaches shard provers and aggregators | Litepaper Economics; homepage "20% provers" | tested by the team | spec 5.3; `proving/igneum-prove` carries the prover's payout address in every shard proof (ledger P12) | None. The pool output exists (row 20); the payout from it against proof records is unwritten. Since 5 October 2026: the payout rule is live on the devnet (`proving.rs shard_payouts`, the carrying segment pays the first valid record per shard its part of the segment's pool credit) | The escrow accumulated on the simnet (92.55 IGN at the end of the v3 run) and nothing can draw it. Rule decided: per block, divided among shards by consensus proving cost, sortition to 8 provers for 10 s then open (spec 7.2). The economy model of 4 October 2026 (`sim/economy`, 1,000 operators, 30 days) kept every block proven within 60 s under six stress scenarios; a model, not hardware Live devnet, 5 October 2026: 388 shards paid by 16:02 UTC, 446.13 IGN from the pool to PC 2's payout address, 0.8813 IGN per mergeset block of the proven segment (bench-log entries of 5 October: "the first shards proven, verified and paid" and "real transactions, the first non-empty shard proven and paid") | none yet |
|
||||
|
|
|
|||
|
|
@ -2528,6 +2528,15 @@ Evidence: `docs/analysis/cryptanalysis/report-acceptance-rule-3.md` sections 6.2
|
|||
|
||||
The three genesis fields of `docs/analysis/mission/mission.md` section 2.8, built on the node fork branch `genesis-forward` (from release-0.3.19-node dc141409) and the repo branch `genesis-forward`; the design and the gates in `docs/design/genesis-forward.md`. Every switch is never on the devnet (its digest c562d70e... does not move); the testnet genesis sets all three (the testnet lane re-pins and re-digests).
|
||||
|
||||
### AP-F8-7. The hash's reads are not uniformly random: about half of epochs carry one load site with a biased address bit
|
||||
"The served text says every hash is a chain of random reads over the dataset. Measured at the acceptance rule's own 2^20 sample over 4,900 drawn eras (lane D's family harness, 8 October 2026) and in adv-cache-2's drawn-program reading the night before: the reads are spread over the whole dataset and the distinct-index floor holds at 0.995 on every accepted program, but 52 to 58 percent of accepted programs in every stratum carry one load site whose address bit R (the era's stride rotation), R+1 or R+2 is biased over 6 sigma, a third over 100 sigma, the worst z 1,024: a product's bit 0 at P = 1/4 landing on an address bit."
|
||||
|
||||
Status: Open, priced: 1.6 percent at f = 1/2, nothing at f = 1; the served sentence corrected 8 October 2026 (the site audit lane, by main's word): the litepaper's lead reads "dependent reads spread over a multi-gigabyte dataset", the "chain of random reads" sentence carries the measured clause after it, evidence row 18 states the measurement with its sources. The disposition is class v6 layer 1's rule: fold the product's low bits before the rotation so no era lands a biased bit on an address bit, with the bias test as its guard (`docs/analysis/class-v6/family-gate.md`).
|
||||
|
||||
Answer: Correct as a measurement and bounded as a gain. The favoured half of one site's window serves 75 instead of 50 percent of that site's reads, 25 percent of 1/16 of a hash's reads, about 1.6 percent, to a chip storing half the dataset; a chip storing all of it gains nothing (the f = 1 verdict unchanged, and the partial store already costs 1.26x the ops). The sentence that said "random" now says what was measured.
|
||||
|
||||
Evidence: `docs/analysis/class-v6/family-gate.md` (lane D, the index-bit bias read, 8 October 2026); adv-cache-2's `docs/analysis/cryptanalysis/report-chained-cache-2.md` section 2.3 (branch adv-cache-2); `site/litepaper.html` Mining; `docs/evidence.md` row 18.
|
||||
|
||||
### GF1. A post-quantum signature scheme would need a hard fork, and every vote key is a public BLS12-381 point
|
||||
"When a quantum computer comes, every BLS vote key is forged and the chain has no way to change the scheme without a fork of the kind you say you never need."
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
Generated by `tools/ledger/export-public.mjs` from `docs/fud-ledger.md`; a gate check fails when the two drift. One row per item: the claim or criticism, its status, what was done, and the evidence. Internal identifiers, times of day and team-member names are left out on purpose; the full ledger is published with the repository.
|
||||
|
||||
193 items. By status: Conceded, stated 52; Fixed 31; Decided 22; Fixed on a branch, pending merge 14; Answered by design 9; Answered with evidence 6; Fixed, stated 4; Closed by rule 3; Open 3; Spec fixed 2; Answered by design, with a correction to our own text 1; Answered with evidence, stated 1; Answered by design for finality, Conceded for the lottery 1; Conceded, implemented, stated 1; Rule implemented and measured; launch month simulated 1; Answered by design, with the concession stated 1; Conceded, stated in the litepaper and the design doc 1; Answered with evidence at 1 block/s 1; Conceded, stated in the simulation report 1; Answered by design, with the dependency conceded. Update 7… 1; Conceded, stated in the litepaper, with the dial explained 1; Closed by spec 1; Conceded by decision, stated in the design doc 1; Answered by design, with the founder's edge conceded 1; Answered by design, with a metrics caveat 1; Closed by removal, 3 October 2026 1; Conceded, stated in the litepaper 1; Conceded, stated in the design doc 1; Measured on the live node line, and the overlay does NOT… 1; Conceded, stated in the simulation 1; Conceded in part, labelled, stated 1; Fixed in the node 1; Answered with evidence for the largest body the rules allow 1; Fixed in the proving code 1; Fixed in the spec 1; Rule fixed 1; Rule written 1; Fixed, logged 1; Answered with evidence for the test half 1; Fixed in the node and shipped, rule not yet activated on… 1; Simulation half run 1; Answered with evidence for all four 1; Written 1; Designed 1; Fixed and confirmed 1; Rolled out 1; Conceded by decision 1; Conceded, scheduled, stated 1; Conceded, contained by rule, stated 1; Fixed on a branch and verified locally 1; Answered with evidence and stated 1; Answered with evidence for PC 2 1; Answered by design and with evidence 1; Fixed, stated; restated 1; Fixed, stated; restated further 1; Fixed in part, finding bounded, stated 1; Fixed as a genesis lever, measurement owed 1.
|
||||
194 items. By status: Conceded, stated 52; Fixed 31; Decided 22; Fixed on a branch, pending merge 14; Answered by design 9; Answered with evidence 6; Fixed, stated 4; Closed by rule 3; Open 3; Spec fixed 2; Answered by design, with a correction to our own text 1; Answered with evidence, stated 1; Answered by design for finality, Conceded for the lottery 1; Conceded, implemented, stated 1; Rule implemented and measured; launch month simulated 1; Answered by design, with the concession stated 1; Conceded, stated in the litepaper and the design doc 1; Answered with evidence at 1 block/s 1; Conceded, stated in the simulation report 1; Answered by design, with the dependency conceded. Update 7… 1; Conceded, stated in the litepaper, with the dial explained 1; Closed by spec 1; Conceded by decision, stated in the design doc 1; Answered by design, with the founder's edge conceded 1; Answered by design, with a metrics caveat 1; Closed by removal, 3 October 2026 1; Conceded, stated in the litepaper 1; Conceded, stated in the design doc 1; Measured on the live node line, and the overlay does NOT… 1; Conceded, stated in the simulation 1; Conceded in part, labelled, stated 1; Fixed in the node 1; Answered with evidence for the largest body the rules allow 1; Fixed in the proving code 1; Fixed in the spec 1; Rule fixed 1; Rule written 1; Fixed, logged 1; Answered with evidence for the test half 1; Fixed in the node and shipped, rule not yet activated on… 1; Simulation half run 1; Answered with evidence for all four 1; Written 1; Designed 1; Fixed and confirmed 1; Rolled out 1; Conceded by decision 1; Conceded, scheduled, stated 1; Conceded, contained by rule, stated 1; Fixed on a branch and verified locally 1; Answered with evidence and stated 1; Answered with evidence for PC 2 1; Answered by design and with evidence 1; Fixed, stated; restated 1; Fixed, stated; restated further 1; Fixed in part, finding bounded, stated 1; Open, priced 1; Fixed as a genesis lever, measurement owed 1.
|
||||
|
||||
| Id | Claim or criticism | Status | What was done | Evidence |
|
||||
|---|---|---|---|---|
|
||||
|
|
@ -195,6 +195,7 @@ Generated by `tools/ledger/export-public.mjs` from `docs/fud-ledger.md`; a gate
|
|||
| AP-F8-1 | A load whose source was last written by `or`, `mul` or `mulhi` makes a cross-hash hot set | Fixed in part, finding bounded, stated | Class v4 sub-version 3 (igneum-pow a commit, the audit-freeze tag) is frozen with the dataflow rule, the shared-operand rule, the 0.98 ratio and the total draw; the in-house pass's F8 re-gate reads 60 of 64 seeds under… | [docs/analysis/ca3-v4-uniform.md](../docs/analysis/ca3-v4-uniform.md) |
|
||||
| AP-F8-4 | The program id's derivation text omitted generator 4's sub-version suffix (interoperability, documentation; no object change) | Fixed | The id and its printed derivation come from one byte recipe (`generator::IdRecipe`, `program_id_recipe`, `program_id_class_recipe`, `Program::program_id_derivation`), so the two cannot drift; the emitter prints that… | [igneum-pow/tests/derivation.rs](../igneum-pow/tests/derivation.rs) |
|
||||
| AP-F8-5 | The public specification did not describe the shipped acceptance rule (documentary; no object change) | Spec fixed | Sections 1.4.3 and 1.4.6 of `docs/spec/01-lottery-hash.md` rewritten to the shipped rule at igneum-pow a commit with every constant named and every order of operations stated (1.4.3: the two per-register states of the… | [docs/analysis/cryptanalysis/report-acceptance-rule-3.md](../docs/analysis/cryptanalysis/report-acceptance-rule-3.md) |
|
||||
| AP-F8-7 | The hash's reads are not uniformly random: about half of epochs carry one load site with a biased address bit | Open, priced | 1.6 percent at f = 1/2, nothing at f = 1; the served sentence corrected 8 October 2026 (the site the team, by the team's word): the litepaper's lead reads "dependent reads spread over a multi-gigabyte dataset", the… | [docs/analysis/class-v6/family-gate.md](../docs/analysis/class-v6/family-gate.md) |
|
||||
| GF1 | A post-quantum signature scheme would need a hard fork, and every vote key is a public BLS12-381 point | Fixed | The byte costs nothing now and a fork later. | none named |
|
||||
| GF2 | A vote key cannot move: a miner who changes keys re-earns 30 days of weight, and so does the post-quantum migration | Fixed | The successor inherits the window, not a fresh one, so a key rotation costs no weight and the migration of GF1 is one item per key. | none named |
|
||||
| GF3 | A 256 MB on-chip cache makes the lottery hash 2 to 3x cheaper for the card that has it, and the cache size is a constant | Fixed as a genesis lever, measurement owed | Consumer LLC is 96 to 128 MB today and datacentre 256 MB (`chip-model-v3`, approximate), so the shortcut is a datacentre card's today and a consumer card's in a generation or two. | none named |
|
||||
|
|
|
|||
|
|
@ -257,7 +257,7 @@ td.mono{font-family:var(--f-mono);font-size:12.5px;min-width:180px}td.iv{color:v
|
|||
<tr data-status="implemented"><td class="n">15</td><td class="claim">Every block is proven, with the proof landing within about a minute at launch<div class="where">Homepage stats ("~60 s to a proof"); litepaper Proving; roadmap phase 3 gate</div></td><td><span class="st st-1">implemented</span></td><td class="mono">repo <code>d7e1f89</code> (GPU proof), <code>e01a3cc</code>, <code>292e800</code>, <code>eedd136</code> (<code>proving/igneum-prove</code>: shard cutter, MPT witnesses, shard and aggregator guests); SP1 6.8.1; spec 7.2, 7.6</td><td><code>proving/windows-wsl2</code> (SETUP-PROVER, PROVE-BLOCK) on the RTX 5090; <code>igneum-prove-host --mode block</code> on <code>proving/fixtures/</code>; bench-log "proving v0 on the RTX 5090" and "proving: devnet v4 shards"</td><td>First GPU proof of an Igneum block, 4 October 2026, RTX 5090 (WSL2, SP1 cuda, mining paused): fixture <code>block-78-increment</code> (2 transactions), core proof 1.4 s (7.3 MB, verify 0.221 s), compressed proof 2.7 s (1.27 MB, verify 0.038 s), post-state and receipts roots identical to the node's; 15.7x and 20.6x faster than a loaded M5 Max CPU. The same day on that CPU (load 38 to 47): a three-shard block proved shard by shard and aggregated by recursion, 19 min (1,139 s) end to end, 245 to 337 s per compressed shard proof, every proof verified. What is not there: no proof is produced, carried or checked on the chain (the devnet prover is a stub that signs claims), the proving pool pays nobody (row 21), the block proven is far below one shard, and the 60-second figure remains a design target; the pass mark is the standard in <code>docs/benchmarks/proving-e2e.md</code>. Second RTX 5090 run, 4 October 2026 evening (job run-20261004-173115): a full shard at the provisional S_p (6.75 M pgas, 60.8 M cycles) executed in 1.63 s, core proof 8.3 s (18.1 MB), compressed proof 10.9 s (1.27 MB, verify 0.040 s); a two-shard block (13.5 M pgas) proved shard by shard (11.7 s and 10.0 s) and aggregated in 2.2 s, 24 s of GPU stages end to end, every proof verified, six tampered witnesses rejected. The two host defects (an abort after the upload, an idle wait that turned out to be an unbuffered 18 MB proof save through the WSL2 file bridge, 24 minutes) are fixed (ledger P20) 5 October 2026, live devnet with real transactions (bench-log "real transactions, the first non-empty shard proven and paid"): block 72704 shard 0, 29 transfers, 5,800 pgas, proven on the RTX 5090 Windows rig in 34 s, verified on the Apple M5 Max in 0.297 s and paid 1.7623 IGN, 53 s after the chain block executed; of about 1,400 blocks in the 20-minute window 36 were proven (the one prover takes the newest shard assigned to it), so "every block" is not yet true; a second content shard (72803, all copies skipped) failed the native-execution veto on the exporter's block structure, fixed with fixtures the same day, the node side pending the 0.3.9 rollout 5 October 2026, evening (bench-log "proving v1"): the aggregated segment record, the chain rule and the unproven rule are implemented behind <code>proving_v1_activation_daa</code> (branch proving-v1, not on the devnet before 0.3.11); on the RTX 5090 a chain of 8 consecutive live blocks proved and aggregated by recursion in 135.6 s with the miner on the card (17 s a block, one proof of 1,272,909 bytes attesting all 8, verified in 0.04 s); the 3-node fast-time harness paid a segment record 1.0 s after submission and refused a late one after its deadline (21 checks); the devnet itself, with one prover, carried proofs for 2.4% of blocks over 30 minutes at a block-to-record latency p50 44 s, p99 52 s. The "within about a minute" holds per proven block; "every block" needs 18 mining 5090s or 6 proving-only cards at empty blocks on the measured rates, and the mandatory rule stays off until the share is one</td><td class="iv">none yet</td></tr>
|
||||
<tr data-status="designed"><td class="n">16</td><td class="claim">A 12 GB card proves one shard in about 20 s (WITHDRAWN 5 October 2026: a 24 GB card proves a full shard at the adopted size in 4.3 s; 32 GB mines and proves)<div class="where">Litepaper Proving ("The proving budget"); roadmap gate 2</div></td><td><span class="st st-0">designed</span></td><td class="mono">spec 5.1 (Target), 7.6 (<code>S_p</code> provisional, 7,500,000 pgas = <code>B_p</code> / 4)</td><td><code>PROVE-SHARD.bat</code> on the RTX 5090 (pending); the end-to-end standard in <code>docs/benchmarks/proving-e2e.md</code>; bench-log "proving: devnet v4 shards"</td><td>Measured on a 32 GB card, not yet on a 12 GB card. A shard at the provisional <code>S_p</code> is 60.8 M SP1 cycles on the prototype pgas table (9 cycles per pgas, 44 per EVM gas; the modexp entry about 100x its SP1 cost); on an RTX 5090 (4 October 2026 evening, job run-20261004-173115) it executed in 1.63 s and its compressed proof took 10.9 s, verified in 0.040 s, so the 32 GB card is inside the 20 s target with margin. Whether a 12 GB card proves it at all, and in what time, is the next measurement (an RTX 3060 and an RTX 5060 Ti 16 GB are on order). A per-shard time can be met by shrinking the shard, so the project does not use it as a pass mark 5 October 2026, evening (bench-log "proving v1", the S_p curve): measured on the RTX 5090 with SP1 6.8.1's GPU prover, the card to itself, 1-s nvidia-smi samples: an empty shard 13,874 MiB and 2.2 s; a full shard at the ADOPTED v1 budget (30,000 pgas, 4.7 M cycles) 20,434 MiB and 4.3 s; the full prototype shard (6.75 M pgas, 60 M cycles) 28,307 MiB and 10.8 s; beside the miner 15,670 and 30,039 MiB. No environment knob of SP1 moves the 13.9 GB floor and the GPU server has no options of its own, so on this build a 12 GB card proves nothing, a 16 GB card only empty shards, a 24 GB card the adopted full shard alone and beside the miner (22,210 MiB and 13.2 s, measured on the 32 GB card: the 5090's allocation pattern, not yet a run on a 24 GB card) and a 32 GB card the prototype shard beside the miner with 2.5 GB spare. The litepaper line now says so; the 12 GB gate returns when a prover build with a smaller floor is measured on a 12 GB card</td><td class="iv">none yet</td></tr>
|
||||
<tr data-status="designed"><td class="n">17</td><td class="claim">The chip resistance claim: at launch the strongest chip in the public model reaches 2.1x (a core as good as a GPU lane, k = 1) to 3.4x (a core three times better, k about 0.33) per joule against an RTX 5090 under class v4, live from genesis on the testnet and the mainnet; the ladder's second rung brings it to about 2.8x; class v5 makes the dataset the chain's state so a stateless or stale chip is wrong on every item; the hot-set cache is bounded at 1.067x at the ceiling and the weak-day FPGA at 12 percent on 15 days a century, both routed to the next class; datacentre silicon does not change the question; a stored-dataset chip pays for itself only at about USD 100 M of market cap in two years; without class v4 the same chip would reach 5x to 9x (the class v3 baseline, the devnet's starting state, never the launch state)<div class="where">the home page's chip line, the litepaper's chip section (/litepaper#chip-model), the miner page's line</div></td><td><span class="st st-0">tested by the team (every card, the verifier, the two attack-pass bounds, the H100), the chip itself modelled, class v5 and the ladder designed, the X9 figure claimed against a CPU core and never measured</span></td><td class="mono"><code>docs/analysis/chip-model-v3.md</code> 5 and 6; <code>docs/analysis/latency-shadow-2026-10-06.md</code>; <code>docs/plans/counter-asic-3-status.md</code>; <code>docs/analysis/attack-pass/f8-uniform.md</code>, <code>f4-weakday.md</code>, <code>docs/analysis/ca3-v4-uniform.md</code>; <code>docs/design/class-v5-stored-state.md</code>; the H100 and market-cap rows of 7 October; <code>docs/plans/cryptanalysis/in-house-pass.md</code> (the internal adversarial pass)</td><td>the chip model's arithmetic in its file; the card rows by the benchmark package; the attack-pass harnesses <code>tools/attack/f8-uniform</code> and the F4 census; the verifier by <code>igneum-pow bench</code></td><td>136 MH/s at 350 W (5090, bench) and 290 W (app); the class v4 efficiency passes (bench log "7 to 8 October 2026, the class v4 efficiency passes: the core clock lock on the RTX 5090 and the RTX 5080", measured): the 5090 at 136.84 MH/s and 475.5 W unlocked, 134.98 at 316.3 W at a 1,400 MHz core lock, the best points class v4 at 1,200 MHz (133.80 MH/s, 305.1 W, 0.439 MH/W) and class v3 at 1,300 MHz (134.62, 223.3 W, 0.603), the premium 145 W unlocked and 82 W at the best points, the knee 1,300 MHz; the RTX 5080 (8 October 2026, the dock card of the three-card Windows rig) at 71.41 MH/s and 253.1 W unlocked under class v4 against 71.28 at 169.7 W under class v3, the best points class v4 at 1,100 MHz (71.20 MH/s, 146.6 W, 0.486 MH/W) and class v3 at 1,000 MHz (71.11, 103.7 W, 0.686), the premium 83.4 W unlocked and 41 W at the best points, the knee between 1,000 and 900 MHz; per tier: a 5080 owner on class v4 locked near 1,100 MHz pays 147 W instead of 253 for 0.3 percent less rate, MH per watt up 72 percent, the lever Ember Tune's core-clock knob in 0.3.24; 27 MH/s at 21 W (M5 Max); 249 MH/s (H100 SXM) at 98 percent of its read ceiling, 1.78x hash, 1.15x MH/W, a third per rented dollar; 2.33 ms per warp; 2.1x, 3.4x, 2.8x at launch; the shadow's premium on a 5090 81.8 W at its knee (class v4 at the 1,200 MHz lock 133.80 MH/s at 305.1 W; class v3 at 1,300 MHz 134.62 at 223.3 W; 7 October 2026); 1.067x at the ceiling; 12 percent on 15 days a century; 10.85 ms at rung 3; USD 100 M; 5.1x to 9.2x the class v3 baseline; 6 and 7 October 2026, the M5 Max, the RTX 5090 Windows rig's RTX 5090, the three-card Windows rig's RX 9070 XT and RTX 4070, a rented H100 SXM, igneum-build-1 The k about 0.33 bound is the implied core of Bitmain's Antminer X9 (RandomX; 1,000 KH/s, 2,472 W, 2.47 J per KH, USD 5,600; pre-orders 26 December 2025), withdrawn in mid-May 2026 with buyers refunded before any unit shipped, no independent benchmark, commodity Sophgo SG2044 server SoCs with an AES accelerator, no tapeout: a claimed, unmeasured figure carried as the pessimistic bound, not a calibration point (attack pass AP-F5-1, 7 October 2026).</td><td class="iv">none yet; the next test is the internal adversarial pass (three lanes new to the hash code, outsider inputs only, reports published whole), whose floor reading is in (measured, 8 October 2026; ledger AP-F8-1 and AP-F8-6): nine of nine hot sets refused; the diffuse era-stride excess, bounded under 0.1 percent of a hash's reads per site, is not caught by the floor and is the next class's test, and no outside review has run yet</td></tr>
|
||||
<tr data-status="tested by the team"><td class="n">18</td><td class="claim">The chip resistance measurements: the program is latency-bound (random reads), not bandwidth-bound, on every card we own, and sits beyond a card's on-chip cache<div class="where">Litepaper Mining ("waits on memory latency, not on maths or bandwidth"), vs RandomX; the numbers page</div></td><td><span class="st st-2">tested by the team</span></td><td class="mono">readwidth e752fc7 (<code>docs/plans/read-width.md</code>), ca2-era 78c0ee4, ca2-cache 2de19e5 (<code>docs/plans/hot-table.md</code>)</td><td>The dependent-read probes at 32 to 1,024 MiB and the hash rate per class on the three cards; the latency-bound share = rate over the probe ceiling per load</td><td>Latency-bound share at the 1 GiB dataset: RTX 5090 0.96 (v2) and 1.01 (v3), RX 9070 XT 0.87 and 0.95, M5 Max 1.01 and 1.06; wider reads do not close the AMD gap (the 9070 XT does 2.4 G dependent reads per second at every width; the 5090 goes bandwidth-bound at 64 B, share 0.58); a 32 to 96 MiB hot table is not kept resident by any card while the dataset streams (g 0.80 to 0.87 in the added form). 5 October 2026</td><td class="iv">none yet</td></tr>
|
||||
<tr data-status="tested by the team"><td class="n">18</td><td class="claim">The chip resistance measurements: the program is latency-bound (dependent reads spread over the whole dataset), not bandwidth-bound, on every card we own, and sits beyond a card's on-chip cache; measured 8 October 2026: the distinct-index floor holds at 0.995 on every accepted program, about half of epochs carry one load site with a biased address bit at the era's stride rotation, priced at about 1.6 percent of a hash's reads to a chip storing half the dataset and nothing to one storing all of it (<code>docs/analysis/class-v6/family-gate.md</code>, lane D; adv-cache-2's <code>report-chained-cache-2.md</code> section 2.3 on its branch; ledger AP-F8-7)<div class="where">Litepaper Mining ("waits on memory latency, not on maths or bandwidth"), vs RandomX; the numbers page</div></td><td><span class="st st-2">tested by the team</span></td><td class="mono">readwidth e752fc7 (<code>docs/plans/read-width.md</code>), ca2-era 78c0ee4, ca2-cache 2de19e5 (<code>docs/plans/hot-table.md</code>)</td><td>The dependent-read probes at 32 to 1,024 MiB and the hash rate per class on the three cards; the latency-bound share = rate over the probe ceiling per load</td><td>Latency-bound share at the 1 GiB dataset: RTX 5090 0.96 (v2) and 1.01 (v3), RX 9070 XT 0.87 and 0.95, M5 Max 1.01 and 1.06; wider reads do not close the AMD gap (the 9070 XT does 2.4 G dependent reads per second at every width; the 5090 goes bandwidth-bound at 64 B, share 0.58); a 32 to 96 MiB hot table is not kept resident by any card while the dataset streams (g 0.80 to 0.87 in the added form). 5 October 2026</td><td class="iv">none yet</td></tr>
|
||||
<tr data-status="tested by the team"><td class="n">19</td><td class="claim">The lottery hash is sound as a hash: uniform output, deterministic, no out-of-bounds read, fuzzed; class v3 bit-exact on the three vendors<div class="where">Litepaper vs RandomX ("Every number above is measured and logged"), the numbers page</div></td><td><span class="st st-2">tested by the team</span></td><td class="mono">ca2-mixer 1ab8b21 (<code>tests/mixer.rs</code>, <code>tests/scratch.rs</code>), ca2-era 78c0ee4, ca2-soundness a465881 (<code>docs/analysis/scratch-soundness.md</code>), <code>igneum-pow/tests/packs.rs</code></td><td>The crate suite (53 + 4 + 19 + 7), the Metal fuzz, edge, stats and determinism runs on the v3 construction, the pack vectors and 2^24 fingerprints on Metal, Apple OpenCL, the RTX 5090 and the RX 9070 XT, the 1,024-hash CPU re-check per card</td><td>Class v3 (mixer x8 + era): 200-program fuzz 200 of 200 on Metal, every tenth on Apple OpenCL; the pinned v3 packs 3/3 + 3/3 and 96 of 96 lanes on Metal and Apple OpenCL; the six era packs' fingerprints equal on the three vendors (the three-card Windows rig (RTX 5090, RTX 4070, RX 9070 XT) job run-ca2-era-pc1-20261005, 5 October 2026); the v2 exports byte-identical on the v3 crate; the final-class PC rows and the G2 re-check: job run-ca2-era-pc1b-20261005 (pending at the time of writing)</td><td class="iv">none yet</td></tr>
|
||||
<tr data-status="implemented"><td class="n">20</td><td class="claim">No premine, no pre-sale, no allocation: every coin is minted by the schedule and every coin goes to the block producer (80%) and the proving pool (20%)<div class="where">Homepage stats and Economics tiles; litepaper Supply, Economics</div></td><td><span class="st st-1">implemented</span></td><td class="mono">repo <code>6ac80a3</code>; fork "igneum-node devnet v0"; <code>consensus/core/src/igneum.rs</code>, <code>coinbase.rs</code></td><td><code>cargo test -p kaspa-consensus-core igneum</code> (8 pass: subsidy table, ramp, split, cap) and <code>cargo test -p kaspa-consensus coinbase</code> (8 pass); <code>igneum-miner inspect 40</code>; bench-log "igneum-node devnet v0"</td><td>Coinbases on the devnet: 80/20 exact on 39 of 39 single-payee blocks, the 20% to the <code>igneum-proving-pool-v0</code> output; the per-second schedule sums to under the 4,000,000,000 cap by less than 100 coins; 3,168,808,781 units per DAA second in years 0 to 2, halving at 63,115,200 DAA s. 3 October 2026, Apple M5 Max. The devnet genesis carries no allocation; the mainnet genesis does not exist yet, so the claim is about the code and the stated rule, not a launch that has happened</td><td class="iv">none yet</td></tr>
|
||||
<tr data-status="tested by the team"><td class="n">21</td><td class="claim">The proving pool's 20% reaches shard provers and aggregators<div class="where">Litepaper Economics; homepage "20% provers"</div></td><td><span class="st st-2">tested by the team</span></td><td class="mono">spec 5.3; <code>proving/igneum-prove</code> carries the prover's payout address in every shard proof (ledger P12)</td><td>None. The pool output exists (row 20); the payout from it against proof records is unwritten. Since 5 October 2026: the payout rule is live on the devnet (<code>proving.rs shard_payouts</code>, the carrying segment pays the first valid record per shard its part of the segment's pool credit)</td><td>The escrow accumulated on the simnet (92.55 IGN at the end of the v3 run) and nothing can draw it. Rule decided: per block, divided among shards by consensus proving cost, sortition to 8 provers for 10 s then open (spec 7.2). The economy model of 4 October 2026 (<code>sim/economy</code>, 1,000 operators, 30 days) kept every block proven within 60 s under six stress scenarios; a model, not hardware Live devnet, 5 October 2026: 388 shards paid by 16:02 UTC, 446.13 IGN from the pool to the RTX 5090 Windows rig's payout address, 0.8813 IGN per mergeset block of the proven segment (bench-log entries of 5 October: "the first shards proven, verified and paid" and "real transactions, the first non-empty shard proven and paid")</td><td class="iv">none yet</td></tr>
|
||||
|
|
|
|||
|
|
@ -4,13 +4,13 @@
|
|||
<meta charset="utf-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
|
||||
<title>Igneum ledger: every criticism, answered</title>
|
||||
<meta name="description" content="Every criticism Igneum expects, in the critic's words, with what was done, the status and the date. 189 entries. Nothing deleted, nothing softened.">
|
||||
<meta name="description" content="Every criticism Igneum expects, in the critic's words, with what was done, the status and the date. 190 entries. Nothing deleted, nothing softened.">
|
||||
<link rel="canonical" href="https://igneum.network/ledger">
|
||||
<meta name="theme-color" content="#0C0C0E">
|
||||
<meta property="og:type" content="website">
|
||||
<meta property="og:site_name" content="Igneum">
|
||||
<meta property="og:title" content="Igneum ledger: every criticism, answered">
|
||||
<meta property="og:description" content="189 criticisms in the critic's words, with what was done, the status and the date.">
|
||||
<meta property="og:description" content="190 criticisms in the critic's words, with what was done, the status and the date.">
|
||||
<meta property="og:url" content="https://igneum.network/ledger">
|
||||
<meta property="og:image" content="https://igneum.network/og-small.png?v=3">
|
||||
<meta property="og:image:width" content="256">
|
||||
|
|
@ -18,7 +18,7 @@
|
|||
<meta property="og:image:alt" content="Igneum. Mined by GPUs. Proven by fire.">
|
||||
<meta name="twitter:card" content="summary">
|
||||
<meta name="twitter:title" content="Igneum ledger: every criticism, answered">
|
||||
<meta name="twitter:description" content="189 criticisms in the critic's words, with what was done, the status and the date.">
|
||||
<meta name="twitter:description" content="190 criticisms in the critic's words, with what was done, the status and the date.">
|
||||
<meta name="twitter:image" content="https://igneum.network/og-small.png?v=3">
|
||||
<meta name="twitter:image:alt" content="Igneum. Mined by GPUs. Proven by fire.">
|
||||
<link rel="icon" href="/favicon.ico" sizes="48x48">
|
||||
|
|
@ -218,9 +218,9 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
|
|||
<section class="page-hero">
|
||||
<div class="container">
|
||||
<div class="breadcrumb"><a href="/">Igneum</a><span>/</span><span>The ledger</span></div>
|
||||
<div class="page-heading"><div><div class="eyebrow"><span class="line"></span>Ledger · 189 entries · regenerated from the repository</div>
|
||||
<div class="page-heading"><div><div class="eyebrow"><span class="line"></span>Ledger · 190 entries · regenerated from the repository</div>
|
||||
<h1>Every criticism, answered<br><span class="accent">or conceded.</span></h1>
|
||||
<p class="lead">This is every criticism the project expects, in the critic's words, with what was done about it and the date. 189 entries since 3 October 2026. Entries are never deleted; a status that changes keeps its history on the line. Where the critic was right the entry says Conceded. Where nothing has been done it says Open and names what settles it. The founder mined through the GPU years. Ethereum's move to proof of stake in September 2022 ended that income and the miners' place in that chain. This is one person building, with AI systems doing the engineering, the coin he wanted to exist for miners: GPU-mined, the miners are the provers, no founder allocation, every cost stated. Help is welcome and a team is wanted: cryptographers, node engineers, miners who will test. This ledger is the application form: pick an open row and write to <a href="mailto:hello@igneum.network">hello@igneum.network</a> with its id.</p></div></div>
|
||||
<p class="lead">This is every criticism the project expects, in the critic's words, with what was done about it and the date. 190 entries since 3 October 2026. Entries are never deleted; a status that changes keeps its history on the line. Where the critic was right the entry says Conceded. Where nothing has been done it says Open and names what settles it. The founder mined through the GPU years. Ethereum's move to proof of stake in September 2022 ended that income and the miners' place in that chain. This is one person building, with AI systems doing the engineering, the coin he wanted to exist for miners: GPU-mined, the miners are the provers, no founder allocation, every cost stated. Help is welcome and a team is wanted: cryptographers, node engineers, miners who will test. This ledger is the application form: pick an open row and write to <a href="mailto:hello@igneum.network">hello@igneum.network</a> with its id.</p></div></div>
|
||||
</div>
|
||||
</section>
|
||||
<section class="section compact"><div class="container">
|
||||
|
|
@ -229,11 +229,11 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
|
|||
<tbody>
|
||||
<tr><td class="num">3</td><td><button type="button" class="chip" data-filter="Open">Open</button></td><td>Nothing has settled it yet. The entry names what will</td></tr>
|
||||
<tr><td class="num">64</td><td><button type="button" class="chip" data-filter="Conceded">Conceded</button></td><td>The critic is right. "Stated" means the public text says so; "not yet stated" means it does not yet</td></tr>
|
||||
<tr><td class="num">64</td><td><button type="button" class="chip" data-filter="Fixed or built">Fixed or built</button></td><td>A code, spec or text change answers it, with the commit or the page named</td></tr>
|
||||
<tr><td class="num">65</td><td><button type="button" class="chip" data-filter="Fixed or built">Fixed or built</button></td><td>A code, spec or text change answers it, with the commit or the page named</td></tr>
|
||||
<tr><td class="num">27</td><td><button type="button" class="chip" data-filter="Closed by rule or decided">Closed by rule or decided</button></td><td>A consensus rule or a decision by the owner answers it, dated</td></tr>
|
||||
<tr><td class="num">15</td><td><button type="button" class="chip" data-filter="Answered with evidence">Answered with evidence</button></td><td>A measurement or a simulation exists and is named</td></tr>
|
||||
<tr><td class="num">16</td><td><button type="button" class="chip" data-filter="Answered by design">Answered by design</button></td><td>A design rule answers it; no measurement is possible yet</td></tr>
|
||||
<tr><td class="num">189</td><td><button type="button" class="chip" data-filter="">All</button></td><td>Every entry. The sections: <a href="#ap">The in-house adversarial pass</a>, <a href="#m">Mining and chips</a>, <a href="#f">Finality and attacks</a>, <a href="#p">Proving and the zkEVM</a>, <a href="#e">Economics and the coin</a>, <a href="#g">Governance and the founders</a>, <a href="#c">Comparisons</a>, <a href="#l">Legal and regulatory</a>, <a href="#x">Launch and operations</a>, <a href="#d">Builders</a></td></tr>
|
||||
<tr><td class="num">190</td><td><button type="button" class="chip" data-filter="">All</button></td><td>Every entry. The sections: <a href="#ap">The in-house adversarial pass</a>, <a href="#m">Mining and chips</a>, <a href="#f">Finality and attacks</a>, <a href="#p">Proving and the zkEVM</a>, <a href="#e">Economics and the coin</a>, <a href="#g">Governance and the founders</a>, <a href="#c">Comparisons</a>, <a href="#l">Legal and regulatory</a>, <a href="#x">Launch and operations</a>, <a href="#d">Builders</a></td></tr>
|
||||
</tbody></table></div>
|
||||
<div class="toolbar"><input type="search" id="q" placeholder="Search the ledger" aria-label="Search the ledger"><span id="shown"></span></div>
|
||||
<h2 id="m">Mining and chips</h2>
|
||||
|
|
@ -1406,12 +1406,18 @@ blockquote{margin:10px 0;padding:10px 14px;border-left:3px solid var(--line-2);c
|
|||
<div class="status"><span class="badge b-fixed-or-built">Fixed</span> <span class="did">7 October 2026, night): the id and its derivation text come from one byte recipe, every pinned pack's id re-derives from its own text in the suite (the igneum-pow suite on box 2 green at 0f45c8be: 64 + 2 + 7 + 4 + 19 + 2 + 7), the spec states the suffix; no object moved.</span></div>
|
||||
|
||||
</article>
|
||||
<article class="entry" id="AP-F8-5" data-bucket="Conceded">
|
||||
<article class="entry" id="AP-F8-5" data-bucket="Fixed or built">
|
||||
<div class="head"><span class="id">AP-F8-5</span><h3>The public specification did not describe the shipped acceptance rule (documentary; no object change)</h3><span class="date">7 October 2026</span></div>
|
||||
<blockquote>An implementation written from a repository file section 1.4.6 at 017e7037 mines a different program from the node on 264 of 400 epochs." Found by the in-house pass adv-accept-3 (report-acceptance-rule-3.md at 0c150e3c, finding 3, section 6.2, 7 October 2026, night): the text described (a), (b) and (c) with a 32-attempt cap and an id without a suffix, while the code adds (a') with the shared-operand rule, (c'), (c'') at 2^20 evaluations, the 256-attempt cap keyed on the class v4 shape, the total draw with the last resort, generator 4 and the sub-version suffix, and executes the 256-instruction shadow block 27 times per iteration inside the acceptance interpreter. Measured (sweep 97, 400 seeds, 1,317 attempt verdicts): 759 verdicts differ (758 the code rejects and the text accepts: (a') 733, (c'') 15, (c) 10; 1 the other way, the shadow block changing a (c) statistic); 264 of 400 seeds choose another attempt; the parts the text did carry, (a) and (b), agree on every row.</blockquote>
|
||||
<div class="status"><span class="badge b-conceded">Conceded, stated</span> <span class="did">7 October 2026, night, the ledger close): <code>a repository file</code>, What Igneum does not claim, "A delay function that outlives a quantum computer. No." with the fallback (a hash-chain delay behind the version byte that moves the signature scheme, one class change) and the reading (a liveness nuisance, not a break of finality). Still not sized. Was: Conceded, flagged in spec 04 section 4.8.</span></div>
|
||||
<div class="status"><span class="badge b-fixed-or-built">Spec fixed</span> <span class="did">7 October 2026, night, the site audit lane by main's order, branch spec-accept-23): sections 1.4.3 and 1.4.6 of <code>a repository file</code> rewritten to the shipped rule at igneum-pow 017e7037 with every constant named and every order of operations stated (1.4.3: the two per-register states of the draw, the dataflow table, the shared-operand rule, the shadow block's draw and the draw counts per class; 1.4.6.1 to 1.4.6.6: (a) cyclic over two passes, (b), (a') to the fixpoint then a checking pass, (c) with the shadow executed and its limits in a table, (c') and (c'') with the integer form of the ratio compare, the attempts and the two caps with the measured per-part rates, the last resort stated as unreachable and unverified, the program id with the generator-4 suffix, a constants table in the shape the crate's read-back test parses, the pinned ids a reader must reproduce); section 1.7 gains the shadow block's execution; section 1.13.1 names the two consumed era draws. The hash lane's <code>igneum-pow/tests</code> read-back test parses the two tables against the crate's <code>pub const</code> items and derives every pinned id (its landing is the row's check; AP-F8-4 carries the derivation-text half of the same finding). Fixed on two measurements by the finding lane: Q4c at master 8b834634, before the closed-form dataset was stated, a text-only implementation of sections 1.3, 1.4.2, 1.4.3, 1.4.6, 1.6, 1.7 and 1.13.1 re-derived the 400 epoch programs of sweep 97 under the Devnet 3 era with 0 of 400 differing on any field and one function (<code>dataset_elem</code>) taken from the crate (report section 6.5, log 983-textderive-8b834634.tsv); Q4d at master 56eebc0d, with <code>dataset_elem</code> written from 1.4.6.4 and its two pinned vectors reproduced, 0 of 400 differing with 0 crate imports (report section 6.6, log 984-textderive-56eebc0d.tsv, 8 October 2026, 01:5x UK).</span></div>
|
||||
<details><summary>The answer as first written</summary><p>Correct, and the largest divergence source the pass found was documentary. The rule the chain runs was right; the text a second implementer would read was three sub-versions behind it. The fix is the text, written to the code line by line, and a test that fails when the two drift again.</p></details>
|
||||
</article>
|
||||
<article class="entry" id="AP-F8-7" data-bucket="Conceded">
|
||||
<div class="head"><span class="id">AP-F8-7</span><h3>The hash's reads are not uniformly random: about half of epochs carry one load site with a biased address bit</h3><span class="date">7 October 2026</span></div>
|
||||
<blockquote>The served text says every hash is a chain of random reads over the dataset. Measured at the acceptance rule's own 2^20 sample over 4,900 drawn eras (lane D's family harness, 8 October 2026) and in adv-cache-2's drawn-program reading the night before: the reads are spread over the whole dataset and the distinct-index floor holds at 0.995 on every accepted program, but 52 to 58 percent of accepted programs in every stratum carry one load site whose address bit R (the era's stride rotation), R+1 or R+2 is biased over 6 sigma, a third over 100 sigma, the worst z 1,024: a product's bit 0 at P = 1/4 landing on an address bit.</blockquote>
|
||||
<div class="status"><span class="badge b-conceded">Conceded, stated</span> <span class="did">7 October 2026, night, the ledger close): <code>a repository file</code>, What Igneum does not claim, "A delay function that outlives a quantum computer. No." with the fallback (a hash-chain delay behind the version byte that moves the signature scheme, one class change) and the reading (a liveness nuisance, not a break of finality). Still not sized. Was: Conceded, flagged in spec 04 section 4.8.</span></div>
|
||||
<details><summary>The answer as first written</summary><p>Correct as a measurement and bounded as a gain. The favoured half of one site's window serves 75 instead of 50 percent of that site's reads, 25 percent of 1/16 of a hash's reads, about 1.6 percent, to a chip storing half the dataset; a chip storing all of it gains nothing (the f = 1 verdict unchanged, and the partial store already costs 1.26x the ops). The sentence that said "random" now says what was measured.</p></details>
|
||||
</article>
|
||||
|
||||
<p class="intro" style="margin-top:var(--sec)">Source: the project's criticism ledger, a file in the repository, rendered to this page at build time; the repository is published at the public testnet. A criticism that is not here, or that shows an entry is wrong, is added with credit if wanted: <a href="mailto:hello@igneum.network">hello@igneum.network</a> or <a href="https://github.com/igneum-network/spec/issues" rel="noopener">an issue on the specification repository</a>.</p>
|
||||
</div></section>
|
||||
|
|
|
|||
|
|
@ -426,19 +426,19 @@ body.all .pager{display:none}
|
|||
<section id="mining">
|
||||
<h2>Mining: a program that never holds still</h2>
|
||||
<p>Every GPU chain that promised ASIC resistance shipped a fixed algorithm, and a fixed algorithm gets a chip the moment the prize pays for one. Igneum does not have a fixed algorithm.</p>
|
||||
<p>Each hour the chain derives a seed from a locked checkpoint one epoch back, passes it through a ten-minute verifiable delay so no miner can see which program a seed implies before choosing whether to publish a block, and feeds it to a deterministic generator. The generator emits a random integer program built from what graphics cards are uniquely good at: wide parallel integer maths, shuffles between the 32 lanes of a warp, and random reads over a multi-gigabyte dataset that changes daily, so the program waits on memory latency, not on maths or bandwidth. Measured: an RTX 5090 hashes at 95 GB/s of useful 4-byte loads against 1,638 GB/s of sequential writes (engineering log, the RTX 5090 entries). The memory footprint and instruction count are fixed and only the maths sequence is random, so no hour favours one vendor's cards and nobody gains by grinding the seed. Miners compile the program once per hour. Anyone running a node, a wallet or an exchange checks a hash on an ordinary CPU in under ten milliseconds by simulating one warp, so nobody needs a GPU except to mine. Measured: 0.61 ms per warp on one Apple M5 Max core for class v2 and 2.1 ms for class v3 (the mixer at x8, 5 October 2026, one core at load average 5.5, worst cold unit 2.15 ms), 3.4x the class v2 verifier; the 10 ms gate leaves 4.8x (4.6x on the worst cold unit); a 2019-class laptop core is not yet measured.</p>
|
||||
<p>Each hour the chain derives a seed from a locked checkpoint one epoch back, passes it through a ten-minute verifiable delay so no miner can see which program a seed implies before choosing whether to publish a block, and feeds it to a deterministic generator. The generator emits a random integer program built from what graphics cards are uniquely good at: wide parallel integer maths, shuffles between the 32 lanes of a warp, and dependent reads spread over a multi-gigabyte dataset that changes daily, so the program waits on memory latency, not on maths or bandwidth. Measured: an RTX 5090 hashes at 95 GB/s of useful 4-byte loads against 1,638 GB/s of sequential writes (engineering log, the RTX 5090 entries). The memory footprint and instruction count are fixed and only the maths sequence is random, so no hour favours one vendor's cards and nobody gains by grinding the seed. Miners compile the program once per hour. Anyone running a node, a wallet or an exchange checks a hash on an ordinary CPU in under ten milliseconds by simulating one warp, so nobody needs a GPU except to mine. Measured: 0.61 ms per warp on one Apple M5 Max core for class v2 and 2.1 ms for class v3 (the mixer at x8, 5 October 2026, one core at load average 5.5, worst cold unit 2.15 ms), 3.4x the class v2 verifier; the 10 ms gate leaves 4.8x (4.6x on the worst cold unit); a 2019-class laptop core is not yet measured.</p>
|
||||
<p>The hash is a lottery, not a general-purpose cryptographic hash. It has to be unpredictable per nonce, free of any shortcut cheaper than honest evaluation, and free of bias a miner can exploit. It does not need preimage or collision resistance. Open: no analysis of the lottery properties exists yet. It is the first job of the external review in phase 1, and until then the hash is a design claim backed by the measurements below.</p>
|
||||
<div class="tbl"><table>
|
||||
<thead><tr><th>Clock</th><th>What changes</th><th>Miner update needed?</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td>Every hash</td><td>The 128 dataset addresses depend on the nonce, so every hash reads different memory. The one-bit select inside the maths costs a chip nothing and is not a defence; the random reads are</td><td>No</td></tr>
|
||||
<tr><td>Every hash</td><td>The 128 dataset addresses depend on the nonce, so every hash reads different memory. The one-bit select inside the maths costs a chip nothing and is not a defence; the dependent reads are</td><td>No</td></tr>
|
||||
<tr><td>Every hour</td><td>A new random program</td><td>No, the miner compiles whatever arrives</td></tr>
|
||||
<tr><td>Every day</td><td>A new dataset</td><td>No</td></tr>
|
||||
<tr><td>Every six months</td><td>A new instruction mix and memory pattern drawn by the chain from rules fixed at genesis, and a new family of instructions unlocked from a reserve written at genesis, so the program space widens every era. A schedule change against fixed datapaths and human forks, not a surprise: a programmable chip reads every drawn parameter as firmware</td><td>No</td></tr>
|
||||
<tr><td>Continuously</td><td>The dataset grows on a schedule fixed at genesis, slowly enough that consumer cards keep up for years. A chip is built with fixed memory, so it is on a countdown from the day it ships. Ethereum's growing dataset ran Bitmain's E3 out of memory in 2020 this way, approximate, with nobody doing anything</td><td>No</td></tr>
|
||||
</tbody>
|
||||
</table></div>
|
||||
<p>Three ideas carry the chip resistance. <strong>The hash rewrites itself.</strong> A new program every hour, drawn from the chain. Its memory pattern changes with it. The rules change on a schedule fixed at launch. No release, no vote. These are automatic schedule changes: they defeat a chip wired for one datapath and they need no human fork. Against a chip that stores the dataset every drawn parameter is firmware, and what meets that chip is the latency-shadow work (class v4) and the price per joule (the Horizon lane analysis, 6 October 2026, section 5.4; ledger M32). <strong>It waits on memory, not maths.</strong> Every hash is a chain of random reads into a table too big for a chip to carry. The wait is the same physics for everyone. <strong>Miners hold the switch.</strong> Spare defences are written into the rules, switched off. A miner signal turns one on, at the class-change threshold: miners signal three things at three thresholds, 60 percent of blue blocks over two weeks for a parameter genesis leaves open, 90 percent for an upgrade (new code), and 95 percent with a floor height for a class change. No fork.</p>
|
||||
<p>Three ideas carry the chip resistance. <strong>The hash rewrites itself.</strong> A new program every hour, drawn from the chain. Its memory pattern changes with it. The rules change on a schedule fixed at launch. No release, no vote. These are automatic schedule changes: they defeat a chip wired for one datapath and they need no human fork. Against a chip that stores the dataset every drawn parameter is firmware, and what meets that chip is the latency-shadow work (class v4) and the price per joule (the Horizon lane analysis, 6 October 2026, section 5.4; ledger M32). <strong>It waits on memory, not maths.</strong> Every hash is a chain of random reads into a table too big for a chip to carry. Measured (8 October 2026; lane D’s family harness at the acceptance rule’s own 2^20 sample over 4,900 drawn eras, and the chained-cache pass’s reading of the night before): every hash’s 128 dependent reads land across the whole dataset and the distinct-index floor holds at 0.995 on every accepted program; about half of epochs carry one load site whose address bit at the era’s stride rotation is biased, which prices about 1.6 percent of a hash’s reads to a chip storing half the dataset and nothing to a chip storing all of it; the next class folds the product’s low bits before the rotation, so no era lands a biased bit on an address bit. The wait is the same physics for everyone. <strong>Miners hold the switch.</strong> Spare defences are written into the rules, switched off. A miner signal turns one on, at the class-change threshold: miners signal three things at three thresholds, 60 percent of blue blocks over two weeks for a parameter genesis leaves open, 90 percent for an upgrade (new code), and 95 percent with a floor height for a class change. No fork.</p>
|
||||
<p><strong>The work that waits can grow.</strong> Class v4 adds a block of latency-shadow arithmetic to every hash, about 100,000 integer operations that run while the memory reads are in flight, so a chip that stores the whole dataset still has to pay for a core. That size sits on a ladder fixed at genesis, six rungs from about 100,000 to about 1,000,000 operations, and it moves one rung at a time only when 90 percent of blue blocks in each of seven consecutive days ask for it; it can never move two rungs inside a week and never past a rung the reference verifier cannot check under 10 ms with its sibling thread busy (measured on the build server, 6 October 2026: the first three rungs pass at 8.8, 8.9 and 9.2 ms, the fourth misses by 0.08 ms on a loaded box and stays out until a quiet re-measurement, the two doublings are out at 12.4 and 15.0 ms). What it buys, on the measured cards: against a dataset-storing chip whose core costs what an RTX 5090's does per operation, the chip's per-joule edge falls from 2.1x at the first rung to 1.3x at the third; against a core as good as the one Bitmain claimed for its withdrawn Antminer X9 (about 3x per joule over a desktop CPU, never measured), from 3.4x to 2.8x. What it costs, per rung, is measured too: the Apple tier gives up 3 points of rate at the first step and 6 more at the second, the RTX 5090 nothing until the second; so the miners who pay for a step are the ones who take it (<a href="/ledger#M34">ledger M34</a>).</p>
|
||||
<h3 id="chip-model">The chip model</h3>
|
||||
<p>We price the strongest chip we can design against an RTX 5090 and publish the arithmetic. Class v4 is live from the first block on the testnet and the mainnet (the ladder’s rung 0 at genesis), so the launch number is the class v4 row. The honest card: an RTX 5090 mines class v3 at 136 MH/s on 350 W in the bench and 290 W in the app (measured, 6 October 2026); under class v4 the same card reads 136.84 MH/s at 475.5 W unlocked and 134.98 MH/s at 316.3 W at a 1,400 MHz core lock, and 133.80 MH/s at 305.1 W at 1,200 MHz, against a class v3 control of 134.68 MH/s at 228.0 W (measured, 7 October 2026); an Apple M5 Max at 27 MH/s on 21 W (measured, 6 October 2026); an H100 SXM at 249 MH/s, 98 percent of its random-read ceiling like the 5090, 1.78x the 5090’s hash at 1.15x the tuned 5090’s hash per watt and a third of the hash per rented dollar (measured, 7 October 2026), so datacentre silicon does not change the chip question. The CPU verifier takes 2.33 ms per warp of 32 hashes on one M5 Max core under class v4 (measured, 6 October 2026), against a gate of 10 ms.</p>
|
||||
|
|
|
|||
|
|
@ -882,9 +882,9 @@
|
|||
"mh_per_w": 0.201,
|
||||
"driver_os": "NVIDIA driver 580.65.06, Ubuntu 24.04 (CUDA 12.8.1 image)",
|
||||
"source": "model sweep 2026-10-08, row 3 (a rented card, result cb2-rtx-3080-ti-12-gb-efll-result.json; 09:28Z)",
|
||||
"note": "rented single-card host, 0.04 h; power.draw mean 293.5 W (max 299.6, limit 320 W), SM 1,936 MHz mean, memory 9,251 MHz, 74 C, the SW power-cap bit set 26 W under the limit; self-test PASS (96 of 96 vector lanes); the class v5 kit runs 2.5 percent faster on this card (60.38 MH/s, fingerprint matched); read ceiling 58.9 MH/s, the hash at 1.00 of it. Matches the 7 October row (58.95 MH/s) across hosts; the worst MH per watt of the sweep and the cheapest MH per rented hour, so a buyer on a power bill prefers the 5070 Ti and a renter this card. Watts are class v3 (read 8 October 2026, 11:4x UK): the fleet's bench pack was the class v3 program (program_class v3, generator 3, load_class mx8-erad810f22d), so this row's watts and MH per watt are class v3 figures; the rate holds under class v4 (memory-bound: a 5070 Ti measured 78.7 MH/s at 141 W on class v3 and 78.8 at 224 W on class v4). The class v4 watts rerun on the same models lands with its date, the v3 watts kept beside as the shadow premium per card",
|
||||
"note": "rented single-card host, 0.04 h; power.draw mean 293.5 W (max 299.6, limit 320 W), SM 1,936 MHz mean, memory 9,251 MHz, 74 C, the SW power-cap bit set 26 W under the limit; self-test PASS (96 of 96 vector lanes); the class v5 kit runs 2.5 percent faster on this card (60.38 MH/s, fingerprint matched); read ceiling 58.9 MH/s, the hash at 1.00 of it. Matches the 7 October row (58.95 MH/s) across hosts; the worst MH per watt of the sweep and the cheapest MH per rented hour, so a buyer on a power bill prefers the 5070 Ti and a renter this card. Class v4 pair (8 October 2026, result cb4-rtx-3080-ti-12-gb-7647-result.json, a different and deep-capped board: 220 W host cap on a 350 W card, the SM clock collapsed to 749 MHz): 42.24 MH/s mean at 216.2 W under class v4 against 44.93 MH/s at 166.2 W under class v3 on that board, the shadow premium +30.1 percent of watts and, on this cap, 5 percent of rate: the first cap that costs rate (a cap near 63 percent of stock on a 350 W GDDR6X card starves the SM clock the memory loop needs, where the 4070 Super at half its 220 W and the 3070 at 88 percent held full rate). The uncapped morning rate (58.86 MH/s) stands as this card's rate; its class v4 watts on an uncapped board are not yet measured and would read about 380 W by this pair's ratio (an estimate). The rule from the pairs so far: a power cap holds the rate until the SM clock falls below roughly 1.8 GHz on Ampere and 2.4 GHz on Ada",
|
||||
"watts_class": "v3",
|
||||
"watts_display": "293.5 (class v3)"
|
||||
"watts_display": "293.5 (class v3, uncapped board)"
|
||||
},
|
||||
{
|
||||
"generator": "v2",
|
||||
|
|
@ -919,19 +919,18 @@
|
|||
"group": "buy",
|
||||
"card": "NVIDIA RTX 3070 (8 GB)",
|
||||
"mh_s": 37.09,
|
||||
"watts": 142.3,
|
||||
"mh_per_w": 0.261,
|
||||
"watts": 196.4,
|
||||
"mh_per_w": 0.189,
|
||||
"driver_os": "NVIDIA driver 580.65.06, Ubuntu 24.04 (CUDA 12.8.1 image)",
|
||||
"source": "model sweep 2026-10-08, row 5 (a rented card, result cb2-rtx-3070-8-gb-qh9j-result.json; 09:32Z)",
|
||||
"note": "rented single-card host, 0.06 h; power.draw mean 142.3 W (max 146.7, limit 225 W), SM 2,002 MHz mean, memory 6,801 MHz, 57 C, no throttle reason; self-test PASS (96 of 96 vector lanes); the class v5 kit holds the rate (37.14 MH/s, fingerprint matched); read ceiling 37.2 MH/s, the hash at 1.00 of it. Against the 3070 Ti: 5 percent less rate for 25 percent less power, the better owner card of the two; 8 GB holds the class v4 set with room. Watts are class v3 (read 8 October 2026, 11:4x UK): the fleet's bench pack was the class v3 program (program_class v3, generator 3, load_class mx8-erad810f22d), so this row's watts and MH per watt are class v3 figures; the rate holds under class v4 (memory-bound: a 5070 Ti measured 78.7 MH/s at 141 W on class v3 and 78.8 at 224 W on class v4). The class v4 watts rerun on the same models lands with its date, the v3 watts kept beside as the shadow premium per card",
|
||||
"source": "model sweep 2026-10-08, row 5 (a rented card, result cb2-rtx-3070-8-gb-qh9j-result.json; 09:32Z); the class v4 watts rerun, 8 October 2026 (result cb4-rtx-3070-8-gb-l6mu-result.json, the v4-devnet-epoch0 pack, sub-version 3, three runs of about 30 s, the class v3 pack paired on the same host)",
|
||||
"note": "rented single-card host, 0.06 h; power.draw mean 142.3 W (max 146.7, limit 225 W), SM 2,002 MHz mean, memory 6,801 MHz, 57 C, no throttle reason; self-test PASS (96 of 96 vector lanes); the class v5 kit holds the rate (37.14 MH/s, fingerprint matched); read ceiling 37.2 MH/s, the hash at 1.00 of it. Against the 3070 Ti: 5 percent less rate for 25 percent less power, the better owner card of the two; 8 GB holds the class v4 set with room. Class v4 watts (8 October 2026, the rerun, self-test PASS): 196.4 W at 37.11 MH/s, 0.189 MH per watt; the class v3 pack on the same host read 153.4 W at the same rate, so the shadow premium on this card is +28 percent of watts for no rate. this board is capped at 193 W by the host (stock 220) and the class v4 draw sits on the cap with the power-cap bit set while the rate holds, the same shape as the capped 4070 Super; the first Ampere pair",
|
||||
"hive": {
|
||||
"core_mhz": null,
|
||||
"mem_mhz": null,
|
||||
"pl_w": null,
|
||||
"label": "stock (rented card, no clock control on the host; no measured tune point)"
|
||||
},
|
||||
"watts_class": "v3",
|
||||
"watts_display": "142.3 (class v3)"
|
||||
"watts_display": "196.4 (class v4)"
|
||||
},
|
||||
{
|
||||
"generator": "v2",
|
||||
|
|
@ -943,19 +942,18 @@
|
|||
"group": "buy",
|
||||
"card": "NVIDIA RTX 3070 Ti (8 GB)",
|
||||
"mh_s": 38.98,
|
||||
"watts": 177.1,
|
||||
"mh_per_w": 0.22,
|
||||
"watts": 267.6,
|
||||
"mh_per_w": 0.146,
|
||||
"driver_os": "NVIDIA driver 595.71.05, Ubuntu 24.04 (CUDA 12.8.1 image)",
|
||||
"source": "model sweep 2026-10-08, row 6 (a rented card, result cb2-rtx-3070-ti-8-gb-8528-result.json; 09:33Z)",
|
||||
"note": "rented single-card host, 0.07 h; power.draw mean 177.1 W (max 183.6, limit 290 W), SM 1,955 MHz mean, memory 9,251 MHz, 67 C, no throttle reason; self-test PASS (96 of 96 vector lanes); the class v5 kit holds the rate (39.12 MH/s, fingerprint matched); read ceiling 39.1 MH/s, the hash at 1.00 of it. Repeats the 7 October row on another host (38.98 then, 38.98 now; 178 then 177 W), so the class v4 number is host-independent to 0.1 percent. Watts are class v3 (read 8 October 2026, 11:4x UK): the fleet's bench pack was the class v3 program (program_class v3, generator 3, load_class mx8-erad810f22d), so this row's watts and MH per watt are class v3 figures; the rate holds under class v4 (memory-bound: a 5070 Ti measured 78.7 MH/s at 141 W on class v3 and 78.8 at 224 W on class v4). The class v4 watts rerun on the same models lands with its date, the v3 watts kept beside as the shadow premium per card",
|
||||
"source": "model sweep 2026-10-08, row 6 (a rented card, result cb2-rtx-3070-ti-8-gb-8528-result.json; 09:33Z); the class v4 watts rerun, 8 October 2026 (result cb4-rtx-3070-ti-8-gb-7705-result.json, the v4-devnet-epoch0 pack, sub-version 3, three runs of about 30 s, the class v3 pack paired on the same host)",
|
||||
"note": "rented single-card host, 0.07 h; power.draw mean 177.1 W (max 183.6, limit 290 W), SM 1,955 MHz mean, memory 9,251 MHz, 67 C, no throttle reason; self-test PASS (96 of 96 vector lanes); the class v5 kit holds the rate (39.12 MH/s, fingerprint matched); read ceiling 39.1 MH/s, the hash at 1.00 of it. Repeats the 7 October row on another host (38.98 then, 38.98 now; 178 then 177 W), so the class v4 number is host-independent to 0.1 percent. Class v4 watts (8 October 2026, the rerun, self-test PASS): 267.6 W at 39.1 MH/s, 0.146 MH per watt; the class v3 pack on the same host read 180.4 W at the same rate, so the shadow premium on this card is +48.3 percent of watts for no rate. the same board as the 7 October row (offer 36538839), uncapped (a 310 W AIB); the uncapped GDDR6X Ampere premium sits with the 4080's and the 5070's rather than the 192-bit Ada third, so the premium scales with the SM the board had idle under class v3",
|
||||
"hive": {
|
||||
"core_mhz": null,
|
||||
"mem_mhz": null,
|
||||
"pl_w": null,
|
||||
"label": "stock (rented card, no clock control on the host; no measured tune point)"
|
||||
},
|
||||
"watts_class": "v3",
|
||||
"watts_display": "177.1 (class v3)"
|
||||
"watts_display": "267.6 (class v4)"
|
||||
},
|
||||
{
|
||||
"generator": "v2",
|
||||
|
|
@ -1232,15 +1230,14 @@
|
|||
"watts": null,
|
||||
"mh_per_w": null,
|
||||
"driver_os": "NVIDIA driver 595.91.07, Ubuntu 24.04 (CUDA 12.8.1 image)",
|
||||
"source": "model sweep 2026-10-08, row 18 (a rented card, result cb2-rtx-4060-8-gb-0672-result.json; 09:53Z)",
|
||||
"note": "watts not read: this host exposes no power sensor (every power field absent on all 244 samples, as the 7 October 4060 host); a third host is being rented for the watts, and the card's draw is about 60 to 70 W by its 115 W limit and the 4060 Ti's 79 W, an estimate until then. Rented single-card host, 0.12 h; SM 2,732 MHz mean, memory 8,251 MHz, 57 C, no throttle reason; self-test PASS (96 of 96 vector lanes); the class v5 kit holds the rate (19.11 MH/s, fingerprint matched); read ceiling 30.2 MH/s, the hash at 0.63 of it (the 128-bit bus: the independent-read line binds, as on the 2070 Super). Repeats the 7 October row (19.09 then, 19.10 now). Watts are class v3 (read 8 October 2026, 11:4x UK): the fleet's bench pack was the class v3 program (program_class v3, generator 3, load_class mx8-erad810f22d), so this row's watts and MH per watt are class v3 figures; the rate holds under class v4 (memory-bound: a 5070 Ti measured 78.7 MH/s at 141 W on class v3 and 78.8 at 224 W on class v4). The class v4 watts rerun on the same models lands with its date, the v3 watts kept beside as the shadow premium per card",
|
||||
"source": "model sweep 2026-10-08, row 18 (a rented card, result cb2-rtx-4060-8-gb-0672-result.json; 09:53Z); the class v4 rerun, 8 October 2026 (result cb4-rtx-4060-8-gb-7165-result.json: the rate on both classes, no watts)",
|
||||
"note": "watts not reported by any rented host (four 4060 boards across 7 and 8 October, one machine family, every power field absent; two other hosts never answered ssh); the class v4 rerun on 8 October read the same rate on both classes (19.09 MH/s class v4, 19.094 class v3) and still no watts; by the 4060 Ti pair on the same silicon (+33.6 percent) the class v4 draw is about 80 to 90 W from a class v3 draw of about 60 to 70 W under the 115 W limit, an estimate until an owner measures at the wall.12 h; SM 2,732 MHz mean, memory 8,251 MHz, 57 C, no throttle reason; self-test PASS (96 of 96 vector lanes); the class v5 kit holds the rate (19.11 MH/s, fingerprint matched); read ceiling 30.2 MH/s, the hash at 0.63 of it (the 128-bit bus: the independent-read line binds, as on the 2070 Super). Repeats the 7 October row (19.09 then, 19.10 now)",
|
||||
"hive": {
|
||||
"core_mhz": null,
|
||||
"mem_mhz": null,
|
||||
"pl_w": null,
|
||||
"label": "stock (rented card, no clock control on the host; no measured tune point)"
|
||||
},
|
||||
"watts_class": "v3"
|
||||
}
|
||||
},
|
||||
{
|
||||
"generator": "v2",
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
Loading…
Reference in a new issue