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.
More experiments have been done with ProgPOW to learn more about its pros and cons, thanks to @traysi and @blondfrogs. These experiments are going well and we’ve been able to benchmark on a single GPU to get a sense of how it might perform.
ProgPOW seems to have a bad reputation, and yet the ideas and concepts behind it seem technically sound. It is, in general, a derivative of Ethash with parameters that are optimized to fully use the capabilities of GPUs. This makes it trickier (not impossible) to build an ASIC that doesn’t waddle and quack like a GPU. ProgPOW is heavy on memory access. It builds a DAG, which is just a large random dataset to draw from while mixing with the blockheader hash. This data will change every X blocks, currently set to 7500, but might be one of the parameters we modify.
There are some tricks that can be used to be able to more quickly verify block hashes without building the entire DAG on a mobile phone, or changing the dataset every 7500 blocks when validating a newly downloaded blockchain. These tricks will be used to help make SPV wallets, like RVN Wallet, Stibits Wallet, and tZero Wallet still possible to build. These changes can’t be used by ASICs (or GPUs) because the extra intermediate info will not be known until after the block is mined, but would be carried as part of the blockchain solely for faster block validation.
Ethereum is considering moving to ProgPOW, and I’ve read some of the dissenting opinions and they boil down to not wanting to switch twice and risk a chain fork since they’re considering moving to a proof-of-stake model. There is currently some controversy and some additional challenges for Ethereum over ProgPOW.
I’ve also read over the suggested exploit for ProgPOW, and this will also be addressed prior to implementing any derivative of ProgPOW.
ProgPOW will be “tweaked” in order to make the algo unique to Ravencoin. These tweaks will be done in consultation with the originators of the ProgPOW algo. This derivative will be called KAAAWWWPOW. For those that think this has too many A’s and W’s, the simple answer is that you cannot have too many A’s or W’s.
Despite my preference, the concepts behind x16r will be dropped. I don’t have a strong enough technical argument to justify keeping them. The strongest argument would be marketing related and continuity of the x16r brand. It seems that on a GPU, KAAAWWWPOW will run at about the same speed as 16 algos chained together, which means that inserting it somewhere into the x16r mix randomly, it would dominate the time profile.
Work is being done to have some tools for pools and GPU mining software prior to any proposed launch. These pool tools include a way to quickly verify a block and some stratum optimizations.
There will be a testnet and more discussion. The source code will be available to everyone to review.
A lot has changed in the last month. The COVID-19 virus has made the Ravencoin project even more decentralized as the team, enabled by Medici Ventures, that ordinarily worked in close proximity at the Peace Coliseum, now works from their respective homes.
But, development continues. A Ravencoin specific version of progPOW called KAWPOW (not enough A’s or W’s for my taste), is live on Ravencoin’s testnet, and anyone can mine with it. https://minermore.com/pool/RVNt/
The advantage of this algorithm is that it is tailored to use the entirety of a GPU. This algo makes it tricky to make a custom machine that does better than a GPU. This should benefit miners that have GPUs and should allow most modern gaming systems to participate in mining and securing Ravencoin.
One unfortunate disadvantage is that the KAWPOW algo needed to be tuned to a certain amount of memory usage which forced a memory requirement decision that prevents some of the older cards with less memory from participating. As I’ve discussed above, the goal is to allow everyone to mine, and sadly this parameter will knock out some GPUs. Initially, a 3GB card will be able to mine Ravencoin, but 2GB will not. Additionally, the memory DAG size parameter adjusts over time (# of blocks) which will knock out more of the older GPUs over time.
For three reasons it is my hope that this is the final required change. First, the algo, by design, adjusts the amount of memory required and therefore adapts to hardware improvements over time. Second, it is very disruptive to the ecosystem to upgrade all the nodes and it would be nice to minimize this disruption. Lastly, algo changes take away from the other more productive improvements that we can make to Ravencoin core.
The plan is to have code and binaries available by mid-April with an algo switch date of May 6th. It is, as always, risky to make consensus changes. I hope that all the miners, wallets, and economic actors (exchanges and merchant tools) will upgrade their nodes to continue the Ravencoin project uninterrupted.