Counter ASIC 2.0: proving v1 segments confirmed from PC 2's log; decision 7 (segment length or cards) for Josh

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

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

@@ -129,7 +129,7 @@ THE CROSSING (6 October 2026): epoch 43 is class v3, generator 3, from DAA 154,8
 
 ## 8a. Proving v1 rides with it
 
-After the crossing (04:17 UTC): proving v1 is active and has proven no segment, by arithmetic rather than fault: the aggregator (app prover.rs, aggregate_once) needs a shard proof for every block of a segment in its own pool, and one prover at about 2.7 percent coverage never holds eight consecutive proven blocks; the share accumulates in escrow until the fleet reaches the proving plan's coverage rows (about 18 mining or 6 proving-only 5090-class cards at one block per second, the reviewer's arithmetic, approximate). v0 shards keep paying (13 per 10 minutes on PC 2).
+After the crossing (04:17 UTC): proving v1 is active and has proven no segment, by arithmetic rather than fault: the aggregator (app prover.rs, aggregate_once) needs a shard proof for every block of a segment in its own pool, and one prover at about 2.7 percent coverage never holds eight consecutive proven blocks; the share accumulates in escrow until the fleet reaches the proving plan's coverage rows (about 18 mining or 6 proving-only 5090-class cards at one block per second, the reviewer's arithmetic, approximate). v0 shards keep paying (13 per 10 minutes on PC 2). Confirmed from PC 2's app log by the proving agent (04:28 UTC): the aggregator loop runs the v1 path every 42 s and waits on all eight shard proofs every pass; each segment passes its 600-DAA deadline unproven. Decision for Josh: cards, or a smaller proving_v1_segment_blocks for the devnet (1 or 2), which is a consensus parameter: a new override object, a new digest, a two-manifest publish at tip + 14,400 by tonight's rules; the public testnet's genesis sets the segment length from the coverage rows.
 
 Josh delegated the proving v1 decisions to its agent (acd4f36bc2c07a4e2). Handoff received 21:05 UTC: fork proving-v1 = ece42979 on 21d4c73c (eb32c645 the feature on protocol 15 / message 75; 2dfad910 the rebased pool test; 3203c8d0 N = 8; ece42979 the digest test edit); Mac unit tests on it: consensus-core 26, exec 8, flows, 0 failed; app proving-v1 FINAL e0de2ab on 5b0d54f (a223ca9 the resume fix, e0de2ab the Metal --prepare-packs fix; docs-only commits between) (6dc686a plus the resume fix: the resume path re-arms every slot without a live worker, re-exports the pack, and logs "<card> is not mining 90 s after resume"; the known-failed case of PC 2's 21:25:11Z resume is the unit test the_pc2_resume_of_21_25_11z_restarts_under_the_new_rule_and_not_the_old, `cargo test -p igneum-app resume` 3 passed; cause: Cmd::Resume re-armed only faulted slots after stop_miners had cleared every restart_at; the tier numbers from the miner-on curve, the AMD and Apple "mines and does not prove" line, the CPU path refused under 32 GB of RAM, the 24 GB tier marked "measured on the 32 GB card", the fast-time file at unproven_daa 10; `cargo test -p igneum-app provedefault` 6 of 6 on the Mac). Harness on the final fork tree: `IGNEUM_PV1_BIN=vendor/igneum-node/target-pv1/release tools/lock/with-lock.sh run node tools/proving-v1/net.mjs --secs 1500 --segment 8` gave "RESULT proving v1 harness: PASSED (21 checks) in 244.4 s" at 20:56:45Z. Override fields at publish: proving_v1_activation_daa = tip + 14,400, proving_v1_segment_blocks 8, proving_v1_unproven_daa 600, proving_v1_aggregator_share_bps 1000; they enter the digest only once the activation is set. Pinned guests unchanged. Mixed fleet: a 0.3.10 node peers with a 0.3.11 node at protocol 14 and never receives message 75; it carries segment records as miner bytes and pays nothing for them; before H the fleet is unchanged, after H only 0.3.11 producers carry and pay segment records and the shard split moves to 90/10, so every node must be on 0.3.11 before H (the fee-switch rule, section 7a). The PC 2 suite job on the merged tree (ca2-v3-node + ece42979) is the suite evidence for both halves. The app half also carries the resume fix (assigned 21:47 UTC to the proving agent on its app branch on top of 6dc686a): engine.rs's resume path restarts every enabled card's worker and the pack export if the pack is stale, re-checks within one tick that every enabled card is mining and logs a failure naming the card if not, with a unit test on the state machine (paused -> resumed -> every enabled card mining within one tick) and the known-failed case of PC 2's 21:25:11Z log; the defect left PC 2's miners off for 20 minutes tonight and the Mac's miner off after pause+resume this afternoon. If its commit is not in hand when the app tree is cut, it is first on 0.3.12's list and the status file says so. 0.3.11 carries program_class_v3 AND proving v1 together: one override object, one digest, one publish, the same gates for each half (its fast-time harness green on the final tree, suites on PC 2); both activation heights set at publish by the same rule (tip + 14,400, checked >= 10,800). If one half is not ready when the other is, the ready half ships as 0.3.11 and the other as 0.3.12; the status file says which.
 

docs/plans/counter-asic-2-status.md

@@ -788,3 +788,5 @@ The watcher (pid 49195, /tmp/igneum-devnet/crossing-154800.out): epoch 42 read "
 The consequences reviewer at 04:16Z: node 1's igneum_getProvingStatus.v1 reads active, segmentsInWindow pending 54, proven 0, unproven 21, paidSegments 0, no segment record carried; PC 2's upload shows no proving line since 03:44Z while v0 shards still paid at 13 per 10 minutes. So the honest line for the morning is "class v3 crossed and held; proving v1 active since 03:51:42Z with 0 segments proven in its first 25 minutes (cause pending from the proving agent)", not "0.3.11 activated". Consequence per tier while it lasts: no segment pays and no aggregator share (10%) is earned, v0 shards keep paying; the fee switch at H = 210,000 (about 18:56Z) is unaffected but C1 (every prover on 0.3.11 by 16:00Z) now has a second condition, that a prover proves v1 segments at all. The proving agent has the ask (PC 2's prover state after the crossing, the app's v1 segment path, aggregate_once); any PC 2 job it needs is one job on my go; a 0.3.11 app cause joins the 0.3.12 list at the top beside 6714a45.
 
 04:17. C47's cause, read from the shipped app (app/igneum-app/src/prover.rs, the aggregate_once doc and line 657): one aggregation attempt needs one shard proof per shard of EVERY block of the segment in this node's pool before it runs `igneum-prove-host --mode aggregate`, else it answers "segment a..b: waiting for shard proofs ... in this node's pool". With one prover (PC 2) at about 2.7 percent block coverage, eight consecutive proven blocks never occur, so proving v1 yields zero segment records on tonight's devnet by arithmetic, not by a fault; the aggregator share accumulates in escrow until the fleet reaches the proving plan's coverage rows (the reviewer's arithmetic, approximate: about 18 mining or 6 proving-only 5090-class cards at one block per second). The morning line: "class v3 crossed and held; proving v1 active, 0 segments proven and none expected at one prover". No PC 2 job; the proving agent confirms from PC 2's log and writes it into docs/plans/proving-v1.md. What it means for the public page: the proving line stays "every block proven" as a design, and the devnet shows the per-block shards (v0) paying while segments wait on coverage; the C1 check at 16:00Z is about the binaries, not about segments.
+
+04:28. Confirmed by the proving agent from PC 2's app log (run win-1ccfe586-20261005-235130): the prover is on and the aggregator loop runs the v1 path every 42 s ("aggregator: segment N..N+7: waiting for shard proofs N/0 ... N+7/0 in this node's pool", all eight missing on every pass); one 5090 proves 13 shards per 10 minutes of about 600 blocks (2.2 percent), so each segment passes its 600-DAA deadline unproven; node 1 at 04:2xZ: pending 55, proven 0, unproven 20, paid 0. No fault, no 0.3.12 item. DECISION FOR JOSH (7, the morning): the fix's shape is cards (about 18 mining or 6 proving-only 5090-class cards at one block per second on empty blocks, approximate) or a smaller proving_v1_segment_blocks for a small devnet (1 or 2 instead of 8), which is a consensus parameter and so a new override object, a new digest and a two-manifest publish at a new height (tip + 14,400, the same rules as tonight); not tonight (main's rule: no further rollout). Until then the aggregator share sits in escrow and v0 shard payouts continue; the public testnet's genesis carries v1 from day one with whatever segment length the coverage rows justify.