53cb492de3
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>
5.8 KiB
Partition sin, 10 min, 20261004-140305
cut at 14:03:23, healed at 14:15:36, converged 768 s after heal (criterion: at most 2 distinct sinks for 3 polls)
| node | side | sink at heal | removed (reorg depth) | added | max single removal after heal |
|---|---|---|---|---|---|
| igneum-01 | majority | 678440416e1a | 0 | 509 | 0 |
| igneum-02 | majority | d4950b436c40 | 0 | 510 | 0 |
| igneum-03 | majority | d4950b436c40 | 0 | 511 | 0 |
| igneum-04 | majority | eaa75038435a | 0 | 513 | 0 |
| igneum-05 | minority | 93e260d3b7f1 | 423 | 923 | 443 |
| igneum-06 | majority | d4950b436c40 | 0 | 520 | 4 |
| igneum-07 | majority | eaa75038435a | 0 | 522 | 4 |
| igneum-08 | majority | eaa75038435a | 0 | 525 | 4 |
| igneum-09 | majority | 25c89f691ff5 | 0 | 528 | 4 |
| igneum-10 | minority | eb726b8eea71 | 469 | 941 | 491 |
| igneum-11 | majority | d4950b436c40 | 0 | 537 | 4 |
| igneum-12 | majority | d4950b436c40 | 0 | 538 | 4 |
Heal time (seconds from the rules coming off until the node's first chain removal of 5 or more blocks, chain.tsv; journal in heal-.txt):
| node | adopted the majority chain after s | blocks removed |
|---|---|---|
| igneum-05 | 11 | 443 |
| igneum-10 | 15 | 491 |
Minority reorg depth, max: 469. Majority, max: 0.
Conflicting locks at heal (same checkpoint index, different hash, both locked): nodes dumped: igneum-01, igneum-05, igneum-10; locked indices seen: 107; conflicting: 0 none: no index locked with two different hashes on the two sides
Locks per side (highest locked checkpoint index, DAA, locked count on one node per side):
| time | moment | side | node | max locked index | daa | locked count |
|---|---|---|---|---|---|---|
| 14:03:14 | at-cut | minority | igneum-05 | 425 | 13718 | 218 |
| 14:03:14 | at-cut | majority | igneum-01 | 425 | 13718 | 218 |
| 14:05:47 | cut+120s | minority | igneum-05 | 426 | 13748 | 219 |
| 14:05:47 | cut+120s | majority | igneum-01 | 430 | 13867 | 223 |
| 14:08:09 | cut+240s | minority | igneum-05 | 426 | 13807 | 219 |
| 14:08:09 | cut+240s | majority | igneum-01 | 433 | 13958 | 226 |
| 14:10:31 | cut+360s | minority | igneum-05 | 426 | 13867 | 219 |
| 14:10:31 | cut+360s | majority | igneum-01 | 439 | 14138 | 232 |
| 14:12:53 | cut+480s | minority | igneum-05 | 426 | 14017 | 219 |
| 14:12:53 | cut+480s | majority | igneum-01 | 442 | 14227 | 235 |
| 14:15:15 | cut+600s | minority | igneum-05 | 426 | 14167 | 219 |
| 14:15:15 | cut+600s | majority | igneum-01 | 446 | 14349 | 239 |
| 14:15:31 | at-heal | minority | igneum-05 | 426 | 14167 | 219 |
| 14:15:31 | at-heal | majority | igneum-01 | 447 | 14377 | 240 |
| 14:28:39 | converged | minority | igneum-05 | 474 | 15187 | 253 |
| 14:28:39 | converged | majority | igneum-01 | 474 | 15187 | 267 |
| 14:29:11 | first-lock-after-heal | minority | igneum-05 | 475 | 15218 | 254 |
| 14:29:11 | first-lock-after-heal | majority | igneum-01 | 475 | 15218 | 268 |
Locks through the cut (igneumd journals, locks-journal-.txt; rules on at 14:03:25 UTC, off at 14:15:36):
| side | node | last lock before the cut | locks during the cut | signed fraction of total weight during the cut | first lock after the heal |
|---|---|---|---|---|---|
| minority (sin, 2 of 12 keys, 15.8% of window weight) | igneum-05 | 426 at 14:03:21.8 (3.5 s before the rules; 80.3% signed) | none: checkpoints 427 to 440 determined, no certificate | n/a | adopted the majority's certificates 427 to 440 at 14:15:47 (11 s after heal; each logged as "certificate at index N is for , this node's checkpoint is "), then locked 441 itself at 14:15:48.5 (12.5 s) at 95.0% of active, 85.0% of total |
| majority (10 keys, 84.2%) | igneum-01 | 426 | every checkpoint 427 to 447 (21 locks, one per 30-s interval) | 66.8% to 84.5% of total (72.2% to 89.4% of active); 437 and 439 locked at 66.8%, 0.1 points above the 2/3 floor | 448 at 14:15:49.1 (13 s after heal), 68.1% of total |
The floor held as specified: the side with 15.8% of the weight never locked, the side with 84.2% locked every interval, and no index was certified with two hashes (0 conflicts over 107 compared indices). The margin on the majority side is thin because votes go missing: with all 12 miners up and connected the certificates carried 8 to 10 of 12 votes (signed 66.7% to 89% of total; checkpoints 420 and 421 at 14:00 UTC locked at 66.7% and 66.8%), and during the cut 8 to 10 of the 10 reachable keys. Had the two heaviest majority keys been the missing ones at one interval, that interval would have paused. Why 2 to 4 votes miss each 30-s checkpoint on a 12-node mesh with 300 to 500 ms propagation is a question for the finality owner, not answered here.
Overlap with another agent's rollout: infra/cloud-devnet/rollout-v2.sh (not part of this run) replaced igneumd on every node one at a time from 14:14:40 to 14:18:05 UTC with a build that reads difficulty_v2_activation_daa 16,170 from the override file (rule v1 keeps running until that DAA score). That is the last 56 s of the second cut and its whole heal window: igneum-01 restarted at 14:14:40, 02 at 14:14:55, 03 at 14:15:10, 04 at 14:15:25, 05 at 14:15:58 and 10 at 14:17:30 (after this script's own heal restarts at 14:15:39 and 14:15:44), 06 to 12 between 14:16:15 and 14:18:05, each back with peers within about 5 s (rollout-v2.log). Unaffected: the cut phase (locks 427 to 447 on the majority, none on the minority), the reorg depths (chain state read at 14:29), and both minority heal times (the reorgs at 14:15:47 and 14:15:51 came before those nodes' rollout restarts). Carrying the caveat: the majority's first lock after the heal (448 at 14:15:49 on igneum-01, 69 s after its own restart) and anything after 14:14:40 on the majority side.
First lock after the heal (script poll, which only started after the sink-count convergence wait): index 474, 807 s after heal; the journal figures in the table above are the real ones (13 s majority, 11 to 12.5 s minority).