Why Ethereum should use DigiByte

Recently on the Eth Research platform, Vitalik Buterin has posed the question: Should they use Bitcoin Cash as a short-term data availability layer for Ethereum.

My immediate thoughts were that DigiByte would be a far superior choice, and after having read through his conceptual background, as well as the summary, I’m going to briefly go through his “Summary of conceptual background” and compare Bitcoin Cash with DigiByte and respectfully suggest that Vitalik investigate DigiByte rather than Bitcoin Cash.

A brief DigiByte history

In case this is the first anybody has heard of DigiByte, here’s a short summary of DigiByte.

DigiByte was originally a fork of the Litecoin codebase (Independent blockchain). However unlike Litecoin, DigiByte has consistently improved the protocol and project since launch. DigiByte’s DigiShield realtime difficulty adjustment algorithm was the first of such improvements just several weeks after launch. It is now used in everything from Bitcoin Cash to being credited with keeping DOGE alive in early 2014 when Multipools were causing major hashrate fluctuations.

DigiByte has subsequently evolved to a MultiAlgo blockchain, being the dominant hash-power in Qubit, Skein & Myr-Gr (More on that later) followed by a MultiAlgo upgrade to DigiShield known as MultiShield.

DigiByte implemented SegWit several weeks prior to Litecoin through majority consensus, implemented Dandelion++, and has just this week locked in a network upgrade to replace Myr-Gr with Odocrypt, an FPGA-focused algorithm designed to deter centralization of ASIC mining.

DigiByte has a supply ratio of 1000:1 vs Bitcoin (21 billion maximum), being fairly mined through PoW over 21 years (Ending in ~2035). Where block timing was originally 60 seconds, it has been improved through MultiAlgo (30s at the time) and subsequently our DigiSpeed protocol enhancements (Based upon Microsoft research) to 15 seconds.

A response to the summary

As a truly permissionless blockchain, there is nothing preventing anybody from using DigiByte, and as such Ethereum could implement the proposal on DigiByte at any time.

Using the same OP_Codes as Bitcoin Core, the latest DigiByte release 7.17.2 is based upon Bitcoin Core 0.17, and as such any RPC calls that currently are utilized should have minimal effort required to migrate to DigiByte.

The key points around using Bitcoin Cash that Vitalik has proposed are:

• High data throughput (32 MB per 600 sec = 53333 bytes per sec, compared to ethereum ~8kb per sec which is already being used by applications)
• Very low fees (whereas BTC would be prohibitively expensive)
• We already have all the machinery we need to verify Bitcoin Cash blocks inside of ethereum thanks to http://btcrelay.org/ 52 ; we just need to repoint it to the BCH chain and turn it back on. Verifying BCH blocks is also quite cheap compared to eg. ETC blocks
• The BCH community seems to be friendly to people using their chain for whatever they want as long as they pay the tx fees (eg. https://memo.cash 43)

Comparatively, the following would apply for DigiByte:

• Higher data throughput (1MB blocks every 15 seconds = 66,666 bytes per sec) with planned block-size increases into the future
• Even lower fees (Due to higher supply count, 1 dSat is worth less than one Bitcoin Cash Sat)
• The btcrelay would easily be able to be migrated to DigiByte instead of Bitcoin Cash
• The DigiByte community embraces the use as a permissionless blockchain, for any use, be it as a currency, document validation through V-ID, DigiAssets, again as long as the tx-fees are paid.

Next discussed is the block timing of 10 minutes.

DigiByte does not actively endorse 0-conf payments (For well known reasons it is safer to have a Tx in a block), but due to having 15-second block timings even if a project were to wait and consider a Tx “safe” after 3 confirmations, this is still only 45 seconds on average. This removes the need for any form of 0-conf, retaining the mantra that “if it’s not in the blockchain, it didn’t happen”.

We also have the protection of DigiShield (MultiShield) helping to ensure the stability of the network hashrate, block timings, and minimize the possibility of any single (Or combination of) algorithm(s) from being able to perform a chain re-org. This means that despite being a minority hashrate on SHA256 as Bitcoin Cash is, there simply isn’t enough hash power in the world to attempt a 1hr re-org of the chain due to the increasing requirements of MultiShield where not all hashing algorithms are being used concurrently at mainnet hashrates. This is where the security of being the predominant hash power in 3x algorithms comes in to play, despite being a minority in SHA256 & Scrypt, and where the weakness of Bitcoin Cash shows.

DigiByte is arguably one of the only PoW blockchains that can go toe-for-toe with Ethereum in terms of block timing, a key factor I would suggest not be overlooked. Were an individual block to be full, the time to wait for another non-full block is far less thanks to the 15s block timing, so unless sustained transaction volume were to occur then there is likely little need for per-KB fees to increase, while still having a minimal impact on immediate inclusion into the blockchain.

DigiByte is also incredibly distributed, across the globe, unlike other Bitcoin forks which struggle to differentiate themselves from the mainchain. DigiByte was launched with the Genesis Block containing the headline from USA Today: “Target: Data stolen from up to 110M customers”, cementing a long-term focus on security of data.

Despite this being a relatively informal response, I would suggest that with the evidence provided that Vitalik and the Ethereum developers take a serious look at utilizing DigiByte.

This has been submitted for consideration as a response to the original discussion at Eth Research.