Summary and Background
As some of you may have heard around the crypto-community, Zcash announced a ‘vulnerability’ in the zkSNARKs proving method (Sprout) used for Z-addresses (aka private shielded addresses) in their codebase was discovered on or around Q1 2018. The Zcash developers patched the ‘vulnerability’ by changing the proving method to Groth16, and then with their latest upgrade to Sapling also had some affect in the shielded transaction process… At least that is my understanding, but regardless, their codebase is using the latest proving method (Groth16) which I’ve assumed has not been found to have the same vulnerability.
We have not determined if we are vulnerable - I’ve read in some places that changing our parameters to Zhash (N144, K5) might make the process to exploit Sprout a bit different, maybe even more difficult, but I cannot confirm this. The details on what was discovered are of the level of cryptography completely beyond my understanding, and it is believed the exploitation requires cryptographer expertise.
Zcash kept the issue secret, and might have only informed one or two other projects. I’m sure it was an explicit decision to not inform the greater spectrum of Zcash projects, for fear of a leak. To me, as far as I can tell, the issue is extremely technical in nature and likely requires intimate knowledge of cryptography.
Our Assessment
Regardless of how difficult the issue is to take advantage of, we still need to upgrade in case someone does decide to make the procedure so easy even a script kiddie could do it. As with anything that affects monetary policy of BitcoinZ, it could be dangerous to not address. We had planned to rollout VaultZ before the announcement and this changes our focus a little bit.
UPDATE: We’ve been informed one method to determine if the blockchain is compromised is to run ‘getblockchaininfo’ on a BitcoinZ node and check the chainValue object value under ValuePools -> sprout. If ths value is greater than 0 then most likely no exploitation has occurred. This is apparently the amount of coins in shielded addresses. At time of this writing getblockchaininfo outputs the following value greater than 0:
"valuePools": [
{
"id": "sprout",
"monitored": true,
"chainValue": 267949918.11088412,
"chainValueZat": 26794991811088412
}
Option 1
We’ve discussed just patching our codebase with Groth16 and adding in VaultZ, but the other option is to upgrade to the newest Zcash codebase (Sapling) which changes the proving method and also includes code for ‘Community Fee’, as Zcash, if I remember correctly, cuts out 20% from their block reward for a development fund. Of course, that would be adjusted down to the agreed 5% for VaultZ.
If we forked the latest code, work would need to be done to:
- Integrate Zhash
- Adjust the Fee down to 5%
Option 2
We could patch the current codebase with Groth16 and integrate VaultZ and the only thing left would be update pools and exchanges (Option 1 requires updates to exchanges and pools as well), but this leaves us behind in the code base.
My personal feelings on upgrading to the newest is their stability. I’ve never been inclined to follow releases so closely, but that is my own personal opinion. I would still also like to have the latest as it probably contains some fun features, right?
If we just patched, we would need to,
- Move to Groth16,
- Integrate VaultZ
It sounds a lot easier in this writing than it takes to do the actual work, a lot of coordination takes place to upgrade a blockchain, as some of you might have noticed during our move to Zhash.
The Road Ahead
Regardless, we are addressing the issue in some way and we’ve had VaultZ in the works for some time. If we’re going to perform a network upgrade, we need to take advantage of the coordination it requires to implement network upgrades/changes. So any activation of new code should be deployed together. At least that is our goal.
Things are a little slower since we don’t have paid full time developers like some projects, but we were partially going to address that with VaultZ, not to pay current members on the development team, but to pay in BTCZ for certain tasks to be completed on the project.
We are in communication with other Zcash-based projects and are keeping an eye on further developments that could potentially affect our blockchain. We’ve not discovered or been informed that anyone has taken advantage of this issue on our blockchain, but we still need to address it to protect BitcoinZ moving forward.
Long Live BitcoinZ and the BitcoinZ Community!
Further Details
