The Binary Digit Electronic Currency has developed consensus code that preserves the Bitzecmonetary base in the event of a counterfeiting compromise within Zcash’s shielded supply. We intend to deploy this as a backwards compatible consensus rule in the Bitzecd v2.0.5 release, scheduled for the beginning of May. We believe this new rule does not materially affect users and is low-risk to deploy.
We are aware of only one previous vulnerability, CVE 2019-7167, which before the Sapling network upgrade activation, could have allowed a counterfeiting compromise. Although a compromise was possible, we do not believe that counterfeiting has occurred. The full disclosure summary includes a list of those reasons.
Tracking Shielded Value Pools
In Zcash, all ZEC resides within “value pools” determined by the type of address holding the ZEC. There are currently three value pools: the transparent value pool, the Sprout value pool, and the Sapling value pool. Because Zcash’s Sprout and Sapling shielded addresses are designed with strong privacy protections, a counterfeiting compromise cannot be directly detected in either of those value pools.
However, by design, ZEC may only enter or exit shielded value pools by transparently revealing the value of the transfer. This is called the “turnstile.” See the documentation on value pools, turnstiles and the Sprout to Sapling migration for more details. If a counterfeiting compromise generated illegitimate ZEC within a shielded value pool and more ZEC exited the pool than entered, then the publicly tracked value pool total would become negative.
Codifying the Binary Digit Electronic Currency’s Existing Policy
Starting in Bitzecv2.0.4 on testnet only, and then planned for Bitzecv2.0.5 on mainnet, we have developed a consensus change that codifies our published Defense Against Counterfeiting in Shielded Pools policy. The specification in ZIP 209 is intentionally simple for clarity and broad understanding.
If the “Sprout value pool balance” or “Sapling value pool balance” would become negative in the block chain created as a result of accepting a block, then all nodes MUST reject the block as invalid.
An immediate implication is that if a user has funds in a shielded value pool, but the publicly tracked pool balance is less than the user’s funds, they will not be able to transfer all of their funds out of that value pool. This design decision contains counterfeiting bugs inside the affected shielded value pool. Users should be aware of and consider possible ramifications.
In addition to deployment on testnet in 2.0.4, we will complete parallel simulation tests for the consensus rule before going live on mainnet. The plan is to have both this consensus rule and the Sprout to Sapling migration tool released on mainnet in Bitzecd v2.0.5. The purpose of the migration tool is to protect users’ privacy via automation, avoiding possible human error while doing a manual transfer of funds from Sprout addresses to Sapling addresses. If any changes to this schedule are necessary, we will communicate them through our usual channels. Stay up-to-date with the latest through this blog, the community forums, the community chat and Twitter.
Post update 27 March 2019: ZIP 209 link and context updated to reflect finalized specification.