Let’s talk about MultiAlgo + MultiShield

I’ve recently been moving house, and unfortunately unable to do the DigiByte Update videos. Internet is still not operational as I begin to write this, but, I’m able to operate from my cellphone in the mean time.

One of the things that’s become pretty obvious that DigiByte needs, are the following:

1. A better repository of places to learn factual information about how things work, and why. Newbie-friendly information.
2. More information about MultiShield and MultiAlgo, and how they actually work together

So here’s a start on that, with info on MultiShield + MultiAlgo, and I hope although this will be slightly technical that I’m explaining this well enough for even relative newbies. Big thanks to Twitter user @vinswaalla for these questions that have prompted this Medium article too.

So what we’ll look at is:

• Single vs Multi algorithm
• How MultiShield works
• Orphaned blocks

So let’s begin with MultiAlgo!

What is MultiAlgo?

MultiAlgo is where you mine DigiByte and secure the blockchain using the hashing from more than just one algorithm.

The primary goal behind this is to avoid centralization where many other single-algorithm blockchains fall short, and avoid rented hash attacks.

For example, the current DGB mining distribution compared with other single-algorithm PoW blockchains:

Please excuse my poor image editing skills

I’ve talked a little about this in the past as well, so this information / comparison isn’t anything particularly new, and the effect only gets better the further you zoom out (Given the incredible number of minor hashrate miners DigiByte has that find a block every day or two).

There are benefits to having multiple different types of mining algorithms, which being MultiAlgo gives us the best of all worlds, for example:

• GPU mining allows for easy onboarding of new users through existing hardware, provides a way for users to “start using” without going through an Exchange / AML process etc
• FPGA mining targets enthusiasts, helps prevents ASIC dominance from any single manufacturer
• ASIC manufacturing affords the highest security, with dedicated purpose-built hardware for an algorithm that far surpasses CPU / GPU mining performance.

None of this of course takes in to account rented attacks, which is possible if there’s more hash-power in the world than your blockchain currently has. This is something presently possible for every single Scrypt-based blockchain out there (despite being ASIC mineable) and many other GPU-only blockchains.

In addition to rented hashpower attacks, the other obvious attack vector is pool-collusion.

Now here’s where MultiShield comes in to play

It’s not enough to specifically just be MultiAlgo, that’s only half the battle, as there are other MultiAlgo blockchains out there that use a different Difficulty Adjustment Algorithms (DAA) that is are as powerful as MultiShield in a variety of ways.

MultiShield works by adjusting the difficulty of all the 5x algorithms every single block. In essence, the difficulty goes up when an algorithm finds a block, and decreases when it does not. This makes it more difficult to find a block using the same algorithm repeatedly, however that in and of itself is not prevented. For example:

Both ProHashing and Coin Foundry found successive SHA256 blocks, which means the “work” for each SHA256 block has grown significantly since 9878708. Every 5 blocks found in succession by an algo, the hash-power required doubles, or every 15 blocks it increases by 8X. As a result of these SHA256 blocks being found, it’s going to be far more difficult to find another one immediately after.

This is MultiShield working as intended.

The primary goal of MultiShield was to take in to account the following:

1. Protection from sudden increases in hashrate in a particular algorithm
2. Preventing the chain from stalling when that hashrate leaves
3. Giving a steady block emission timing for each algorithm so that all have a 20% chance at finding the block

It seems to me that MultiShield is one of the best difficulty adjustment algorithms, if not THE best, in the entire industry. I looked at block timings previously and DigiByte maintains far more steady and superior block timings than any other PoW UTXO blockchain I’m aware of.

Now MultiShield does not prevent one algorithm from finding, say, 5 blocks in a row. That could happen if a large mining pool were to throw 50X the hashrate at the network. An attempt from a large attacking pool for example, could still outpace the main-chain with a single algorithm in the short-term, say for a few blocks.

For example, let’s say there was severe miner collusion across the BTC network, and all 88,000 PH/s was used to attack the DigiByte network, compared with DigiBytes current 36PH/s. In the industry it is generally considered that to attempt to attack any network you would need “an hour” of hashrate, though you could definitely get away with far less in some instances once you became well-practiced (Depending on what you’re trying to do with this double-spend attack).

If you calculate based on the amount of SHA256 hashrate doubling every 5 blocks, then 100% of all the currently-mining BTC hashrate would get approx 60 to 65 blocks before it was unable to outpace the main-chain. This would be approx 15 to 16 minutes worth. Keep in mind this is the whole entire BTC network colluding to attack DigiByte.

Still, it is plausible, though impractical and incredibly unlikely.

Remember: If you cannot 51% attack a network, it’s because it’s centralized.

Allow me to explain a little. If you cannot 51% attack a network, somebody is controlling what is / is not “valid”. As such, it’s centralized. Even though there are very far-fetched possibilities, it’s still plausible for DigiByte (And Bitcoin), because they are permissionless, and truly decentralized.

