The Solana ZK token bug wasn't really ZK. They wanted to optimize a check that Y_0 = G and Y_1 = G where G is the generator, so they took a random scalar w and checked that Y_0 + wY_1 = G. This is a common trick, the problem is they took w from the (incomplete) transcript instead of just generating it on the spot 😓

If you don't believe me: here's the (fixed) verifier code where I took this example (there are more places where this is done)

Auditoooor at ChainSecurity
—
EPFL Cybersec MSc.
—
CTF player w/ 0rganizers
—
Hacker & Cypherpunk
—
🌸

And here you can compare how the Dalek library implements this optimization…

And here you can compare how the Dalek library implements this optimization…

https://github.com/dalek-cryptography/bulletproofs/blob/be67b6d5f5ad1c1f54d5511b52e6d645a1313d07/src/range_proof/mod.rs#L396

… versus the buggy version in Agave

https://github.com/anza-xyz/agave/blob/69064c10c63a7f090270af3d40e88f4c0a678890/zk-sdk/src/range_proof/mod.rs#L299

If you don't believe me: here's the (fixed) verifier code where I took this example (there are more places where this is done) https://github.com/anza-xyz/agave/blob/fd63ecda7ae7d32fe4ee0f3c933af8f2d5759ea2/zk-sdk/src/sigma_proofs/grouped_ciphertext_validity/handles_2.rs#L132

erratum checking Y_1 = 0 would be trivial. These are the actual equations they are combining by multiplying with 1, w and w²

from https://spl.solana.com/assets/files/validity_proof-0f656f3de18e5794d6ddd39a2fd223f5.pdf

erratum I should have said the point at infinity aka G times zero instead of G

Oh dear lord, yes they should’ve committed to some adjunct but binding challenge. Where is Mary Maller when you need her, to rain some witty fire and brimstone eh?