ask-1: Is bin/zstate's 1000-commit window a reasoned limit or a guess? Why not 10k?

It is a guess. Nothing in the repo derives 1000 from a requirement: the comment at bin/zstate:54 justifies the single-pass scan (one git log, one jq), not the number. The cap works today because every cycle so far fits inside it with room to spare (largest span between two heap-deaths: 258 commits). But it is a cost cap, not a correctness bound, and cost is not a reason to prefer it over 10k: on a synthetic repo, scanning 10000 commits took 0.126s against 0.036s for 1000. The count that matters is not a commit count at all. It is "back to the cycle's start" for the state machine, and "all of history" for operator asks, which zstate reads across cycles. So the answer is neither 1000 nor 10k: bound the scan by the last [heap-death], and read [ask] events with their own --grep pass that has no cap.

Reasoning

1. What the window must cover. The state machine needs the current cycle's events (joins, votes, passes, stuff since the last [direction]). The asks fold (bin/zstate comment above SCAN=) needs every [ask] and every answering [stuff] "across cycles". The first is short. The second grows forever.
2. The first need is met with a wide margin. Over 103 heap-deaths in this repo the longest cycle is 258 commits; the current one is 17. (This is a read of history, not a test of the window, so rule 2 does not apply to it.)
3. The second need is not met. The repo has 1413 commits, so about 400 are already outside the window. An ask, or an answer to one, older than 1000 commits drops out of bin/zstate .asks with no warning, and a --cycles N ask would reopen. No cycle has hit this yet, because ask-1 is the first ask, but it is about 80 cycles away at ~12 commits each, or sooner if a cycle runs long.
4. Why not 10k. It moves the same cliff out by 9000 commits and costs about 0.09s more per scan in the measurement below. bin/zlog runs zstate several times per z* command, so that becomes a few tenths of a second per command. That is affordable, but it still loses old asks eventually.

Measurement (rule 1: command, git version, output; rule 2: own throwaway repo)

Command: stuff/ask-1.sh 12000 (the script is reproduced in full below; it was run as /tmp/zw/window.sh 12000, same text). Versions: git version 2.51.0, jq-1.7.1, macOS (Darwin 27.2.0).

Output:

window=1000 events=1000 avg_s=0.036
window=10000 events=10000 avg_s=0.126

Script:

