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

Merge remote-tracking branch 'build/master' into ca3-coord

Browse source
This commit is contained in:
igneum-labs 2026-10-07 20:30:55 +00:00
commit 42fd7c9bc5
1 changed files with 8 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
docs/plans/release-0.3.22.md
View file

@ -104,3 +104,11 @@ Three commits on 96161037: bd710a36 the sub-version 3 re-pin (byte 7, igneum-pow
**PC 2 tonight:** the take-4 0.3.21 installer (mingw host, run-20261007-175020) was picked up at 18:51:57 BST before its removal deployed and the runner's abort ended the install in its first second (the build-server lane's fault, two rules added to the job tooling: an installs-app job is never removable without --force; never remove a published job without reading the machine's latest line); the update-return lane re-ran the kept installer at 19:07:56 BST and the 0.3.21 engine then restarted four times a minute apart and died ("quit requested by the window host went away (stdin closed)" 3 s after the node start: an engine started by a parent whose stdin closes at once); the founder reinstalled PC 2 by hand with the public 0.3.20 installer (45b2f3fb, the MSVC host; the public alias confirmed as that file by hash at 19:12:54 BST). PC 2 is read-only for every lane until its app uploads as 0.3.20; then the 0.3.22 installer job (--installs-app) and the smoke, one job at a time; then the Intel lane's driver retry with the minidump copy folded in (one UAC click). PC 1: released to the Counter lane's queue at 19:04:37 BST (the 0.3.21 MSVC host e223db18 built there in 9 s, collected by the relay Blob); one slot for the 0.3.22 host (app/windows/version.h moved to 0.3.22, host.cpp untouched).
## 10. The chain id finding, the proven share, the pool hour (20:5x to 21:0x BST)
**Chain id, a fact for the record (main's ruling 21:0x BST, corrected by the node lane 21:1x):** eth_chainId answers 0x116f (4463) on both the live shared devnet and Devnet 3 (the fleet's read at 20:59 BST while closing the steward's MINER_KEY item), so from Devnet 3's first block at 18:06 BST until the class v5 floor's crossing (the 0.3.24 object, about 01:00 BST on 8 October at the estimate) a signed transaction replays across the two chains by the chain id alone (the networks refuse each other at p2p; a raw transaction carried by hand to the other chain's RPC is accepted). Nothing of value sits on either chain. The first form ("existing transactions judged by the id they carried at acceptance, new ones at 4464") does not hold: body validation checks every EVM transaction of every block against one fixed id and the executor runs each recorded transaction under one env id, on history as on new blocks, so a 0.3.24 node at a flat 4464 would refuse every past Devnet 3 block carrying a 4463 transaction and re-execution would move the state root. The form that lands in the v5 object commit: on a suffixed devnet the chain id is a function of the block's DAA score, 4463 below program_class_v5_activation_daa and 4464 from the floor on, for validation, execution and CHAINID; the mempool and templates take the id valid at the tip (so until the floor a new transaction still carries 4463), eth_chainId answers the executed tip's; one digest move at the crossing the v5 object already makes. Rule from tonight, a gate check: every network object names a chain id no other object carries (mainnet 4461, the testnet 4462, the shared devnet 4463, Devnet 3 4464, a suffix N devnet 4461 + N; the simnet keeps 4463 as the devnet's tooling twin), a test over every Params table, known-failed first on tonight's duplicate.
**The steward's two items before the public repository opens, both closed:** tools/exec-attacks/lib/common.mjs MINER_KEY is the public Anvil/Hardhat default account 1 key (five harnesses use it; balance 0 and nonce 0 on both chains at 20:55 and 20:59 BST; the fix is a chain-id guard in the five harnesses and a README line, a 0.3.24 steward row); app/igneum-wallet/src/hd.rs's KEY in one history commit is the public Hardhat default account 0 key in a removed test.
**Proven share, the second hour (20:59 BST):** cumulative 0.468 (1,848 of 3,952 shards since DAA 0); the hour's own segments 0.84 (1,094 of 1,304), the shortfall mostly the 34a2dbaa sweep's one-minute node restart per prover; eleven provers (five 3060s at about 85 s a segment, two 3090s, three 4090s, one A5000), a twelfth starting; the next hour's own segments should read one and the founder's 24 hours count from the first that does. **The pool hour** counts from 20:33:28 BST (dn3-pool-b's first OPEN SHARE on the 017e7037 daemons a357c581; WRONG HASH 0 since), the pool split's condition.