|
|
|
|
@ -29,8 +29,8 @@ Evidence locations referenced below: `docs/bench-log.md`, `proto-metal/TESTS.md`
|
|
|
|
|
### M1. The program space is tiny
|
|
|
|
|
"Eleven integer ops, 64 instructions, 8 iterations, a splitmix register init. That is not RandomX. RandomX leans on a superscalar out-of-order CPU with floating point and branches. Yours is a sea of 32-bit ALUs and a memory bus. A chip for that is a weekend."
|
|
|
|
|
|
|
|
|
|
Status: Open, program space counted, the claim stands as a target (5 October 2026, evening sweep). Was: Open, experiment scheduled. Sweep (5 October 2026): nothing runnable; the bounty, the public benchmark and a chip design are M22's decisions and hardware. The nearest number stays M16's arithmetic.
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 1 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:35 UTC, by the owner; decisions item 1, corrected): no standing bounty. A team with a real 2x chip earns more by mining than any bounty pays, so a device bounty attracts nobody; the tiers announced at 17:25 UTC are withdrawn. The claim "under 2x" is backed by the paid independent cryptanalysis (the Monero route: four paid reviews, no bounty) and by the public benchmark with M22's metrics. Optional, the owner's call later: one cryptanalysis prize of USD 50,000 for a published 2x or better shortcut in the mixer, the chained cache or the acceptance rule, escrowed before it is named; nothing public before that. The claim stays a target until the audit and the benchmark have reported. Was: Open, program space counted, the claim stands as a target (5 October 2026, evening sweep). Was: Open, experiment scheduled. Sweep (5 October 2026): nothing runnable; the bounty, the public benchmark and a chip design are M22's decisions and hardware. The nearest number stays M16's arithmetic.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Sweep (5 October 2026, evening): the program space, swept as arithmetic from the version 2 generator (`igneum-pow/src/generator.rs`: 16 load slots as a uniform 16-subset of instructions 1 to 63, then nine draws per instruction, 592 draws per program; 10 non-load operations with weights 12/10/8/8/8/7/6/6/6/4; 8 registers; a 31-way rotation, a 32-way bit and a 5-way mask per instruction; two 32-bit immediates). Counting choices: the slot subset is 48.4 bits; the operation draw carries 3.26 bits of entropy (of log2 10 = 3.32); operations and registers alone give about 770 bits per program; with the rotation, bit and mask fields about 1,550 bits; with the immediates about 5,650 bits, all capped by the 256-bit seed, so the space a chip has to serve is 2^256 distinct programs drawn from a structure of about 2^1550 shapes, and the critic is right that it is a small instruction set: 12 operations, 8 registers, no floating point, no branches, by design (vendor-identical rounding). What the sweep adds to the ledger's answer is the number that matters for a fixed-function design, the spread a chip must absorb: under generator version 2 every accepted program does 120 to 128 distinct loads per hash (median 128.00, 20,000-program census), so the per-program hash-rate spread on a memory-bound device is the 1.10x residual the census measured, not the 2.7x of version 1; the chip's advantage therefore cannot come from the program (it is one fixed memory-bound shape) and must come from the memory system or from the recompute route, which is M16's cost model (`docs/analysis/m16-recompute-attacker-2026-10-05.md`: 1.5x to 2.4x at equal integer budget before any fixed-function factor, 3x to 6x with one, and the mixer-cost lever that cuts it below 1x). The experiment that closes M1 is unchanged: the bounty and the public benchmark (M22, decision owner the project lead).
|
|
|
|
|
|
|
|
|
|
@ -103,8 +103,8 @@ Sweep (5 October 2026, evening): stated. `site/litepaper.html`, Mining section,
|
|
|
|
|
### M8. Only two vendors, two programs, one day
|
|
|
|
|
"'Any card, any vendor, bit-exact' rests on 192 vectors across two programs on one Apple chip and one NVIDIA card, all run on the same day. AMD is untested. Intel is unmentioned."
|
|
|
|
|
|
|
|
|
|
Status: Answered with evidence for what was measured; Open for AMD and Intel. Sweep (5 October 2026): Intel is now run. A Windows laptop with only an Intel UHD integrated GPU mined on the live devnet through the OpenCL worker at 1.46 MH/s, found one block that the network accepted, and its votes on checkpoints 1202 and 1203 were accepted (`docs/bench-log.md`, "first machine in the United States"). Discrete AMD is the remaining gap (hardware, O-1.15).
|
|
|
|
|
Decision owner: the project lead (a discrete AMD card). Decision request: `docs/plans/ledger-decisions.md`, item 12 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 12): a discrete AMD card (9070 XT) and a 12 GB NVIDIA card (4070) are on order for PC 2; the measurement runs on arrival. Was: Answered with evidence for what was measured; Open for AMD and Intel. Sweep (5 October 2026): Intel is now run. A Windows laptop with only an Intel UHD integrated GPU mined on the live devnet through the OpenCL worker at 1.46 MH/s, found one block that the network accepted, and its votes on checkpoints 1202 and 1203 were accepted (`docs/bench-log.md`, "first machine in the United States"). Discrete AMD is the remaining gap (hardware, O-1.15).
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Answer: 192 of 192 vectors matched across Metal and CUDA on two programs, standalone and in batch. That is the measurement and it is small. AMD (ROCm or OpenCL) is the next run, then the full 10,200-program fuzz set on NVIDIA and AMD with the 14 edge-case programs, and the shuffle, mulhi and shift semantics must agree bit for bit on every vendor. Intel Arc after that. The litepaper says "Any card, any vendor" and should say what was measured.
|
|
|
|
|
|
|
|
|
|
@ -133,8 +133,8 @@ Evidence: `docs/bench-log.md`, RTX 5090 sections. Fix: overclaims list, item 14.
|
|
|
|
|
### M11. Hourly JIT on real rigs
|
|
|
|
|
"50 ms compile is a Mac number. On a HiveOS rig the miner has to ship NVRTC or a ROCm compiler, compile for eight cards of mixed generation, and do it every hour without crashing. Every miner that tried runtime codegen had a bad year."
|
|
|
|
|
|
|
|
|
|
Status: Answered with evidence on the fleet that exists, Open for a multi-card rig and ROCm (5 October 2026, evening sweep). Was: Open, experiment scheduled. Sweep (5 October 2026): partly measured. One RTX 5090 compiled the hourly program at runtime (nvcc in the background) on the live devnet in 1,285 ms with no pause and 0 rejected (bench-log, "first hourly program swap"). A multi-card mixed rig and ROCm remain unmeasured (hardware, O-1.16).
|
|
|
|
|
Decision owner: the project lead (a multi-card rig and ROCm). Decision request: `docs/plans/ledger-decisions.md`, item 12 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 12): the mixed-generation rig is borrowed from a farm operator later, at the HiveOS package's first test; the 9070 XT on order gives the ROCm half on PC 2. Was: Answered with evidence on the fleet that exists, Open for a multi-card rig and ROCm (5 October 2026, evening sweep). Was: Open, experiment scheduled. Sweep (5 October 2026): partly measured. One RTX 5090 compiled the hourly program at runtime (nvcc in the background) on the live devnet in 1,285 ms with no pause and 0 rejected (bench-log, "first hourly program swap"). A multi-card mixed rig and ROCm remain unmeasured (hardware, O-1.16).
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Sweep (5 October 2026, evening): hourly runtime codegen measured on five machines, four compilers and three vendors over the live devnet's boundaries of 5 October 2026 (miner logs through the intake, DAA 82,800 to 111,600, from each machine's 0.3.5 start; `docs/bench-log.md`, "FUD ledger sweep round 6", M11). NVRTC on the two RTX 5090s: prepare 580 to 1,074 ms in all (nvrtc 147 to 180 ms, cache, dataset, 96-lane self-test), 22 of 22 boundaries swapped with no pause, 0 rejected. OpenCL on the two integrated Radeons: prepare 6.9 to 11.7 s on PC 2 and 55 to 124 s on PC 1 (its 1 GiB dataset build on the iGPU runs beside today's WSL build jobs), the two late boundaries on PC 1 (82,800 and 93,600, the prepare sent 156 to 160 DAA before the boundary instead of 449) compiled inline, the rest swapped. OpenCL on the Intel UHD laptop: prepare 7.3 to 11.7 s (build 3.0 to 6.4 s), 7 of 7 swapped with no pause. Metal on the two Macs: program 0 to 444 ms, prepare 34 to 40 s because the hourly race runs inside it, 9 of 9 swapped with no pause. The failure the critic predicts did happen, on the 0.3.4 miner: a wrong prepared pack at DAA 61,200 made both PCs' NVIDIA workers refuse the prepare every 0.7 s for two hours (4,299 and 4,233 `prepare-failed` lines) and cross two boundaries by inline compile; the 0.3.5 miner's rate limit ended it (M27). The variant race on the 5090 (the job of `docs/plans/miner-perf.md`, run on PC 1 at 15:52 UTC with the miners stopped): 17 NVRTC variants, 3 rounds, twice; base won both runs at 139.75 and 139.65 MH/s, gain +0.00%, every variant within -1.5% (`ldcs`) and +0.05% of base, compile 232 to 300 ms for the 17, 112 s of timing per run; the Mac fleet records agree that base wins on the M5 Max with the GPU to itself (10 records, g256 at -4.2%, against +17% under 4 October's contention). The race is therefore switched off as a default worth nothing on this program class: 40 s an hour of paused mining on the Macs for a base winner. Still unmeasured: a multi-card mixed-generation rig and ROCm (hardware, O-1.16).
|
|
|
|
|
|
|
|
|
|
@ -189,8 +189,8 @@ Evidence: `sim/results.md` table E and "What the simulation cannot tell us"; des
|
|
|
|
|
### F3. Participation grinding through the bitmap
|
|
|
|
|
"The aggregator picks which votes go in the certificate once quorum is reached. A block producer carries the certificate it likes. Drop a rival pool's votes from your bitmaps for two hours and its participation factor falls, your share rises."
|
|
|
|
|
|
|
|
|
|
Status: Closed by rule (3 October 2026), parameter open. Spec section 3.3 Q2 and 3.4.1: participation is computed from every vote seen in blocks over the presence window (votes are block payload), never from the certificates an aggregator chose; the per-block vote bound is O-3.3. Was: Open, experiment scheduled. Sweep (5 October 2026): the block reading is exercised on the fork by harness s3 (block-carried votes give participation; 35 of 35 locked on each of 3 nodes) and s4 (a producer dropping the finality section from 40% of its blocks adds 0 ms to lock latency, 35 locks), bench-log "finality v2 attack harness"; the per-block vote bound and the hostile-aggregator simulation of O-3.3 were run and proposed in round 2 (5 October 2026, night, below; decision at gate 3). Re-run on the `finality-fixes` build under fast time (5 October 2026, 01:13 UTC, `run.mjs s4 --fast-time`, 2 nodes, 223 s): node B locked 14 checkpoints with a 40% vote-dropping producer, median lock latency 1,042 ms against 1,042 ms for the control, 0 ms added. PASS.
|
|
|
|
|
Decision owner: the project lead (gate 3, the spec 3.4.2 proposals). Decision request: `docs/plans/ledger-decisions.md`, item 13 (6 October 2026, 00:05 UTC).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 13): the per-block vote bound and the bitmap wire bound of spec 3.4.2 items 2 and 3 are adopted for gate 3; the spec moves them from Proposed to Decided at the next spec edit. Was: Closed by rule (3 October 2026), parameter open. Spec section 3.3 Q2 and 3.4.1: participation is computed from every vote seen in blocks over the presence window (votes are block payload), never from the certificates an aggregator chose; the per-block vote bound is O-3.3. Was: Open, experiment scheduled. Sweep (5 October 2026): the block reading is exercised on the fork by harness s3 (block-carried votes give participation; 35 of 35 locked on each of 3 nodes) and s4 (a producer dropping the finality section from 40% of its blocks adds 0 ms to lock latency, 35 locks), bench-log "finality v2 attack harness"; the per-block vote bound and the hostile-aggregator simulation of O-3.3 were run and proposed in round 2 (5 October 2026, night, below; decision at gate 3). Re-run on the `finality-fixes` build under fast time (5 October 2026, 01:13 UTC, `run.mjs s4 --fast-time`, 2 nodes, 223 s): node B locked 14 checkpoints with a 40% vote-dropping producer, median lock latency 1,042 ms against 1,042 ms for the control, 0 ms added. PASS.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Answer: This is a new finding from writing this ledger and it is not in the design doc. The participation factor is "observed certified votes over P divided by expected votes". If "observed" means votes present in certificates carried in blocks, then whoever aggregates and whoever produces blocks can shape it. Candidate fixes: participation computed from all votes seen in blocks (votes as transactions, not only certificates), or a certificate must include every valid vote the aggregator received above a size bound, or participation falls only on checkpoints where the key's vote appears in no certificate and no block. Goes to the cryptographer for phase 1 and to the gate 3 simulation.
|
|
|
|
|
|
|
|
|
|
@ -387,8 +387,8 @@ Evidence: design doc "Proving speed on consumer GPUs" risk item and Finality v2
|
|
|
|
|
### P9. Shard griefing
|
|
|
|
|
"Claim a shard with a small bond and never prove it. Repeat. Finality waits on you."
|
|
|
|
|
|
|
|
|
|
Status: Answered by design, parameter table written from the live numbers (5 October 2026, evening sweep). Was: Answered by design, parameters open. Sweep (5 October 2026): the parameters (O-5.6) are phase 4 devnet work; the economy simulator's lever study found the claim timeout a market parameter and recommends starting the devnet at 120 s (`docs/analysis/economy-2026-10-04.md` section 6).
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 10 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 10): the parameter table's values are the phase 4 devnet's starting values (8 assignees, a 25-s exclusive window, a 120-s job claim timeout, no shard bond, the external job bond set on the devnet); the devnet measurement moves them. Was: Answered by design, parameter table written from the live numbers (5 October 2026, evening sweep). Was: Answered by design, parameters open. Sweep (5 October 2026): the parameters (O-5.6) are phase 4 devnet work; the economy simulator's lever study found the claim timeout a market parameter and recommends starting the devnet at 120 s (`docs/analysis/economy-2026-10-04.md` section 6).
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Sweep (5 October 2026, evening): shards carry no bond (spec 7.2, P13), so shard griefing is a prover sitting on an exclusive window; the only bond is the external job's. The table, from the live devnet at 16:00 UTC (`igneum_getProvingStatus` on the Mac node: 352 shards paid, pool 19 entries, 0 failed, 0 pending, 154 verified; the task's figure of 215 paid was the morning's) and the measured shard times:
|
|
|
|
|
|
|
|
|
|
@ -723,8 +723,8 @@ Evidence: CLAUDE.md rules (privacy rejected). Fix: overclaims list, item 68.
|
|
|
|
|
### L1. It is a security under Howey
|
|
|
|
|
"A founder's company earns a dev fee, runs a pool and a proving business, seeds the DEX, pays 'launch grants', and the roadmap ends in 'exchange listings after'. Expectation of profit from the efforts of others, in writing."
|
|
|
|
|
|
|
|
|
|
Status: Open, counsel not yet engaged. Sweep (5 October 2026): counsel; nothing runnable.
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 6 (5 October 2026, night).
|
|
|
|
|
Status: Open, counsel engaged (6 October 2026, 17:25 UTC, by the owner; decisions item 6, in progress). Was: Open, counsel not yet engaged. Sweep (5 October 2026): counsel; nothing runnable.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
Decision owner (5 October 2026, evening sweep): the project lead, with counsel; nothing runnable here.
|
|
|
|
|
|
|
|
|
|
Answer: There is no sale, no premine, no allocation and no promise of return, and nothing in consensus is controlled by the team and no protocol fee reaches it (the development fund was removed on 3 October 2026), which is the structure that regulators have treated most favourably (approximate: compare the SEC's own framework on sufficiently decentralised networks and MiCA's exemption for tokens created automatically as a reward for maintaining a distributed ledger, approximate quotation). The weak points a lawyer will circle are the ones quoted: founder-run pool and proving business, founder-seeded DEX, launch grants, and the phrase "exchange listings after". None is in consensus; all are promotional. The litepaper must drop the listing sentence and counsel must review the founder-business paragraph before v0.2. The legal entity is "offshore, parked" in the design doc, which is not an answer.
|
|
|
|
|
@ -734,8 +734,8 @@ Evidence: design doc "Legal" paragraph. Fix: overclaims list, items 75 and 76.
|
|
|
|
|
### L2. Financial promotion rules
|
|
|
|
|
"Several jurisdictions now treat a cryptoasset promotion to their consumers as regulated: the UK since October 2023 needs an authorised approver, the EU under MiCA has its own marketing rules, the US has the Howey test. 'The people who show up early get the most' on a domain you own is a promotion wherever the reader sits."
|
|
|
|
|
|
|
|
|
|
Status: Open, counsel not yet engaged (decision owner the project lead, with counsel); text half stated (5 October 2026, night): `site/litepaper.html`, Economics, Supply, "Nearly a quarter of all supply is mined in the first year and half in the first two." with no "so" clause (overclaims 54 and 76, fud-fixes row 6); "Half of all IGN" absent from `site/index.html`. Was: Open, counsel not yet engaged. Sweep (5 October 2026): counsel; nothing runnable.
|
|
|
|
|
Decision owner: the project lead (counsel). Decision request: `docs/plans/ledger-decisions.md`, item 6 (5 October 2026, night).
|
|
|
|
|
Status: Open, counsel engaged (6 October 2026, 17:25 UTC, by the owner; decisions item 6, in progress); the text half is stated below. Was: Open, counsel not yet engaged (decision owner the project lead, with counsel); text half stated (5 October 2026, night): `site/litepaper.html`, Economics, Supply, "Nearly a quarter of all supply is mined in the first year and half in the first two." with no "so" clause (overclaims 54 and 76, fud-fixes row 6); "Half of all IGN" absent from `site/index.html`. Was: Open, counsel not yet engaged. Sweep (5 October 2026): counsel; nothing runnable.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
Decision owner (5 October 2026, evening sweep): the project lead, with counsel; nothing runnable here.
|
|
|
|
|
|
|
|
|
|
Answer: A litepaper describing how to mine a coin that does not exist is arguably not an invitation to engage in investment activity, and the regime has carve-outs for information that is not an inducement (approximate; this needs an opinion from counsel in the jurisdiction the project is established in, which is offshore and not yet named). Sentences that read as inducements to acquire ("show up early get the most", "half of all supply in the first two years") should be rewritten as schedule facts before v0.2. Country-code domains such as igneum.co.uk redirect to igneum.network and carry no separate content.
|
|
|
|
|
@ -745,8 +745,8 @@ Evidence: none. Fix: overclaims list, item 77.
|
|
|
|
|
### L3. GoDaddy domains are a seizure risk
|
|
|
|
|
"Fifteen domains at a US registrar on US nameservers behind a US host. One court order and igneum.network is a parking page."
|
|
|
|
|
|
|
|
|
|
Status: Conceded, mitigation scheduled. Sweep (5 October 2026): a deSEC token now sits in `~/.config/igneum` (mode 600), so the nameserver move of fud-fixes row 44 has started; the registrar move waits for December.
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 7 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 7): the nameserver move to deSEC in one sitting with every domain's Vercel verification checked afterwards; a non-US registrar in December 2026 when the transfer lock ends. Was: Conceded, mitigation scheduled. Sweep (5 October 2026): a deSEC token now sits in `~/.config/igneum` (mode 600), so the nameserver move of fud-fixes row 44 has started; the registrar move waits for December.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
Decision owner (5 October 2026, evening sweep): the project lead, with counsel; nothing runnable here.
|
|
|
|
|
|
|
|
|
|
Answer: True. GoDaddy and Vercel are both US companies and have both complied with takedowns. Mitigations: an ENS or equivalent name and an IPFS mirror of the site and litepaper, the site's content hash published in the repository and in the genesis block, at least one non-US registrar for a second TLD, and the chain itself never depending on any domain (seed nodes are addresses in the client, not DNS only). Phase 5.
|
|
|
|
|
@ -756,8 +756,8 @@ Evidence: CLAUDE.md "Domains". Mitigation: not yet.
|
|
|
|
|
### L4. Paying testnet miners real money is a payment before launch
|
|
|
|
|
"'Testnet miners are paid real money for real proofs from phase five.' That is a business paying contractors in crypto across borders with no entity."
|
|
|
|
|
|
|
|
|
|
Status: Open. Sweep (5 October 2026): counsel and entity; nothing runnable.
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 6 (5 October 2026, night).
|
|
|
|
|
Status: Open, counsel engaged (6 October 2026, 17:25 UTC, by the owner; decisions item 6, in progress). Was: Open. Sweep (5 October 2026): counsel and entity; nothing runnable.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
Decision owner (5 October 2026, evening sweep): the project lead, with counsel; nothing runnable here.
|
|
|
|
|
|
|
|
|
|
Answer: Correct that it needs an entity, terms and tax treatment before it happens. The payments come from the customer rollup on its own chain, not from Igneum, but the arrangement is organised by the project. Counsel before phase 5.
|
|
|
|
|
@ -767,8 +767,8 @@ Evidence: design doc "The first six months".
|
|
|
|
|
### L5. Trademark
|
|
|
|
|
"Igneum. Have you checked EUIPO, USPTO and the UK IPO? There is no evidence you did."
|
|
|
|
|
|
|
|
|
|
Status: Open. Sweep (5 October 2026): a person's search, recorded outside the repository; nothing runnable.
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 6 (5 October 2026, night).
|
|
|
|
|
Status: Open, counsel engaged (6 October 2026, 17:25 UTC, by the owner; decisions item 6, in progress): the clearance search is recorded in the repository as a dated one-line result per register when it returns. Was: Open. Sweep (5 October 2026): a person's search, recorded outside the repository; nothing runnable.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
Decision owner (5 October 2026, evening sweep): the project lead, with counsel; nothing runnable here.
|
|
|
|
|
|
|
|
|
|
Answer: No clearance search is recorded in the repository. One is required before the name is used commercially, in all three registers and in Nice classes 9, 36 and 42, approximate. Until then the name is provisional and the litepaper should not claim otherwise.
|
|
|
|
|
@ -833,8 +833,8 @@ Evidence: litepaper "Roadmap"; design doc "Team".
|
|
|
|
|
### X5. 1,000 independent miners is a Sybil number
|
|
|
|
|
"Your testnet gate is 1,000 independent miners for 30 days. One person with a script is 1,000 miners."
|
|
|
|
|
|
|
|
|
|
Status: Conceded, measurement defined from the vote-key window and today's numbers (5 October 2026, evening sweep); decision owner the project lead (O-X.1). Was: Conceded, measurement to define.
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 3 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 3): the independence definition as written, with the silent-fleet addition (a key with no fingerprint counts as its own class only when its address is in an autonomous system no other key uses); the observer columns on `ledger-observer` (O-X.1) ship with the next cut; measurement scheduled. Was: Conceded, measurement defined from the vote-key window and today's numbers (5 October 2026, evening sweep); decision owner the project lead (O-X.1). Was: Conceded, measurement to define.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Sweep (5 October 2026, evening): the definition, measurable from chain data plus two attestations, and today's reading. Unit: a vote key with at least the dust count of blue blocks in the 30-day weight window (W3), which is the smallest thing the chain can count. Independence: two keys are independent when they differ in all three of (a) the autonomous system of the address their blocks' nodes announce (seed and peer tables, the observer's address field), (b) the machine fingerprint the miner app sends with its log uploads (`machine_id`, already in every STATUS line's run id), and (c) the pool attestation, a signed statement by a pool operator listing the keys it runs (absent for solo keys). N_ind = the number of distinct (ASN, fingerprint, pool) classes among eligible keys; the gate of `site/journey.json` phase 5 reads "N_ind >= 1,000 over the same 30 days with top-10 share of window weight under 50%". Today's reading from the live window (Mac node, `getFinalityWeights` at DAA 112,395): 22 keys, 21 voters above dust (dust 5 on the devnet), total weight 7,196 of 7,200 blue blocks; top-1 share 8.3%, top-3 20.3%, top-5 31.9%, top-10 60.3%; the console counts 5 machines and 21 identities in 10 minutes, so the fleet runs 4.2 keys per machine (the launcher's one key per worker, F17's client default) and N_ind by fingerprint alone is 5, by ASN at most 3 (two home networks and one US household, approximate). That is the Sybil ratio the critic means, measured: 21 "miners" are 5 machines. The hashing concentration of X14 (top-1 12.8%, top-3 34.5% over 8,090 blocks on 4 October) and tonight's weight shares agree within the window's drift. What the observer must add (O-X.1): the ASN per announcing address, the fingerprint per key (the app already has both), and the pool statement format.
|
|
|
|
|
|
|
|
|
|
@ -1272,8 +1272,8 @@ Evidence: the files above. Review id R3.2.
|
|
|
|
|
### F16. A lock can become uncertified after a heal
|
|
|
|
|
"Section 3.5: two certificates at one index, strike the equivocators, re-evaluate, and if neither or both still lock the index is uncertified. So the lock my node reported and I credited on is revocable."
|
|
|
|
|
|
|
|
|
|
Status: Open, the two options priced, one recommended (5 October 2026, evening sweep); decision owner the project lead (gate 3, O-3.17). Was: Open, decision at gate 3 (extends O-3.6). Sweep (5 October 2026): a decision item (O-3.17); nothing runnable.
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 2 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 2): option B, a verified certificate is never withdrawn (spec 3.11.4); the 3.5 paragraph is replaced by 3.11.4's text after `c4-fix` merges, `finality_conflict` and the `finality_active` clear go into the node, the forced double-certificate test of 3.11.7 follows; fix scheduled, consensus engineer. Was: Open, the two options priced, one recommended (5 October 2026, evening sweep); decision owner the project lead (gate 3, O-3.17). Was: Open, decision at gate 3 (extends O-3.6). Sweep (5 October 2026): a decision item (O-3.17); nothing runnable.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Sweep (5 October 2026, evening): the two options, with their measured cost.
|
|
|
|
|
|
|
|
|
|
@ -1296,8 +1296,8 @@ Cross-reference (external review, 3 October 2026, night): what holds during a pa
|
|
|
|
|
### F17. Keys are free and the official client mints eight per card
|
|
|
|
|
"Your launcher runs 8 identities per vendor, each with its own vote key. For the vote that is harmless by design. For shard sortition, which ranks every eligible key and takes 8, it is the whole game: 1% of hashrate holds 259 keys above dust. And a few thousand PCs cross your 8,192-voter switch, whose construction is open."
|
|
|
|
|
|
|
|
|
|
Status: Rule fixed (3 October 2026): spec 7.2 step 2 draws the 8 assignees by weight (blue blocks drawn uniformly from the window, their keys assigned, with the 1-key-versus-1,000-keys test in O-5.1), and spec 3.1 W6 states that keys are free and weight is the only Sybil-resistant quantity. The client's one-key default (O-3.5) and the bitmap size (O-3.12) are proposed in spec 3.4.2 (round 2, 5 October 2026, night, below), decision at gate 3. P8 stays closed. Was: Open, rule change proposed. Reopens P8.
|
|
|
|
|
Decision owner: the project lead (gate 3, the spec 3.4.2 proposals). Decision request: `docs/plans/ledger-decisions.md`, item 13 (6 October 2026, 00:05 UTC).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 13): the client defaults to one vote key per machine, identities share it (spec 3.4.2 item 4); the bitmap bound as item 3. Was: Rule fixed (3 October 2026): spec 7.2 step 2 draws the 8 assignees by weight (blue blocks drawn uniformly from the window, their keys assigned, with the 1-key-versus-1,000-keys test in O-5.1), and spec 3.1 W6 states that keys are free and weight is the only Sybil-resistant quantity. The client's one-key default (O-3.5) and the bitmap size (O-3.12) are proposed in spec 3.4.2 (round 2, 5 October 2026, night, below), decision at gate 3. P8 stays closed. Was: Open, rule change proposed. Reopens P8.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Answer: Correct. Spec 7.2 step 2 ranks per key and eligibility is 100 blue blocks in 30 days (0.004% of hashrate at one block a second), so a miner with share s holds up to s x 2,592,000 / 100 keys and the draw of 8 is dominated by whoever splits most. `proto-cuda/windows-miner/start-mining.ps1` derives a key per identity (`MINERS` default 8). O-5.1's acceptance test (fastest prover under 25% of shards) does not catch a splitter, who wins by count. Fix: draw the 8 assignees by weight (8 blue blocks uniformly from the window, take their keys), so splitting changes nothing; the client defaults to one key per operator; specify S2 (O-3.5) and the bitmap size (O-3.12) before the count can cross 8,192.
|
|
|
|
|
|
|
|
|
|
@ -1459,8 +1459,8 @@ Run (5 October 2026, night): `python3 sim/difficulty/record_report.py devnet-202
|
|
|
|
|
### M22. The ASIC challenge has no scoring rules, and 2x is not the economic line
|
|
|
|
|
"Your bounty says 'beats a GPU by more than 2x'. Per what? Hashes per second, per joule, per dollar, on the average program or the worst hour? A chip at 1.6x with half the capital cost wins. And nobody has published eligible hardware, funding or a judge."
|
|
|
|
|
|
|
|
|
|
Status: Open, decision for the project lead (terms, judge and funding) and experiment scheduled (extends O-1.17). Sweep (5 October 2026): nothing runnable; the terms, judge and funding are the project lead's decision.
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 1 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:35 UTC, by the owner; decisions item 1, corrected): no bounty, so no bounty terms; M22's metrics (hashes per second and per joule per program over at least 100 epochs as a distribution, capital cost per unit of hash rate at a stated volume, the longevity term, the shortcut classes scored separately) become the public benchmark's scoring rules and the brief of the paid cryptanalysis; the optional USD 50,000 cryptanalysis prize, if ever set, is escrowed before it is named. Was: Open, decision for the project lead (terms, judge and funding) and experiment scheduled (extends O-1.17). Sweep (5 October 2026): nothing runnable; the terms, judge and funding are the project lead's decision.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Answer: Correct. M1 and O-1.17 name a bounty for "more than 2x" without a metric, a judge or a fund, and 2x is a design target for the hash, not an economic threshold: a chip at 1.5x per joule and 3x per dollar of capital is an economic ASIC whatever the hash-rate ratio says. The scoring rules go out with the January 2027 benchmark: hashes per second and per joule measured per program over a published set of at least 100 epochs, reported as a distribution (worst decile, median), never as one average; capital cost per unit of hash rate at a stated volume; a longevity term against the instruction-family reserve and the dataset growth of spec 1.13; and the shortcut classes (recomputation, partial storage, weak-program selection) scored separately. Eligible hardware assumptions, the judge, the reward and the payer are the project lead's decisions (fud-fixes row 50: the payer is the entity). The supportable public claim until a design has been scored: across the tested workloads and the stated economic assumptions, consumer GPUs remain competitive against the best independently proposed specialised design. Extends M1, M16 and C13.
|
|
|
|
|
|
|
|
|
|
@ -1500,8 +1500,8 @@ Evidence: `infra/cloud-devnet/results/2026-10-04/partition-sin-20261004-140305/p
|
|
|
|
|
### P16. The proving gate can be passed by shrinking the shard
|
|
|
|
|
"'A mid-range GPU proves a shard in under 20 s.' Your own R2 says: if missed, halve the shard and re-measure. That is the trap. Fix the workload first, measure the whole journey, and have strangers reproduce it."
|
|
|
|
|
|
|
|
|
|
Status: Open, blocked on a 12 GB card (decisions item 12, already pointed: a 3060-class NVIDIA part for PC 2 before the public benchmark): next measurement O-7.1 end to end on that card when it arrives, inside the phase 2 gate (Nov 2026 to Jan 2027 per the litepaper roadmap). Was: Open, experiment scheduled (O-7.1). The journey's phase 2 gate was rewritten the same night. Sweep (5 October 2026): hardware item (the 12 GB card end to end); the standard is written.
|
|
|
|
|
Decision owner: the project lead (a 12 GB card for the end-to-end run). Decision request: `docs/plans/ledger-decisions.md`, item 12 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 12): a 12 GB NVIDIA card (4070) is on order for PC 2; O-7.1 runs end to end on it when it arrives, inside the phase 2 gate. Was: Open, blocked on a 12 GB card (decisions item 12, already pointed: a 3060-class NVIDIA part for PC 2 before the public benchmark): next measurement O-7.1 end to end on that card when it arrives, inside the phase 2 gate (Nov 2026 to Jan 2027 per the litepaper roadmap). Was: Open, experiment scheduled (O-7.1). The journey's phase 2 gate was rewritten the same night. Sweep (5 October 2026): hardware item (the 12 GB card end to end); the standard is written.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Answer: Correct. P1 conceded that the 20-s figure is a target; this is about how the target is tested. `docs/design/execution-layer.md` 9.1 R2 passes at any shard size by halving `S_p` until the time fits, so a pass says nothing about throughput, and R4 measures the wrapper only. The phase 2 benchmark now has an acceptance standard: a fixed published workload (real transactions, never empty blocks or tiny shards) with its shard plan, proven end to end from job received to proof accepted, including queueing, transfers, aggregation, verification and payment; the median and the slowest 5% and 1%; failure and retry rates; full cost (electricity, host, bandwidth, aggregation, failed work, hardware); results per advertised card with mining and proving compatibility stated separately; sustained with no growing backlog; reproduced by at least three unrelated operators from the published code and configuration. A halved shard is a new declared workload, never a pass. The reviewer's figure for SP1's cluster requirement (NVIDIA, 24 GB, approximate; not checked, SP1 is not in `vendor/`) is why a 12 GB card has to show the whole pipeline, which R2 and R4 already target.
|
|
|
|
|
|
|
|
|
|
@ -1545,8 +1545,8 @@ Evidence: spec 2.5, 5.1 to 5.4; `docs/commercial/prover-customer-brief.md`; P10,
|
|
|
|
|
### E14. No funding table
|
|
|
|
|
"Who pays for development, the independent review, the infrastructure and an incident response, from what, and what happens if revenue is late? You have no fund by design, which means you have no table either."
|
|
|
|
|
|
|
|
|
|
Status: Open, with a placeholder table: `docs/plans/funding.md` (3 October 2026, marked PLACEHOLDER on 4 October) lists the sources (the founder's own means today, the 1% client fee, the team's own mining and proving, no protocol fee) and the cost lines; the project lead parked funding on 4 October 2026 and the decision stays his. Was: Open, decision for the project lead.
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 4 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 4): the funding table stays internal until counsel has read it; one public sentence in the litepaper names the unfunded lines (the second client, the external reviewers, the bounty before escrow). Was: Open, with a placeholder table: `docs/plans/funding.md` (3 October 2026, marked PLACEHOLDER on 4 October) lists the sources (the founder's own means today, the 1% client fee, the team's own mining and proving, no protocol fee) and the cost lines; the project lead parked funding on 4 October 2026 and the decision stays his. Was: Open, decision for the project lead.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Answer: Correct. The fund was removed on purpose (E4) and the team earns from the 1% client fee, its pool, its provers and the app share (E5); none of that is costed, and the second client has no funder (fud-fixes row 47), nor do the external reviewers (G1), the bounty (M22), the seed nodes or the public infrastructure. The table: each cost line (development, independent review, infrastructure, incident response, the bounty, the second client) against its source (the entity's own money, the client fee, the proving business, a grant mechanism added by signalling), labelled funded, dependent on future revenue, or unfunded, with the consequence if revenue is late. It assumes a flat IGN price, which is E15's test. The table is internal until counsel has read it (L1, L2); the litepaper states which lines are unfunded.
|
|
|
|
|
|
|
|
|
|
@ -1573,8 +1573,8 @@ Evidence: X1; `docs/fud-fixes.md` section 5. Decision: the project lead. Review:
|
|
|
|
|
### X13. One paying customer for a stated reason
|
|
|
|
|
"'One rollup signs for testnet' is a letter of intent with no money. A customer who pays once, pays again without a rebate, and then a second unrelated customer, is evidence. A signature is not."
|
|
|
|
|
|
|
|
|
|
Status: Open, experiment scheduled (the pilot itself), decision for the project lead on timing and terms; extends L4 and the customer brief. Sweep (5 October 2026): a decision and a customer; nothing runnable.
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 5 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 5): the paid pilot stays in phase 5, the phase 4 gate stays the signature, nothing moves earlier before counsel answers L4. Was: Open, experiment scheduled (the pilot itself), decision for the project lead on timing and terms; extends L4 and the customer brief. Sweep (5 October 2026): a decision and a customer; nothing runnable.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Answer: Correct. The phase 4 gate is a signature and the brief says so ("a signed letter of intent with no payment"). The progression is adopted and the brief carries it at its next version: agree the workload, proof format, deadline, failure rate and price before the pilot; publish the outcome and the customer's own reason for buying; then repeat purchases without reimbursement; then several unrelated customers. The reviewer places the paid pilot before public testnet; the journey has it in phase 5. Phase 4 keeps the signature as its gate and phase 5's line gains the paid pilot; moving it earlier is the project lead's call and needs the entity, terms and tax treatment of L4 first.
|
|
|
|
|
|
|
|
|
|
@ -1584,6 +1584,7 @@ Evidence: `site/journey.json` phases 4 and 5; `docs/commercial/prover-customer-b
|
|
|
|
|
"Define independent for the 1,000-miner gate, then report concentration in hashing, checkpoint signing, proving and aggregation, because a thousand miners behind two pools is two."
|
|
|
|
|
|
|
|
|
|
Status: Answered with evidence for all four (5 October 2026, night, ledger close round 2: signing concentration read from the certificates and votes the chain blocks carry in their coinbase finality section, top-1 10.0%, top-3 29.1%, top-10 77.3% of signed weight over the heaviest certificate at each of 126 indices in the window; bench-log "5 October 2026 (night), ledger close round 2: X14 signing concentration from block payloads"); the independence definition stays the project lead's (X5). Was: Answered with evidence for hashing, aggregation and proving, Open for signing (5 October 2026, night, ledger close round 1: no RPC exposes a certificate's signer set, so the signing concentration needs the observer extract of O-X.1; bench-log "5 October 2026 (night), ledger close round 1: X14 concentration in hashing, signing, proving and aggregation from the Mac node's RPCs, and E16 one live block"); the independence definition stays the project lead's (X5). Was: Open, measurement scheduled (O-X.1); extends X5. Sweep (5 October 2026): hashing concentration computed from the devnet record (`sim/difficulty/records/live-2026-10-04.csv`, 8,090 blocks, 18 vote keys): top-1 12.8%, top-3 34.5%, top-9 98.0%, the nine being devnet v4's nine identities run by three machines (approximate), so by machine the devnet is three parties. Signing, proving and aggregation concentration need certificate and proof-record extracts the observer does not keep yet (O-X.1).
|
|
|
|
|
Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 3): the independence definition and the four concentration reports as X5 states; the observer columns ship with the next cut.
|
|
|
|
|
|
|
|
|
|
Answer: Correct. X5 conceded that "independent" needs a measurable definition (distinct ASNs, benchmark hardware fingerprints, pool attestations) and left it to phase 4. The four concentrations can each be computed from chain data: blue blocks per vote key and per pool (hashing), signed weight per key in certificates (checkpoint signing), proof records per prover key (proving, once P12's fix puts the key in the statement), and certificates and proof records per aggregator key (aggregation). The gate reports all four as top-1, top-3 and top-10 shares over 30 days, beside the independence count, on the live page. Transaction choice inside pools is a separate measurement and is already scheduled: whether members of the reference pool use declared templates (spec 9.4.2, mode C) is recorded under O-9.5.
|
|
|
|
|
|
|
|
|
|
@ -1669,8 +1670,8 @@ Evidence: `docs/bench-log.md`, 4 October 2026 "difficulty rule: timestamp attack
|
|
|
|
|
### P21. The SP1 proof is not what consensus checks in proving v0
|
|
|
|
|
"Your proof records pay provers, and the node pays a record whose statement matches its own execution whether or not the SP1 proof behind it verifies. A prover can sign the native statement without proving anything."
|
|
|
|
|
|
|
|
|
|
Status: Open, stated in spec 7.7 item 4 (4 October 2026). Branch `proving` of the fork, `igneum/exec/src/proving.rs`. Sweep (5 October 2026): stated; the in-consensus verifier is a build item (execution engineer).
|
|
|
|
|
Decision owner: the project lead. Decision request: `docs/plans/ledger-decisions.md`, item 11 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 11): proving v0 (every producer verifies off the consensus path) through the public testnet; the in-consensus verifier is the execution engineer's plan item for after it; the litepaper sentence labelled Open stands. Was: Open, stated in spec 7.7 item 4 (4 October 2026). Branch `proving` of the fork, `igneum/exec/src/proving.rs`. Sweep (5 October 2026): stated; the in-consensus verifier is a build item (execution engineer).
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Answer: Correct for v0, and by design for now. The consensus check on a carried record is the native-execution veto (spec 7.2 item 5): the statement must equal the node's own 328-byte shard statement for that shard and payout address, so no record can move state or pay for a wrong claim. The SP1 proof is verified off the consensus path by the proof pool's verifier (`igneum-prove-host --mode verify`), and a producer offers only verified records to its templates; a producer that includes unverified records (trust mode, test networks only) can pay a prover who did not prove. The damage is bounded to that prover's payout. What closes it: the aggregated segment record of design 5.4 verified in consensus, which needs the SP1 verifier inside the node (the SDK dependency the node does not carry today) or a bounded in-consensus verification budget. Until then the devnet runs v0 with every producer verifying.
|
|
|
|
|
|
|
|
|
|
@ -1871,8 +1872,8 @@ Fix (5 October 2026, night): the chain already on master was read end to end and
|
|
|
|
|
### G14. Secrets and identity in the history of a repository with a public date
|
|
|
|
|
"The intake key is in six files across eight commits, the dl token in one, the review and ledger files are tracked, 51 tracked files carry the founder's first name, and every commit today is stamped with the local-time offset. The 3 October sweep said zero hits."
|
|
|
|
|
|
|
|
|
|
Status: Fixed on a branch, pending merge (5 October 2026, night), the tooling part: ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Decision owner: the project lead for the rewrite date (`docs/plans/ledger-decisions.md`). Was: Open (4 October 2026); extends `docs/fud-fixes.md` section 5.
|
|
|
|
|
Decision owner: the project lead (the rewrite date). Decision request: `docs/plans/ledger-decisions.md`, item 8 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 8): the history rewrite runs the morning after the last of the close's branches merges, with every worktree removed first and both secrets rotated regardless. Was: Fixed on a branch, pending merge (5 October 2026, night), the tooling part: ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Decision owner: the project lead for the rewrite date (`docs/plans/ledger-decisions.md`). Was: Open (4 October 2026); extends `docs/fud-fixes.md` section 5.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Answer: Correct, count-only. The key: `packaging/mac/packaged-config.sh`, `infra/gpu-bench/upload.sh`, `proving/windows-wsl2/prove-block.sh`, `prove-shard.sh`, `proto-cuda/windows-miner/upload-log.bat`, `proto-cuda/windows-app/upload-log.bat`, commits `78df757` to `4c9810f`. The token: `docs/plans/morning-2026-10-04.md:49`, commit `c47ff03`. `git check-ignore` returns nothing for the ledger, fixes and review files. The CI identity grep covers the public export list, by design. Fix: both secrets join section 5 step 4's rewrite list (and are rotated regardless); `TZ=UTC` in the commit path now. Review ids R4.4.8, R4.5.3, R4.5.4.
|
|
|
|
|
|
|
|
|
|
@ -2111,8 +2112,8 @@ Evidence: `docs/design/miner-dev-fee.md`; the unit tests in `igneum/miner/src/ma
|
|
|
|
|
### X29. Host and file hygiene, minor
|
|
|
|
|
"The Mac's live node binds its gRPC to every interface. Four secrets or pointers in `~/.config/igneum` are world-readable, one token is a filename, and the intake key rides on `curl`'s command line. The manifest answers CORS `*` and the clock source is a cacheable page's Date header."
|
|
|
|
|
|
|
|
|
|
Status: Fixed on a branch, pending merge (5 October 2026, night), the curl part: ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Open: the live node's `--rpclisten` (decision, operator, group E) and the app's clock source (round 2). Was: Open, minor (4 October 2026). Sweep (5 October 2026): read-only checks on this Mac: every secret under `~/.config/igneum` is now mode 600 (only `ota-signing-key.pub` is world-readable, as it should be), so that half is fixed; the live node still listens on every interface (`lsof`: `igneumd` on `*:26610`). The `curl` command line and the clock source were not re-checked.
|
|
|
|
|
Decision owner: the project lead (the live node's RPC bind at its next restart). Decision request: `docs/plans/ledger-decisions.md`, item 9 (5 October 2026, night).
|
|
|
|
|
Status: Decided (6 October 2026, 17:25 UTC, by the owner; decisions item 9): node 1 binds its RPC to localhost at its next planned restart, and the wallet's node too; PC 2 on its own node or a tunnel. Was: Fixed on a branch, pending merge (5 October 2026, night), the curl part: ledger-relay 28c028b, tests 47 of 47 (relay, 6 suites) + 16 of 16 (packaging/windows/test-inputs-signing.sh) + 2 CI class checks. Open: the live node's `--rpclisten` (decision, operator, group E) and the app's clock source (round 2). Was: Open, minor (4 October 2026). Sweep (5 October 2026): read-only checks on this Mac: every secret under `~/.config/igneum` is now mode 600 (only `ota-signing-key.pub` is world-readable, as it should be), so that half is fixed; the live node still listens on every interface (`lsof`: `igneumd` on `*:26610`). The `curl` command line and the clock source were not re-checked.
|
|
|
|
|
Decision owner: the project lead, decided 6 October 2026 (`docs/plans/ledger-decisions.md`, outcomes section).
|
|
|
|
|
|
|
|
|
|
Answer: Correct. `--rpclisten=0.0.0.0:26610` on pid 33114 (no `--unsafe-rpc`, `--disable-upnp`); `ls -la ~/.config/igneum`; `app/igneum-app/src/update.rs` (`https_time`, `upload_log`); the dl host's headers. Vercel rewrote `Date` to now on a cache hit today, so the cached-Date failure did not show. Fix: RPC on loopback with PC 2 on a tunnel or its own node; `chmod 600`; the stray file removed; the key passed to `curl` through `-K` or a header file; an uncacheable path for the clock source. Review ids R4.5.5 to R4.5.7.
|
|
|
|
|
|
|
|
|
|
@ -2193,3 +2194,20 @@ Same rule as the count above. 167 entries (P23 added by round 2).
|
|
|
|
|
| Open, found tonight, fix in round 3 | 1 | P23 |
|
|
|
|
|
| Another agent's tonight | 1 | C4 |
|
|
|
|
|
|
|
|
|
|
## Count by status, 6 October 2026 (17:30 UTC, round 3 merged and the owner's decisions applied)
|
|
|
|
|
|
|
|
|
|
Same rule as the counts above. 167 entries.
|
|
|
|
|
|
|
|
|
|
| Bucket | Count | Entries |
|
|
|
|
|
|---|---|---|
|
|
|
|
|
| Fixed, rolled out, rule written, or designed | 57 | the 56 of the 00:10 count plus P23 (the pool reorg hook on `ledger-fixes-0311` fbb0082a); every fork item now sits on `ledger-fixes-0311`, rebased onto the 0.3.11 fork tip 89dfcb95 |
|
|
|
|
|
| Conceded, stated, or terminal | 52 | unchanged |
|
|
|
|
|
| Answered by design or with evidence | 28 | the 26 above plus M16 (the inline-cache kernel on PC 2's RTX 5090: inside the L2 at 64 MiB the recompute route runs at 0.256x of the honest rate, 5.1x worse per joule) and E17 (the 5090 draw lines: 132.2 Mhash/s at 326.6 W median, 0.40 Mhash/J) |
|
|
|
|
|
| Decided or closed by rule | 29 | the 12 above plus the owner's decisions of 6 October 2026, 17:25 UTC: M1 M22 F16 X5 E14 X13 L3 G14 X29 P9 P21 M8 M11 P16 F3 F17 (F3 and F17 already counted; X14 carries the decision line beside its Answered status) |
|
|
|
|
|
| Open, counsel engaged (in progress) | 4 | L1 L2 L4 L5 |
|
|
|
|
|
| Open, blocked on a later phase, blocker and next date in the Status line | 3 | P3 (phase 2 wrapper) X15 (public testnet) P22 (phase 2 consensus proof) |
|
|
|
|
|
| Conceded, scheduled | 1 | D5 |
|
|
|
|
|
| Another agent's | 1 | C4 |
|
|
|
|
|
|
|
|
|
|
The bucket "Decided or closed by rule" counts each entry once: M8, M11 and P16 move there from Answered, so Answered is 28 less those three plus M16 and E17, as the table states; the sum of the rows is 167 with M8, M11, P16 and F3, F17 counted in Decided only.
|
|
|
|
|
|
|
|
|
|
|
igneum-labs