A game of Whack-A-FUD 🔨

Zebraman · June 9, 2026, 2:12pm

I stumbled across this tweet claiming the recently found bug was known as early as 2016, months before Zcash was even launched.

Here’s the issue on GitHub:

github.com/zcash/zcash

Ensure Spec mitigates Double Spending by Colliding InternalH

opened 01:03AM - 23 Feb 16 UTC

closed 12:00AM - 01 Apr 16 UTC

defuse

C-bug I-SECURITY A-crypto A-consensus A-circuit in 1.0 special to Daira special to Nathan protocol spec Zerocash paper

I think I found an attack that would let an attacker create as much money as the…y want for themselves at the cost of finding 128-bit hash collisions. **Background:** A coin is a tuple (apk, v, ρ, r). The coin commitment CoinCommitment((apk, v, ρ, r)) is computed as: > InternalH = Leading128(CRH(apk || ρ)) > k = CRH(r || InternalH) > cm = CRH(v || k) The truncation of InternalH is done to make the commitment statistically-hiding, i.e no matter how much computational resources I have, I can't find out what v or apk are. **Attack:** Because InternalH is only 128 bits, in 2^64 operations I can find some ρ != ρ' such that: > Leading128(CRH(apk || ρ)) = Leading128(CRH(apk || ρ')) And therefore: > CoinCommitment((apk, v, ρ, r)) = CoinCommitment((apk, v, ρ', r)) To carry out a double-spend attack I first acquire some real Zcash (e.g. by buying it with USD), and then double spend it to myself as follows. Ignoring the faerie gold fix, I create a new coin for myself, but as I do so I make sure to find a collision (apk, v, ρ, r) and (apk, v, ρ', r) where ρ != ρ'. By completeness of the protocol, I'll be able to spend the (apk, v, ρ, r) coin, and so that's what I do. This will reveal the serial number PRFsnask(ρ). After that first spend has made it on to the ledger, as far as I can see, nothing prevents me from spending that coin _again_, using ρ', because: - I can still give a path from the root to CoinCommitment((apk, v, ρ', r)), namely the same path as I gave in the first spend (and because of the zero-knowledge property nobody will know the path is the same). - With high probability PRFsnask(ρ') is not equal to PRFsnask(ρ), and I can obviously still prove I computed PRFsnask(ρ') correctly inside the pour. - I can still satisfy spend authority (I know ask for the apk I used). - I have to use the same r (old) for both spends (otherwise the commitments won't collide), but again because of the zero-knowledge property I don't think anyone (except for me, the holder of ask) can tell it's been reused. After the faerie gold fix, I'm forced to find colliding ρ by altering hsig, and I'm forced to commit to either ρ or ρ' because hsig gets published. This doesn't prevent the attack, since when I go to spend for the second time it is not going to be noticed that ρ' doesn't match the old hsig, at least not according to the current protocol. **Fix:** Maybe CoinCommitment needs to be collision-resistant? Or maybe we should re-use hsig as a commitment to ρ and check it when I try to spend with ρ?

Feel free to add more such coping clown claims to this thread for the sake of dispelling false rumours with evidence.

Zebraman · June 10, 2026, 9:22pm

Can we attribute this to the double top pattern that was forming at the time, or is it too excessive?

Topic		Replies	Views
Several Zcash Vulnerabilities Successfully Remediated General	5	309	April 21, 2026
Successful Zcoin attack proves once again why Zcash's unknown supply is a flawed setup Technology	6	1973	February 23, 2017
Security Disclosure: we remediated a vulnerability in Sprout General	4	470	April 2, 2026
Zcash Counterfeiting Vulnerability Successfully Remediated General	79	8223	March 6, 2019
Open letter to Justin Ehrenhofer et al General	18	1823	May 23, 2019

A game of Whack-A-FUD 🔨

Related topics