It is evident that there are ASICs mining Ravencoin. As I’ve stated many times, there isn’t anything wrong with specialized hardware mining on the Ravencoin network. In fact, a case can be made that specialized hardware adds stability to the hash rate because their hardware isn’t useful anywhere else. This creates a sort of lock-in to the coin.
So, why the angst about ASICs? Because the Ravencoin’s whitepaper discussed ASIC resistance and the desire to keep ASICs off the network. Why was that in the whitepaper? Because there’s also a strong argument that wide distribution of a coin (RVN) is healthy for the network. Imagine if everyone in the world had one RVN. That would be a near-perfect distribution, and at that point, each individual could decide whether to hold, spend, or trade their RVN. Allowing consumer-grade hardware (CPU or GPU) to mine is closer to the distribution ideal.
At this point, we have these two ideals in tension. We have dedicated hardware, which is good for commitment to the Ravencoin network in tension with the wide distribution ideals of profitably mining RVN on consumer-grade hardware.
There’s a reason that I’m not overly concerned about the existing CPU/GPU/ASIC mining ratio and mining difficulty. It isn’t an existential threat to the Ravencoin ecosystem. For the sake of argument, let’s say that the algo never changes from here. The worst-case scenario is that Ravencoin starts to look more like Bitcoin with some concentration of mining power in the hands of data farms with specialized hardware and low power rates. These commercial operations are mostly concerned with profit, so they will sell the RVN on the open market. This adds downward price pressure more so than GPU miners that hold, but on the flip side, it allows anyone to inexpensively get a stake in RVN in these early days. What would you give to be able to go back in time to 2011 and get Bitcoin knowing what you know now?
First, let me address the previous algo change. The intention was originally to have something more ASIC resistant, but there were other circumstances that necessitated accelerating the change to address two critical bugs. For anyone that missed it, more info is in the update here. https://medium.com/@tronblack/ravencoin-upgrade-retrospective-705707b4b51
Ok, so what about changing the mining algo again? We have a large community of miners and most are GPU miners that would like to mine profitably. So, how can we make mining profitable on GPUs? Well, there are a number of well-intentioned folks that say it is impossible to keep ASICs off the network. They may be right, but I’m convinced that there are algorithms that use enough of a GPU’s capabilities and strengths, that making an ASIC for the algorithm will make it look, and perform very much like a GPU. So let’s set that as our goal.
Another issue to think about is the feasibility of the algo for a mobile wallet that must validate blocks. There are two options: 1) Make sure the algo can be implemented for mobile (iOS and Android), or; 2) lose the self-validating SPV wallet option. The current mobile wallet checks each block to make sure that the blocks are valid and chained together. This is great for security and a best practice, but may not be strictly necessary. If a mobile wallet is spoofed, it leads to a bad experience but does not allow counterfeiting of RVN. Most mobile wallets are API-based and do not need to validate blocks by executing the mining algorithm. The two exceptions I’m aware of are tZero Wallet and the RVN Wallet which do validate every block. The iOS version of tZero wallet has been converted to an API-based wallet to improve user experience.
There are other critics that point out that there is no way to eliminate FPGAs or ASICs, and that with enough incentive, they are capable of everything that a CPU or GPU can do. I agree with this, but as an algorithm pushes the boundaries of the CPU or GPU, the ASIC loses its advantages as it begins to look like a general-purpose computer or a graphics card. The goal then is to neuter the special advantages of special-built hardware.
I have also received criticism, some private and some public, that the existing proposals in the #algos channel of the Ravencoin Community Discord is largely driven by those with FPGA-driven motivations. From my perspective, that doesn’t seem to be the case, but it is difficult to vet an untested algorithm and how well it would resist the engineering efforts of FPGA developers.
Ok, so let’s assume that we switch the mobile wallets to API-based or remove block validation and open up maximum flexibility for an alternative mining algorithm.
Moving to a CPU-only algo is an option, but the majority of the Ravencoin community is GPU, so for that reason, the goal is to favor GPUs.
Which algorithm to use?
- Keep x16r variant (roots and branding)
- Reduce ASIC to be similar to GPU.
- Have an algorithm that isn’t identical to another coin to prevent coin hopping and reduced security
With these goals in mind, a few options come to mind. One is to integrate an existing GPU friendly algo into x16r. There are two ways of doing this. One is to swap out one of the existing algorithms with something GPU friendly like progPOW or Ethash. The only problem with this is that there is a significant speed disparity between the existing 16 algos and something like Ethash. This can lead to gaming of the system by only solving blocks that don’t include the Ethash in the 16 bytes that determine the algos for the next block. This can be easily solved by using x16r as-is and then always swapping out one of the algos for Ethash. To increase security and prevent pre-caching of the Ethash solutions, we could insert Ethash into algo 2 through 15 (when counting starting at 1).
- Bitmain E3 ASIC — 190MH/s @ 760W
- Innosilicon A10 ETHMaster — 500MH/s @ 850W — $5000
- 1070–30MH/s @ 150W
- 1080Ti — 50MH/s @ 250W
- Titan V — 75MH/s @ 250W
Currently, the best public ASIC is the Innosilicon A10 and is the equivalent of about 10 1080Ti. This does outperform GPUs
Mining stats: https://minerstat.com/coin/RVN
- 1070Ti 20MH/s @ 150W
- 1080Ti 35MH/s @ 250W
- OW1 182MH/s @ 1400W
- Rumor 680MH/s @ 800W
To my knowledge, there currently isn’t any overlap between the x16r ASIC manufacturers and the Ethash ASIC manufacturers and they seem to be using different technologies (Xilinx chips vs custom silicon). I’m open to being corrected on this.
Ok, there are millions of possibilities for combining algos. I’m going to propose one that meets the goals outlined above.
It begins with the original x16r. x16r is well documented.
The first phase is x16r, but before the hashing begins, the 16 nibbles are summed up, giving a number between 0 and 256. Take the mod 14 of this number, which will give a number between 0 and 13, and then add 1, giving a number X between 1 and 14. Then replace the algorithm in position X with Ethash.
So there will be 16 hashes chained, and one of them will always be Ethash, and it will never be the first or the last hash.
It is a simple melding of two known ASIC resistant algorithms which forces the FPGAs/ASIC to implement both algorithms where they are only slightly more efficient in either one. The characteristics of each (x16r and Ethash) are well known, while the ASICish solution for each has been different.
I welcome feedback on this proposal.
Shortly after publishing this, there was feedback on twitter and Telegram questioning why it wasn’t progPOW instead of ethash. My response was that I had heard that progPOW wasn’t as ASIC resistant as previously thought and in the absence of a longer track record, I’d need evidence that it is an improvement.
The evidence was sent. Here it is:
For these reasons, progPOW might be a better choice. All of this assumes, of course, that we lose the direct block proof for the SPV wallets, or add some additional data to allow fast block hash validation. We are exploring the latter.
I’ve also received private feedback on Alterhash and why it would be better than progPOW or ethash. However, Alterhash was benchmarked by @blondfrogs and we ran into a problem that we got only 66 hashes/sec on a pretty fast Linux box (single-threaded). We did the math and it would add hours to sync time on a fast machine and potentially days on a slower machine just to properly validate blocks.
Currently, we are experimenting with progPOW which is closer to 1500 h/s on a fast Linux box. There are some discussions about adding the interim hash found during the memory-intensive portion of the mining so that SPV wallets can verify blocks.
Feel free to DM me @Tron#2687 on Discord. I’m looking for reasons that the original proposal (x16rE) is better or worse than x16r+progPOW (x16rP), or Alterhash which also integrates the two and is going by xdag16r.