In pursuit of GPU mining, a timeline pre Odocrypt -> DigiByte v8

The lead up to, and release of Odocrypt

DigiByte had evolved to be at a point where it was faced with 5x ASIC-mineable algorithms since all the way back in 2017. Immediately after all of the fervor of DigiByte briefly reaching the Top 10 in CoinMarketCap around July of 2017 had begun to die down, rumors began to swirl of ASICs (or at least highly optimized FPGAs) on all the remaining algorithms.

The Baikal X10 Giant product page at release
Some earlier messages of mine in the Mining channel on Telegram about the X10 Giants efficiency
  1. It vastly improves the distribution of the mined asset, compared with ASICs
  2. It greatly distributes the hashrate globally because of better distribution channels for CPU / GPU vs ASIC / FPGA
  3. It encourages a decentralization of mining thanks to participation from hobbyists or people testing the waters of mining
  4. Users can participate in the network without needing a costly investment in single-purpose hardware
  5. Ease of onboarding to the network, without requiring KYC purchases from an exchange
Some earlier messages of mine around alternative PoW algorithms

What happened to GPU support?

Well we very quickly noted even pre-activation of Odocrypt that it would be heavily favoring FPGAs to the point where GPUs couldn’t keep up. Had the Cyclone V based hardware been where things remained, it might have been a different story, however we were seeing even the AtomMiner coming out and being over twice as efficient, then BlackMiner announcing support for Odocrypt and being an order of magnitude more efficient. I immediately began the hunt again, even before the activation of Odocrypt, for a GPU-focused algorithm.

Enter: ProgPoW

Following on from Odocrypt (once activated on mainnet), I began a bit of a deeper dive in to the algorithms. Over the coming months, I discovered this video of Kristy-Leigh Minehan at Ethereums Devcon4 which had me sold on the idea of ProgPoW as the next major upgrade for DigiByte:

Excerpt from the DigiByte Infopaper I began writing in 2018
The Infopaper I wrote was originally created in 2018 but released in 2020 Q2

The start of DigiByte 8

Jared, ycagel, DigiContributor and myself all jumped on a video call, as DigiContributor worked with Jared to do a whole lot of initial work on DigiByte version 8 on the 31st of January. The video call went on for around 4 hours, which I recorded as Jared was wanting to document some of the ways that he and DigiContributor worked through merging the code. Sadly, because I was at work on the day and remotely accessing my PC, I didn’t notice that I wasn’t recording desktop sounds, and so the entire recording had no audio.

When things had completely stalled

Then in May 2020 we saw Jared getting furious at Exchanges for not “giving back” to projects such as DigiByte and announcing he would take a sabbatical from DigiByte. He had, however, not contributed code since January, but nonetheless choosing to intentionally step away seemed positive at the time.

Progress starts up again in Q4 2020

In October I was contacted by someone through Reddit. This person, barrystyle, had heard we were looking for someone to help with a RandomX implementation and had begun work on it. Barry caught me up to speed on where things were at with what he’d done already and what more needed to be done. In particular he was doing a bunch of extra work to ensure that it would work “out of the box” with existing XMRig and other Monero-expecting mining software implementations.

  1. More up-to-date codebase to work from of Bitcoins, zero objections there
  2. Bitcoin was using that as the basis for their Schnorr signature work (which we were also interested in), and it would minimize effort there
  3. The codebase Jared left in January for 8.19 was in quite a state, so much so that SmartArray and Akshaynexus were at a loss with how to proceed
  • Improvements to the sync of the blockchain from scratch so it occurred in half the time on a normal machine, and in a fraction of the time where you were re-syncing to test code (important for developers)
  • RAPID start up of the blockchain, taking it from 12 minutes on some test machines to 60 seconds flat.

Undertaking ProgPoW and RandomX

Throughout October / November, Barry managed to get a really good 0.20 base working for DigiByte, which was then being used for RandomX development. SmartArray had also made a pull request with a replacement of hashmap with btree, as he’d been loosely working with Barry at that time in the same Telegram channel.

Odocrypt upgrades

In December of 2020, I got together with Matthew, SmartArray, and Barry, with the goal of getting to the bottom of the Odocrypt “Is there an ASIC?” question.

Planning the release of 0.21, Jareds return

On January 14th 2021, Barry messaged me to say that 0.21 had been released by the Bitcoin Core team. Given things were working so well with 0.20 at this point, we were both kind of loathe to do things based off 0.21, but at the same time if doing a larger release such as we were with DigiByte version 8, it kind of makes sense to be as “up to date” as possible.

Letting Jared know where things were at
Jared beginning to lose the plot
Sharing proof that 0.21 was working on January 23rd
It will only take Jared 3–5 hours to get 8.21 working!?!
So it’s gone from 3–5 hours to 2–3 months?
DigiByte 8.19, nothing from Jared despite it allegedly only taking “3–5 hours” to get things working
First commit on Jan 29th, 2020 (the year prior)
Second commit on Jan 29th, 2020 (the year prior)
The 19th of January when Barry committed the work for 8.21
Jared saying he wouldn’t work with the rest of us
Advising Jared on Monday 18th Jan that Barry was only on Telegram
Jared recommending Telegram on Jan 14th
Allegedly wanting to work together??
Jared is now using Telegram for when he thinks he’ll eventually be kicked off Twitter
Jared trying to imply yet again that the code wasn’t working, not realizing at the time he’d broken his Mac
Jared began working on 0.21 after suggesting he would help Barry
Jareds last commit towards 8.21 in January

