Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Support of CryptoNight Waltz based on CryptoNight MoneroV8 #216
Can I ask why you decided to tweak CNv2 (aka CN-MoneroV8), rather than CNv0 (the original cryptonight)? The iteration tweak done here seems almost trivially easy for FPGA bitstream authors to implement: modifying a Monero bitstream to support simply a different number of iterations seems likely to be trivial.
While any tweak would get away from NiceHash (the primary goal here), CNv2 iterations have the disadvantage of being a fairly power-hungry algorithm on GPUs compared to the earlier versions (with things like an low-precision integer square root added to deliberately thwart potential ASIC performance). But also by only being an iteration change rather than any deeper modification, FPGA bitstreams will be so easy to implement (and perhaps even already exist, if the bitstream authors were lucky enough to anticipate different iteration sizes) that we'll likely continue to see GPU miner hashrate being eroded by FPGAs.
On its own that probably doesn't matter that much, but a consequence of this has been that GPU miners have gone elsewhere (predominantly to CN-heavy and variants thereof, it seems). We currently have only 1/4 of the network hashrate happening on known pools:
While any specific tweak will make nice hash incompatible. FPGA would always exists and merge over . So really it doesn't matter which algo you would have used. Cnv0 etc...
Fpgas on cvn2 vs heavy.. .. GPU's are not as profitable.. but fpga's don't have such a profit difference.
FPGA are more profitable on cvn2 then on heavy. While you cnat get rid of them you could make them less profitable. While GPU's with 8 gigs ( todays standard) are more efficient on heavy then on cnv2
It would have been just as simple to change the iteration changes to the heavy!
Rx580 8gig will get 1156 hashs vs 980 hashs on cnv8 on cheap elpida/Hynix memory. Samsung even more. Its far more efficient.
Although I guess its winter time I can use the extra heat.
Constructive criticism isn't negative. So please don't take it this way. Its just if your changing you guys should have at least asked whats the best algo for the miners... (after all) the miners with the cheapest profitbililty sets the lowest price they sell the emission for...
I can tell you exactly whats gonna happen.
Nicehash will be gone.. Then when monero forks again. this simple iteration change.. will be changing on FPGA and all hashrate will come to Graft once again. So although this takes care of nicehash. It still leaves the door open to FPGA. FPGA would rather mine CNV2 then Heavy.
Heavy would have been a better choice with this simple iteration change. Fpga's would have went to the other coins who were tweaked cvn2 before tweaked heavy.
Theres a reason some of the smaller other coins picked heavy. The scratpad was a limiting factor for FPGA
The main goal of this PR, as @jagerman wrote, is a move away from Nicehash, because Hicehash can be used for network centralization and future 51% attacks. We do not think that FPGA bitstreams can be used for it since their cost is larger than GPU cost, but their profit isn't so high at all. FPGA support can be even advantaged for increasing network hashrate if FPGA miners will support network decentralization. However, if you know examples when FPGA was used for large attacks or some large FPGA-based mining pools which support CryptoNight variants, please, provide this information and support us to estimate risks from FPGA.
Because we already use it. Yes, we can simply move back, but from our current point of view, there isn't a big problem to be based on CNv8 and advantages to moving back.
Yeah, this is a problem, however, I do not think that we get them back only because we switch to heavy or heavy-based tweaks.
You are right, and Heavy or its tweak is still the option, however, at that moment we don't see the reason to provide FPGA resistance.
I do not think, that direct comparison of hashrate of algorithms makes sense, only if the goal isn't to see larger hashrate.
Yes, and potentially we will also apply their changes. Currently, we prepare to merge with Monero and plan to make it periodically (of course, with a smaller period than now
Heavy is less profitable on fpgas then cnv2... .
Using heavy brings the cost to mine closer.. meaning gpu's don't get screwed as bad by the FPGA's and the end result is the same.
If you would have forked the iteration on heavy it would have kept Fpga's on it(because they gonna fork anyway) and let gpu's be closer to the profitability of fpga. meaning them being on the network would strengthen it.... but instead the further apart they are it has the opposite effect
This literally made it no more difficult on the fork but kept individual miners.. not getting screwed as bad. While both would solve nice hash. The point I was making was. FPGA would be on the network anyway.. might as well let the cost to mine be closer together per Individual hash value.
FPGA cnv2 aim was to provide more fpga resistance then even heavy. But they managed to fit the bistream and the Squaroot into it. so really it just ended up putting a harder workload on GPU's and fpga's are 3x as profitable.
Heavy 2x as profitable.
With just an iteration change FPGA's with luck will not have to do anything but change itrations. nicehash will be gone. but the GPU miners will be eating a profit difference meaning they leave and fpga's are still 3x as profitable.
hashvalue for gpu's an fpga's are different... meaning fpga's dump at 3x less satoshis.
you want the gpu's and fpgas cost to mine to be as close as profitable.
Furthermore all Nicehash has to do is an iteration change and it supports cnv2. It wouldn't matter if cnv0 or cnv2 had a tweak to thwart nicehash.
Basically to sum it up.. any algo tweak gets rid of nice hash. It would have been better to make profitability of Gpu's close to Fpgas by using heavy with a tweak
That's exactly what CN-GPU algo fireiceuk is authoring does...
IT makes FPGA's as profitable as GPU's... meaning fpga's strengthen the network and you cant nicehash.
Instead of tweaking to get rid of nciehash and making gpu's 10x less efficient then any bitstream they could have made.
The closer the hashing power between GPU's and FPGA, the more democratic and decentralized the network becomes.
This alone should motivate the algo changes.
If GPU are at a clear disadvantage, they will leave the network, and progressively FPGA's will dominate the hashrate.
GPU are consumer level and available. FPGA highly specialized to source and run, so despite not being NiceHashable, the exact same risk factor is enabled.
Just like the chain already uses CNv0 and CNv1 (you can't sync the chain without them).
I already gave you one: noticeably lower power consumption from GPUs that miners would appreciate.
Monero bitstreams (i.e. CNv2) already exist, and are rumoured to obtain somewhere around 100kH/s, making them quite profitable relative to GPUs. Mining profit on Monero and Graft have sunk far below the profitability level for GPU mining.
Modifying a CNv2 bitstream for CN-waltz would be almost trivially easy since all you changed is the number of iterations.
Yeah. Um. That statement is just as true as this one: "NiceHash support can be even advantaged for increasing network hashrate if NiceHash miners will support network decentralization."
This is just plain false. FPGA bitstreams have been developed following profitability, which is why effort went into CNv2.
This thinking is naïve. NiceHash can add support for any tweak very quickly and very easily, but they won't do it unless there is a sufficiently large market for it. It really would be every bit as easy for them to add support for CN-waltz based on CNv2 as it would for a CN-waltz based on CNv0.
Heavy and tweaked heavy algoritms like Haven or Bittube have proven themselves more resilient to FPGA mining. This may be because the algorithms are harder for FPGAs, or it may be because the markets simply aren't big enough to bother the undertaking of writing FPGA bitstreams for heavy and its variants. That wouldn't apply to this CN-waltz tweak because it really would require almost no change at all to existing CNv2 bitstreams.
It is useful and makes sense in that the larger scratch pad size of CN-heavy algorithms ought to be noticeably reduce FPGA hashrates to deal with, but the (double-scratch-pad + half iterations) has quite a small impact on GPU hashrates (and even ends up faster for cards like the 8gb rx580s).
cnv2 fpga (widespread 8,000 hash first bitstream)
cnv2 Rx580 1050 hashs max
considering nicehash will be gone.. but the same tweak requires no change on the bistreams on certain ones.. means that Fpga's will still be on the network on an algo that is 25 to 100x as profitable. however the electricity is 4x that for a fpga then a gpu.
So really its 5x to 25x on certain bitstreams.
None of these exist. FPGAs (BCU to be specific) can't mine cnv2 faster than 1-2 KH/s. It's not FPGAs that mine cnv2 now, it's ASICs. Stellite and Masari forked more than a week ago with simple iteration change and they're still consistently 2x more profitable than Monero.
Even if what your saying is true. GPUs would have been brought closer together to the profitability of FPGA using an iteration change of heavy ; as well as, getting off of the Nice Hash support list.
The further apart in profitability "fpga' sets the minimum profitability on network difficulty"
This is the third fork we have went through because they just fork and never ask questions of what they should do. They keep cloning Monero which is fine... but nicehash always follows monero!!! Monero was never forking to get away from nice hash. They forked to get away from FPGA.
There are two community solutions for FPGA... (fork away every 6 months) or come up with your own FPGA/GPU algo where they are close together in profitability and just let the fpga's support the network with the increased hash rate. Ryo is doing just that with "CN-GPU"
For Graft... heavy with a tweak was the quickest solution. instead of cnv2 with a tweak.
Grafts main problem is they don't take community input as they feel its micromanaging. Then when we prove to them its the right way. They stop taking input and come up with the solution on their own. If we don't agree with the solution.
The answer is always. "we leave it in the hands of the community if they don't like what we did".
No one would want to do anything for free with that attitude.
Just automaticly asking about a CNV0 tweak
which makes GPU's more efficient then Gpu's on cnv2 (lack of squareoot)
If the tweak is a simple iteration change … then graft will be so many fpga's on Graft.. profitilbity will go to zero.
There's no point in going to CNV0 to make GPU's more profitable if FPGA's are more profitable on CNV0 then CNV2.
The best idea is to accept FPGA's will always fork... and just make them efficient... You cant copy monero because nicehash does...
The best soluition is heavy with a tweak or wait for cn-gpu … anything else might as well stick with what you already done because fpga on cnv0 is way more profitable then fpga on cnv2.