Let’s play this out a little further then: If the biggest 4x BTC pools have an estimated 50 to 55% of that, so let’s say 49,000PH/s, they wouldn’t be able to get 60 blocks. The biggest two pools colluding at 35% (31,000PH/s) wouldn’t be able to get 55 blocks.

OR if you were to rent 100% of all SHA256 hashrate available on Nicehash, you would have approx 280PH/s at your disposal, not even enough to get yourself 20 blocks.

It’s for this reason that most exchanges set the deposit confirmations for DigiByte around 50 blocks.

Let’s look at some more hypothetical scenarios here though, what if those 4x pools continued to collude, and attempt to attack DigiByte long-term?

Well aside from the fact they would be giving up BTC mining rewards, let’s presume they noted the honest DigiByte chain catching up to them at approx 50 blocks and so they now broadcast their privately mined attacked-chain, they would now have themselves 50 blocks @ 629 DGB, plus any additional fees, so approx 31,500 DGB (USD$210 at todays rates). On the contrary, they would have forgone a 50%+ chance of mining the next block for BTC, at 12.5BTC per-block plus ~1BTC in tx-fees (13.5 BTC total) worth USD$100,000 at todays rates.

Irrational, but again: still plausible

How would the rest of the network react to such an event?

The network would then have to re-broadcast the transactions, and add them in to blocks that are subsequently mined by other algorithms, such as Odocrypt, Skein etc.

For the most part the network could carry on unaffected. The attacker may / may not have attempted a double-spend during that time, they may have simply behaved irrationally for the sake of it.

The point is: They could use that same hash-power to almost permanently attack the BTC, BSV or BCH network and outpace it entirely for prolonged periods, such as hours, days or even weeks. With DGB they need to stop, wait for the difficulty to “cool off” on their particular algorithm, before they began anything malicious yet again.

Again this security is why most exchanges will set their deposit confirmations at 40 to 50 blocks, due to the increasing unlikelyhood of any attack. That’s really all that confirmations are, a measurement of the likelyhood that a transaction is valid and that you’re not looking at a wrong chain.

What about orphaned blocks?

This happens more regularly with MultiAlgo blockchains. It happens with Myriadcoin, Verge, Auroracoin etc.

Why does this happen?

Well as the difficulty changes across each algorithm, some times more “work” will be put in to one algo vs another. For example, the difficulty may have been lowered for Odocrypt so it can help find the next block, and it does, but as that block is propagating across the network a Skein block is found with a higher difficulty level which then becomes the new “longest” tip of the chain.

The Odocrypt block would be orphaned off and the Skein block locked in to the blockchain. Under normal circumstances, both likely contain the same transactions, even where testing on the DigiByte network has occurred and sustained consecutive full blocks happened.

As such, even if something went wrong with the network, or the network was attacked with an exponential influx of hashpower and 8 blocks were orphaned off, that would still be only 120 seconds worth. That 120 seconds equates to a network which is still operating faster than Litecoin or Bitcoin before those orphaned transactions subsequently get included in to another block (IF they weren’t included in the new tip regardless).

Because of this, orphaned blocks are less of a concern, but again a good reason why you should not trust 0-conf transactions.

Again though, blocks being full or not had no effect on miners being able to mine any differently from empty blocks. What we did find during testing in mid->late 2019 was that some smaller pools did not support SegWit, despite them believing they did, and some generous members of the community assisted them in resolving that.

Some additional Q/A:

So MultiShield doesn’t stop 51% attacks?

No, not at all.

It makes it harder, but it’s still not impossible.

The combination of MultiShield, along with DigiByte being the dominant hash-power in 3 of it’s 5 algorithms (Odocrypt, Qubit & Skein) is what makes it so difficult to attack.

MultiShield makes it incredibly difficult, but does not completely stop it.

What should an Exchange set their deposit confirmations to?

That’s up to an Exchange to assess their risk. I would advocate some “smarts” and a sliding scale, rather than a permanently set figure. Where the total value of funds deposited is minimal, across all users, why not set it low at, say, 4–6 confirmations?

If the combination of several users have deposited millions of DigiByte, why not increase it to 40–50 confirmations?

Why not have a limit on the number of blocks an algorithm can find consecutively?

I think there’s a couple of reasons:

1/ If the other 4 algorithms all disappeared into the void, the blockchain could still continue

2/ How do we define that arbitrary limit safely?

3/ If we set it, say, to 3x consecutive blocks, what do those miners then do? Stop? Sit there and wait?

This isn’t something I have a good answer for overall, but something I would be interested in further discussion around.

In closing

The combination of MultiAlgo + DigiShield is truly incredible, a powerful duo that affords a lot of security to DigiByte despite being being a minor hashrate in two algorithms and a dominant hashrate in the remaining three.

Although it doesn’t prevent 51% attacks completely, it makes sustaining one for anything longer than a very brief period increasingly difficult. This could be from a rented hash power attack, or, a collusion of pools.

I would encourage the community to look deeper in to this, be educated on the capabilities / limitations, and to help educate others too.