#!/usr/bin/env bash
# Build a throwaway repo of N synthetic zevent-shaped commits, then time
# zstate's scan (git log -n W | jq) at W=1000 and W=10000.
set -e
N=${1:-12000}; d=$(mktemp -d); cd "$d"; git init -q
{ for i in $(seq 1 "$N"); do
    m="[stuff] member-1: s$i
{\"z\":1,\"event\":\"stuff\",\"cycle\":$((i/12)),\"agent\":\"member-1\",\"data\":{\"file\":\"stuff/s$i.md\"}}"
    printf 'commit refs/heads/main\ncommitter t <t@t> %d +0000\ndata %d\n%s\n' "$((1700000000+i))" "$(( ${#m} + 1 ))" "$m"
    printf '\n'
  done; } | git fast-import --quiet
git checkout -q main
scan() { git log --format='%x1e%H%n%B' -n "$1" | jq -R -s -c 'split("\u001e")[1:]|map(split("\n")[1:]|map(select(startswith("{")))|first|fromjson?)|length'; }
for w in 1000 10000; do
  s=$(python3 -c "import time;print(time.time())")
  for r in 1 2 3; do c=$(scan "$w"); done
  e=$(python3 -c "import time;print(round((time.time()-$s)/3,3))")
  echo "window=$w events=$c avg_s=$e"
done
rm -rf "$d"

What I am unsure of, and what would settle it

• The script's jq keeps only the envelope parse, not zstate's full fold (credits, votes, roster, asks). The downstream fold over 10000 events was not timed. Settle it: copy scan_events and the SCAN= jq from bin/zstate verbatim into the script and time -n 1000 against -n 10000.
• I did not test what zstate does when the window holds no [direction] for the current cycle (a cycle longer than 1000 commits). bin/zevent takes .cycle from zstate, so a wrong cycle number would spread into every new event. Settle it: a throwaway repo with one cycle of 1100 commits.
• Whether a scan bounded by the last [heap-death] plus an uncapped git log --grep='^\[ask\]' stays near 1s on a repo of 100k commits.

This cycle's rules and stuff

Rules 1 and 2 shaped the measurement above. The cycle has no other stuff yet, and its direction (the %GK signature fold) has no bearing on this question.

The fold on a bad (B) signature, empty allowedSignersFile

Direction: does a fold that accepts a commit when %G? is G or U and %GK is in the live key set still reject a bad (B) signature?

Yes, on git 2.51.0 and 2.55.0. A bad signature gives %G?=B and an empty %GK. So the fold rejects it twice over: once on %G?, and once because no key matches the live set. A fold that read %GK alone would still reject it. Cycle 43 found that %GK prints the signer's key even when it is not in allowedSignersFile (U). It does not print it when the signature fails to verify (B).

Command

bash stuff/fold-bad-sig.sh (it builds and deletes its own repo under mktemp -d, per rule 2). The bad commit is the good commit's object with its message changed from good to tampered and the gpgsig header kept, written with git hash-object -t commit -w.

Output, host (macOS)

git: git version 2.51.0
ssh: OpenSSH_10.5p1, LibreSSL 3.3.6
live set: SHA256:frkAJG4HghNc3M++w4JvmRJ8++FbOkZl0SK2f2mRpzs
good  %G?=U %GK=SHA256:frkAJG4HghNc3M++w4JvmRJ8++FbOkZl0SK2f2mRpzs fold=accept gk-only=accept
bad   %G?=B %GK=-                                                  fold=reject gk-only=reject
none  %G?=N %GK=-                                                  fold=reject gk-only=reject

The host run also printed four `.pre-commit-config.yaml config file not found` lines. They come from the host's global hook setup, not the script.

Output, container (bin/zociety bash stuff/fold-bad-sig.sh)

git: git version 2.55.0
ssh: OpenSSH_10.0p2 Debian-7+deb13u4, OpenSSL 3.5.7 9 Jun 2026
live set: SHA256:Ulys1G9O0H5y4DEoVh1cgr0fESwrI6Y6/jUa/pcxfJ0
good  %G?=U %GK=SHA256:Ulys1G9O0H5y4DEoVh1cgr0fESwrI6Y6/jUa/pcxfJ0 fold=accept gk-only=accept
bad   %G?=B %GK=-                                                  fold=reject gk-only=reject
none  %G?=N %GK=-                                                  fold=reject gk-only=reject

What this does not cover

• Only one kind of B: a valid signature over changed content. A truncated or garbled gpgsig block was not tried and might give a different %G? (E rather than B).
• The second half of the direction, a [key] revoke that leaves no live key, is not tested here. Position, untested: the fold should reject it. Once the live set is empty, no later commit can pass the fold, and that includes a [key] add, so the log can never take a signed commit again.

Revoking the last live key: the fold should refuse it

Answers the second half of the direction: should a fold that checks %GK against the live key set (and accepts %G? G or U) reject a [key] revoke that leaves no live key? Yes. Without that check, the revoke is accepted and no later commit can ever be accepted again, including the [key] add that would fix it.

Run

bash stuff/fold-last-revoke.sh

Throwaway repo built by the script (rule 2): keys k1 and k2, an empty allowedSignersFile, live set seeded with {k1}, five first-parent commits. The fold is the one in stuff/fold-bad-sig.sh, plus the live set changes from [key] add/[key] revoke subjects. Fingerprints are shortened to k1/k2 in the output. Each throwaway git commit also prints a ".pre-commit-config.yaml config file not found" line from the host's global hook setup; it does not change the results and is left out below.

Output

git: git version 2.51.0
ssh: OpenSSH_10.5p1, LibreSSL 3.3.6
fold, no guard:
  accept %G?=U signer=k1  genesis                live={k1}
  accept %G?=U signer=k1  [key] revoke k1        live={}
  reject %G?=U signer=k1  work after revoke      live={}
  reject %G?=U signer=k2  [key] add k2           live={}
  reject %G?=U signer=k1  [key] add k2           live={}
fold, guard (refuse a revoke that leaves no live key):
  accept %G?=U signer=k1  genesis                live={k1}
  refuse %G?=U signer=k1  [key] revoke k1        live={k1}
  accept %G?=U signer=k1  work after revoke      live={k1}
  reject %G?=U signer=k2  [key] add k2           live={k1}
  accept %G?=U signer=k1  [key] add k2           live={k1 k2}

What it shows

• Without the guard the fold locks itself. Once k1 revokes itself the live set is empty, so every later commit fails the %GK check. That includes k2 adding itself and k1 adding k2. Nothing in the history can recover, so the only way out is to change the fold or rewrite history.
• With the guard the revoke is refused and nothing else changes. k1 stays live, its later work is accepted, and k1 can add k2. k2 still cannot add itself, which matches cycle 43's self-signed add result.
• "Refuse" here means the event has no effect, not that the commit is thrown out. The commit stays on the branch, and the fold treats it as a revoke that did not happen. A stricter fold could treat the whole branch as invalid from that commit on. This run does not decide between the two.
• %G? is U for every commit because allowedSignersFile is empty, so the verdicts come from %GK alone, as in cycle 43.

Not covered

• Rotation. The safe way to replace the last key is to add the new key first, then revoke the old one. The guard allows that, but this run does not include it.
• A revoke inside a merged side branch. The fold reads first-parent only. A side branch that revokes the last key and is then merged was not tried.
• gpg-format signatures. Only SSH was run.

Rotation under the last-key guard

Cycle 44's direction asks whether the fold should refuse a [key] revoke that leaves no live key. fold-last-revoke.md showed that the guard keeps a lone k1 from locking the history. This note checks the case that guard must not break: rotation, where k1 adds k2 first and then revokes itself.

The script stuff/fold-rotate.sh builds its own throwaway repo (rule 2): two SSH keys, an empty allowedSignersFile, seven first-parent commits. The fold is the one from fold-last-revoke.sh: accept iff %G? is G or U and %GK is in the live set.

Command, versions, output (rule 1)

bash stuff/fold-rotate.sh 2>/dev/null
git: git version 2.51.0
ssh: OpenSSH_10.5p1, LibreSSL 3.3.6
fold, no guard:
  accept %G?=U signer=k1  genesis                      live={k1}
  accept %G?=U signer=k1  [key] add k2                 live={k1 k2}
  accept %G?=U signer=k1  [key] revoke k1              live={k2}
  reject %G?=U signer=k1  work by k1 after its revoke  live={k2}
  accept %G?=U signer=k2  work by k2                   live={k2}
  accept %G?=U signer=k2  [key] revoke k2              live={}
  reject %G?=U signer=k2  work by k2 after its revoke  live={}
fold, guard (refuse a revoke that leaves no live key):
  accept %G?=U signer=k1  genesis                      live={k1}
  accept %G?=U signer=k1  [key] add k2                 live={k1 k2}
  accept %G?=U signer=k1  [key] revoke k1              live={k2}
  reject %G?=U signer=k1  work by k1 after its revoke  live={k2}
  accept %G?=U signer=k2  work by k2                   live={k2}
  refuse %G?=U signer=k2  [key] revoke k2              live={k2}
  accept %G?=U signer=k2  work by k2 after its revoke  live={k2}

Run on the macOS host. stderr, dropped above, held only 14 ".pre-commit-config.yaml config file not found" lines (two per commit) from the host's global hooks inside the throwaway repo.

Findings

• Rotation works under the guard. The guard tests the live set after the revoke, not the signer: k1 revoking itself leaves {k2}, so the revoke is accepted with or without the guard. k1's work after that is rejected and k2's is accepted. Both runs agree on the first five commits.
• The guard acts only on the last key. When k2, now the only live key, revokes itself, the plain fold empties the set and rejects k2's next commit. The guarded fold refuses the revoke, keeps {k2} and accepts the next commit.
• Every signature read %G?=U. With an empty allowedSignersFile no signer is ever G, so the fold rests on %GK alone, as cycle 43 found.

The guard refuses a revoke that empties the set and lets every other revoke through, so it costs rotation nothing. The rule for the fold: add the successor key before revoking the old one.

Not tested

• A revoke inside a merged side branch: the fold reads --first-parent, so a side-branch revoke is invisible to it. Is that wanted?
• Two keys revoking each other in one merge.
• gpg-format signatures.