New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support of CryptoNight Waltz based on CryptoNight MoneroV8 #216

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
7 participants
@EDDragonWolf
Copy link
Collaborator

EDDragonWolf commented Jan 28, 2019

No description provided.

@EDDragonWolf EDDragonWolf requested review from mbg033 and bitkis Jan 28, 2019

@mbg033

mbg033 approved these changes Jan 28, 2019

Copy link
Contributor

mbg033 left a comment

only thing is we need to discuss/plan actual dates for v12

@jagerman

This comment has been minimized.

Copy link
Contributor

jagerman commented Jan 30, 2019

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:

image

@Patrickdurbin

This comment has been minimized.

Copy link

Patrickdurbin commented Jan 30, 2019

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.

https://github.com/graft-project/GraftNetwork/tree/feature/cn-heavy-pow

Although I guess its winter time I can use the extra heat.
It will be more profitable to mine something else and buy graft.

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

@EDDragonWolf

This comment has been minimized.

Copy link
Collaborator Author

EDDragonWolf commented Jan 31, 2019

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.

@jagerman

Can I ask why you decided to tweak CNv2 (aka CN-MoneroV8), rather than CNv0 (the original cryptonight)?

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.
Anyway, CNv0 has the largest possibility to be supported by FPGA than any other CryptoNight variants, as well as it has the largest computational power on Nicehash (than other CryptoNight-s), so it potentially means that Nicehash can add support of CNv0 tweaks.

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:

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.

@Patrickdurbin

It would have been just as simple to change the iteration changes to the heavy!

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.

Rx580 8gig will get 1156 hashs vs 980 hashs on cnv8 on cheap elpida/Hynix memory.

I do not think, that direct comparison of hashrate of algorithms makes sense, only if the goal isn't to see larger hashrate.

Then when monero forks again.

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 😄)

@Patrickdurbin

This comment has been minimized.

Copy link

Patrickdurbin commented Jan 31, 2019

@EDDragonWolf
I wasn't meaning to compare hashrate's on different algos in reference to total network hashrate.
I was merely pointing out.

Heavy is less profitable on fpgas then cnv2... .
cnv2 is less profitable on GPU's then Heavy.

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.

Minimumprofitableprice=Hashvalue*Difficulty/Blockreward

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.
He embraced it and brought the profitability so close it doesn't matter.

Instead of tweaking to get rid of nciehash and making gpu's 10x less efficient then any bitstream they could have made.

@yidakee

This comment has been minimized.

Copy link

yidakee commented Jan 31, 2019

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.

@jagerman

This comment has been minimized.

Copy link
Contributor

jagerman commented Jan 31, 2019

Because we already use it.

Just like the chain already uses CNv0 and CNv1 (you can't sync the chain without them).

from our current point of view, there isn't a big problem to be based on CNv8 and advantages to moving back.

I already gave you one: noticeably lower power consumption from GPUs that miners would appreciate.

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.

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.

FPGA support can be even advantaged for increasing network hashrate if FPGA miners will support network decentralization.

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."

Anyway, CNv0 has the largest possibility to be supported by FPGA than any other CryptoNight variants,

This is just plain false. FPGA bitstreams have been developed following profitability, which is why effort went into CNv2.

as well as it has the largest computational power on Nicehash (than other CryptoNight-s), so it potentially means that Nicehash can add support of CNv0 tweaks.

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.

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.

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.

I do not think, that direct comparison of hashrate of algorithms makes sense, only if the goal isn't to see larger hashrate.

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).

@Patrickdurbin

This comment has been minimized.

Copy link

Patrickdurbin commented Jan 31, 2019

cnv2 fpga (widespread 8,000 hash first bitstream)
cnv2 fpga (second generation bitstream 25,000 hash)
cnv2 fpga (private 100,000 hash/s bitstreams) (rumored)

cnv2 Rx580 1050 hashs max
cnv2 Rx580 880 hash min

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.

@bitkis

This comment has been minimized.

Copy link

bitkis commented Feb 1, 2019

Please see a "help wanter" #223

@bitkis bitkis closed this Feb 1, 2019

@SChernykh

This comment has been minimized.

Copy link
Contributor

SChernykh commented Feb 1, 2019

cnv2 fpga (widespread 8,000 hash first bitstream)
cnv2 fpga (second generation bitstream 25,000 hash)
cnv2 fpga (private 100,000 hash/s bitstreams) (rumored)

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.

@Patrickdurbin

This comment has been minimized.

Copy link

Patrickdurbin commented Feb 1, 2019

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"
The closer together they are in profitability GPU's/fpga's set the minimum profitability on network difficulty ( If the price minimum profitability is set to the most efficient gpu) the price will rise slowly based on blockreward reduction and difficulty as well as pumps) (if set to the most efficient fpga the price will drop slowly over time as it dumps far below gpu profitiblity)

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.
"Closed" no input from the team....
#223

Just automaticly asking about a CNV0 tweak

which makes GPU's more efficient then Gpu's on cnv2 (lack of squareoot)
But the fpga's have even further away performance.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment