Hello Blossom


I did a test with zecwallet FN v0.8.0, obviously block times are what they are and the difficulty is doing a pretty good job of what it’s supposed to I’d say, from send to confirm it took about just over a minute, pretty nice! :hibiscus:


FYI. The new block height (post Blossom activation) for the first Zcash halvening and sunsetting of the FR is 1046400 which I’m currently estimating to occur about 12:30 UTC on 11/16/2020.


Edit: The following is wrong. There was no drop in solutions-per second, and difficulty-per-block halving was as expected.

How come the mining difficulty (in solutions-per-second) dropped by half after Blossom activation?

Are miners running old versions of zcashd, past their EOS-halt date? Or are they running some external tx/block-processing code that needed udpating?

Or is the reporting of solutions per second (by zcashd and several explorers) somehow not adjusted for the new block time?

The drop was expected and simulated.

In short: the block target spacing was halved, but the difficulty adjustment algorithm was itself left unaltered. This meant that once Blossom activated, to the difficulty adjustment algorithm it looked like blocks were taking twice as long as they should be, and it adjusted downwards to compensate. The simulation indicated it would take around six hours to stabilise, which is basically what we saw.

But it looks like the difficulty persistently dropped from ~80M to ~40M sol/s and is still there now.

(Zcash Difficulty Chart - ZEC Difficulty - CoinWarz)

If correctly calculated then it indicates real loss of hashpower, no?

That’s the difficulty, not the solution rate. Looking at data either side of the activation height:

$ zcash-cli getblock 653500
  "hash": "0000000000bde7f5b3d3852ed5ecea28c8a9f65fdfb1b98f10380e03a69e2d62",
  "height": 653500,
  "time": 1576086518,
  "bits": "1c01b53b",
  "difficulty": 78584808.9000545,
$ zcash-cli getblock 653800
  "hash": "0000000000bb8a66ecafbe66333ce91845f9395f3c1b5a48754ce44c474b8856",
  "height": 653800,
  "time": 1576117299,
  "bits": "1c02c011",
  "difficulty": 48801750.12894958,
$ zcash-cli getnetworksolps 653500
$ zcash-cli getnetworksolps 653800

Put another way: the only two variables that affect the block emission rate are:

  • The difficulty (inverse of the target uint256 that a block hash must be lower than to be valid).
  • The network solution rate (Sol/s).

For a fixed network solution rate / stable population of miners, the difficulty was required to halve after Blossom activation in order for the target block spacing to halve. The fact that it basically exactly halved is a good indication that we did not lose any miners across the network upgrade.


Ah yes! I mis-parsed that website (and was fooled by coincidental similarly between the leading digits in that graph vs. Sol/s as reported by zcashd at the moment when I last compared them). I thought they were converting the difficulty to implied solutions per second.

It’s all good!