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

morning summary: the segment rule is a consensus switch; 0.3.12 carries the node

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-06 08:36:28 +00:00
parent aee2ce9cbc
commit b9da053b7e
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
docs/plans/morning-2026-10-06.md
View file

@ -22,11 +22,11 @@ Everything on the overnight list landed. The one thing that could have gone wron
| PC 1 | Back on 0.3.11 at 07:00, 5090 and 9070 XT mining; integrated card off. The update needed your click because the app's hourly rollout slot had not come; fixed as a catch-up rule (`update-catchup` 2207cd7, 0.3.12) |
| Mac | Mining paused through the app (persists); its node runs |
| Chain | 19 miner ids, 225 MH/s on the two PCs |
| Zero proven segments | Solved prover-side: the prover claims a whole segment and proves its 8 blocks in order. Measured on PC 2 beside the miner: one segment every 210 s, 8 of 8 shard records accepted, 585 blocks of margin. The segment RECORD is still refused by the chain's rule; the proving agent's report says whether that is a node rule (0.3.12) or a consensus one (two-manifest publish) |
| Zero proven segments | Solved: the prover claims a whole segment and proves its 8 blocks in order (9 segments in 30 minutes on PC 2 beside the miner, 72 of 72 shard records paid, 11 percent hash cost). The segment record itself needs a consensus switch on the node fork (`proving_v1_fresh_rule_daa`), folded into 0.3.12 |
| Ember Tune re-run on PC 1 | Failed at 07:56 with no rows: the playbook wrote the test engine's settings with a byte-order mark, the engine parsed defaults, sat idle 35 minutes. Nothing was set on either card; the app restored its miners by itself. Fixed (8273494, watchdog 1e9550e, CI check). Re-run `ember-tune-pc1-3` needs one more click when you are back |
| GPU list order | Cards ordered by performance, integrated last (`card-order` ffb2bfa, 0.3.12) |
| Counter ASIC 3.0 | Running, all seven items plus a new item 8. See below |
| 0.3.12 | Being prepared, app only, stops at the publish gate for your go |
| 0.3.12 | Being prepared: the app items plus the node fork with the segment switch; stops at the publish gate for your go |
## Counter ASIC 3.0 so far
@ -50,8 +50,8 @@ Other items: item 2 (per-day random derivation) works bit-exact at no hash cost
The full list with recommendations is in `consequences-decisions.md` (14) and the 3.0 status file. The ones that bite first:
1. **The public claim "under 2x".** True of the recompute chip per chip, false of the stored-dataset chip per joule. Two re-wordings are drafted in the 3.0 status file; nothing on the site changed. Pick one before any public push.
2. **The segment rule.** If the refused segment record is a consensus rule, it is a two-manifest publish at tip + 14,400; if node-side, 0.3.12 carries it.
3. **0.3.12 go.** App only: the state-reply fix, the update catch-up, the card order, Ember Tune and its guards. No prompt on any machine.
2. **The segment rule.** Answered at 08:50: it is a consensus rule (as shipped a fresh segment record is valid for an 8-second window). The fix is on the node fork behind a new switch `proving_v1_fresh_rule_daa`, so 0.3.12 carries the node and goes out as a two-manifest publish with the switch at tip + 14,400. Measured on PC 2 beside the miner: 9 whole segments in 30 minutes, 72 of 72 shard records paid, 11 percent of hash rate.
3. **0.3.12 go.** The state-reply fix, the update catch-up, the card order, Ember Tune and its guards, plus the node fork with the segment switch (two-manifest publish, switch at tip + 14,400). No prompt on any machine.
4. **The 12 GB card.** Into PC 2 when it lands (PC 1 has no prover toolchain); the playbook is written.
5. **Cryptanalysis budget** (D11 and item 3), **growth mapping (b)** (D4), **a release-tag convention**, **the bounty only once escrowed**.