Let’s imagine a thought experiment where you moved your entire cryptocurrency portfolio to a single coin and then froze your body via cryogenics for 10 years. How should you pick that one coin? In this scenario, the best way to approach the problem would be defensively. Avoiding the possibility of losing the coin and making sure that the protocol will survive the next 10 years should be your biggest concern.
Here are a couple of ways the protocol or network might die:
- Sustained majority attack by miners, hackers, opponent protocols or governments
- Serious design issues
- Serious bugs in the code
- Corruption inside the development team
- Rise of quantum computing
- Encryption algorithm becoming obsolete
- Distrust to team and community
What decision models should be employed to make sure your single coin won’t suffer from these potential vulnerabilities?
1. Majority Attack
To survive an attack, the coin should:
- A) Have a completely different mining algorithm than other coins. This will make it extremely difficult for large miner pools to switch their ASIC hash power to your coin and centralize it.
- B) Ideally, the amount of hardware and block producing power should not be correlated. A correlation will sooner or later lead to network centralization by a certain party. This can be achieved by changing consensus mechanisms. Proof of Capacity is harder to buy in than Proof of Work. Proof of Stake will make it harder to centralize because of early ownership of tokens.
- C) Is immune to classic known attacks: Sybil, DoS, Flood, Double Spend, Network Denial, Finney etc..
- D) Have low cost of security and decentralization, which is mostly a problem with PoW coins. Classic capitalism incentives lead miners to create pools, become more efficient and eventually turn into big companies that acquire smaller companies. This competition increases electricity and hardware cost per coin. Eventually, these companies turn into monopolies. If the cost of security and decentralization is high, the miners will — by economic incentives — get into a position of power where they can slowly destroy the whole network.
2. Serious Design Issues
Some protocols have serious security issues by design and have very large attack surfaces. While the public is aware of these problems, the developers seem to be under the influence of consistency bias and won’t/can’t fix these issues. Just directly eliminating these protocols would be the best bet.
3. Serious Bugs In The Code
The more features a protocol includes, the more attack surface it has and is also more susceptible to bugs. So, ideally, a protocol that doesn’t have hundreds of use cases and smart contracts would be a secure choice. Just keeping the ledger safe is what you need.
Also, the most dangerous bugs aren’t the ones which an ill-intentioned developer puts in a bug and tries to corrupt the network. The code is usually peer-reviewed and tested which helps catch and punish this behavior easily. Even if this type of bug makes its way into the live version, when caught, the network probably would be forked.
A more dangerous form of bug is when a good intentioned developer, while working on improving the protocol, creates a bug that passes through the peer-review process. Which then a small group of people finds out about and exploits it without getting noticed for years until the bug comes to light. This will compromise the trust for the protocol.
The way to prevent bugs produced by ill-intentioned developers:
- A) Have a better organization and hiring process
- B) Have a way to keep track of developer intentions and mental health
- C) Have a more thorough peer review process
The way to prevent bugs from good intentioned developers:
- A) Leave the code base as it is. (No new features, no commits, codebase stay same)
- B) Build the protocol on top of secure tools, libraries and languages, making it unlikely to create bugs. Like using a functional, strongly & statically typed, memory safe programming language.
- C) Hire or give authority to world class developers that won’t introduce bugs. Choosing a functional programming language will indirectly lead you to world class developers.
To prevent bugs from both categories:
- A) Have a very formal, strict, scientific and methodological process for updating the protocol
4. Corruption Inside The Development Team
What if the team is corrupt from the beginning and does not plan on supporting the protocol for a decade? What if they want to flip the project for profit in a few years? Or if by politics or other factors the team members slowly change and most of the authority in the protocol is eventually owned by 1 group of people? (Like BitPay/Blockstream taking control of Bitcoin development) This kind of event could hurt trust in the community. This group could decide to put in features that would benefit themselves over the network, they may purposely stop the improvements of the protocol, they may create ways to steal coins from other people, give themselves some advantages over others, etc..
5. Rise Of Quantum Computing
Quantum computing may or may not enter our lives in the next 10 years. But it does have a real chance of being used in big data centers, specifically crypto mining facilities. Imagine a mining corporation’s hash rate increasing 1000x one day. That has a potential to seriously affect all the balances in the network. The ways to protect against this are:
- A) Have a quantum resistance algorithm
- B) Have a consensus algorithm that doesn’t work with processing power
- C) Have a team that has planned for and is ready to react to huge changes like this
6. Encryption Algorithm Becoming Obsolete
If you look at the history of cryptography, every algorithm gets broken eventually. That’s why we make new algorithms. The question is how long it takes to figure out the math to break it. The answer changes for every single algorithm but every now and then this does happen and the whole industry has to change their algorithms.
If the used encryption algorithm becomes obsolete, susceptible to attack or is somehow broken, the protocol needs to use a new one. The teams that are ready for a scenario like this can update their encryption easily while others, not so much. If the method of breaking the encryption becomes widely available suddenly, and there are obvious attacks and hacks, the protocol can and will probably be hard forked. But if a small group secretly hacked the algorithm, or our computation power grew enough to be able to crack it by brute force, that might be devastating for the protocol.
7. Distrust To Team And Community
This might be a subjective criterion but it is an important criterion. The protocol should have a competent, good intentioned team and community around it. There is always going to be bad actors, but if the core people are good actors, the long term damage will be minimal. Ideally you’d want people fighting to protect your coins and protocol while you sleep. Human intuition is good at spotting these, so if a lot of people distrust a team, it’s a good bet to stay away from their protocol.
Other things to consider:
- Running a masternode for 10 years would provide great economical returns, but the risk of protocol getting destroyed should be the priority, because the returns a masternode can provide won’t match all your portfolio going bust.
- How to secure your private keys? Obviously by using cold wallets, but what if you never wake up from your freezing session? Does your private keys get sent to a member of your family? Or do you break it up with multisig and give it to 5 people? How do you know they won’t decide to screw you over in the next 5 years? Maybe consider adding a time lock to the multisig?
- It is optimal if the protocol is actually useful and has market adoption. While it might be pretty secure, if this protocol does not get market adoption, your coin value is only going to decrease in 10 years. Not having market adoption also creates a huge risk for a majority attack. You might wake up and see that the coin fell by 99% just because of market forces.
A good way to put these criteria into use will be creating a spreadsheet and going through each of these risks for each cryptocurrency.
After my research and thinking process, I’ve come to the conclusion that the single cryptocurrency for me would be Cardano. I believe it checks most of the boxes, if not all. Some of these are being Proof of Stake, having a scientific peer reviewed process, having a team that seems to be good intentioned, having a great organization that is functioning properly, is using functional programming language, has the most amount of PhD’s in a blockchain project.
What’s your conclusion?