More delays, and the new dev process

Following on from this drama from Jared, several members eventually expressed grave concern, predominantly from Jareds aforementioned comments about two competing codebases now that he was starting solo. This concern was mostly due to the fact that outside of myself and Jared (who were clearly at odds), gto90 wasn’t commenting on Jareds antics, and DigiContributor had been busy and not around the groupchat (as DigiContributor is usually uninterested in the ‘personality politics’ and just likes to write good code). There was nobody else who could really independently advise them on if Jared was telling the truth when he said things would take 3–5 hours or not. Similarly there was nobody who could advise if the 8.20 / 8.21 that Barry had been working on was “broken in thousands of places” vs the existing codebase (or that which Jared had started on himself).

DigiByte 7.17.2 fails the tests in 14,529 ways
First few slides from the development suggestion PDF

Fixing the Unit Tests

Well, in March, Barry had already begun to work on fixing some of the unit tests (despite the request of no further coding from the others in that groupchat, but still…) in a version 7.17.3, based on 7.17.2. Then, SmartArray continued this in April. The goal was to have 7.17.2 effectively re-released but with fixed and working unit tests.

Jared clearly mad about 7.17.3 shipping

The infinite supply issue

Jared had already disappeared again since the January events, a move not uncommon for him. However, he returned halfway through the unit tests being completed to ACK just two requests, one of which was the fabled infinite supply issue:

Pull Request 33 that Jared ACKd, which had a direct link to all of Yoshis breakdown / charts
The release of DigiByte 7.17.3

Where is DigiByte 8 then?

Following the release of DigiByte version 7, nothing at all happened for several weeks.

DigiByteCoin intentionally stiffling development progress
Jared going to give 2 weeks of 110% focus on DigiByte Core Protocol
Jareds on the left, fails. Barrys on the right, builds just fine.

You know what would have been better a better solution from Jared / DigiByteCoin?

If they really needed that history in the same branch, given Barry had already done this twice with DigiByte in relation to BTC 0.20 and BTC 0.21, would have been for them to reach out to him (or me even) and say “Hey can we contribute to this fundraiser (for the first time) and ask Barry if he’d be willing to do it as a merge rather than a rebase?”.

Where does this leave us?

Well that’s a really good question. As of now, Jared has created a second codebase that he’s been super lucky somebody else has managed to finish off . After the 26th of July, SmartArray has very clearly done most of the work (And we’re lucky he’s such a kick-ass developer).

  • Infinite supply curve (they’ve not merged in my fix yet)
  • Supply emissions are skewed
  • Users aren’t able to send from older wallets
  • Fee guesstimates are not working
  1. Take Bitcoin Core 0.21 (or v22 now) and rebase off it. This is where it’s the Bitcoin codebase is taken as-is and used as a sound starting point. Then, we bring in ONLY the neccessary changes to make it “DigiByte”, getting rid of a bunch of guff and outstanding issues in the process. This would require a review of JUST the changes, and the parts that make DigiByte “DigiByte”. Developer history would be in a separate branch and require a 5 second change to “look it up” (Even better, if you really need, keep a separate terminal window open with it and just alt-tab).
  2. Take DigiByte 7.17.3 and merge each patch that’s gone in to Bitcoin 0.18, 0.19, 0.20, 0.21 and then 22, leaving everything in DigiByte still in there, including the developer history (with the benefit of requiring no additional time when referencing). This would mean that all of the code, across the board needs reviewing, every single line in every single file, including all that’s being changed with merging-in Bitcoin to ensure that how it was done did not bring in any inadvertent issues. It would also require reviewing all of the DigiByte code too, both historical and current, which is where the majority of the time would be spent.
Jared on the suggestion we replace SHA256

Timelines as promised

So here’s a longer timeline of all the work since the DigiSpeed upgrade which I mentioned previously, was the last time prior to Odocrypt we had “new” code in DigiByte:

A more zoomed in timeline
Asking Jared about his own “better” version of 8.21 after the same time as Barry’s, which did compile + work

Maybe one day that will change?

Maybe one day DigiByte will realize the aspirations of being truly forward-thinking?

Nothing is more important than having a secure network, safe from double-spends and 51% attacks 😡
Jared even sent me this screenshot confirming he knew it was broken back in April 5th 2018
Jared replied, but then, ignored it…

This is also why ALL code, existing and new, needs reviewing.

You’ll note that despite these messages being in April 2018, work on 6.16.3 didn’t start to happen until August 6th, a whole week after I told Jared there were double-spend issues occurring on the blockchain: https://github.com/DigiByte-Core/digibyte/commits/archive/6.16.3

Jared on July 31st 2018 trying to say there was no issue still
Jared doesn’t understand how MultiAlgo / MultiShield works
From 2:14:07 Jared shows he doesn’t understand MultiAlgo, confuses it with Sharding

--

--

I write interesting things about cryptocurrency, especially DigiByte

Love podcasts or audiobooks? Learn on the go with our new app.

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