Updating DigiByte with ProgPoW & RandomX
A number of people have asked for a more concise summary of what’s happening, so here goes:
We’re implementing ProgPoW for GPU mining, and RandomX for CPU mining on DigiByte!
A little history…
DigiByte when it started was originally Scrypt-only, and GPU mineable in 2014 due to there being no Scrypt ASICs at the time.
We then upgraded to MultiAlgo, and had 5x algorithms:
- SHA256 : ASIC
- Scrypt : ASIC
- Skein : GPU
- Myriad-Groestl : GPU
- Qubit : CPU (Then GPU)
However, by the middle of 2018, it was clear that all the algorithms are being ASIC mined, and by late 2018 it was unfeasible to mine any of them on a GPU.
Enter Odocrypt
Odocrypt was designed to be an FPGA-friendly ASIC-resistant algorithm that mutates itself every 10 days. The idea being that we worked backwards from an ASIC-friendly design and changed just enough (on a regular basis) that you’d only be able to run it from a FPGA.
Odocrypt was implemented in Q3 2019. While we originally anticipated that it *may* be able to be GPU mined, the early indications on FPGA performance improvements that we were seeing quickly cleared that up for us that it wouldn’t happen. For comparison the DE10-Nano we were seeing was pulling over 100X the performance of a CPU, so even optimizing for GPU likely wouldn’t have been worthwhile long-term.
Bringing back GPU mining
One of the more interesting discussion points that I’ve heard is around the “social contract” of mining, and if that’s a reason itself to try and maintain the ability to mine DigiByte on a GPU. This isn’t something I have a concrete answer for, but on a personal level I think it’s something worth attempting to maintain, and ProgPoW + RandomX look the best way to do that.
ProgPoW has been built from the very beginning to be GPU-focused.
RandomX has been built from the very beginning to be CPU-focused.
Both have been independently audited by 3rd-party specialist companies who have stipulated how well they would stand up to an attempt to making an ASIC.
That’s the goal in my mind really, is not to outright stop any attempt at making an ASIC. Rather, the goal is to have an algorithm that is so well optimized for a particular type of hardware (Such as a GPU or a CPU) that any ASIC would very much resemble that, and there would be little-to-no gains to be made from such an attempt at making one in the first place.
Mining distribution: Low barrier to entry
One of the main benefits for a GPU focused algorithm is the mining distribution. Again similarly to the ‘social contract’, this is often one of the most overlooked aspects of mining (More-so overlooked than the security or decentralization of mining) but it’s still quite an important one.
When it comes to GPU mining, many home-desktops / gamers have a GPU in their PC or Laptop, meaning all they need is some minimal software setup and they are good to go. They can also scale up relatively easily, with a second moderate GPU purchase able to be reasonably offset by the mining rewards when they are not gaming. Alternatively if you have a PC without a graphics card and you want to add one, there are multiple benefits over and above just “mining” that you can get from a graphics card, such as acceleration for video editing, better gaming, using things like nVidias RTX Voice to remove background noise when you’re on your Zoom calls (Stay home, stay safe folks).
Compare this to an ASIC and they basically have zero use outside of hashing cryptocurrency. This is important because the “commitment” from users to get involved is far less when buying a graphics card, or even using an existing one.
The same goes for CPU focused mining with RandomX. You can even mine both RandomX and ProgPoW on the same machine, similarly to how Litecoin chose to use Scrypt for CPU-mining back in 2011 at launch, so that Bitcoin miners could carry on mining BTC with their GPU concurrently.
The difference here is *everyone* has a CPU in their PC (Though some are naturally significantly more powerful / efficient than others) and it’s more difficult to just “add one more” to your PC (Hint: You can’t, on basically any desktop motherboard).
However, the benefit is the barrier to entry is lower, you’re far more likely to be able to mine with RandomX and get started without any kind of “commitment” than you are even with ProgPoW.
That’s not to say that RandomX is “better”, not at all, but simply to say they both fill an important role and I think at this point in time it’s prudent that DigiByte adopts both.
This is why we are taking up a collection to donate to Kristy-Leigh for this implementation.
What will happen from here?
Before we proceed, I want to give the following disclaimer:
DigiByte is not run by any centrally controlled company, it was not an ICO and there is no central slush-fund of money available. There are no block-rewards, founders-rewards or any such thing. All contributions from developers are done in their spare time as and when they are available, usually in their evenings or weekends etc… Therefore, there is never, ever any fixed timeline and at best they are a wild ballpark guess, so please keep that in mind.
However here’s my best guess at what will happen with the implementation:
- Pull request with the code
It’s my understanding that Kristy-Leigh Minehan has started this work already
This could take a week, it could take several weeks, I’m not going to make any time-commitments from her though. It’s ready when it’s ready. - Merge and decide on which algos to replace
Bringing the code in and ensuring it’s compatible with the latest 8.19 code shouldn’t be too difficult, presumably there will be minimal other changes that need to be made compared with 8.19 as Yoshi is working on it.
We’re going to then need to decide which algorithms to replace. It’s pretty clear SHA256 is our biggest weakness right now, and then it’s just about deciding if we replace Skein or Qubit. I’ve been keen to replace Qubit myself, most other developers seem more interested in replacing Skein, so I’m not going to split hairs over it there as I don’t have any big reasons either way.
This part will probably only take a few days to a week - Testing, testing, testing….
We’ll then upgrade the testnet and implement ProgPoW + RandomX on the testnet. We’ll make sure the upgrade takes place happily, and then probably reset the testnet (Or start another private testnet) and do it all over again (maybe multiple times) just to be on the safe side and ensure the upgrade proceeds smoothly as expected.
This could take 2 weeks to 3 months, depending on the contributions from people assisting with testing, timings to begin, and a few other variables - Finalizing 8.19
We’ll then get anything else in DigiByte Core 8.19 finalized and ready, packaged up, Gitian builds (I absolutely hate doing them but it’s a neccessary evil), and then a release finalized and out the door.
This could take between a couple of days to a few weeks, as Gitian builds take a while to get the environment setup etc - Get miners to upgrade and indicate support
As miners upgrade to the new 8.19 package, it will anonymously indicate support in each block that they are running the newest and supporting the upgrade to ProgPoW + RandomX. This requires 70% of blocks mined to indicate support over a 7-day epoch (40320 blocks).
Previously we’ve had half a dozen people go through and contact every single known mining pool, but even that isn’t guaranteed to get us there so we need to basically sing about this upgrade and the overall benefits for the network to get everybody behind it, and upgraded to 8.19 when it’s available, and so the more people we have educating the world about these benefits the easier it’ll be.
It is perfectly safe (and arguably preferred) during this time for exchanges and other such service providers to upgrade.
We’ll probably have the block migration date set ~3 months in the future to give the whole network plenty of time to upgrade.
NOTE: We’re likely going to schedule ProgPoW first, and RandomX to occur perhaps a week afterward. - 1-week lock-in period
From there once we’ve got 70% signalling support in an epoch, we have a minimum 1-week lock-in period. If we’ve passed the block migration date, it’ll be just one week. If we get a quick consensus then it’ll potentially be up to that block # we’d set 3 or so months in the future. - Success!
All upgraded, and mining on ProgPoW + RandomX
I’ll go in to more details about how the upgrading will work, but feel free to look through previous articles here on Medium about how we did it for Odocrypt. The process is basically the same and I’ve detailed it well in the past.
Until then, the best thing you can do is head on over and donate to the community fundraiser so we can get this rolling!
I’ve gone and purchased another 5,000 $DGB to donate to this today, I hope you’ll also be able to contribute.
