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

Counter ASIC 2.0 status: the 00:28 and 00:29 headings stamped from the clock (were guessed ahead)

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-josh 2026-10-06 00:29:39 +00:00
parent 55eb281a7f
commit 20511b52a5
2 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/plans/counter-asic-2-rollout.md
View file

File diff suppressed because one or more lines are too long

6
docs/plans/counter-asic-2-status.md
View file

@ -714,9 +714,9 @@ agg-cost-pc2-4 (00:18:26 to 00:22:05Z, exit 0): card_off and card_on both read "
A finding on the shipped fork from the ledger closer (00:21): kaspa-consensus test processes::pruning_proof::igneum_m20_tests::witnesses_are_checked_in_epoch_order_under_their_own_seeds fails on its Mac run of the ledger-fixes-0311 suites (fork fbb0082a on 89dfcb95; 99 passed, 1 failed, 4 ignored): the pruning-proof stand-in (igneum_pow.rs 114) fills era 0 with the genesis hash and the test expects EpochSeeds::v2's era ZERO_HASH (consensus/pow/src/igneum.rs 88). The code read: the node's RPC always reports Some(genesis) in era 0 (consensus/src/consensus/mod.rs 838 to 869) and the miner's legacy walk gives genesis (main.rs 504 to 536), so the proof code matches the node and the test's expectation is the odd one out; seeds_from_info's unwrap_or(ZERO_HASH) differs only against a pre-field node (a mixed case that ends at the three relaunches), and a v2 program reads neither field, so no hash changes. PC 2's combined suite job on the release tree reported kaspa-consensus exit 0, which disagrees with the Mac run; the single test is running on 89dfcb95 on the Mac under the build lock to settle it. Either way the next cut carries the test fix (the expectation, or v2() taking the genesis as its era) and the miner's unwrap_or aligned to genesis.
## 00:36 the 0.3.12 list, in order; the /api/state defect (decided by main: next cut, no re-ship tonight)
## 00:28 the 0.3.12 list, in order; the /api/state defect (decided by main: next cut, no re-ship tonight)
1. App proving-v1 6714a45: `/api/state` answers `{}` on every proving machine about 15 paid shards after an app start (paid_wei is a u128; serde_json refuses it above u64::MAX = 18.45 IGN; a paid shard averages 1.23 IGN; engine.rs 180 swallowed the error into an empty object). Consequence per tier: the dashboard on any proving 24 or 32 GB machine goes blank within about 12 minutes of its first payout and stays blank until a restart; mining, proving and payouts unaffected; every PC playbook that read /api/state failed the same way (agg-cost-pc2-4 tonight). Fix: paid_wei as a decimal string, the error logged once, a reply carrying `error` and `version`; a unit test; 114 app tests green; 2 files, 37 lines, no UI change. Workaround until 0.3.12: restart the app (12 more minutes of dashboard). Rule for every PC 2 playbook tonight (main, 00:35): card keys from the app's settings.json, never from /api/state (agg-cost-pc2-5 is built that way).
1. App proving-v1 6714a45: `/api/state` answers `{}` on every proving machine about 15 paid shards after an app start (paid_wei is a u128; serde_json refuses it above u64::MAX = 18.45 IGN; a paid shard averages 1.23 IGN; engine.rs 180 swallowed the error into an empty object). Consequence per tier: the dashboard on any proving 24 or 32 GB machine goes blank within about 12 minutes of its first payout and stays blank until a restart; mining, proving and payouts unaffected; every PC playbook that read /api/state failed the same way (agg-cost-pc2-4 tonight). Fix: paid_wei as a decimal string, the error logged once, a reply carrying `error` and `version`; a unit test; 114 app tests green; 2 files, 37 lines, no UI change. Workaround until 0.3.12: restart the app (12 more minutes of dashboard). Rule for every PC 2 playbook tonight (main, 00:27): card keys from the app's settings.json, never from /api/state (agg-cost-pc2-5 is built that way).
2. The miner resubscribes after a node restart, and the watchdog's "accepted or a template change in 120 s" rule (C43).
3. Per-day dataset reuse in the CUDA and OpenCL workers (the integrated tier's restart per epoch).
4. The M20 test expectation and the miner's era unwrap_or aligned to the genesis stand-in (pending the feature-gated run on 89dfcb95).
@ -725,4 +725,4 @@ A finding on the shipped fork from the ledger closer (00:21): kaspa-consensus te
7. fud-close 647b08c (with ledger-fixes 3d4ec451 rebased onto the 0.3.11 fork), ota-k2, ember-tune, rig-install's two follow-ups, the explorer split (3e01212 safe, d7e797c waits), the step-1 "every new-side node has a miner" check in the publish runbook.
No further rollout tonight beyond the planned object sweep (done: every live node at 0139ab9d).
00:40. The M20 test finding is CONFIRMED on the shipped fork: on 89dfcb95 itself, `cargo test -p kaspa-consensus --features igneum-pow --lib witnesses_are_checked_in_epoch_order_under_their_own_seeds` on the Mac under the build lock fails at igneum_m20_tests.rs:122 (left era = the test's genesis 0x5e51 from the stand-in, right era = ZERO_HASH from EpochSeeds::v2; 20.2 s). Without the feature the test is not compiled ("102 filtered out"): the whole igneum_m20_tests module is behind `#[cfg(feature = "igneum-pow")]`, and tools/build-job.mjs passes no feature flag, so PC 2's combined suite job (G6, build-20261005-230745, "six node suites exit 0") never ran the lottery-hash consensus tests. Two items, both 0.3.12 (item 4 of the list above, now split): (a) the test's expectation (the era-0 stand-in is the genesis hash on every path that has it: the node's RPC, the miner's legacy walk, the pruning proof; the class fix is one `era0_seed(genesis)` helper used by all three and by seeds_from_info's fallback instead of ZERO_HASH, with v2 seeds compared on (epoch, day, class) where the era is unread); (b) the gate: build-job.mjs runs the node suites with `--features igneum-pow` so the gated tests count, and G6's evidence names the feature set. What it does NOT mean: no consensus or hash change (a v2 program reads neither class nor era; the proof-path stand-in and the node agree), nothing on the devnet is affected; it is a test and a gate gap.
00:29. The M20 test finding is CONFIRMED on the shipped fork: on 89dfcb95 itself, `cargo test -p kaspa-consensus --features igneum-pow --lib witnesses_are_checked_in_epoch_order_under_their_own_seeds` on the Mac under the build lock fails at igneum_m20_tests.rs:122 (left era = the test's genesis 0x5e51 from the stand-in, right era = ZERO_HASH from EpochSeeds::v2; 20.2 s). Without the feature the test is not compiled ("102 filtered out"): the whole igneum_m20_tests module is behind `#[cfg(feature = "igneum-pow")]`, and tools/build-job.mjs passes no feature flag, so PC 2's combined suite job (G6, build-20261005-230745, "six node suites exit 0") never ran the lottery-hash consensus tests. Two items, both 0.3.12 (item 4 of the list above, now split): (a) the test's expectation (the era-0 stand-in is the genesis hash on every path that has it: the node's RPC, the miner's legacy walk, the pruning proof; the class fix is one `era0_seed(genesis)` helper used by all three and by seeds_from_info's fallback instead of ZERO_HASH, with v2 seeds compared on (epoch, day, class) where the era is unread); (b) the gate: build-job.mjs runs the node suites with `--features igneum-pow` so the gated tests count, and G6's evidence names the feature set. What it does NOT mean: no consensus or hash change (a v2 program reads neither class nor era; the proof-path stand-in and the node agree), nothing on the devnet is affected; it is a test and a gate gap.