Dec 11 ·14 min read Recently, we found that many people are curious about the relationship between ASIC and ASIC resistance and want to know the relationship between different algorithms and mining methods.This article mainly describes the possible changes in the future of Ravencoin’s thinking on ASIC.Although some of questions and thoughts in the article have results (here is an article about the algorithm implemented recently in Ravencoin), the analysis process and thought method in the article still provides a very good way for logical analysis essentially.By reading this article, we can know the factors what a developing project needs to be considered when someone want to implement ASIC resistance and the basic logic of analysis.Author: Tron Black Source: Tron Black ’s article in Medium In January of 2018, the whitepaper for X16R was published with the suggestion that it was an ASIC resistant algorithm.It has been about a year and a half, and although the hash rate and profitability do not suggest there are ASICs on the Ravencoin network, there is some evidence that there might be an ASIC being built , or possibly deployed.
I’ve been told privately that FusionSilicon tried to create an ASIC and gave up.There’s also a paper suggesting that one mining pool has a high hash rate .
So, now what? Well, here are some of my thoughts… Yes, I know you didn’t ask for my thoughts.An ASIC isn’t evil but as I stated in the original whitepaper, “The unfortunate side-effect of this transition to ASIC hardware is the centralization of mining.” This is made even truer by the fact that we’ve suggested we don’t want ASICs on the Ravencoin network, so they will likely be running on a hidden pool, and not be sold to everyone.An ASIC is just a chip that is optimized for one specific purpose.This is right in the ASIC name as it stands for A pplication S pecific I ntegrated C ircuit.
The specific application is mining with a particular algorithm like x16r, and an Integrated Circuit is a microchip.ASICs can be faster because they do one thing well, and can ignore everything else.An analogy is an Olympic marathon runner whose body composition is built for speed and distance only vs.
a decathlon athlete that might be built differently to be able to do pretty well on ten different athletic skills.The marathon runner might not be able to shot put very well because the light, lithe, lean frame needed to win a marathon isn’t well suited for shot put.Those types of tradeoffs exist when making a fast mining chip.Therefore a mining algorithm that forces a chip to do many varied tasks is considered ASIC-resistant, and this runs on a continuum.So what if you combined marathon running with weight lifting with Sudoku solving? It gets harder to optimize for one without sacrificing something for the other tasks.The muscle-bound weight lifter has trouble quickly running 26.22 miles, while the light, lithe marathon frame has trouble lifting hundreds of lbs.
Throw in the additional uncorrelated task of solving Sudoku, and a custom athlete is trickier to find/build.That is the premise of ASIC-hard algos.There are several of these: · RandomX — A leading candidate for the next Monero hard fork.· CNv4 ( CryptoNight R ) aka CN-V9 — The current Monero algo.
Favors CPU s.GPUs possible.ASICs difficult.
· ProgPOW — An algorithm designed to favor GPUs over ASICs Is centralization bad? I would argue that yes, in the context of a crypto-currency, you do not want centralization.If a government or small collection of governments can shut down the mining, or request that certain transactions not be allowed, then a lot of the benefits of a crypto-currency, or crypto-asset platform has been lost.
If, on the other hand, CPUs everywhere are mining, then there is no way to make such a request.I do not think ASICs are dominating the Ravencoin network.
I believe this because I’ve done back-of-a-napkin math to evaluate the profitability of a 1080 Ti mining rig we have at the office.At the time of the calculation a few weeks ago, it is making about $300 and costing about $65 in electricity.We do not know how much faster an ASIC can be than a GPU for x16r.
But if there were a lot of ASICs that run thousands of times faster, then GPUs would be wildly unprofitable, and that isn’t the case.
Our rig is still running a profit.In the Ravencoin Whitepaper , it said, “Create a platform like Bitcoin with a new mining algorithm, x16r, intended to prevent immediate dominance by mining pools, and future dominance by ASIC mining equipment.” x16r has worked well so far those both goals, but the final goal of preventing future dominance by ASIC mining equipment is in question.So, it seems like we should at least address the issue of potential ASICs.Let me state up front that there are some opposing an algorithm change.I do not believe that these individuals have an ASIC, and therefore a hidden agenda.And they make a valid point that changing mining algorithms can be risky.
During the transition, the mining hash rate can drop and the security can be reduced.If the existing miners don’t follow or additional miners aren’t added to make up the difference, then the security of Ravencoin is reduced.There is also the valid argument that a contentious hard fork, which ironically the folks leading the charge to keep it the same are more likely to make any hard fork a contentious one, may lead to chain splits.This older article about the Monero hard fork describes the outcome of at least one attempt to prevent ASICs.https://medium.com/@ecurrencyhodler/was-moneros-pow-change-a-success-81cfeaa08aae The final outcome was not terrible but led to several new coins like Monero Original, and Monero Classic, although Monero does not have the additional consideration of assets on their chain, and therefore has a lower bar to clear for a successful algorithm change.So let’s explore the options.
Nothing One option is to do nothing.
The x16r algorithm is working.There isn’t clear and convincing evidence that ASICs are on the network yet.This is not a proactive approach, and once there are ASICs on the network, it will require more of a non-ASIC community effort to change the algorithm because simple BIP9 voting will not work if the network is already dominated by those that want to keep the status quo.
Minimal One option is to make a minor change that would be easy for GPU mining software to change.It would likely be one line.Perhaps an XOR with a specific 512-byte value after one of the algorithms.This would obsolete any existing ASICs, but would not have much effect beyond that.
It would be easy for ASICs to adapt to that change for any ASICs that aren’t already manufactured.It would obsolete any custom ASIC chips that are already manufactured whether on-network or not.Medium Another option is to switch from x16r to x21s.x21s was created by one of the forks of Ravencoin.It has two differences from x16r.First, it uses every algorithm every time.As a refresher, x16r uses random algorithms based on the nibbles (half-a-byte) from the previous block hash.
The nibbles which are just random numbers between 0 and 15 determine the order of the algorithms.
If a nibble (number) occurs twice, then the algo will be used twice.The ‘s’ part of x21s prevents an algo from being used twice.Second, the 21 part of x21s add an additional 5 algos to x16r.These algos are evenly slotted in between the 16 algos that are selected by the x16r algos after the duplicates are removed and all 16 have been used.
The advantage to ‘s’ over ‘r’ is that it is easier to tune GPUs because there is less possible variance in load which has been known to cause power supply issues.It has one other big advantage which we’ll cover later.The x21s may be a bit harder to create an ASIC, but only because it has 5 more algos to worry about.But it may be easier to make an ASIC because of the power stability that the ‘s’ (all algos) brings.
I’ve had people privately contact me independently and suggest that ‘s’ makes ASICs easier, and another suggested that it makes it harder.I can’t see how ‘s’ would make it harder, and only varying power fluctuations might make it harder under ‘r’ Neither provided evidence or strong argument for their assertion.Full Another option is to make x17r or an x16rV2 with CNv4 as one of the algorithms.This is a non-starter.If you look at the x16r paper , you’ll find a graph of the relative speeds of the sixteen algorithms.One of the reasons we measured the relative speeds was to ensure that none were so out-of-line that it would make financial sense to wait for blocks that didn’t include certain algos.If you included CNv4 in the rotation of x17r, or even a modified x16rV2 where an algo was swapped out, it would open up other attack vectors to wait until there were 0 instances of CNv4 in the random selection.The reason for that is that CNv4 is up to 100,000 times slower than some other hashing algorithms.
The existing algos in x16r are within an order of magnitude of each other.CNv4, also known as CryptoNight R, is the current mining algorithm for Monero and does seem to have ASICs available for it.It is, by itself, an ASIC resistant algorithm, that also closes the gap between the performance of CPUs and GPUs.For example, a RYZEN ThreadRipper CPU can outperform 2:1 over a 1080 Ti.
There are GPUs that are faster than CPUs, and CPUs that are faster than GPUs in hashing CNv4, so this algorithm puts CPUs and GPUs in the same ballpark.
Another option is to switch from x16r to x16r+CNv4.This simply chains the existing algorithm together with CNv4.This isn’t much different than just switching to CNv4 because the x16r algo can be pre-computed much faster than the CNv4 algo can run on any hardware.Even a mediocre CPU could feed the fastest CNv4 GPU with the output of the x16r calculation.The main advantage of keeping x16r (or something) in addition to CNv4 is to prevent sloshing of pure CNv4 hash power from Monero to Ravencoin when Ravencoin is more profitable.
By having a separate algo, any custom CNv4 only hardware wouldn’t be able to mine Ravencoin.And it keeps the continuity of x16r branding and makes it harder to make a CPU-less ASIC and FPGA because they’d need all the algos of x16r and the CNv4.But, since CNv4 is so slow relative to x16r, it doesn’t add much over just CNv4.Another option is x21s + CNv4.This is easy to build.We already have the code available from another project for x21s, and the output of CNv4 is a 256-bit hash, so the last step of x16r is to take 256 of the 512-bit hash.
That could be replaced with CNv4.This has similar issues as x16r + CNv4 in that the x16r can easily be pre-computed to feed the much slower CNv4.Another option is to switch from x16r to x22s by including CNv4 in the mix.This seems like a solid option.
The importance of ‘s’ where all algorithms are used every time negates the attack vector of waiting until there are no CNv4 in the random list of algos.It makes FPGAs difficult, but not impossible, just because of the sheer number of algorithms that are included.Because CNv4 is randomly positioned in the randomly ordered algorithms, it makes it trickier to pre-compute the feed for CNv4, although it can be done.But it would be a different sequence of algos, and a different number of algos feeding CNv4 each block, so the optimization may not be worth the effort.
Advantages of x22s (w/CNv4) · Some future-proofing against ASIC, FPGA, GPU dominance.· Brings CPUs back into the fold.· Better decentralization.· A relatively straightforward change to make.
· Both x21s and CNv4 have been tested in the field..