Announcement: BitcoinZ Current zkSNARKs Proving Method


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:

  1. Integrate Zhash
  2. 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,

  1. Move to Groth16,
  2. 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

Zcash Vulnerability
Correspondance to ZEN & KMD

Implementation of Sapling + VaultZ Proposal at 5.00% Blockchain Reward

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


Hi @cryptorex, many thanks for this input about the coming update(s) in the BTCz blockchain.

If I understand correctly the 2 options:

  • Option 1: Update to VaultZ with zapling. Asuming that this is the latest Zcash core update (that could again have some vulnerability).
  • Option 2: Update to VaultZ without zapling, and we assume that the Q1 2018 vulnerability is also patched with Groth16 (It is NOT the case in the actual BitcoinZ core).


  • Groth16 update is patched against the Q1 2018 vulnerability, but not updated to sapling.
  • Sapling (the latest Zcash update) improvment is mostly for schielding coin with a mobile device (Z-addresses)… but unknow vulnerability are possible.

I think that the actual question is :

  • Do we need Sapling right now ? Or can we wait a other 6 month (or one year) to update the BTCz blockchain to Sapling ?

My opinion would be to play the security card…



Thanks for update…
Would we be ASIC resistant with Option 1 (Sapling) with some parameters update?


@Marcelus - My understanding is Sapling still uses Groth16 so its considered ‘not vulnerable’.

To be honest, we would rather just get this update out of the way together since it still requires forking. Too many forks too soon I think is a real pain in the ass to coordinate and we don’t have a full-time dev team.


I think BTCZ needs anytime the ZCash update “Sapling” before ZCash implements the new StarkWork features, wich will adapt ZCash from zkSNARKs to zkSTARKs.

Eli Ben-Sasson is the co-founder of ZCash and StarkWare:


Thanks for all the hard work!!!


Please update your nodes or windows wallet. All other 3rd party wallets have been addressed (Coinomi, Zelcore) as well as BTCZ Co-pay. Node version 1.4.0 shutdown at block 313,512.

Please find updated builds and binaries here.

Linux build & binaries:
Windows CLI build & binaries:
Windows Swing Wallet:

Other News

Team renuzit seems to be is making great progress with our major update to zcash core 2.0.3. This will address the proving method ‘vulnerability’, among other upgrades.

The latest progress is blocks are being successfully mined on testnet:

There are a few other things to tidy up then we can start scheduling further updates and announcements.

Please stay tuned.


Hello everyone - we’ve had great progress in addressing zkSNARKs and VaultZ.

On testnet it appears we’ve addressed all consensus compatibility with Zhash params 144,5 and previous blocks that were 200,9.

We’ve also completed testing the following:

  1. shielded coinbase coins using z_shieldcoinbase" from multisig one - “t2FpKCWt95LAPVRed61YbBny9yz5nqexLGN” to a sapling z-address
  2. sent from sapling z address to single wallet tmQaL15dnng34TNknZiedx9qjRpaHihJMT6
  3. sent from t single wallet tmQaL15dnng34TNknZiedx9qjRpaHihJMT6 to sprout z-address
  4. sent from sprout z-address to tmQaL15dnng34TNknZiedx9qjRpaHihJMT6
  5. tried to send between Sapling -> Sprout and was denied, as it should be denied
  6. Mined blocks and the 5% block reward split is being sent to community fee addresses as intended

There is other work to be done, our co-pay wallet system, insight explorer, perhaps windows wallet/binary need to also be built and tested.

Stay tuned, much progress has been made.


Fantastic job guys! Keep it up the good work.
One question: will we loose Zhash?


Nope, we don’t lose Zhash. We will remain on the 144,5 Zhash algo.


Working Windows wallet on Testnet Sapling + VaultZ activated: