Step-by-step walkthrough

The following is a sequence of events that would happen in the scenario of a forking attempt, as described and illustrated above.

Block 100000

The hash power on both chains will try to build a new block on top of block 99999.

In order for this new block to be built on the minority chain, it needs to acquire at least 3 votes from the live ticket pool and the selected votes depend on block 99999.

The tickets required to build block 100000, based on a block 99999 hash, are ticket numbers 17113, 17331, 21307, 21328, and 24903.

As we can see, 4 out of those 5 tickets are stakeholders on the majority chain (ticket numbers 17113, 17331, 21307, and 24903), which means they are going to cast their votes for block 100000 on the majority chain.

The minority chain is only able to acquire 1 vote (ticket number 21328), so it can’t build a block 100000. Instead, it must go back and find a new solution to block 99999 to cause a new set of tickets to be selected.

At this point, the chains look as follows. Parentheses with the * in this notation indicate blocks that are being worked on.

... -> [99999] -> (100000*)

majority stakeholders (75%) are on this chain \-> (99999a*)

minority stakeholders (25%) are on this chain

In other words, the majority chain is now working on block 100000, while the minority chain is stuck trying to find a new solution for block 99999 in order to get a new set of tickets hoping this time they’ll be able to get at least 3 votes. Since, per our thought experiment, both chains have equal hash power, we can safely assume that, on average, both block 100000 on the majority chain and new block 99999 (call it 99999a) on the minority chain will be found around the same time.

Block 100001

At this point, the following will happen:

The hash power on the majority chain will try to build a new block on top of the majority chain’s block 100000. The votes required for this block are ticket numbers 563, 6766, 21009, 37394, and 37775.

This time, all 5 out of those 5 tickets happen to be stakeholders on the majority chain, which means they are going to provide their votes for block 100000 on the majority chain which allows block 100001 to be built.

The minority chain, now with a new version of block 99999 (99999a) has a new hash, so it ends up requiring ticket numbers 1069, 8007, 16413, 19172, and 31821.

The minority chain is still only able to acquire 1 vote (ticket number 19172), so it must once again go back and find yet another new solution to block 99999 in order to cause a new set of tickets to be selected.

The chains now look as follows:

... -> [99999] -> [100000] -> (100001*)

majority stakeholders (75%) are on this chain \-> (99999b*)

minority stakeholders (25%) are still on this chain

In other words, the majority chain is now working on block 100001, while the minority chain is still stuck trying to find yet another new solution for block 99999 in order to get a new set of tickets hoping this time they’ll be able to get at least 3 votes. Since, per our thought experiment, both chains have equal hash power, we can again safely assume that, on average, both block 100001 on the majority chain and a new block 99999 (call it 99999b) on the minority chain will be found around the same time.

Block 100002

At this point, the following will happen:

The hash power on the majority chain will try to build a new block on top of the majority chain’s block 100001. The votes required for this block are ticket numbers 174, 1999, 12808, 31928, and 38317.

This time, 3 out of those 5 tickets are stakeholders on the majority chain (ticket numbers 174, 1999, 38317), which means they are going to provide their votes for block 100001 on the majority chain which allows block 100002 to be built.

The minority chain, now with a new version of block 99999 (99999b) has a new hash, so it ends up requiring ticket numbers 4653, 15211, 29988, 35175, and 35665.

The minority chain is still only able to acquire 1 vote (ticket number 29988), so it must once again go back and find yet another new solution to block 99999 in order to cause a new set of votes to be selected.

The chains now look as follows:

... -> [99999] -> [100000] -> [100001] -> (100002*)

majority stakeholders (75%) are on this chain \-> (99999c*)

minority stakeholders (25%) are still on this chain

In other words, the majority chain is now working on block 100002, while the minority chain is still stuck trying to find yet another new solution for block 99999 in order to get a new set of tickets hoping this time they’ll be able to get at least 3 votes.

Fast-forward to Block 100010

The process repeats until, eventually, some variant of block 99999 on the minority chain gets lucky and happens to select 3 tickets that are on the minority chain. This turns out to be roughly 1 in 10 tries. So, fast forwarding a bit to see the chain by the time this happens, the chains would look as follows:

... -> [99999] -> [100000] -> [100001] -> [100002] -> ... -> [100009] -> (100010*)

majority stakeholders (75%) are on this chain \-> [99999j] -> (100000a*)

minority stakeholders (25%) are still on this chain

It should be pretty clear, since both chains have equal hash power, there is no way the minority chain can now ever catch up to the majority chain. Furthermore, the same process is going to repeat for the minority chain’s block 100001 where it will have to go back and remine (find new solutions) for its block 100000 over and over until it gets a lucky draw again such that it gets the 3 votes it needs.

Consequently, miners are not going to stay on the minority chain because they are hardly getting any rewards. The minority chain will never be profitable and hence all mining power will eventually return to the majority chain.

Common objections

What if the minority chain gets more than 10x the hash power of the main chain?

Theoretically, if the minority chain with only 25% stakeholder approval had 10x the hash power of the main chain, yes, it could keep up with the majority chain. However, this is not a realistic scenario because of the economic incentives.

Mining the minority chain with 10x the hash power effectively means that the miners would only be getting 1/10 of the block reward as they would on the majority chain, based on hash power alone. In our scenario it’s reduced even further to 1/10 of 60% due to only being able to include 3 votes on average. In other words, miners would only receive 6% of the rewards they would by mining the majority chain. Looking at it from another angle, they would receive 94% less by mining the minority chain.

Putting that into numbers, if a miner had, say 5% of the total network hash power, they could expect to receive roughly 5% of the PoW reward per block, or 5% of ~13.89 ≈ 0.6945 DCR at the current time. However, on the minority chain, first the reward would be 60% of ~13.89 ≈ 8.334 DCR, and then that 5% hash power would only be 0.5% of the total hash power on the minority chain, thus 0.5% of ~8.334 ≈ 0.04167 DCR. Looking at the numbers, we can see that 0.04167 DCR is indeed 6% of 0.6945 DCR.

PoW mining is very competitive since it is a zero sum game. Most miners, even those with huge advantages such as free electricity, have thin margins and are often banking on future appreciation to pick up the slack. Given the 94% reduction in income, most miners would actually have to pay in order to mine on the minority chain.

Can’t somebody just change the consensus rules to ignore the stakeholders?

If the minority chain removed or disabled ticket voting for a certain period of time, it would be able to produce blocks and fork away from the majority chain. While it is theoretically possible, doing so would completely destroy the hybrid system and return the forked currency to effectively being a pure PoW network. It would undoubtedly no longer be Decred.

Unlike in pure PoW coins where nobody can say which chain is the “real” one due to the lack of a provable and formalized governance system, Decred has a very clear and well understood governance model. Decred stakeholders make the decision which chain is the real Decred and they do so in an on-chain and cryptographically provable fashion.

Stakeholders sign up for Decred with the expectation that major consensus decisions are made by the stakeholders themselves. Removing the authority of the stakeholders would be akin to removing Proof-of-Work from a pure PoW coin. In other words, it would completely destroy the security properties of the system. How much confidence are holders going to have in a coin that ignores one of the primary characteristics it claims to offer?

Conclusion

Decred’s hybrid PoW and PoS consensus system makes blockchain forks extremely difficult — if not impossible — without majority stakeholder approval. The walkthrough has demonstrated why a Classic, Gold, or Cash scenario is highly unlikely on the Decred network.

The costs to maintain a minority fork with even 10x of the hash power are substantial; miners can expect a severe reduction in income if they decide to participate. Alternatively, it is possible to remove or disable the PoS system and split the Decred chain like any other PoW network. However, this defeats the purpose of Decred and it is doubtful whether anyone would take such an attempt seriously.

Getting the fundamentals of fork resistance right is critical to longevity. The hybrid PoW and PoS system creates checks and balances to ensure that small groups cannot dominate the flow of transactions or make changes to Decred without agreement among stakeholders. It incentivizes coordination and collaboration, which turns Decred into an uncommonly strong network that is built to last for the long-term.

Further reading

This post has covered the important topic of fork resistance, but there is much more to discover. For example, the hybrid PoW and PoS system of Decred is also a superior deterrent to majority (51%) attacks. If you want to know how this works, read this post by Zubair Zia:

For more advanced topics, you could investigate how Decred can smoothly upgrade its network via voting on consensus rule changes, or how people can submit proposals to the off-chain governance system called Politeia.

If you prefer the basics, check out the Decred Documentation.

Pick one of the chat platforms listed here if you want to interact with the Decred community. We are a pragmatic bunch of people — come join us!

Credits

If it wasn’t for the original analysis by davecgh, this post would probably not exist. Furthermore, Artikozel’s review and the constructive comments in the writers room improved this post tremendously. The illustration of the scenario was created by Zubair Zia. Thank you, all!