From 20eb0dd045452a26640367a6de636b0ee77024ec Mon Sep 17 00:00:00 2001 From: igneum-labs <337424239+igneum-labs@users.noreply.github.com> Date: Tue, 6 Oct 2026 08:35:13 +0000 Subject: [PATCH] bench-log: the fast-time harness on the fresh-record rule, both cases Co-Authored-By: Claude Fable 5.1 --- docs/bench-log.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/bench-log.md b/docs/bench-log.md index 5c06c110a..7b12ceaa6 100644 --- a/docs/bench-log.md +++ b/docs/bench-log.md @@ -1837,3 +1837,12 @@ What the refusal is (the fork, `igneum/exec/src/proving.rs` `check_segment_recor Run b (`segments-pc2-pv1b`, 07:20Z to 07:51Z) claimed nothing in 88 passes: the driver's segment keys were doubles against int64 hashtable keys (fixed in 330207d); its 30 minutes are the miner-alone baseline above. +### 6 October 2026, 08:26Z to 08:35Z, the fast-time harness on the fresh-record rule (Mac, `tools/lock/with-lock.sh run`) + +`IGNEUM_PV1_BIN=vendor/igneum-node/target-pv1/release node tools/proving-v1/net.mjs --segment 8 --unproven 10 [--fresh-rule 0]` (fork 0f0dda95, 3 nodes at 60x, ports 29950+): + +| Case | Checks | Time | +|---|---|---| +| The rule as shipped (no switch): fresh refused while the previous segment is pending (known-failed), accepted after it is unproven | 22 passed | 166.2 s | +| `--fresh-rule 0`: fresh accepted while the previous segment is pending, `freshAdmissible` true, still refused after a proven one, the second offer a duplicate ("segment already paid") | 23 passed | 139.9 s | +