Title: Ethereum Classic Supply Control by means of a hard fork.
Type: Standards Track Created: 9/5/2016
Table of Contents
- Backward Compatibility
This ECIP (Ethereum Classic Improvement Proposal) recommends a cap for the total number of ETC tokens to be 100,000,000 ETC (Subject to change) by means of a hard fork. This action is required to maintain an incentive structure that insures security. A cap will also motivate people to contract on the network.
For those of you who read my (Hassan’s) last blog1 about Ethereum Classic, you know that I am pretty excited about the prospects for its future. However, I am not going to mindlessly pump Classic. I have no problem bringing up issues that need to be addressed. We live in a world where greed takes precedent over prudence and this has to stop. We need to guarantee a future for our children and not let the basic principles that guide us be lost.
Classic must be unwilling to forget the basic premises of what makes a cryptocurrency work. Certainly immutability is an important factor and Classic has strongly stood up for that. However, there is another important issue that we should not overlook- the amount of tokens on the network must be capped.
If you will recall in one of my earlier posts2, I took the time to explain what a Nakamoto Consensus is. I use this term instead of “blockchain” because that term does not adequately express the full meaning of the basic elements of a functioning cryptocurrency network. People need to understand that Bitcoin remains the standard by which a Nakamoto Consensus should work. Bitcoin is the digital gold standard for a reason and there are consequences to ignoring that standard. Understand me, I don’t think Ethereum Classic should simply be a clone of Bitcoin, any more than I feel it should remain a clone of Ethereum. Yet, imagine Ethereum’s applications ramped on a platform that conforms to a Nakamoto consensus.
There are certain basic elements that define what is and is not a Nakamoto consensus. Let’s look at the Bitcoin white paper3 to help us see what I mean:
“By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation.”
This incentive structure is part of a subtle, but effective gaming model that maintains security on the network and to date has been remarkably effective on a global scale:
“The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favor him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.”
No matter how much people would prefer it otherwise, tokens must be limited for the system to function. The rabid refusal to accept this is sending the world down a very dangerous path. Satoshi’s application of limited tokens was never meant to be a crusade to convert the world to Austrian Economics, it is simply that limited tokens keep the network secure. Bitcoin has become the internet of money and ignoring the basic premises of how it works, is like pretending you can run a cryptocurrency network with HTML. Possible, but hardly effective.
The gist of Ethereum tokens is that it is meant to be a driver of smart contracts instead of a fungible internet currency. This is hilarious when you think about it, since most contracts have always involved an exchange of fungible value. It really is shocking to see developers try to override 300 years of contract precedent with a double click.
A contract4 is often used to:
- Say what is expected of you.
- Say what you expect of the other person or organization.
- Protect each other’s needs and rights.
- Make each party more responsible for what that party promises to do.
- Say what happens if a party does not keep its promise.
Contracts by their very nature involve matters that rely on events over time. People can and do lock themselves into contracts for extended periods. There is a multi-billion dollar hedging industry designed to help companies manage obligations over time. Currency hedging is a primary example of what I mean. When contracts require payments in Yen, you will need to manage the risk if the Yen collapses. How can we expect people to execute smart contracts in exchange for a tokenized, inflationary asset? People need to be incentivized via a Nakamoto Consensus. If they can expect the value of the token will rise, or remain the same, they will gladly participate. Provided that token is fungible and operates on a secure network.
I often ponder if something like the DAO hack could have happened to Bitcoin. I suppose the answer might be yes, since the contract itself was buggy, but then Bitcoin’s open source vetting is quite rigorous. Most importantly, because incentives exist for people to remain honest actors with Bitcoin, I suspect the DAO hack could not have happened. It really is no small matter to ignore the Nakamoto consensus.
Let’s be honest, Bitcoin could easily increase the number of coins on the network. All that is required is to change the Satoshi decimal system. Just add one or more numbers and you have a lot more satoshis on the network. However, this cannot happen without consensus. If we need more coins, we can have it, but for now the current supply is sufficient. Why have an ever increasing number of tokens? Better to let the system demand it than to include it as part of protocol.
Which leads me to another important part of Nakamoto Consensus. Hard forks are a part of the process. The DAO debacle has put the future of hard forks at risk. This is simply not acceptable. We need to show that a hard fork for the right reasons can be done. Certainly there are other problems with Ethereum, such as the difficulty bomb and the eventual conversion to proof of stake, but how are we to tackle these problems without an immediate fork to cap the number of tokens?
A rule of thumb is that a hard fork should be by consensus. Which means it should not be contentious. My colleague MAbtc5 has already done a far better job of explaining contentious hard forks and their full implications. I can’t do a better job, so I refer him to you. Nevertheless, it should hardly be contentious for Ethereum Classic to conform to the very standards laid down by Nakamoto consensus algorithms. To ignore them is to accept that you do not conform to the standards of a true cryptocurrency.
Do we want to remain in the game or do you prefer to return to the system we already have? Are we a Nakamoto consensus or not? Buggy Horse or Tesla Motors?
Consider the possibility that mathematics is the only proper way to back the value of something. That until now humanity has been unable to properly conduct finance because we have not had the technological sophistication to do so. I won’t bother to go over the details, but I invite you to look back at history and see how so much of what occurred may have been the result of inadequate financial systems that ultimately implode.
Mathematics is the basis of reality6. How magnificent that we finally have a system based in reality! However, the numbers better add up. We can’t afford to let this opportunity pass us by. We can’t forget exactly why the system works.
- Set the cap limit to be 100,000,000 ETC at a trigger point.
- Trigger when 95% of the last X blocks signals support.
4. Backward Compatibility
As a hard fork, older software and nodes need to upgrade to continue to operate.
- Modified from Jeff Garzik’s Bitcoin Block size increase to 2MB (https://github.com/bitcoin/bips/blob/master/bip-0102.mediawiki)
- Modified from Johnson Lau’s and Pieter Wuille’s Bitcoin’s Transaction Signature Verification for Version 0 Witness Program (https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki)