Source: the scratch engine's own log in collect ember-c35-collect-1 (06:59Z): 22:31:02Z '0.3.10 is available: downloading',
22:31:05Z 'update: starting the installer first ... ota-apply.ps1', and the installed app's 'quit:' at 22:31:06Z.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
the project lead watched the 9070 XT at 90% usage with its fans barely turning and the app could not say what it drew: the
draw, temperature and MH per watt line came from nvidia-smi only, and the earlier per-watt figure used the board
rating. proto-opencl/gpu-telemetry.c prints one line per AMD card per sample (bus from SetupAPI by the display
device's name, kind, name, watts, temp_c, fan_rpm, fan_pct, mclk_mhz, gclk_mhz, util_pct, source), built by
build-windows.sh against vendor/adlx (the SDK clone), shipped by make-payload.sh and push-inputs.sh. The engine
runs it with -l 5 beside nvidia-smi (Source::AmdTelemetry, tick_amd_telemetry), parse_amd_telemetry fills
power_w, temp_gpu, fan_pct, fan_rpm, mclk_mhz, util_pct and telemetry_at on the AMD card matched by kind and
ordinal, so eff_mhw and the dashboard's existing line show it; app.js shows fan and memory clock when present.
Tests: three on the parser with lines captured on PC 1 and the Mac fixture; the sysfs path ran on a fixture tree.
Measured over 20:27:45 to 20:29:41 UTC with both cards mining (docs/bench-log.md, under the 9070 XT ceiling table):
9070 XT 198.9 W (193 to 212), 64 C, 657 rpm, 2,505 MHz memory, 3,290 MHz shader, 100% busy, 17.73 MH/s =
0.089 MH/W; RTX 5090 307.6 W, 69 C, 44% fan, 122.30 MH/s = 0.398 MH/W.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
igneum-prove-core carries the node's fees.rs (PgasTable, FeeParams PROTOTYPE and CALIBRATED_V1,
FeeSchedule::at); the shard input and every fixture carry the schedule and the block's DAA score; the executor
reads the set at that score, raises the base fees to its floors and meters with its intrinsic, B_p and modexp
entry, as the node's execute_segment does. The 328-byte statement is unchanged: the node's native veto pins the
schedule (a new layout would be a consensus change for every node). Exporter: schedule and daaScore from the
dump (gen.mjs writes them), per-segment switch on replay, S_p from the set. Fixtures from one simnet chain across
the switch at DAA 800: fees-switch-prototype (block 51), fees-v1-shards2 (351), fees-v1-shards3 (355); 358
segments replayed, every state root the node's. Host tests on both sides. Guest re-pinned: shard
0x2b1a81cb..., aggregator 0x474678f3...; pinned-guests-check passes.
Node fork 2b6d23ef unchanged (igneum-exec tests 11 passed). Digest for the override with
fees_v1_activation_daa 210000: ab8847da538dead1dc10e046dfaadab3c1c35928e3748810c4e050d4a886087a.
Runbook docs/plans/fee-switch-devnet.md; infra/devnet/restart-hand-nodes.sh and restart-seed.sh take the
override object (the hand nodes and the seed run 20139145 today and must move to 2b6d23ef first). One line on
the live page, spec 5.11, the testnet README, the floor analysis, the bench log and the journey.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
tools/txgen/run.mjs funds generated wallets from the devnet dev-fee key and sends transfers at a steady rate through
one node (nonce tracking from the pool's pending nonce, two-strike drop verdict, pool back-pressure counted as
deferred, spend cap, clean stop, summary JSON); tools/txgen/proving-watch.mjs watches the proving layer and builds the
per-block report. Two runs through the Mac node: 2,275 sent at 2/s, 2,161 included at 1.86/s (run 1), 1,650 sent,
1,633 included at 1.71/s with no failure (run 2, fixed code). Block 72704 shard 0 (29 transfers, 5,800 pgas) proven on
PC 2 in 34 s, verified on the Mac in 0.297 s, paid 1.7623 IGN.
Block 72803 (seven skipped copies, no executed transaction) failed the native-execution veto: the exporter rebuilt the
including blocks from an export that names no block, position or skipped copy's miner, sorting skipped copies out
of their block, merging consecutive blocks of one miner, dropping empty blocks (the node counts them in the link's
block index) and guessing the zero address. blocks_of now rebuilds from the 0.3.9 export's "blocks", "block" and
"position" fields (the fork change on vendor/igneum-node-txgen branch txgen-export), keeps an old export in its
order and refuses a skipped-only block without a miner. Fixtures block-72803-skipped-copies and
block-72854-empty-block-first with the node's shard plan beside each; the fixture test now checks the cut's links,
roots, gas, pgas and counts against the node's plan (shown failing on the old 72854 cut). No change under core/.
Bench-log entry and evidence rows 15 and 21.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
On 5 October 2026 the Mac's host (shard program id 0x0559759b...) rejected every
proof from PC 2's host (0x05db1aca...). Both were built from the same guest
sources: host/build.rs compiled the guests on each machine and the ELF depends
on where it is built (cargo's -C metadata for a path crate includes the checkout
path; a worktree on the same Mac gave a third id, 0x0dfade07...). The node's
verifier also spent 114 s to 138 s per proof in the prover client and both key
setups before a 0.1 s to 0.4 s verify.
- elf/: both guest ELFs, their verifying keys and manifest.json (sha256, ids);
host/src/pinned.rs embeds and checks them at every start; the prove modes
refuse when SP1's setup does not derive the manifest's id
- --mode verify: LightProver with the pinned key, no prover client, no key
setup; prints the proof's own program id next to ours ("IS NOT OURS")
- --mode id; igneum-prove-pin and pin-guests.sh to re-pin; build.rs builds a
guest only under IGNEUM_BUILD_GUESTS=1
- tools/ci/pinned-guests-check.sh: elf/ must match its manifest, no script
builds a guest outside pin-guests.sh; make-package.sh and build-dmg.sh print
the pinned ids
- unit tests on the pinned set; bench-log entry with the three ids, the cause
and the timing: 127.0 s wall per verify before, 1.8 s to 2.4 s after
- rollout order in proving/README.md: every prover and verifier moves together
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The fact: PC 2's exporter failed blocks 58,752 to 58,843 (and the task's 58,584 to 58,984) at
shard.rs:175, "shard 0 post-root from the witness", while three empty shards were later proven, verified and
paid. Every failing block is empty: one blue block, one reward, the pool credit, no transactions, no payouts
(igneum_exportSegments 0x0..0xe738 from the Mac node, fork 2b6d23ef). The proven block 59,507 has the same
shape and the same miner as the failing 58,927. So the difference is not block content.
The rule that differed: the planner's post-root of an empty segment. The exporter on PC 2 was a stale build
whose core predated commit d6d6153 (the assertion sits at line 175 there and at 179 since). That planner
returned root_at(end) for a segment with no transactions, which is the pre-root; the statement applied the
rewards and the pool credit, as the node does (vendor/igneum-node-036/igneum/exec/src/executor.rs,
execute_segment) and as spec 7.7 item 8 says. Left = the root after the rewards (the node's), right = the root
before them; PC 2's export log for 58,752 shows exactly that pair. Reproduced here: master's core with that one
rule put back fires the same assertion on 58,927 with left 0x7886b9cf (the node's root) and right 0xea9db302
(the pre-root). Master's core as it is reproduces 58,927 and 59,192 with the node's roots, the host's native
mode matches the fixture, and the SP1 executor runs shard 0 to post-root 0x7886b9cf.
So the prover core needs no rule change: the fix is commit d6d6153, which PC 2 received with the 10:49 and
10:52 UTC rebuilds (job-rebuild-prover-pc2-037 and 037b), after which its proofs were paid. What this commit
adds is the regression and the guard for the class:
- proving/fixtures/block-58927-empty-reward.json: the failing shape cut from the devnet (33 KB).
- proving/igneum-prove/export/tests/fixtures.rs: every fixture in proving/fixtures reproduces (block
statement, plan, every shard statement from its witness, the chain of roots and links), and the empty
segment's shard ends at the root after the rewards, never the pre-root. With the pre-d6d6153 rule put back
the test fails. The test lives in the export crate so the core's manifest, part of the guest build, stays
untouched.
- export/build.rs and host/build.rs stamp each binary with a hash of the native sources it was built from,
printed on the first line of every run, so a stale build names itself in the log instead of in a line
number (the stale-build class of 4 and 5 October).
- docs/bench-log.md: the row under the first paid proofs.
The guest is unchanged: built in one directory, this branch and master give byte-identical loadable segments
for the shard program and the aggregator, so no prover needs a rebuild for this commit. Noted on the way and
left open: the same sources built in three directories on this Mac gave two different guest ELFs, so the
program id is not yet a pure function of the sources on a native build.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
s8-steady.mjs: two nodes, one honest vmine miner at 1 block/s, no flood,
RSS and cache-build count every 60 s, vmmap -summary at 0, 500, 1,000 and
1,500 blocks. Both builds ran 1,500 blocks on the 60x profile: before
41 to 1,342 MB by 514 blocks (9 cache builds, five 256 MiB chunks resident:
KEEP 4 plus one evicted chunk the allocator keeps) then flat, 27 builds in
1,529 blocks; after 319 MB at 510 blocks (1 build), 589 at 1,029 (the second
day's cache, by design), 603 at 1,526, 2 builds. Residual 30 MB per 1,000
blocks on both builds, read as the consensus database and caches filling,
not the PoW cache. JSON and vmmap files under
docs/benchmarks/memory-floods-2026-10-04/.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
s6 +6/+3/+1 MB per load, s7 302 to 318 MB, 0 cache builds, epochs 0 to 3
rolled, 202 blocks accepted; the pass-1 column stays beside it. Result JSON
after-{s6-exhaustion,s7-flood}.json added. The s6 one-instant sink check is
noted as a harness flake.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
tools/harness: IGNEUM_HARNESS_BASE_PORT and IGNEUM_HARNESS_TMP move the test
network's ports and data directory so two agents can run it at once; the u64
sentinel round-trip in overrideParams is fixed with the BigInt reviver from
tools/finality-attacks (ledger F25); s6 records rss_start, rss_delta and
cache_builds per load and reports per-load growth (the old row subtracted one
baseline taken before all three loads, which is how the mempool flood was
read as +270 MB); s7 counts "PoW cache built" lines beside every RSS sample;
--live-only skips the s7 simulator part.
docs/bench-log.md: the 4 October 2026 (night) entry: the floods' growth was
one 256 MiB PoW cache per epoch roll (the engine kept a cache per (epoch,
day) pair, KEEP 4), measured before and after the fork fix (fork branch
fud-memory, 796f758d): submit load +263/+257 MB with 1/1 builds before,
+9/+2 MB with 0/0 after; block flood 302 to 1,085 MB with 3/3 builds before,
300 to 315 MB with 0/0 after. Result JSON under
docs/benchmarks/memory-floods-2026-10-04/.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
9 fee blocks in the 785 blocks of the two fee-paying miners (1.15%, expected 1 in 100 templates), the miners' fee
counters equal the chain's count on both nodes, the control miner at --dev-fee 0 paid nothing.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Conflicts resolved keeping both: engine.rs carries the sweep state (miner-eff) and the node watchdog (reliability);
the STATUS line goes through watchdog::parse_status and still feeds the sweep's rate sample; main.rs declares both
modules; bench-log.md keeps both entries. site/build.mjs keeps master's partial-injected pages and adds the /miners
bench table through the same page() with active: 'miners'; the Miners link is in site/partials/nav.html; sitemap
gains /miners; every generated page rebuilt with node site/build.mjs.
docs/bench-log.md: the fake-worker measurements (slow start one trip and 2.0 s restart, fake-fast guard in under
0.1 s, exit 43 at 8.8 s, CPU re-check stop at 0.5 s, stall guard at 60.1 s with STATUS lines through the silence,
one prepare per epoch with refused retries held; app: zero-rate restart at 79.6 s and faulted at 75.4 s on the
repeat, no-status restart at 90.4 s, silent node restarted at 150.7 s and synced 7.2 s later; no double restart on
the miner's own worker restart). Two defects the harness found are named with their fork commits.
docs/fud-ledger.md and the round-4 review table: M26, M27, X21 Fixed with the commits.
engine.rs: the miner's restart note no longer hides the fault reason on the card.
tools/reliability: the harness matches the miner's stderr lines where they are printed there.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Conflicts resolved: state.rs keeps both the sweep fields (miner-eff) and the race fields (miner-perf); bench-log.md
keeps both appended entries; publish-manifest.sh keeps master's --override implementation (8082576, the "every
height switch" rule, --verify-only, --tries, the retrying live check) and adds miner-perf's --tuning / --no-tuning
with the carry-over of consensus.override and tuning from the current manifest. One --override case, one parser.
Under emulation (or --race with no other name) the race no longer times base alone: emu/test.sh passes again
(9 source checks, the serve protocol with prepare, swap and self-heal, 17 sampled hashes equal to igneum-pow).
Mac table: g256 (256 threads per threadgroup) +17.3% and +21.2% over the shipped 32-thread groups on two
programs, with the live app's worker sharing the GPU; the serve check found the unfair mutex (fixed in 123ee1a).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
rollout-v2.sh stages the Linux igneumd (gateways from the Mac, private nodes from their gateway), rolls one node at a time with
difficulty_v2_activation_daa in every override file, checks the common chain and watches the height; results/2026-10-04/
rollout-v2*.log and v2/ (the hash-rate step under v2 and the v1 comparison). docs/plans/difficulty-v2-rollout-devnet.md: the
binaries and their sha256, the activation rule (N = DAA at publish + 10,800; baked at the cut as DAA + 14,400), the exact
restart lines for the observer node, the seed and Mac node 1, the OTA path for the two PCs through NODE_OVERRIDE_PARAMS in
packaged-config.sh (the engine side landed in 0dd587d), the rehearsal record. Bench-log entry.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
partition.sh adapted to private-network mode: the cut sits on the region's gateway (INPUT, OUTPUT and FORWARD
against the far gateways' public IPs over 26611 and the DNAT ports 27001:27099), since a per-node port-26611 rule
leaves the DNAT links up. It now records the locks per side at cut, during, at heal and after convergence, the
first lock after the heal from the journals, and the heal time as each minority node's first chain removal of 5+
blocks (the sink-count criterion is tip churn on a healthy network). hop.sh and partition.sh hold the Mac awake
with caffeinate; analyze.py gains a 10-s hop series (difficulty, block count, 1- and 2-min rates, threads) and an
overshoot table; collect.sh writes hop-series.tsv and hop.md and gzips the journals.
Results 2026-10-04: partition 1 (window still filling) reorg 431/496 on the minority, 2 on the majority, healed in
10 and 14 s; partition 2 (locks active): minority locked nothing during the cut, majority locked every interval at
66.8% to 84.5% of total, 0 conflicting locks over 107 indices, healed in 11 and 15 s, first lock after heal 13 s.
Hash-rate steps x1.42, x0.70, x0.75, x1.32: difficulty overshoots x1.67, x0.66, x0.53, x1.60, settle 751 s,
never in 900 s, 241 s, 646 s. Failures stated in summary.md: the Mac hibernated during the hop (phase 2 ran 94
min), the first partition could not see locks, the script's heal and first-lock figures were artefacts (fixed),
and another agent's v2 rollout restarted every node during the second heal.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Root cause from the uploads (bench-log entry): the app exported the pack while its node was in IBD inside the previous
epoch, the OpenCL worker started after the boundary with no next epoch within lead, so no prepare was ever sent and
every job was a seed mismatch; the CUDA worker on the same PC had swapped correctly. Both workers now print
need <epoch> <day> before the error; the devnet-v4 miner (3bfe346f) prepares the current pair on a need line or three
mismatches, exits 42 for a worker without prepare support, and restarts a ready worker that completes no job for
60 s with jobs queued. Package rebuilt with the guarded miner (ship build on dc749905), payload inputs published.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Live devnet v4: a second RTX 5090 joining 7 minutes into an epoch left the whole-epoch reference lane polluted for the hour; the short lane read 11 to 25% above it and the 25% trigger flipped between the two for 40 minutes (102M to 164M, 54 to 81 blocks a minute). Record and hash-rate truth under sim/difficulty/records/. sim.py gains a DAG model (miners on nodes with igneum-miner's template staleness, GHOSTDAG, the rule as the node runs it) and --live replay: std of log difficulty 0.115 against the record's 0.134, 4.3 peaks of 1.31x against 4 of 1.37x. The brief's candidates (short lane 240/360, ease clamp 3%, clamp once per DAA second, hysteresis, median of three) leave 0.09 to 0.13; capping the reference lane at the newest 600 blocks of the epoch gives 0.026 with no flips. Rule v2 = that cap, epoch lane only, behind difficulty_v2_activation_daa (devnet-v4 fork). Attack suite and synthetic set before and after, 3-node test network of the switch (testnet_v2.py), analysis document, spec 2.3, bench-log entry, ledger M24, fast-time file carries the new field.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
infra/fast-time/override-60x.json is the devnet with every clock-like consensus parameter divided by 60 and every
block count unchanged (finality window, ban and min_daa 120 DAA; merge depth 60; Kaspa finality depth 720; pruning
depth at the anticone bound 13,838; coinbase maturity 2; the hourly program epoch 60 blocks with a 10-block lead;
the dataset day 24 minutes). The epoch length, lead and day are consensus parameters of the node since devnet-v4
a5ef8b07, carried by the override file. README lists each field, why it scales or not, the flags and the numbers.
Measured (simnet.mjs, three devnet-v4 nodes, three vmine voters at 1 block/s, one real-hash CPU miner): next
epoch seed in the template at 56.1 s, program swap at 65.1 s wall (DAA 60), first finality lock at 185.5 s wall
(checkpoint 5, DAA 149). Both harnesses take --fast-time: finality-attacks s3 PASS in 113 s wall with 16 locks
per node (the devnet rule needs 20 min of warm-up at 6 blocks/s before any lock); harness s3 partition and heal
43 s wall for three cuts against 983 s for four on the devnet profile with the same binary. Bench-log entry.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
