A paper titled “Burning Zerocoins for fun and profit” was published that discussed several vulnerabilities of the original Zerocoin library. There was a bug that allowed inflation, which was patched and in force and another bug that resulted in improperly signed transactions. These issues are resolved and also mentioned here. There are also additional security fixes that were patched.
The attack allows someone to make someone’s Zerocoin mints unspendable. Meaning you can mint the coin, but you cannot redeem it because it has been vandalized. However news reports and social media coverage have vastly blown up the issue out of proportion. Firstly, you can read the actual academic paper that discloses the vulnerability here.
We were made aware of this flaw by Tim Ruffing who discovered the flaw while he was engaged by us to improve the Zerocoin library and we implemented the necessary code to patch it. We had also disclosed this bug together with Tim Ruffing to several other projects using Zerocoin including PIVX and Zoin. The code remains in place in our latest Zerocoin wallet along with other fixes and is awaiting activation via a Zerocoin ID number meaning when Zerocoin mints hit a certain number, the new scheme would take into effect which is in effect similar to a hard fork block except for Zerocoin. Although we would have liked to activate it immediately, it was imperative to allow a transition period where the old mints could still be spent and honored and it is in particular the transition that is tricky rather than the actual fix.
Although we do acknowledge the flaw, the actual economic benefit derived from it is quite low and is quite difficult to do in practice which is also acknowledged by the authors (with certain sections bolded by us for emphasis):
“Performing the attack in practice
There are several issues which make it difficult to perform this attack in practice:
- An attacker needs to be able to intercept and block network messages sent by the victim. This often requires the attacker to be in a somewhat privileged position in the network, e.g., the ISP of the victim or a malicious Tor exit node if the victim uses the Tor network. Also, being a miner will help the attacker.
- If the attacker is not able to block network messages reliable, it may actually happen that the spend transaction of the victim is included in the blockchain before the spend transaction of the attacker. If that happens, then the zerocoin of the attacker and not that of the victim becomes unspendable, i.e., the attack backfires. As a consequence, it is risky to try to perform the attack in practice.
- This is even further complicated, because Zerocoins minted in one block can only be spent in a later block, and more than one block distance may be necessary depending on the consensus rules of the cryptocurrency. That means that the attacker may need to be able to block network messages for a longer period to avoid the risk of a backfire.“
- No new coins are generated
- No new “Zerocoins” are mined contrary to poorly researched reports.
- It requires control of the network (ISP or a malicious exit TOR node or being a significant miner) for the attack to work.
- In the disclosed attack, this is an attack of vandalization and doesn’t directly profit the attacker and in many cases, would result in loss for the attacker. Any benefit is through indirect means by mounting the attack to cause uncertainty and lack of confidence and profiting from shorts from the price drops. Ironically, the irresponsible reporting of some news sources and rival privacy projects that greatly inflated the issue arguably has a similar effect.
- The fix for this has been in place in our code but wasn’t activated to the original schedule due to us wanting to include additional important bug fixes in one Zerocoin ID limit.
Some have asked us why we have not disabled Zerocoin. We note that some other coins have implementations that utilizes Dash ‘sporks’ that allows the developer to disable Zerocoin where necessary through the use of a master private key that is controlled by the developers. Although it is useful and we can understand why projects would want to have such a feature, we feel that it is against the spirit of decentralization and would allow a third party to compel us to disable Zerocoin transactions. Some other coins have instead manually disabled Zerocoin. Some of the tweets also mentioned that these coins are unaffected, but many of these are unaffected because they have Zerocoin disabled which is not the same as patching the problem. Furthermore, this particular flaw is again, hard to pull off in practice and in our opinion has limited practical effectiveness due to the high chance of the attack backfiring.
It was our intention to have this fix activated earlier to hit the requisite Zerocoin ID number for the new scheme that resolves the “denial-of-spend” attack, however we identified other fixes that we wanted to have incorporated before we activated the new Zerocoin scheme and thus held off from activation of the patch so that we could resolve these bugs in one go rather than having to create another Zerocoin “hard fork” especially since we felt that the “denial-of-spend” attack although important, wasn’t a critical flaw. The new wallet with these additional fixes will be rolled in a couple of days that resolves block syncing issues relating to Zerocoin and other important security fixes.
We have been in touch with coins such as Zoin and Hexx that use Zcoin as a base for their code who disabled their Zerocoin implementations for various reasons and had advised for them to wait till we have released the latest fix. We also had been in touch with PIVX’s lead dev Presstab in discussing this in implementing the fix. We also reached out to Smartcash who had informed us that they were not reactivating Zerocoin anytime soon. During this time, we had also introduced Tim Ruffing (and some which Tim reached out by himself) to some of these projects for those who wanted further clarification or assistance in patching this. We welcome collaboration in making Zerocoin stronger and more resilient and thank the projects that had coordinated with us for responsible disclosures.