Updating DigiByte with ProgPoW & RandomX

High-end graphics card in a PC (Source: wccftech)

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.

  1. SHA256 : ASIC
  2. Scrypt : ASIC
  3. Skein : GPU
  4. Myriad-Groestl : GPU
  5. Qubit : CPU (Then 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.

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.

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.

What will happen from here?

Before we proceed, I want to give the following disclaimer:

  1. 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.
  2. 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
  3. 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
  4. 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
  5. 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.
  6. 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.
  7. Success!
    All upgraded, and mining on ProgPoW + RandomX



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Josiah Spackman

Josiah Spackman


I write interesting things about cryptocurrency, especially DigiByte