Releasing mining rewards over 50 weeks

Mining
163

Just got curious about how verus has setuped everything so i tried it out the last 2 days. Actually it’s an more than interesting approach they took. I will just make some comments about the things that got my attention and where/why i think that this approach by verus is way better than the blossom harmony upgrade:

  • First of all the time lock of coins was just for the first some months as it seems. Now half a year later i can’t see any block rewards time locked. Seems the time lock was for 3 months. Someone can live with this having in mind that the CPU electricity consumption is way lower than asic & gpu electricity consumption.

  • Second, seems these guys at verus indeed favour cpu mining. I just tried out the mining with my CPU, I7-8700k and a gpu 1080ti to compare them. Amazing result. The cpu mines at 22-23 MH/s while the 1080ti mines at 2.5-3 MH/s. That’s amazing and i really liked it.

  • 50/50 POW/POS seems really fair and good for security as well. As a POS and hybrid POS fan i anyway think this is the way to go in 2019.

  • The CPU mining is possible even within the agama wallet they use. Just a great feature just by entering the CPU threads number you want to use and hit “start mining” and you are done. Sure, it’s solo mining there only, but it’s still easy and great to see how easy they made it for everybody that can install a miner to particapte in the mining process. For mining pool mining there is a need to use a nhminer, still easy to setup with everybody familar to gpu mining, but not for everybody.

  • Various anti-cheat, anti-farm, anti-asic/fpga measures. Someone can mine/stake only from 1 wallet.dat file which is again great in my opinion. As soon as superior FPGAs have been spotted on the network the guys there immediatly changed the algo to ensure CPU’s are favoured over all other possible hardware, again, not bad. Interesting that staking is taking place on unshielded adresses only from what i can see, no matter they had to go through the process of shielding and than unshielded again. My guess is that this is for more transparancey, but i could be wrong here. And very importnt in my opinion defence against bot nets.
    Not sure, but i think nice hash traffic is blocked as well, be it by accident or intentionally.

I wished zcash would take a similar direction as Verus (fork of Zcash and komodo). While it’s indeed a very small coin/project so far, no doubt, things are done way more easy on their end. However, i think they will achieve maximum security and decentralization this way with way less electricity consumption.

Now sure, ZEC is a different story and scale, but imagine that such approach would be applied to ZEC makes me dreaming about the positive impacts it would have… But than again, we are going with Harmony Blossom … was just dreaming for a second :thinking:

P.S. & Edit: I really think the Zcash should have some eye on competitors and/or possible competitors like Grin, Beam, even Verus if you want and frequently check what they are doing, what approaches lead to what instead of watching only ETH & casper from distance… Competitors aren’t sleeping …

164

Harmony Mining has been postponed until further analysis can be done. It will not be included in the next Blossom upgrade scheduled this October.

Per @nathan-at-least :

Hello all, back from vacation. While I support the design requirements both @zookozcashand I laid out above for a Zcash upgrade, I’m going to advocate within our company that we postpone Harmony Mining from NU2-Blossom (with NU3 being the next candidate slot).

There are four logistical/technical (not strategic) reasons for doing so:

  1. We are behind schedule for Blossom / NU2, according to The Network Upgrade Pipeline, Upgrade B 2019. According to that plan we should be in the midst of third party security auditors analyzing our specification while we work on implementation.
  2. There is no clear leading candidate for block selection design (including difficulty-adjustment), and I believe the “rewards ramp-up” + time-locks are inseparable and thus inter-dependent on the block selection design.
  3. @daira’s simulation is precise for two designs, and shows in both cases a reduction in rollback protection. Even though @zookozcash clarified that a regression is acceptable, I want a stronger understanding of how much of a regression a given design introduces (and then to weigh that against advantages we’re trading off for).
  4. I haven’t looked at existing designs yet, and I’m not aware of any company engineers doing so, yet, and our best effort should verify scrutinize similar designs, their security models, and our different requirements and design choices. (Much love to @zawy12 for linking directly into Grin DAA code in this comment! That’s a good start, though I’d want to start by looking for security models / design rationale.)

We’ll continue R&D for these design goals on the NU3 Upgrade A 2020 slot.

So this means that this proposal of releasing the second (GPU mining) algorithms rewards over 50 weeks is also postponed.

5 Likes
165

This one made me smile, including it in NU 3 2020 is even worse than in NU 2 and 2019 in my opinion…

1 Like
166

@boxalex Can you elaborate? I’m not sure why it would be worse after more is known.

