Starting with June we could see that the Zcash Blockchain started being attacked via Orchard txs bla bla.
In this time, we have seen a HUGE grow in the size of the Zcash Blockchain (2gb/day), syncing periods went up a lot. My idea is that the attackers are purposely driving up the size in order to make a 51% attack on the nodes, as well as getting 51% of the hashrate later (it’s quite cheap doing it now), thus forcing legit blocks to resync and make historical changes .
I have operated nodes a long time ago. In my ‘frugal’ way of thinking, I would never take into assumption that nodes could bump so drastically in size, and I wouldn’t have updated my hardware to fit, thus reducing me and a number of nodes to dust. Second, it vastly increases the cost of maintaining a node, so it would make me quit either way.
Another anomaly is mining rewards.
I have been mining Zcash since it’s inception. I have seen a huge collapse in mining rewards, without any clear or explainable reason( I am monitoring hashrate, difficulty and halving religiously as mining is my main income). At one point rewards were <50% of their calculated estimates.( This being a problem until recently).
[ I have had a pause in mining from may to october because some gypsies stole my mining farm (facts, not being racist); got ahold of some miners at the end of october, so I wasn’t really paying attention in that period.]
My first thought was that it is a pool problem, so I switched 1 z11 per each of the following pools:
Viabtc
f2pool
antpool
poolin
2miners
Luxor
Except for the payment method differentials (PPS, PPLNS) rewards were ~ identical.
I have contacted the Luxor team (nov-dec), asking them for ideas on why the KNOWN hashrate plummeted, difficulty remained the same, and rewards reduced drastically. They were as surprised as I was about the problem.
I think that the SandBlast phenomenon was exclusively based on the Sapling protocol, at least as of last June. So, not Orchard, but I don’t have any useful insight apart from that thought.
Potentially, miners many decide to drop shielded transactions to get an edge. F2pool was doing it for years allegedly.
Obviously, it would not be good for the network and it is another reason why the spam is hurtful.
Hashrate can only be estimated directly from difficulty, or from pool shares. Assuming the latter, that means winning shares are purposely withheld.
But this should be quite noticeable for the pool. If an honest pool miner submits some large number N of shares in some time period, all passing the share difficulty threshold d, then approximately N*d/D of their shares should pass the global difficulty D.
So I’m skeptical when you say the pool has no clue what’s going on…
I have a hunch that due to points you raised we can also see the negative impact on ZEC. It has been abysmal in recent months while all other up-and-up altcoins and bitcoin showed strength. If the protocol was emitting coins at a problematic low difficulty then miners were further incentivized to cash out.
To HanH’s point, and I’m becoming a broken record on the forum about this topic. T-addresses are destructive to Zcash in both the near term and long term. The peculiarities of how miner pools treat T or Z transactions furthers my point. Zcash are not actually fungible (in a pragmatic sense) if major network participants favor one coin type vs the other.
T-addresses have historically been important because integrating support for them has been far easier than integrating with the shielded pools, thanks to the similarity with Bitcoin. I 100% want T-addresses to be removed—I think it’s really important because people have been confused into thinking T-addresses are private because “Zcash is private”—but before doing so, we need to make shielded pools easier to build with.
In Zingo, the only possible spend from the transparent pool is to the User’s Orchard pool. It’s possible to receive to a t-address which is the only way to interact with apps that only support t-addresses. In Zingo, if there’s more than a fee worth of transparent value, the User is offered a “Shield” button which sends the transparent funds to the User’s Orchard pool.
In Zingo, we balance the usability benefit from allowing receipts to t-addresses, with a User-controlled “Shield” button that prompts the user to move that transparent value into their own Orchard pool.
