12 months and the core security of DigiByte still isn’t fixed
Also known as “Did you know DigiByte can be rent-attacked?”
So, it’s time to share this document with everyone, which will hopefully explain why I’ve been so frustrated with, well, everybody… from the Founder, to the other “developers” (All of whom are noticeably absent from committing any code with the exception of Barry / Yoshi), the DigiByte Foundation who were in all the discussions, there were multiple members of the DigiByte Awareness Team, and also most of the DigiByte Alliance (though it wasn’t formed at that stage).
Yep, almost everybody who should have been deeply and proactively caring for the blockchain, and wanting to see things progress, see the security maintained, was there. They have known about this for 12 months now, since I made a video on ProgPoW / RandomX and I talked with them about it. Some knew prior to that given we had 1:1 talks, but this was the day the first real serious discussions took place aroud it.
But alas, here we are, 12 months on from when I first made the “Importance of ProgPoW / RandomX” video (365 days to the day):
Where I showed just what an issue SHA256 is for DigiByte:
This image directly shows the crux of the problem, and all the aforementioned were all made aware of this 365 days ago now. The little black blip, is the pixel representation of how much hashrate DigiByte has in SHA256, as opposed to the orange being worldwide available.
There’s something in the computer industry known as “responsible disclosure”. All you have to do is look at the likes of Bitcoin CVE-2018–17144 to see how rapidly they respond (A release with a fix is published in under 12 hours). This, despite being a multi-trillion dollar blockchain. Keep in mind there’s no hard-fork there for Bitcoin, but you get the picture.
The picture that something serious was disclosed, and a solution was already 95% ready with the work Barry had done that the community crowdfunded for, and it was discarded… roadblocked intentionally by Jared.
Now, many other places have responsible disclosure timeframes of 7 days (Linux kernel etc) for severe issues where you should give the vendor 7 days to fix the issue and release an update. That’s why it’s “responsible” disclosure. Others have 30 days. Not 365 days. Not a whole year!
Please allow me to just reiterate here: a blockchain should never rely on security through obscurity. That’s a fundamental design flaw if it does and you should run a mile. Instead, it should rely on sound cryptographic principals, and in DigiBytes case solid irrefutable Proof of Work to determine who is the longest chain (It’s different for PoS but you get the picture).
Just as it was the last time Jared introduced a vulnerability in the difficulty code (from a mess of a merge he made pulling in BTC code no less), it wasn’t an issue until it was an issue and being exploited. Similarly, this isn’t an issue until it’s being exploited, which could be any moment.
You see, this isn’t just one lone-wolfs attempt at quickly getting GPU mining here for some selfish purpose as Jared has tried to portray over the past year, but rather, a twofold solution: 1/ To resolve this security issue that SHA256 in particular presents. 2/ Bringing back GPU mining to further decentralize and distribute the mining, of which the community as a whole crowdfunded on 3x separate occasions over the last 2.5-odd years.
Let that sink in for a moment, 2.5 years since Odocrypt! What has been done since on the Core codebase outside of the work Barry has done? Nothing.
Even Ethereum with its much higher market cap has done 8x hard forks since then. This upgrade is not the sort of thing that needs to take years, especially as the community clearly showed it was happy to fund this sort of upgrade. To suggest otherwise simply reeks of incompetence, or intentional deception.
Yes, all the DigiByte crowdfunding attempts were successful, and goals met. The 3x fundraisers were raised for ProgPoW, for RandomX, and for getting it all implemented in to 8.20 (which was the going version at the time).
In October 2019, we had Barrystyle working on all of the things we crowdfunded for, taking over ProgPoW from Kristy-Leigh Minehan. He got most of those items finished in just a few short weeks time (Full timeline here). That’s what happens when a competent person is working full-time on things, and not Jared half-assing two days worth when he says he’ll focus 110% on the Core codebase and won’t do anything else until the upgrade is out.
In this completed work that Barry had done by December 2020 was: an implementation into the Core codebase of ProgPoW, an implementation of RandomX, stratum code for each algorithm respectively, major memory-use improvements, huge start-up optimizations, faster sync, and best of all it was based off the latest BTC Core and included those improvements as well.
Again, the issue is not funding. We crowd funded, successfully!
The issue is not developers. We’d found someone who was willing to do it, who is incredibly talented, and who did all of that solo over a few short weeks.
To bring up a point by GTO90 and Gary, they had both previously expressed an interest in ensuring the code was well reviewed & tested, not rushed at all, with which I wholeheartedly agree(d). There was never any doubt that would happen, and in addition to writing a whole lot of manual testing procedures I’ve also helped spearhead the release of 7.17.3 which includes fully operational unit-tests. However the suggestion from GTO90 & Gary that they want a codebase to be reviewed is pretty ironic given we’re 12 months down the line now with a different codebase that isn’t going to be, nor is it able to be, reviewed. It’s a monolithic mess of a merge that is genuinely impossible to code-review.
You do not wear the “We changed several hundred thousand lines of code” as a badge of honor. That sounds like several hundred thousand ways a merge could have been messed up, and a major vulnerability introduced that directly affects the security blockchain, as Jared has done in the past.
But back to the topic at hand. In 2019 there were talks about furthering decentralization of DigiByte. Talks of improving the security. Talks of lowering the onboarding of users through GPU / CPU mining so that people can obtain DGB in a KYC-free manner. Talks of improving the security and resolving the issues. Talks of improving the distribution of the DigiByte asset. Talks of a faster, more secure, forward-thinking DigiByte, implementing ProgPoW, another CPU algorithm, and something further. Those talks continued many times over since.
To some of us, we acted on those talks and did all we can to progress things and bring about the security improvements, raising funds for it, working with developers to bring it to bear, educational and informational videos and content about the benefits and the need for it.
To others, they were just talks which to this day have not been progressed on.
So, it’s been a year, and the way I see it there are two possibilities right now based on what I’m alleging:
1There’s not any security issue, everything is fine and the blockchain is perfectly secure. In which case, releasing this document isn’t actually an issue. It’ll be easily debunked, I’ll eat humble pie, gravely and repeatedly apologize for the misunderstanding, and never say anything about DigiByte ever again.
2 It is actually an issue, and those involved have done absolutely nothing. Even worse, they’ve actively stood in the way and roadblocked progress that would secure the blockchain. In which case, they’ve been the worlds worst stewards of the blockchain and need to be called out for it so they can be sidestepped, the Founder included. Because 12 months and zero progress is atrocious and completely unacceptable.
Which one that is, you can do the numbers on, it’s not difficult.
I was asked originally in February of this year to make this document as a way to help explain the issue to the other members of the Foundation / Alliance / DGBAT. So I made it for them the very next day. They wanted something that was impartial, that just focused on IF there is an issue, which is why a lot of the phrasing is incredibly generic. There was no finger-pointing, no blame, and yet here we are 10 months later since this document was made and still no solution in sight.
The numbers may be slightly off now given the timeframe, but you’ll see in the document (despite Jareds numerous misguided slander attempts) that it contains some hard numbers for you to work with.
At last check on whattomine, I saw DigiByte hadd 72PH/s in SHA256, vs Bitcoins 174,621PH/s. Keep in mind you can rent 631PH/s right now on NiceHash alone. So when he throws out ridiculous statements like “We need hard data”, I’m sure you as an astute reader know by now based on Jareds history to take that with a grain of salt, because as we’ve seen countless times even over the last 12 months, he’ll outright ignore any data that doesn’t support his ignorance (as Jared did with the infinite supply):
With that in mind, here it is for you to review, with the exchange details redacted. Keep in mind this: The hashrate needed to get blocks doubles ever 5 consecutive blocks.
This means if you start with “1” hash per second, you’d need 2 per second to ensure you’re going to be finding the next blocks, then 4 per-second to ensure you get 5 in a row, 8 per-second if you want to ensure you get 10 in a row, or if you can find 16 hashes per-second then you’ll get 15 in a row. With one algorithm. Adding a second algorithm greatly reduces the hashrate needed.
This was shared in February as I mentioned. It’s now December, and nothing has happened to address it. So if it was *actually* an issue, if security was at stake as I allege it is, then you’d think they would have acted on it over the past 10 months (365 days from the video when we first truly discussed it in-depth).
Again, please take the numbers in the document with a grain of salt, naturally they change over time, they go up and down and I don’t expect them to be 100% accurate for December 29th 2021… However in fact they’ve now gotten worse if you ask me.
Where DGB was previously 0.07% of all the worldwide SHA256, it now makes up ~0.04%. From what I can see, renting all the SHA256 hashrate on NiceHash alone could get 10+ odd blocks reorged, without even looking at including Scrypt which would significantly increase the number of blocks.
The real difficulty here is that Jared still doesn’t understand how MultiShield works. He didn’t write it, MentalCollatz did, and as seen from these chats I had with Jared back in May discussing this, he misguidedly believes if the hashrate available to rent by an attacker is halved, that you halve the blocks. That’s wrong, you only lose the tail end, as the difficulty is what “ramps up” effectively:
Which is why it’s time to share that document today, because apparently there’s no issue whatsoever!
Allegedly (according to him at least) all my math and numbers are all totally wrong. So according to the DigiByte Founders reasoning, then it shouldn’t matter if I share the document given there’s no issue at all right?
He asked for the data that I provided in the document:
So DigiByte community: Jared, the Foundation, the Alliance, DGBAT members, they’ve all known for 12 months now about what I allege is actually a serious enough issue that it should be acted on immediately. Yet, there is no solution in sight at all.
Development only happens when Barry does something (he was still further on his 8.20 in December 2020, than Jareds merge is this year that Barry / Yoshi have been cleaning up). There’s been zero discussion around any form of resolution for this outside of that which I instigated earlier this year.
But you wait, Jared will run some twitter poll tomorrow about Algo upgrades, and then promptly forget about the results, which is what he always does.
So if Jared is right about these numbers of mine being totally off, then cool, me sharing this is only going to put egg on my face.
If he’s wrong, and the numbers check out, then I hope this motivates some actual action because he has been pathetically absent while virtue-signalling and posturing as being “busy working on DigiByte” on a daily basis.
Just remember: Every 5 blocks the hashrate needed for a single-algo attack doubles. That’s something Jared can’t wrap his head around for some reason (as seen above in the screenshots). Not to mention, the difficulty of carrying out an attack decreases significantly if you have more than one algorithm.
So take a read of the document, it’s really just some basic multiplication using numbers from whattomine and the NiceHash marketplace to verify.
Good luck, DigiByte community. I hope that this is either the end of any further comment from myself about DigiByte if I retreat with apologies and egg on my face from being wrong about the numbers. Or, that you use this as the motivation to overthrow your tyrannical founder from his current centralized positions of power, side-stepping his roadblocks and finally getting some true progress! After all, that’s why the Dev process was made right? So that the project could be improved? So that code could be reviewed, thoroughly, before being accepted? Coz that sure as hell hasn’t happened to date with that mess of a merge that he’s been loosely involved in since July.
Again, like I’ve said all along: A rebase is the way, with ProgPoW, RandomX, and an upgraded Odocrypt. You can even include the three-line fix I wrote for the infinite supply issue 6 months ago.
This doesn’t need to take years (as has been the case), it could easily be finished in just a couple of weeks with some actual dedicated time put into it. Remember, Ethereum being a multi billion dollar chain has done 8x upgrades in the last 2.5 years. If funding is an issue, go crowdfund, it’s been done it before! I just so happen to know of a few really good devs (*cough* Barry / Yoshi *cough*) who could possibly be funded to code and then review the work.
The choice… is yours!
But if my math is off, please do let me know because so far none of the aforementioned parties have been able to say-so.
Final note: To date, we don’t have concrete evidence of any ASICs on Odocrypt. The last two known mining pools that joined in Q2 of 2021 are based out of China and are using BlackMiner F1+ FPGAs, one of which currently as of December accounts for approx 25% of the hashrate. However, that didn’t stop me and others (Barrystyle, mctrivia etc) from proactively looking at ways we could ensure there aren’t ASICs by replacing the Keccak in Odocrypt back in December last year / January this year. That PR has sat there, with no real action from the “main” developers, also since January.
EDIT: Someone has asked if an increase in price will solve things. This point is addressed in the document itself, and the short answer is no.
Despite what others might suggest, a temporary Pump & Dump does not make for good security:
Especially when you look on CoinGecko and see it’s down almost 80%:
No, a real solution would be to fix the problem, not hope for a price-pump to band-aid over the issue.