167

As said allready, it was a bad idea allready for NU2 and working on it a full year, now postponed to NU3 and working another year on it doesn’t make it even worse. Of course it makes sense to postpone it if there are security concerns or whatever.

But having working on it for 2020, after ETH allready switched to POS and leaving only gpu miners profitable at best in up to 5 cent regions makes about 0 sense. Working on something 2 years that will be absolutly outdated, unprofitable and even more useless than if included in 2019 makes me indeed smile. Actually it just proofs that by now exactly 0 professional research by an unbiased institute/experts has been done

I would go even as far as saying that this postpone will be a present to the current, new and upcoming privacy coins on GPU POW algos. Pretty sure that they these will be more than happy to not have any gpu competition from ZEC the next 2 years and give them time to build up to become indeed a potential competitor to ZEC.

Seriously & honestly, no matter i was an asic miner, the right moment for a 1st or 2nd gpu algo was right after sapling release, immediatly and asap, leave alone the time lock issue. As for more reasons, read my long posts above for all the various reasons that will as well apply in 2020. Just my 2 zatoshis…

168

@MyloKomodo

just saw the Komodo newletter and some comments you made there about the zcash community discussing the time lock issue.

The zCash community forums have been discussing time-locked rewards. They discuss various problems they need to overcome, time-locked block rewards for pool mining has been brought up. I don’t think they could create a solution in less than a week or a month, let alone this solution built on crypto-conditions by jl777 in less than a day. (Incidentally, one keen researcher finds Verus mining concentration – however they also don’t realize they are looking at old data. Hope this doesn’t prove to be a costly error for their community).

Seems the keen researcher is me as i pointed out that there is a mining pool concentration on verus. Actually as i’am my own testing out Verus with cpu mining after i got intrigued by the approach they have choosen.
When i made my comment than back i wasn’t aware that there is solo cpu mining from the agama wallets which indeed changes the picture:

Explaination:

Network hashrate: 175.28 GH/s
by mining pools: 97.40 GH/s (55.57%)
by solo miners: 77.88 GH/s (44.43%)

When i checked than back the hashrate i wasn’t aware of these wallet solo miners and saw only the mining pool hashrate distribution:

52hash.com (China): 81.69 GH/s (84.8%)
luckpool.net (Canada): 10.04 GH/s (10.4%)
jeepool.com (China): 4.17 GH/s (4.3%)
others: ~ 400 MH/s (~0.5%)

Means that 52hash.com has 46.6% of the total hashrate and not how i indeed stated 80-90% of the hashrate due the wallet solo miners. But than again, this mining pool has more hashrate than all solo miners together.
I could imagine this could be a problem if for some reason, for example a wallet problem, during wallet updates or whatever reason the wallet solo mining function doesn’t work this mining pool would have automaticlly indeed over 80% of the hashrate. Isn’t this a cocern at all?

Other than this you pointed out in your newsletter that the mining pool NOT paying out mined time lock shares/rewards or going out of business is fixed with a code implentation. As this was a concern too i’am happy that this can be fixed at least. Copying over from your newsletter:

A sample of mining pools paying out 2 shares to a time-locked contract address indicates that miners no longer have to worry about a pool going out of business. marmarapoolpayout 0.5 2 ‘[
[“024131032ed90941e714db8e6dd176fe5a86c9d873d279edecf005c06f773da686”,1000],
[“02ebc786cb83de8dc3922ab83c21f3f8a2f3216940c3bf9da43ce39e2a3a882c92”,100]
]’;
That takes half percent pool fee, scans coinbases starting from height 2 and distributes to the pubkeys with shares of 1000, and 100 & it generates a signed rawtx that spends all the eligible coinbase.

“firstheight”: 2,
“lastheight”: 59,
“total”: 87,
“totalpayout”: 86.56706466999999,
“totalshares”: 1105.5,
“poolfee”: 0.43293533,
“perc”: 0.5001155250560722,
“payouts”: [
{
“024131032ed90941e714db8e6dd176fe5a86c9d873d279edecf005c06f773da686”: 78.69733152000001
},
{
“02ebc786cb83de8dc3922ab83c21f3f8a2f3216940c3bf9da43ce39e2a3a882c92”: 7.86973315
}
]

So pools would need to use this for their payout, but they feed in pubkeys and shares. the end result is CC locked payments to each miner groups of 60 blocks all unlock at the same height, so they can be combined hourly (however many coinbases a pool mined)