A Bitcoin Reorganization, as Suggested by Binance CEO, is not Right or Wrong, it is Just Extremely Difficult

Interview of Donald McIntyre by Omar Faridi on CryptoInsider.

1) Please explain, in detail, why a chain organization of Bitcoin (BTC), as recommended by Binance CEO, would be wrong or a bad idea.

A chain reorganization as Changpeng Zhao, the CEO of Binance, referred to is not either wrong or right. Bitcoin and any proof of work blockchain can be reorganized with little work within a short time window, generally accepted as 6 confirmations or less in Bitcoin, after which point it becomes exponentially difficult, therefore more costly. This is why the whole Binance ordeal was so short, it either demanded a quick reaction, or bribing miners to recover the funds doing a reorg was not even economical for the victim (Binance) nor the bribed miners. This actually shows the power of proof of work after a certain amount of confirmations.

I wrote it is not wrong or right because it is an original design assumption and everybody knows that, with a majority computing power, a pow blockchain can be reorganized. That is a standing threat to coin receivers, even if done by well known full node operators such as Binance and recognizable miners, to any chain of that type and it is widely acknowledged since 2008 as it was written and proved mathematically by Satoshi Nakamoto in the Bitcoin white paper.

The only protection against reorgs is waiting sufficient confirmations. For example, and ironically, for the hacker who stole the 7000 BTC from Binance, he/she should wait for at least 3 to 5 days of confirmations to minimize the threat of Binance colluding with miners to reorganize the chain and steal back the coins. After that, the hacker can feel secure at least on-chain. The consequences off-chain are that he/she will be hiding or running from the law for the rest of his/her life.

It is important to note that the Bitcoin white paper actually describes the invention of proof of work as a new and improved consensus mechanism, not a digital currency, those existed long before. The brilliant invention was the consensus mechanism which provides four things:

  1. As mentioned, consensus between machines with a 50% fault tolerance (all others have 33%-1 fault tolerance).
  2. A cost to producing the blocks which adds a barrier to printing currency spuriously.
  3. Security by making it difficult computationally to rewrite the chain.
  4. The same computational cost as a signal to the market that provides a reference for the price of the currency in the economy.

The stupidity of the CEO of Binance, and the silly anti-Bitcoin and anti-pow people who suggested him the reorg alternative, was to think that he would be able to collude with miners in a few hours to recover the funds. This is because not only Bitcoin is protected on-chain by proof of work as described above, but it is also protected by what is called the “coordination problem”.

That is, when you have operators of a $114 billion decentralized, permissionless, cross border network, with developers, miners and full nodes in different nations and different cultures, spread all over the world in the tens of thousands, and all with high incentives for the network to maintain its integrity to guarantee their property, thus livelihood and businesses, it is extremely unlikely that you will lead them into damaging the network just to recover your petty 7000 BTC which you lost because of your own incompetence in the first place.

Even if a group of miners were to decide to help, they would have gotten a strong counter reaction by developers and full node operators globally, which is a much larger threat to their businesses, in terms of capital and future cash flow, than any reward Binance could have given them. It is much more profitable to remain an honest node and miner in Bitcoin than to go through the trouble and coordination cost of reorganizing the chain. Ethereum Classic already demonstrated that.

It is important to note that a reorg can, in fact, be pulled if the highly unlikely coordination mentioned above actually happens. However, even with the partial reputational loss of the system, the only victim would be the hacker who stole the funds. This is because, even if all miners were to collude with Binance, the only thing they would be able to do is to double spend the money the hacker stole. This means, they cannot change network rules, modify monetary policy, steal money from other accounts nor do anything else for that matter.

2) Can you compare the events that took place at the time of the DAO Attack with Ethereum hack and what we learned from that event (specifically, in how it would be relevant to this most recent event).

TheDAO attack and subsequent chain reversion was orders of magnitude worse than what was suggested by the CEO of Binance. That event was an out of protocol, community wide coordinated attack to the whole network. It was an agreement by a great majority of miners, full node operators and developers to implement an irregular state change to delete the funds by hand from one account, to transfer them to another account (or group of accounts). All without the consent or using the private key of the owner. This was possible in Ethereum because it has a very high profile and strong leader in Vitalik Buterin that sets direction, a foundation with a lot of money who pays for a lot of the development and marketing of the network, therefore has direct influence in the roadmap of the system, and has a philosophy of subjective security, therefore maintain high coordination between the decision makers of the system, which is a reduced and culturally homogeneous group.

A reorg using 50%+ of hashing power, as suggested by Binance, would just be a local problem between the receiver of the funds and the sender, not a system wide violation of the protocol. And, again, it is a known vulnerability that receivers can protect from by simply waiting more confirmations. In a 51% attack, nobody can delete or move funds without the private keys.

3) What do you think would be the main lessons learned from this event as far as Cybersecurity and Digital Assets are concerned?

There is nothing new to learn as reorgs with 50%+ are a known vulnerability. There are, however, many opportunists in the industry (such as Vitalik Buterin, Emin Gün Sirer, Andrew Miller, Washington Sanchez, Vlad Zamfir, Amir Taaki, and Angela Walch amongst many other anti-Bitcoin and nanti-pow people) saying that the suggested reorg by Changpeng Zhao is some sort of final proof that Bitcoin is centralized. To that I tell them that proof of 51% attacks was already given in the October 31st of 2008 white paper by Satoshi Nakamoto, that proof of stake has only 33%-1 fault tolerance and is much more centralized, and, in any case, they actually didn’t get any new proof in this particular episode because it was just one arrogant CEO with a group of Bitcoin skepticals doing intellectual posturing about an imaginary reorg that **never** happened.

4) Does this recent Binance hack suggest that crypto exchanges are highly unsafe, and we need maybe completely different infrastructure for platforms that allow users to trade cryptoassets?

In the same way that it is known that 51% attacks are possible in proof of work chains, it is also widely known that trusted third parties are security holes. This includes, of course, crypto exchanges. But they are not more insecure than traditional banks, brokers or mutual funds. They are just the old format of holding wealth. Proof of work blockchains are precisely looking to solve that problem: In traditional banking, providers have custody of wealth and grant access to owners. In proof of work blockchains, owners have custody of wealth and grant access to providers, which significantly minimizes the risk of trusted third parties. This is done by at least controlling the private keys, and at most (ideal) by running your own full node in your own machine.

5) What are your predictions regarding crypto market this year, in terms of both price and adoption? Where do you see the crypto industry towards the end of 2019?

I can’t predict what will happen in the next year, but in the medium and longer terms I see increasing discovery, by developers, of how to more precisely use a combination of blockchain and layer 2 systems and off-chain systems to build useful applications. This will attract more individual users, enterprise and government to secure blockchains, and that will create more demand for the tokens of highly secure networks such as Bitcoin and Ethereum Classic.

//

Ethereum is a Sports Car and Ethereum Classic is an Armored Vehicle

This is an original interview of Donald McIntyre by Omar Faridi, published on CryptoGlobe.

1) Why is Ethereum Classic a better alternative to building dApps compared to Ethereum?

A useful analogy is to see ETH as a sports car and ETC is an armored vehicle. The problem is to think that ETH can be an armored vehicle and ETC can be a sports car. ETH is about scaling and performance and ETC is about high value and security.

For this, ETH and ETC have different functions in the blockchain industry stack. ETC will be a highly secure base chain, perfectly suitable for decentralized computing and high value smart contracts between people and businesses, while ETH is aiming to be a high speed and high volume transactions layer to satisfy high performance applications.

In that context, ETC could even provide security services to high performance networks such as ETH. I think it would be a big advantage for both ecosystems (ETH and ETC) to analyze that possibility as it would likely minimize, in the context of a standards war, which means that only few networks will survive in the future, the threat of alternative ETH compatible chains such as EOS, Tezos, Cardano, and others.

2) What are some of the unique features of Ethereum Classic?

When ETH finally moves to ETH 2.0, which is a PoS based system with database fragmentation, in the form of sharding, and variable monetary policy, ETC will be the only non-fragmented, fixed monetary policy, PoW and Turing complete blockchain. That is an extremely valuable niche in the industry that will be increasingly appreciated in the next few years as the L1 vs L2 and security vs performance segmentations become more evident for market participants.

3) What are the main challenges Ethereum Classic faces as a platform?

On the technical side, ETC as a platform is not facing major challenges as I see the ECIP (Ethereum Classic Improvement Proposal) upgrades pipeline is advancing smoothly. For example, the Atlantis hard fork on block 8,750,000, which integrates ETH’s Spurious Dragon and Byzantium upgrades, will likely be deployed and activated by mid September, and the Agharta hard fork on block 9,200,000, which integrates ETH’s Constantinople and St.Petersburg upgrades, is under technical analysis, but has minor observations that are being ironed out.

On the market side, I do observe ETC, for historical reasons, has a lower profile and less top-of-mind awareness, so communications about its true state and advancement is always more difficult and costly to convey. The fact that ETH and EOS and the others have billions of dollars to spend in this, is of course a factor as well. However, there are several volunteers, professionals and entities in the ecosystem working on more and more effective communications, such as the ETC Cooperative, IOHK, ETC labs, Christian Seberino, Kevin Lord, myself and others.

4.a) Dan Larimer, the CTO of http://Block.one , recently said EOS’ delegated proof of stake is more scalable and compatible with future technologies.

No matter how many gimmicks PoS distributed ledgers such as EOS invent, they are just that: distributed ledgers. Those are not blockchains, they just make blocks to mimic the authority and perceived security of Bitcoin and Ethereum Classic, but they are no better than normal Byzantine Fault Tolerant and subjectiveness dependent networks. Their security is up to 1/3  fault tolerance and nothing more. I would say that the fact they designate stakers or, even worse, a few privileged nodes to be ‘master nodes’ reduces security further, because the consensus has to be reached only between that subset of a few players, and the rest of the nodes become just followers of their decisions instead of true validators.

For a system as centralized and subjectively directed as EOS to say that it is ‘scalable’ and ‘compatible’ with future technologies is not only a truism, but a stupid truism. This is because it is actually a very inefficient centralized and cumbersome distributed ledger, when AWS, Microsoft Azure, IBM Cloud, Google Cloud are equally centralized, but less bureaucratic and much more efficient and secure by trusted third party standards.

From a business strategy perspective, EOS is “stuck in the middle”. This means it is not trust minimized as Bitcoin and ETC, but it is not as efficient as AWS or Azure and the other cloud services. Therefore, EOS is a dead end for all intents and purposes.

4.b) He also said proof of work is not compatible because we cannot create a new chain with the same network effect as BTC and ETH, among others. Thoughts?

That is the false argument that assumes that high computing power is the only security feature of blockchains that use PoW. It also shows why Larimer would use PoS and copy features of democracy such as ‘delegated-proof-of-stake’ and voting, because he ignores the security model of PoW chains, and thus ignores that EOS is a significantly inferior system in terms of security, and not competitive even in the performance segment, as I mentioned above.

To illustrate, proof of work blockchains security features include, but are not limited to:

  • Consensus & transaction ordering with 1/2 fault tolerance, which is not achievable by PoS.
  • Sybil resistance is much stronger in PoW, with most accumulated work fork choice, than the subjective model of PoS.
  • Accumulated work means that the work done by the miners since genesis is accumulated, making it practically impossible to reverse the chain, even with all the hash power in the network. In PoS 1/3+ of stakers can reverse to genesis in seconds.
  • Unforgeable costliness means the coin is extremely costly to create, thus very difficult to forge. Also, that cost sets a proxy for its value in the economy. In PoS to create the coins has no cost.
  • The above unforgeable costliness also creates a fallback in case the fee model doesn’t work (which is unlikely) or the social layer goes rogue with monetary policy.
  • Broadcast and replication among all full nodes who are true validators, not like PoS, where the only validators are stakers (or ‘master nodes’ in EOS).
  • Miner-client division of power, related to the previous point, also means that PoW miners only build blocks, but those blocks are worthless if not validated by full nodes, this divides the power in the chain and renders no particular participant all powerful, even with 1/2+ computing power. In PoS, such division of power does not exist, rendering 1/3+ of stakers (note this is a subset of the subset) as the only group that controls everything in the distributed ledger.

All of the above means that whether there are several proof of work chains and some are larger than others or if they even share the same mining algo, does not mean they are less secure, it only means that the smaller chain users have to use more confirmations for larger transactions as they may be vulnerable to double spends, which is in itself a local, non-systemic attack vector in PoW public blockchains. In fact, ETC is proof of this.

5) What do you think the crypto landscape will look like next year, and maybe two years from now? And what role with ETC play in that?

It is impossible for me to know what will happen in the next year or two, but what I expressed above indicates that the whole industry will eventually reorganize itself in layers: L1 being the most secure, low performance, high value layer; L2 being the high performance, high volume, and lower transaction value layer; and other systems on top that may constitute the applications layer, such as Lightning network, Plasma, Raiden, Liquid, other sidechains and others.

If ETH, EOS, Cardano, Tezos and other PoS networks actually acknowledge their true nature, they would stop trying to compete at the base layer, and assume their position as layer 2 systems that would use the security services of the base layer as I described in the first question.

//

Notes About Ethereum Classic

A Vision for Ethereum Classic (ETC): Notes from recent social media posts, diagrams and other loose ideas.

Ethereum Classic is the original smart contracts blockchain, founded by Vitalik Buterin, and launched in July 30th of 2015. However, on July 20th of 2016, Vitalik led a great majority of the Ethereum ecosystem to split from the main network to bailout TheDAO. Ever since, Ethereum Classic has been a blockchain focused on security and Ethereum on scalability.

  • The market will be segmented into L1 vs L2 and non-Turing complete vs Turing complete.
  • View of the above in quadrants.
 
 
  • View of how the ETH/ETC stack would look like if there were a rational collaboration between ecosystems.
 
  • View of a future wider landscape with ETH/EOS/Tezos/Cardano/etc. on top of BTC, ETC and probably others.
 
  • At the same time, because people, businesses and governments will want to diversify systemic risks (currency, miners, validators, developers, full nodes, ledger, execution environment, program custody, platform replacement risk, tech rotation, blockchains are very calcified!), this means there will not be only one blockchain, e.g. Bitcoin, at the base layer either.
  • “People, businesses and governments” above means 7.7 billion population, in 190 countries, with $80 trillion in GDP, with $220 trillion in wealth, all those people will not risk everything in one base layer, so there will be systemic risk diversification.
  • Additionally, ETC has a fixed monetary policy which makes it more securehttps://github.com/ethereumclassic/ECIPs/blob/master/ECIPs/ECIP-1017.md
 
  • Bitcoin’s limited Turing complete capacity (Taproot/Graftroot are, by no means, good nor complete solutions) and ETC’s distinct model, with program custody, transparency and execution inside the secure environment of the blockchain, make ETC an absolute necessity at the base layer.
  • Comparison of Bitcoin capacity and Ethereum Classic capacity: Bitcoin currently has a throughput of ~550,000 transactions per day. Ethereum Classic has a current capacity of ~680,000 transactions per day, this is using an average of 67,000 gas, which means transactions are all totally programmable and highly secure, not like BTC, which are just raw basic money movements.
  • Comparisons of traditional settlements layers with volumes and transactions per day: Federal Reserve’s Fedwire processes ~620,000 wires per day, totaling ~$2.9 trillion, and CHIPs processes ~460,000 a day, totaling ~$1.6 trillion in value.
  • The above volumes, including transaction and dollar value quantities, are perfectly executable today on chains such as Bitcoin and Ethereum Classic, which have much higher security, are cross border globally, censorship resistant, immutable and highly programmable in the case of ETC.
  • Comparison to cloud computing systems: Cloud computing services such as Amazon AWS, Microsoft Azure, Google Cloud and others provide high performance, but are not censorship resistant and immutable across all borders and jurisdictions in the world, respond to local and corporate rules and policies, therefore are not socially scalable as Ethereum Classic.
  • How stacking works in computer science, the OSI model: The OSI model has 7 layers:
 
Source Wikipedia.
  • How stacking works in computer science, the TCP/IP model: The TCP/IP model has 4 more or less analogous layers to OSI model:
 
Source Wikipedia.
  • The above means it is perfectly suitable for the “blockchain stack” to be divided in L1, L2, an application layer, and probably several layers in between
  • How stacking works in payments, example VISA: Similarly, payments systems, which can be analogies as well to Ethereum Classic as a component in the blockchain stack, are organized in layers:
 

Conclusion: Present, Repositioning and Future Landscape of the Blockchain Stack

  1. Many chains today, but few will remain at L1.
  2. L1 is about security over scalability.
  3. PoW is more secure, thus will be L1.
  4. PoS is scalable, thus will be L2.
  5. People will also diversify systemic risk.
  6. Therefore, Bitcoin won’t be the only L1, and Ethereum Classic will likely be a highly secure Turing-complete base layer blockchain complementing Bitcoin in use cases and systemic risk diversification.
 

PoW vs PoS

The list of PoS weaknesses:

  • 1/3 fault tolerance
  • low barrier to forge currency
  • low barrier to reverse the chain
  • No unforgeable costliness
  • No proxy for value
  • No fallback in case monetary policy is violated
  • No fallback in case fees don’t work
  • Incentive for stakers to horde, no fair distribution of coins
  • Vulnerable to staker private key risk
  • Nothing at stake problem
  • Vulnerable to long range attacks
  • There is no division of power between node operators and stakers
  • No reliable source of randomness
  • Vulnerable to network partition
  • Vulnerable to low rate of participation in staking
  • PoW miners sink costs and run risk to recover the money by working, PoS validators do not sink any capital and just earn an interest
  • No reliable fork choice rule means there is no way for the nodes who were present, temporarily offline or new nodes joining the network to objectively decide which is the correct chain
  • No reliable fork choice rule means that Sybil attacks are not minimized, in PoW “most accumulated work rule” minimizes them as connecting to just one honest nodes enables new nodes to know which is the correct chain

Proof of Work has Division of Power Between Miners and Full Nodes, Proof of Stake Does Not

Yet another of the brilliant solutions, perhaps one of the most important ones, that Satoshi Nakamoto created when building Bitcoin was to solve the famous Byzantine Fault Tolerance problem in distributed systems. This means that, rather than 33% -1 fault tolerance, Proof of Work blockchains have up to 50% fault tolerance.

However, what Satoshi really did was actually to avoid the problem,rather than solving it directly, by establishing an external physical signaling system: Mining.

 
Bitcoin miners create an external physical signal that is then sent to Bitcoin full nodes.

As an external physical signal, it resembles the signals earth receives from outer space, which are uncontrollable, therefore unforgeable by humans. For example, when laser interferometers on earth detect gravitational waves, those are truly “trustless” because it is impossible for humans to forge such signals, and whoever has a detector (scientists in the US, European Union, China, India, and others) can actually verify the signal directly from the source.

 
Gravitational waves are an external (outer space) unique immutable signature in spacetime, therefore are unforgeable by humans. Image source: Wikipedia.

However, mining in proof of work blockchains is not totally “trustless” as many confuse, it is really “trust-minimized because if a sufficient amount of miners collude to reorganize the blockchain, they can actually do it. This threshold is the famous “51% attack”.

Division of Power Between Miners and Full Node Operators

The good news is that in proof of work networks, such as Bitcoin and Ethereum Classic (ETC), full nodes actually have an additional very powerful recourse to defend themselves from potentially malicious miners: To split from them.

The above can be done by rejecting blocks built with undesirable rules, such as implementing a User Activated Soft Fork (UASF), or by outright “firing” or excluding miners from the network by changing the mining algorithm, which would render their mining equipment, and thus capital investment, useless.

 
As full nodes in a proof of work blockchain can “fire” or exclude miners by splitting away, this constitutes a very powerful division of power in the operating network.

The ability to split from miners, when and if they behave maliciously, constitutes a very powerful symmetrical division of power in any proof of work operating network such as Bitcoin and Ethereum Classic. This is because the standing threat of being excluded is an important deterrence for miners to build blocks with different rules, reorganize the blockchain, make double spends, or disturb network liveness and safety in any way.

Division of Power Does Not Exist Between Validators and Full Nodes Operators in Proof of Stake Distributed Ledgers

Note that I wrote “distributed ledgers” in the title above. This is because proof of stake networks are not blockchains. “Blocks” are only made by miners in proof of work networks using enormous amounts of energy, similar to the large events in space that are detected on earth. All the other digital asset networks using the format and terminology of “blocks” just do that to make the market believe they are “blockchains” to appeal to the authority of Bitcoin and Ethereum Classic.

Moreover, proof of stake distributed ledgers do not have the division of power that proof of work blockchains have. This is because the way those networks are organized is that, of all the nodes, only a subset, the validators (sometimes called Stakers, Block Producers, Bakers, Masternodes, etc.), are the ones who collect, produce and enter new data batches into the distributed ledgers. As the form of becoming validators is by depositing a digital currency (stake) in their accounts, that means that they are inside the same ledger as the rest of the nodes:

 
Proof of Stake validators, a subset of all nodes, create an internal signal that is sent to full nodes. They are inside the same ledger as the other non-validating nodes.

What the above organizational structure creates is that if there are attacks by malicious validators, and the full nodes and the remaining honest validators want to split, they actually carry the attackers with them to the new distributed ledger:

 
“Sleeping with the Enemy” scenario: The attackers, who are a malicious subset of the validator subset, are inside the ledger, therefore are carried to the new ledger if full nodes and honest validators were to split.

This is a huge weakness in proof of stake systems because it means that the only nodes with any power are the subset who are established as validators. They are under no threat of being “fired” or excluded from the network unless a cardinal rule in trust-minimized networks is broken: Immutability of accounts, smart contracts and balances.

The above is because some theorists believe that “social consensus” or “weak subjectivity” in proof of stake means that a hard fork to exclude the malicious validators from the distributed ledger, for example by deleting their accounts and balances or confiscating their deposits, would be a perfectly fine action. This philosophy was, in fact, applied when TheDAO attacker was neutralized from the Ethereum network in 2016 by means of a hard fork that implemented an irregular state change.

However, the reality is that such arbitrary interventions as described above only confirm that the proof of stake design is fundamentally flawed for high security use cases.

The other important thing that this exercise shows is that the true fault tolerance in proof of stake networks is 33% -1 of the subset of nodes who are established as validators, this means, the subset of the subset. That is an extremely weak security threshold.

Conclusion

There are other serious security vulnerabilities in proof of stake distributed ledgers below their fault tolerance. These include, that validator entries in the ledger do not accumulate work, therefore reversing the whole chain to genesis is trivial, while in proof of work, the accumulated work in the chain since the genesis block actually makes it practically impossible to reverse the blockchain, even if miners have 100% of mining power.

 
Proof of work chains are extremely difficult to reverse, even if miners collude to have 100% of mining power, which is extremely difficult to achieve in itself.

The other vulnerability is that the absence of an objective fork choice when there are network splits, such as the most cumulative proof of work, does not minimize Sybil attacks. In proof of work blockchains, that objective fork choice minimizes Sybil attacks because, as long as a node is connected to at least one honest node, it is easy to always select the best version of the chain.

As to symmetrical division of power, it exists in proof of work blockchains because the signal that miners send to the network of full nodes is produced and sent from totally external sources. This means that full nodes have the option of “firing” and replacing such external sources, if they become systematically or significantly corrupted, without violating immutability of the ledger, accounts, smart contracts, and balances.

Such division of power does not exist in proof of stake distributed ledgers making them significantly more vulnerable. That makes proof of stake networks perhaps more adequate for higher performance, but less secure tasks in the digital asset industry.


My thanks to Hugo Nguyen for helping me confirm the absence of “Division of Power” between proof of stake validators and full nodes: https://twitter.com/TokenHash/status/1113285028849442817

Response to Peter Rizun’s “cascading margin call effect” in Lightning Network Thread

You can read Peter Rizun’s thread here: https://twitter.com/PeterRizun/status/1118314312269885440


Peter Rizun told me he is writing a post about how a rise in BTC fees may activate a run on LN channels to close them, rendering, according to him, the Lightning Network ‘broken’.

However, on twitter he posted a figure in a thread that illustrates his point with regards to current channels opened in the Lighting Network:

 
According to Peter, the there is a “cascading margin call effect” in Lightning.

Of course, that is exactly the same phenomenon that happens to accounts and transactions inside Bitcoin or any other money moving system in the world: A fee of X renders an account of X or a transaction of X uneconomic.

But to show that his finding is not very relevant, I did this table below, with future hypothetical Bitcoin fee levels as compared to PayPal, that shows that channels can adjust to perfectly reasonable values when fees goes up.

 
Using PayPal fees as a proxy: What value a channel should have to make Bitcoin fees equivalent to PayPal’s.

The chart shows an indifference point where a Bitcoin fee is equivalent to a current PayPal fee if it were liquidated. In other words, if the Bitcoin fees were $100, then a channel worth $3,437.93 would pay the same fee as a PayPal transfer if it were liquidated.

Of course whoever has accounts, transactions or Lightning Network channels of value X when fees are X, they either have to wait for another moment of lower fees to move their money or they should have managed their money better in the first place!

Ethereum Classic (ETC) Roadmap as Implied by its ECIP Pipeline

As the Ethereum Classic ecosystem has no appointed leadership and operates under an ethos of permissionlessness, it is sometimes worthwhile to gather and summarize the activity in the network from the core development perspective. The ecosystem has at least four development teams which actively work on the protocol layer. These teams maintain four clients which are:

“ECIP” stands for “Ethereum Classic Improvement Proposal”, and there are several repositories, from the different teams named above, where these improvement proposals to the ETC protocol may be found. In general, no consensus changes may be implemented if they don’t go through the ECIP process first, this is why the open ECIPs may serve as a good proxy for a sort of “implied roadmap” for the Ethereum Classic network.

Please note this is not an “official” roadmap, nor the one planned by each team, such as the ETC Labs Core project plan, nor the general roadmap aggregated by the ETC Cooperative that is posted in the EthereumClassic.org website. This is just an indication of the live proposals that are presently under analysis and discussion, which may help more concretely track the future steps taken by the ETC network.

Also, note that ECIPs go through several phases, from “draft” to “active” if they are successful. They can be rejected, withdrawn, deferred or replaced, as well. This means that the list of active ECIPs below and the implied roadmap are just an indication, but are subject to change. Following is the ECIP flow diagram:

 
ECIP process. Source: ETC ECIPs.

In general, ETC is a conservative ecosystem and goes by slowly, but safely, when implementing changes to the protocol. Many developers and participants are involved in the ECIP process. This includes the core developers mentioned above, miners, mining pools, node operators, wallet operators and other independent ETC ecosystem participants. You can watch our last developer and ecosystem ECIP call here:

ETC is migrating from a centralized ECIP process to a decentralized one, thus some ECIPs are in the original community repository on Github, and others are in the respective team repositories. The following are some repositories where ECIPs may be found:

To read more about the migration to the Decentralized ECIP process please click here.

Open ECIPs

The following is a list of ETC’s active ECIPs, with its authors and status, that are planned or may be implemented in the short and medium term in the operating blockchain. Under each ECIP title, a summary from the original ECIP, or other sources, when applicable, is included. Each ECIP below has the link to the original document on Github in case readers want to see more details.

ECIP-1043: Fixed DAG limit restriction 
Author: Cody Burns
Status: Draft

The purpose of this ECIP is to set a limit on the maximum size of the DAG to its initial state and no longer increase it on an epoch schedule.

The original intent of the DAG was to provide ASIC resistance to the mining protocol in order to prevent centralization of mining distributions and thereby provide for an objectively fair distribution of tokens. As evident by ASICs being developed that are capable of matching current GPU miners while being more energy efficient, the DAG has failed at its task and now only serves as a deterrent to broader investment in application specific hardware by competent distributors.

ECIP-1046: NiPoPoWs — Precompiled contract for Merkle Inclusion Proofs
Author: Kostis Karantias and Dionysis Zindros
Status: Draft

Verification of Merkle Inclusion Proofs is obviously possible in EVMbytecode. However, the gas cost for such an operation is very high. We propose adding this functionality to Ethereum Classic as a precompiled contract in order to combat this cost.

Non-Interactive Proofs of Proof-of-Work (NIPoPoWs) are short stand-alone strings that a computer program can inspect to verify that an event happened on a proof-of-work-based blockchain without connecting to the blockchain network and without downloading all block headers. For example, these proofs can illustrate that a cryptocurrency payment was made.

ECIP-1047: Reduce Gas Limit to 1 Million
Author: Anthony Lusardi
Status: Draft

All Ethereum-based chains face a major issue where blockchain bloathas the potential to drastically increase sync times and make it difficult to impossible for users to fully validate their copy of the ETC blockchain.

To mitigate this issue, this ECIP is a request that miners target a gas limit of 1 million which is an 8x reduction from the current limit of ~7.95 million; and well above the average gas size of blocks on the ETC blockchain.

ECIP-1049: Change PoW to Keccak256 (SHA3) 
Author: Alexander Tsankov
Status: Draft

A proposal to replace the current Ethereum Classic proof of work algorithm with Keccak-256.

A response to the recent double-spend attacks against Ethereum Classic. Most of this hashpower was rented or came from other chains, specfically Ethereum (ETH). A seperate proof of work algorithm would encourage the development of a specialized Ethereum Classic mining community, and blunt the ability for attackers to purchase mercenary hash power on the open-market.

As a secondary benefit, deployed smart contracts and dapps running on chain are currently able to use keccak256() in their code. This ECIP could open the possibility of smart contracts being able to evaluate chain state, and simplify second layer (L2) development.

ECIP-1053: Add OpenRPC Service Discovery To JSON-RPC Services 
Author: Shane Jonas and Zachary Belford
Status: Draft

This is a proposal to add OpenRPC support to existing and future JSON-RPC services by adding the method rpc.discover to the projects JSON-RPC APIs, enabling automation and tooling.

The OpenRPC Specification defines a standard, programming language-agnostic interface description for JSON-RPC 2.0 APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code, additional documentation, or inspection of network traffic. When properly defined via OpenRPC, a consumer can understand and interact with the remote service with a minimal amount of implementation logic, and share these logic patterns across use cases. Similar to what interface descriptions have done for lower-level programming, the OpenRPC Specification removes guesswork in calling a service.

ECIP-1054: Atlantis EVM and Protocol Upgrades 
Author: Isaac Ardis
Status: Draft

Add[s] support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Spurious Dragon and Byzantium hardforks. The proposed changes for Ethereum Classic’s Atlantis upgrade include:

  • Spurious Dragon state-trie clearing.
  • Spurious Dragon contract-code size limit.
  • Byzantium EVM opcodes, namely REVERTRETURNDATASIZERETURNDATACOPY, and STATICCALL.
  • Byzantium EVM precompiled contracts, namely addition and scalar multiplication on the elliptic curve alt_bn128, optimal ate pairing check on the elliptic curve alt_bn128, and BIGINT modular exponentiation.
  • Replacing the intermediate state root field in transaction receipts with the contract return status.
  • Change difficulty adjustment to target mean block time including uncle.

ECIP-1055: Succinct PoW Using Merkle Mountain Ranges 
Author: Zac Mitton
Status: Draft

The addition of a Merkle-Mountain-Range (MMR) root to blockheaders.

A block _chain_ could be interpreted as a linked-list using hashpointers from each block to its previous block. A Merkle-Mountain-Range is a type of tree that will allow every block to point back to _all_ its previous blocks. This can be accomplished using only a single hashPointer in each block — the current MMR _root_. Adding this will allow proving the cumulative work, of an entire chain in O log(n) time, instead of the current O(n) time. In the case of [Ethereum Classic], with small block-times, and over 7 million blocks and counting, this will open a ton of doors in the area light-clients, and data verification.

ECIP-1056: Support for ETH Constantinople EVM and Protocol Upgrades, nicknamed “Agharta” 
Author: Isaac Ardis
Status: Draft

[To] enable the outstanding Ethereum Foundation Constantinople and St. Petersburg network protocol upgrades on the Ethereum Classic network in a hard-fork code-named Agharta to enable maximum compatibility across these networks.

[To] add support for a subset of protocol-impacting changes introduced in the Ethereum Foundation (ETH) network via the Constaninople and St. Petersburg hardforks. The proposed changes for Ethereum Classic’s Agharta upgrade include:

  • Constantinople bitwise shifting instructions- Constantinople skinny.
  • `CREATE2` opcode- Constantinople `EXTCODEHASH` opcode.

ETC’s Conservative Approach

In Silicon Valley and other business settings there is a mantra that says “move fast, break things”. However, because ETC aims to be a safe blockchain perfectly suitable for global decentralized computing and a highly secure cross-border settlements layer, that is exactly the opposite of what ETC does when upgrading the network. It could be said that the mantra in ETC is “move slow, don’t break anything”.

The above can be observed by the time and care that is taken in ETC to analyze and integrate the changes already implemented by the Ethereum Foundation in the ETH chain. For example, ETC’s Atlantis hard fork is expected to take place in September of 2019, but it is making upgrades that were made in ETH in 2016 and 2017. Similarly, the Constantinople and St. Petersburg upgrades implemented in ETH in February of this year are projected to be deployed in ETC no earlier than December of 2019.

The Roadmap Implied by the Open ECIP Pipeline

Below is the Ethereum Classic roadmap as implied by the ECIP pipeline described in the “Open ECIPs” section above:

 
Ethereum Classic roadmap as implied by its ECIP pipeline. Other ETC projects that do not affect the protocol or modify consensus rules are not included in this view. ECIPs and this implied roadmap are subject to change.

Please note that the above pipeline is just an estimate, so any individual ECIP may be implemented earlier or delayed, or sometimes not accepted depending on the outcome of the process within the ecosystem. The process consists of a proposal and technical debate period, then a public discussion, and finally an implementation and deployment if all the hurdles are sorted out successfully by each ECIP.

However, the majority of the ECIPs above are considered serious proposals, as per feedback received from the ETC community, and ECIP-1054 Atlantis in particular is practically moving to an “accepted” status in the short term. This means that the above implied roadmap is plausible.

Observations

The most pressing ECIP at this moment in the pipeline is 1054 that specifies the Atlantis hard fork. Fortunately, it seems the six changes proposed have little opposition in the ecosystem and they will likely be implemented, as described, on block 8,750,000 in the ETC Mainnet.

ECIP-1047 to reduce the gas limit is considered important as it asks miners to reduce the block size, so the ETC blockchain minimizes bloating and new nodes are easier to synchronize.

ECIP-1056, that specifies the Agharta hard fork, which is proposed to activate on block 9,200,000, is considered important because it adds opcodes to ETC and is in line with a policy of compatibility. However, some core developers have raised concerns with the `CREATE2` opcode, therefore that hard fork is still under technical discussion.

ECIP-1049 is a proposal to change the mining algorithm, which is a very structural change, and, as such, it is being tested by the author who will be presenting the results to the ecosystem in 2020.

As mentioned above, both ECIP-1049 and ECIP-1055, which are marked for September 2022, may be implemented earlier if they have no opposition, but because it has been mentioned in community discussions to reduce hard fork frequency to possibly once a year, they are marked, at least temporarily, for that date.

Conclusion

The above roadmap, as implied by the active ECIPs, may be a useful tool for the ETC ecosystem in particular and the blockchain industry in general to understand and track the concrete steps the network is taking in the short and medium term. It may also be a good way to provide visibility about Ethereum Classic’s changes and innovation. However, Ethereum Classic has a “move slow, don’t break anything” philosophy. This guarantees the best security practices when upgrading the network which uphold ETC’s philosophy of security, immutability and backward compatibility.

Ethereum Classic (ETC) ECIP-1054 Atlantis Hard Fork Call — Recap

 
Atlantis — ECIP-1054

Today, part of the ETC ecosystem held a call to kickstart discussions about the proposed hard fork, nicknamed Atlantis, as specified in ECIP-1054.

The proposed changes discussed were:

  1. Spurious Dragon state-trie clearing.
  2. Spurious Dragon contract-code size limit.
  3. Byzantium EVM opcodes, namely REVERT, RETURNDATASIZE, RETURNDATACOPY, and STATICCALL.
  4. Byzantium EVM precompiled contracts, namely addition and scalar multiplication on the elliptic curve alt_bn128, optimal ate pairing check on the elliptic curve alt_bn128, and BIGINT modular exponentiation.
  5. Replacing the intermediate state root field in transaction receipts with the contract return status.
  6. Change difficulty adjustment to target mean block time including uncle.

Following is the list of topics discussed during the call:

  • The present situation was described where the ETC core developers have specified the six changes in the Atlantis hard fork and are opening the proposal for discussion to the rest of the community.
  • The goals were also discussed and these include performing the hard fork on block 8,750,000 on the ETC mainnet.
  • Of the six changes the only observation was made by Zac Mitton to analyze the risk/reward ratio that state trie clearing (item 1 above) may represent as it does not affect ETH compatibility, and the benefits in reducing the state size seem to be marginal as compared to some risks when relating those changes to other ECIPs. Also, there seems to be some buggy code risk in the specification of that change.
  • There was general agreement in the call to have a quantifiable benefit of the state trie clearing, and to analyze it further.
  • Zac Mitton offered to run a script to quantify the state size reduction in GB and get back with some results.
  • The state trie clearing topic will be followed up in the next few weeks to reach some consensus of whether to implement it or not.
  • Cody Burns and others in the call agreed that if the state trie clearing were not included in Atlantis, that would have their support as well.
  • Cody Burns asked to clarify whether other changes will be included in Atlantis other than the ones listed above. The general response was that there were no other changes projected for Atlantis so it will likely be frozen after there is a satisfactory conclusion of the state trie clearing issue.
  • Other ECIPs were tangentially mentioned when Cody Burns asked if other changes were projected in Atlantis: Alex Tsankov mentioned that his ECIP-1049, a proposal to change the PoW mining algorithm in ETC, will take longer to test and debate so it was clearly not part of Atlantis. The Constantinople changes were mentioned as well, but it was also indicated that those changes will not be part of the Atlantis hard fork.
  • Regarding Atlantis in particular, from the mining pool perspective, Nick Sawinyh of 2Miners mining pool, manifested that, as they don’t see any miner rule changes, they support the Atlantis hard fork as proposed, which was also manifested on twitter by the company.
  • From the node operator perspective, Aaron LowryMaciej Nowosielski, and Nick Noriegaco-founders of ETH/ETC node hardware and operating system company, Ethernode, manifested that they will support the Atlantis hard fork as proposed.
  • Ethernode also explained that they will communicate the upgrade to all their hardware node users with a notification to voluntarily upgrade their operating system to include the changes.
  • In a previous part fo the call, the Etherenode team indicated to Alex Tsankov that they will also help him test ECIP-1049 (not included in this hard fork as expressed above).
  • The Ethernode team noted that Atlantis will be deployed on the Morden testnet, but that the only client that supports it out of the box by default is Classic Geth, so they asked if the other nodes will support it. The response was that this issue will be relayed Multi-Geth core developers and that it is likely they will address it for Atlantis.
  • There was a question whether Mantis will be supported in the long term and if it will include this hard fork. Kevin Lord responded that IOHK will support Mantis 100% and that the client will include this hard fork.

Conclusion:

In general all the changes as proposed were well received in the call, except for the state trie clearing, which will be discussed further with more analysis as described above. There were representatives from several core developer teams, mining operations, node operators, and other ETC ecosystem participants. The discussions about this hard fork will continue in the following days and weeks.

This is the video to watch the complete original call:

ECIP-1054 Atlantis call.

Ethereum Classic (ETC) Invitation: Atlantis ECIP-1054 Hard Fork Chat on Google Hangouts 4/5/2019 at 12 PM EST

This call has ended. If you want to watch the video it is located here:


After a lot of work, the ETC core developers have prepared the ECIP-1054 hard fork specification, nicknamed “Atlantis”, to integrate the “Byzantium” and “Spurious Dragon” hard forks made in Ethereum (ETH) to assure compatibility across chains.

If you are an ETC node operator, mining pool, miner, developer, general ecosystem participant, or just interested in Ethereum Classic, you are invited to a voice chat to talk about the changes, gain consensus, or discuss possible variations to Atlantis.

 
Atlantis — ECIP-1054

Following are the details:

Call Place and Time:

Agenda:

1. Current situation:

ECIP-1054 named “Atlantis” has undergone developer technical discussion and is ready for wider community discussion with node operators, miners, and the rest of network participants and users.

2. Goals:

The goals for Atlantis are:

  • To make ETC compatible with the Ethereum Foundation hard forks named “Spurious Dragon” and “Byzantium”.
  • Deploy on block 1,039,000 on Kotti — early August 2019.
  • Deploy on block 4,723,000 on Morden — early August 2019.
  • Deploy on block 8,750,000 on ETC mainnet — mid-September 2019.
  • To gain node operator and miner consensus in these goals and deployment dates.
  • To revise these goals and deployment dates ASAP in case there are objections or disagreements.

3. Description:

ECIP-1054 Atlantis includes the following changes and additions:

  • Spurious Dragon state-trie clearing.
  • Spurious Dragon contract-code size limit.
  • Byzantium EVM opcodes, namely REVERT, RETURNDATASIZE, RETURNDATACOPY, and STATICCALL.
  • Byzantium EVM precompiled contracts, namely addition and scalar multiplication on the elliptic curve alt_bn128, optimal ate pairing check on the elliptic curve alt_bn128, and BIGINT modular exponentiation.
  • Replacing the intermediate state root field in transaction receipts with the contract return status.
  • Change difficulty adjustment to target mean block time including uncle.

4. Invite creators to describe their proposal:

Developers invited to describe the changes are:

  • Isaac Ardis @ isaac
  • @ Soc1c
  • Wei Tang @ Sorpaas
  • Other devs who participated

5. Open discussion:

After developer comments, ECIP-1054 Atlantis is open for discussion.

Useful links:

Technical specifications for each EIP can be found at those documents respectively:

  • EIP 100 (Change difficulty adjustment to target mean block time including uncles)
  • EIP 140 (REVERT instruction in the Ethereum Virtual Machine)
  • EIP 161 (State-trie clearing)
  • EIP 170 (Contract-code size limit)
  • EIP 196 (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128)
  • EIP 197 (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128)
  • EIP 198 (Precompiled contract for BIGINT modular exponentiation)
  • EIP 211 (New opcodes RETURNDATASIZE and RETURNDATACOPY)
  • EIP 214 (New opcode STATICCALL)
  • EIP 658 (Embedding transaction status code in receipts)

Critique of Vitalik Buterin’s Comments About the “Dishonesty” of Projects with Early on Supply Caps

In a recent interview Vitalik Butering stated:

“I feel like projects that institute caps early on, there is something dishonest to this decreasing reward schedule concept.”

Sources:

Below I am posting his statements from the transcription on Reddit with my observations below each quote.


I think if people want a supply cap, then 140 million is a totally [achievable] number. Right now, the supply is 105 million, and when proof of stake launches, maybe the supply will be 110 million. Then at some point, we will be able to cut down the proof of work mining reward. Then at some point the proof of work chain will be retired entirely. Maybe at that point the supply will be somewhere in the high 110 millions to 120. Then when that happens, you could totally just follow the same formula I added in EIP 960 and have the issuance just taper off to 140. I think that is something that totally could be done. I think going toward 120 million as the number would be aggressive but 140 million could be achievable if people want a cap.

The supply cap choice in blockchains such as Bitcoin and Ethereum Classic (ETC) does not primarily nor directly address the security proof-of-work mining provides. Mining can be paid with any currency, inflationary or deflationary, including fiat. This means that as long as miners receive revenues that cover their costs plus their expected return, they will invest in hash power, regardless of the medium used to pay them.

What the fixed monetary policies in those chains effectively and directly address is a property rights problem: With variable supply, as opposed to fixed supply, it becomes uncertain what share of the total stock any particular holder owns, moreover, variable supply policies almost always tend to eventually dilute individual ownership shares of money.

Because supply caps are a good way of solving the property rights problem in currencies, then those currencies tend to have increasing value. When currencies have increasing value, they can be used, amongst many other things, to pay for network hash power.

As a matter of coordination and as a token distribution choice, especially during the bootstrapping period, the currencies of proof-of-work blockchains are normally issued and paid to miners in the form of rewards in exchange for their work when producing very costly blocks. The fact that cryptocurrencies have demand for the security they provide, in the form of property rights, is the reason miners can actually use those rewards to pay for the resources they consume such as electricity and equipment.

It seems that in the quote above Vitalik generally agrees, “if people want”, with supply caps. As he expresses below, his objection is really that some projects do it “early on”. However, there doesn’t seem to be, to my knowledge, any logical explanation of why violating people’s rights “early on” is fine, but less fine “later on”, especially if supply caps are created precisely to secure property rights.

The other thing to keep in mind though is that one of the intuitive arguments I have against caps is that I feel like projects that institute caps early on, there is something dishonest to this decreasing reward schedule concept. And the reason why I feel it’s kind of dishonest is that you’re basically claiming two contradictory things at once. You’re using the present level of issuance of the system and the systems ability to operate under the present level of issuance as a proof that the system is safe. But then you’re using the fact that it has this baked in decreasing reward schedule as a proof that it’s finite supply. But then if it’s finite supply then the reward schedule is going to decrease and we have no evidence that the system is going to be safe under the decreased rewards.

As I wrote above, supply caps accomplish the goal of securing property rights, therefore they are totally consistent with their purpose, even more if that implies ending fixed rewards to miners at some point in the future, or through a decreasing reward schedule.

The above “block rewards vs insufficient transaction fees” argument is practically identical to Paul Sztorc’s argument that I refuted in a previous article. Paul argues that the “store of value” feature of Bitcoin, analogous to the “supply cap” objection by Vitalik, is currently paying for miner hashing power, but, as block space is supposedly unlimited through altcoins, and as current fees are very low compared to rewards, then fees will not compensate for the lost revenue miners will suffer. In the same manner, Vitalik is arguing that there is “no evidence” that fees will cover for the cost of hashing power in the future.

Paul and Vitalik are making two mistakes:

  1. They are using the current depressed transaction volumes and fee levels as a proxy to demonstrate that fees alone will probably not cover mining costs in the future.
  2. They are neglecting to acknowledge that in the future there will be very few chains at the base layer, therefore, highly secure block space will be very scarce

Number 2 above means that future transaction fees will likely be much higher than today, therefore, together with higher volumes, will likely cover and probably even surpass today’s and future block reward levels to miners.

If we want a practical example of this it would be current Bitcoin fees today are about $140,000 a day and the current Bitcoin block reward is 12.5 BTC multiplied by 144 blocks which goes up to 1800 bitcoins a day which multiplied by $4,000 which is $7.2 million dollars a day. So Bitcoin going to a fees only model would decrease rewards by a factor of 50. But if you take Bitcoins mining power and divide it by a factor of 50, that’s not much stronger than what ETC has, and ETC got 51% attacked.

The example given by Vitalik above is a gross fallacy because not only is he wrongly using the current depressed fee levels as a proxy for future fees, but he is also falsely using ETC’s recent 51% attacks as an example of a catastrophic event, when what it really proved was exactly the opposite: that double-spends in proof-of-work blockchains are not a general network failure, but a local issue between sender and receiver, and that receivers can easily increase security of their incoming deposits by increasing confirmation times, as many important cryptocurrency exchanges have done.

It is also important to note here that proof-of-work in a blockchain achieves several goals other than just minimizing 51% attacks:

  • It makes it extremely difficult to forge units of the currency, a key feature of functional money.
  • Accumulated historic difficulty makes it practically impossible to reverse the chain after a given number of confirmations, even with 100% of network hash power.
  • It establishes an objective cost for each currency unit which is then used as a proxy for its value in the economy.

The above illustrates that, although 51% attacks and double-spends have become the boogeyman everyone fears, that is only one of several benefits of proof-of-work.

So I think in general people should view promises of supply caps, even if they are backed by angry and ideologically excited people that are extremely attached to their [Schelling points]. I think people should view them as less credible than people generally view them now.

In this segment Vitalik does what he has been doing for a long time: To characterize Bitcoin maximalists, immutability and security buffs, and sound money and proof-of-work enthusiasts as irrational individuals who hold beliefs irrespective of their sound and thoughtful arguments.

The truth is that the one who has been bending reality, even when he knows it perfectly well, and going against any sound blockchain principle, is Vitalik himself:

 
Vitalik and other supporters arguing for weak blockchain security.

More proof of this is that he has consistently reneged on trust minimization as the main goal of public blockchains, has promoted unsound designs for Ethereum, such as proof-of-stake and sharding, has introduced subjective consensus at the social layer as a security assumption for what should be highly secure and objective systems, and, of course, has repeatedly argued against fixed monetary policy and in favor of changing supply whenever a small group of ‘intellectuals’, ‘cryptoeconomists’ and core developers decide to change it.

To the contrary, the people who Vitalik calls “angry and ideologically excited people that are extremely attached to their Schelling points” are actually the ones with the sound principles and promoters of best practices in public blockchains.

But at the same time there is this argument that Proof of Stake can achieve the same level of security much more cheaply than proof of work, and so maybe if proof of work with a supply cap can’t work, proof of stake with a supply cap can work.

Proof-of-stake blockchains cannot achieve the same level of security and sound game theoretical equilibrium as proof-of-work chains precisely because they do not incur in the same external costs that protect the several parts of the blockchain previously mentioned. Therefore, proof-of-stake fails against proof-of-work because:

  • Its fault tolerance is 1/3 instead of 1/2, which even reduces its ability to minimize the feared 51% attacks.
  • For the same reason, there is no barrier for staking nodes to get together to forge the currency.
  • It has no historical accumulated difficulty, which means there is no barrier for staking nodes to get together to reverse the whole chain, all the way to genesis, with no cost whatsoever.
  • No hash rate means there is no proxy for determining the currency unit’s value.

Conclusion:

And if he wants to do the number on that, Ethereums current transaction fees per day are something like I think 500 Ether so if you take 500 Ether multiplied by 365 days a year, you get 180,000 Ether ever year. And 180,000 Ether every year basically means like the equivilent of 0.15% annual issuance. 0.15% annual issuance with 10% of the staking, that means 10% of the staking can get 1.5% annual reward. So it’s definitely not out of the question, but it’s an unproven hypothesis that 10% of Eth stakers will be willing to stake, in exchange for a 1.5% annual reward. So we’ll see. I think it’s almost counter-productive to argue about this too much before we have clearer numbers of how many proof of stake participants are willing to participate. Then after we have those numbers, things will get a lot more interesting.

In the above example, although referring to proof-of-stake, Vitalik is still making the mistake of using the current fee levels as a proxy for future fees when, in the future, it is very likely that block space supply will be very limited at the base layer, transaction volumes will be higher, and, therefore, fees will be much higher.

However, the relevance of Vitalik’s comments in this last segment is that the “we’ll see”attitude is an open door for arbitrary behavior that Ethereum developers have shown in the past e.g. TheDAO reversal, an irresponsible difficulty bomb to force the ecosystem to hard fork, the plans to move from proof-of-work to proof-of-stake with no scientific arguments whatsoever, to fragment the blockchains when maximal replication is one of the key, if not the most important security assumption in a blockchain, and, the main point of this article, frequently changing monetary policy.

Why There Will Only Be 3 or 4 Surviving Blockchains in the Future

For a while I have been insisting that the current state in the blockchain industry, where there are so many competing platforms and systems, will not last very long, and that, in the end, very few blockchains will “win the race” at the base layer.

Below I transcribed two segments of recent articles I have written that refer to the reasons why I believe there will only be 3 or 4 surviving chains in the future.

 
There will be very few winning base layer blockchains.

Security, Exchange and Coordination Costs:

This is a segment of my critique of Paul Sztorc’s Bitcoin “Security Budget in the Long Run” essay. In it I explain some of the transactional costs that will induce the market to select a few platforms and coins in the future.

The segment starts with Paul’s quote followed by my response:

But it is the reverse when we consider transaction fees and “btc-block-bytes”: Altcoin-blockspace is a pretty good substitute for Bitcoin-blockspace.

I disagree that block space is a generic commodity, therefore a transaction in Bitcoin is totally replaceable by a transaction in any altcoin or L2 system for that matter. Up to a certain extent, and in different proportions, users will tend to tradeoff low transaction fees for standards and safety. This is because there are several types of costs that will induce the world to select very few chains in the future: security costs, exchange costs, and coordination costs.

Security costs: It is not the same to move value using the Bitcoin network or using any altcoin or L2 solution. This will create a market for high value, highly secure transfers in Bitcoin, e.g. central banks, governments, interbank, corporate and other large value payment users, who will gladly pay very high fees. For those who don’t need such security or for low value transfers there will be of course cheaper alternatives in other chains or in L2 solutions as mentioned above.

Exchange costs: When senders and receivers want to store value in Bitcoin, but need to transfer them, it will not be frictionless to move from BTC to an altcoin, send it for a lower fee, and then pass it back to Bitcoin on the other side. Between exchange commissions and spreads there will be an indifference point beyond which it will be better to pay for Bitcoin fees. Not only that, but the security dynamics mentioned above also change substantially. If Bitcoin is a very good store of value, transfers will occur within Bitcoin precisely for the same reason it is a good store of value.

Coordination costs: Just because you can create N altcoins does not mean they are all going to survive. Because they are all not going to survive, there will be a limited competing block space market in the world. This is because our minds are limited and we will not think about 250 cryptocurrency names, transfer fees, the subsequent 250 prices, and go selecting the cheapest one each time we move value. Our brains will only support understanding the value of 3 to 5 coins at most, and we will be comfortable using them interchangeably up to a certain point. If this is correct, then, together with the security and exchange costs considerations above, there will be a limited amount of coins in the future, with a limited amount of block space and transaction capacity. This means that the cost of sending value will be distributed between the surviving chains in proportion to value and safety requirements.


The Comparison to the Operating System Industry:

This segment is from an article where I explained how a rational collaboration between Ethereum and Ethereum Classic should be in the context of a standards war, where very few chains will survive. I wrote it in response to Virgil Griffith’s “deal” offer on Twitter where he asks for a“wishlist” to some ETC folks.

The segment starts with my quote on Twitter followed by my expanded explanation below:

For several reasons I think the base layer blockchain space will end up in the long run with 3 or 4 leading global chains. The share will be distributed something like this:
1st chain: 50% 
2nd: 25% 
3rd: 12.50% 
4th: 6.25%
The balance may be an “all the rest” niche residual list.

The reason I stated the above is because blockchains have network effects and, when those externalities kick in, usually it is a “winner takes all” kind of market. This means that when the sector as a whole, and some of the blockchains inside the sector individually, reach a certain critical mass, they will enter a runaway growth phase in total market size and relative market share, where very few chains will be the “winners” and they will likely be very big.

The current period, where there is no defined winner and the general sector is still small relative to the competition and its total addressable market, is called the “standards war” or “format war”. In history, there have been many ways in which standards have been established in the market. Some examples of industries that have gone through intense standards wars with a single or very few resulting winners have been: electricity alternative current vs direct currentrailway gaugeBetamax vs VHS video standards, and during this information age, the browser war and the operating systems war, amongst many other format fights in the past.

I think the most comparable products to blockchains that are sensitive to externalities are operating systems, e.g. Windows, macOS, Android, IOS, Linux, Apache, etc. This is because, in essence, notwithstanding the large efficiency differentials, both blockchains (especially Ethereum and Ethereum Classic) and operating systems serve as multipurpose computing or computing enabling systems across the world where developers can create and build new applications and use cases on top.

Having said the above, if we see how operating system markets are distributed today we will see that there are always very few, usually 3 to 4, winners and then a residual list of players who either find a niche or become irrelevant.

Some examples of few winners in the consumer operating system market are:

Desktop and Laptop OS Shares:

 
Desktop/laptop OS market shares, 1st quarter 2019. Source: NetMarketShare.

Mobile OS Shares:

 
Mobile OS market shares, 1st quarter 2019. Source: NetMarketShare.

All Global Consumer Devices Combined (desktop/laptop, mobile, tablet, handheld and TV) OS Share:

 
All consumer devices worldwide OS market shares, 1st quarter 2019. Source: NetMarketShare.

As blockchains, especially highly secure base layer chains, may be regarded as non-consumer facing, but backend computing infrastructure, I include below examples of enterprise operating systems, web server systems and super computer market share data:

Enterprise Server OS Market:

 
2017 enterprise server OS share (RedHat is Linux and Microsoft is Windows). Source: IDC/Red Hat.

Web Server Market Share:

 
Web server market share, March 2019. Source: W3Techs.

Supercomputer OS Market Share:

 
Supercomputer market shares from 1993 to 2018. Source: Wikipedia.

As can be seen in all operating system segments above, there are usually one or two players at the top who command the largest market shares. Then, the third and fourth players experience a significant lag, and, usually, after the third and fourth players, the market shares of the remaining systems become practically insignificant.

Of course the blockchain industry is very unique because secure chains are not only analogous to a computer operating systems, but also contain currencies and smart contracts, which represent property and agreements. However, it is safe to say that currencies in general also have network effects, either locally in their jurisdictions or globally, and that the shared internal state of secure blockchains are also environments with strong externalities.

Due to the above, my guess is that after this period of standards wars, there will be very few winning blockchains, say, 3 or 4, and whichever group of chains wins will have market shares roughly as the operating systems I used as examples above. As a gross simplification, my “guesstimate” is that more or less 4 chains will win, with more or less 50%, 25%, 12.5%, 6.25% of market shares respectively, and all the rest the remaining 6.25%.


Conclusion:

Because human brains have limited capacity and we tend to seek for standardized platforms to reduce transactional costs and increase cooperation, I think it is highly unlikely that many chains will be operating at the base layer in the future as many advocate. Of the few that will make it I feel very confident Bitcoin will be one of the selected ones by the market for its size, liquidity and historical importance. The other one that I feel very comfortable with is Ethereum Classic because, when Ethereum migrates to proof-of-stake and sharding, ETC will be the only proof-of-work and Turing complete chain with a fixed monetary policy, that is a very valuable position.

 
ETC is in a very valuable niche.

As to which other blockchains may make it, I think developers, researchers, designers, miners, stakers, node operators and the other participants in their ecosystems need to find, as soon as possible, a valid and specific problem they can solve, with a logical and well thought solution, if they aspire to eventually occupy one of the obviously scarce and highly valuable positions in the base layer of the blockchain stack.

Ethereum Classic (ETC): Decentralized ECIP Chat on Discord on 3/22/2019 at 12 EST — Recap

Today we conducted a voice call in the Ethereum Classic ecosystem about a new Decentralized ECIP Process proposal:

 
Tweet by Ethereum Classic thanking community participation in the call.

High Level Summary:

  1. The ECIP aggregation site is a good idea (nearly everyone agreed with it).
  2. The proposed Decentralized ECIP process in general is a nice to have, but there are more important things in the short term to focus on, such as the Byzantium hard fork.
  3. The proposed Decentralized ECIP process creates a lot of friction for developers, minimizing its possible adoption, by adding steps and activities on top of their normal work.
  4. Going in small steps: A tool to create standard preambles for decentralized ECIPs will be built to see if developers like it and adopt it (see “Preamble Tool” section below).

Agenda and Feedback:

1. Current situation: 
• Migrating from centralized to decentralized ECIPs
• Existing repos:
– ETC community ECIPs
– ETC Labs Core ECIPs
– That.World/Ethoxy Initiative ECIPs

The current situation was described and there were no major objections in the general discussion. A few days before this call ETC Labs Core had changed its improvement proposal name from “ECLIPs”, a name that caused controversy, to “ECIPs” (see here), which was well received as an indication that they wish to follow ecosystem standards.

It was, however, brought by some participants in the text chat during the call that the Byzantium hard fork seems a more pressing matter and that perhaps that would have been a higher priority than the Decentralized ECIP process:

  • “I’m also not sure if we need this right now e.g. I’d prefer this talk was about byzantium changes”
  • “Same.”
  • “yes, let’s talk Byzantium”
  • “It’s an interesting problem to think and discuss but we should prioritize stuff”
  • “Our time is pretty much up though”
  • “happy to help there if it means we can focus on more important stuff”
  • “We need to talk about that while we’re all here”
  • “next Friday call maybe, need to drop for my next meeting”
2. Goals: To agree on a standard process. To have all teams and individual devs use it (e.g. the above + Parity + IOHK + independent developers).

The goals of the Decentralized ECIP process were presented. There is general agreement about having “a system”, but there were some objections in the general discussion around having the freedom to use or not specific tools, such as Github, a team web repository, etc.

3. Description: ECIPURI + starIP + ECIP-1000 + Archiving + Model site
• ECIPURI:
– URI formats:
– ecips.teamdomain.tld/ECIP-hash
– github.com/teamname/ECIPs/ECIP-hash
– URI Directories:
– Known directory: standard known.json file
– Specs directory: standard specs.json file (team need to update each new ECIP)
• starIP deterministic numbering
– Standard preamble
– SHA3–512 hash
– Encode in BASE58
– Use last 8 characters as ECIP version number
– Use last 4 characters as ECIP proposal number
– Complete standard preamble with numbers, URIs and discussion URL
• ECIP-1000: a standard process described in 2017
• Archiving: the idea is for all ECIPs “live” in independent archives in case teams shut down, delete them or anything that may happen
• Model site: ecips.that.world

The components of the Decentralized ECIP process were presented. The feedback in the general discussion was that adding steps and new rules for developers to follow may create friction that, in the end, may discourage adoption of the new system:

• “yeah KISS method :)”

4. Invite creators to describe their proposal: Wei (ECIPURI + ECIP-1000 + model site), Zach/Shane (startIP), Tomasz Zdybal (Archiving)

Wei Tang and Tomasz Zdybał were not present to describe the components they created (ECIPURI and Archiving respectively), but Zachary Belford explained the StarIP Standard along the argument that in a federated system with several teams writing ECIPs in different repos, it is necessary to have a standard deterministic numbering system. There was general agreement:

  • “yeah the starip distributes the control over the processes instead of one repo”
5. Open discussion: Questions & answers

After the introduction and explanation by Zach Belford, Zac Mittonexpressed that it is ideal to have aggregation and the the ideas presented, but he felt that the additional friction brought on developers may discourage adoption of the Decentralized ECIP. There was general agreement by various participants.

A user by the handle DBamford explained that from his outsider view he thought that ETC seems to be going through a lot of chaos and that he thinks the community should not fear a centralized process (presumably referring to using Github and imitating the BIP and EIP processes). Responses by other participants were that the curent discussions about the ECIP process were not regarded as a threat or “chaos” within ETC. In general there was a an agreement that, eventually, a logical and decentralized process could emerge and that such discussions were actually productive and a signal of true decentralization.

The following are some other questions that were addressed in the call:

1. Where will this ECIP run? Github? Who will be the admins? Or it will be etc chain dependant?

Zach Belford responded that really the underlying tools to implement the ECIP process should not be compulsory, that people can submit an ECIP using Github, their own website, or other means including mailing letters! (the last was a joke, but served as an analogy of the freedom devs should ideally have).

Donald McIntyre expressed his preference that everybody use Github as it is the software versioning platform everybody uses in the world, but there was general agreement about freedom of tools and having no specific set, especially as compared to the systems of Bitcoin-BIP and Ethereum-EIP processes.

2. How does a casual follower get a global view of ECIPs that are active?

Several participants responded that aggregation sites would be a good idea to help casual followers find ECIPs and their discussion locations.

It was commented that Wei tang did a great job creating the aggregation site ecips.this.world as an example of how such aggregation sites could work.

It was also reminded by Anthony Lusardi that the ECIP aggregation site above is actually open source and can be used by anyone to create their own ECIP aggregation site. You can find it here.

The following are some questions that were not addressed, as they were not seen or the call ended, but remain pending:

  1. how do we retain comment history? if you have N repos where there are comments for an ECIP, the probability of one disappearing is higher. Do we care about this or is it a non issue?
  2. I see that our difficulty rn is not the platform or channel of reference but the difficulty of agreement between different entities. So are we gonna fix the github reference to make it more easy to come easier to an agreement?
  3. How are ecips closed/finalized/accepted ? this has always been a bigger issue than discovery for me
    im happy with any system as long as it is easy to understand for the casual observer. ethereumclassic.org header process and tracks would be nice. also an infographic on ther explaining it

Comments about the “Preamble Tool”:

As some of the main themes of the chat were to “keep it simple” and “start small” to see if developers would start adopting new decentralized standards for the ECIP process, there was general agreement to build in the ETC Cooperative and/or the ethereumclassic.org website a tool to easily build ECIP preambles using the standards described in the meeting.

The idea of the tool is that it would convert a basic standard ECIP preamble entry into the full preamble in the following way:

1. You enter:

Title: Byzantium on block 696969
Author: Santa Clause <a@b.c>
Discussions-To: a@b.c
Status: Draft
Type: Standards Track
Created: 2020–05–25
Replaces: kRau7PZs
Superseded-By: ZxftDmL3

2. And returns:

ECIP: kMre
Title: Byzantium on block 696969
Author: Santa Clause <a@b.c>
Discussions-To: a@b.c
Status: Draft
Type: Standards Track
Created: 2020–05–25
Version: 6z9ekMre
Replaces: kRau7PZs
Superseded-By: ZxftDmL3
URI: ecips.santaclaus.com/ecip-kmre
Discussion URL: github.com/santaclaus/ecips/ecip-kmre/issues/

Notes, Other Thoughts and Conclusions:

  • Help create a similar call to talk about the Byzantium hard fork (ECIP-1054).
  • Anthony Lusardi (ECIP-1047) and Alexander Tsankov (ECIP-1049) should continue to push their ECIPs in the ETC community repo where they originally submitted them.
  • Biggie is better than Tupac.
  • “Voting” was commented in the text chat during the call as a solution to agreeing on ecosystem processes, but it was generally rejected.
  • Zac Mitton expressed that the problem-solution logic should be stated clearly to understand if the Decentralized ECIP process was adequate. Zach Belford agreed and stated that is an important way of proceeding going forward.
  • There was general agreement that doing these calls are productive when addressing important ecosystem issues.

Useful links:

Post Call Reactions:

 
By Kimi Sian-Yu Chen
 
By Zachary Belford
 
By Donald McIntyre
 
By Donald McIntyre

Model for a Rational Ethereum and Ethereum Classic Collaboration

This article is based on a deal bellow offered on Twitter by Virgil Griffith, Special Projects Manager at @ethereum, where he asks Ethereum Classic (ETC) folks for a wishlist of things ETH could do that would benefit ETC:

 
Deal offered by Virgil Griffith to @ClassicIsComing

These three tweets contain the main point of the wishlist I wrote to Virgil:

 
My response to Virgil Griffith’s wishlist request.

Bellow I’m re-posting the full thread so I can elaborate further on some of the reasons, sources of information and ideas for such wishlist, which I think is a rational way of approaching a more productive collaboration between the two networks.

Full Thread and Rationale:

1. For several reasons I think the base layer blockchain space will end up in the long run with 3 or 4 leading global chains. The share will be distributed something like this:
1st chain: 50% 
2nd: 25% 
3rd: 12.50% 
4th: 6.25%
The balance may be an “all the rest” niche residual list.

The reason I stated the above is because blockchains have network effects and, when those externalities kick in, usually it is a “winner takes all” kind of market. This means that when the sector as a whole, and some of the blockchains inside the sector individually, reach a certain critical mass, they will enter a runaway growth phase in total market size and relative market share, where very few chains will be the “winners” and they will likely be very big.

The current period, where there is no defined winner and the general sector is still small relative to the competition and its total addressable market, is called the “standards war” or “format war”. In history, there have been many ways in which standards have been established in the market. Some examples of industries that have gone through intense standards wars with a single or very few resulting winners have been: electricity alternative current vs direct currentrailway gaugeBetamax vs VHS video standards, and during this information age, the browser war and the operating systems war, amongst many other format fights in the past.

I think the most comparable products to blockchains that are sensitive to externalities are operating systems, e.g. Windows, macOS, Android, IOS, Linux, Apache, etc. This is because, in essence, notwithstanding the large efficiency differentials, both blockchains (especially Ethereum and Ethereum Classic) and operating systems serve as multipurpose computing or computing enabling systems across the world where developers can create and build new applications and use cases on top.

Having said the above, if we see how operating system markets are distributed today we will see that there are always very few, usually 3 to 4, winners and then a residual list of players who either find a niche or become irrelevant.

Some examples of few winners in the consumer operating system market are:

Desktop and Laptop OS Shares:

 
Desktop/laptop OS market shares, 1st quarter 2019. Source: NetMarketShare.

Mobile OS Shares:

 
Mobile OS market shares, 1st quarter 2019. Source: NetMarketShare.

All Global Consumer Devices Combined (desktop/laptop, mobile, tablet, handheld and TV) OS Share:

 
All consumer devices worldwide OS market shares, 1st quarter 2019. Source: NetMarketShare.

As blockchains, especially highly secure base layer chains, may be regarded as non-consumer facing, but backend computing infrastructure, I include below examples of enterprise operating systems, web server systems and super computer market share data:

Enterprise Server OS Market:

 
2017 enterprise server OS share (RedHat is Linux and Microsoft is Windows). Source: IDC/Red Hat.

Web Server Market Share:

 
Web server market share, March 2019. Source: W3Techs.

Supercomputer OS Market Share:

 
Supercomputer market shares from 1993 to 2018. Source: Wikipedia.

As can be seen in all operating system segments above, there are usually one or two players at the top who command the largest market shares. Then, the third and fourth players experience a significant lag, and, usually, after the third and fourth players, the market shares of the remaining systems become practically insignificant.

Of course the blockchain industry is very unique because secure chains are not only analogous to a computer operating systems, but also contain currencies and smart contracts, which represent property and agreements. However, it is safe to say that currencies in general also have network effects, either locally in their jurisdictions or globally, and that the shared internal state of secure blockchains are also environments with strong externalities.

Due to the above, my guess is that after this period of standards wars, there will be very few winning blockchains, say, 3 or 4, and whichever group of chains wins will have market shares roughly as the operating systems I used as examples above. As a gross simplification, my “guesstimate” is that more or less 4 chains will win, with more or less 50%, 25%, 12.5%, 6.25% of market shares respectively, and all the rest the remaining 6.25%.

2. I think the base layer will primarily provide high security in the form of consensus and monetary policy.

As experienced during the block size debates in Bitcoin, and later seen in Ethereum with the “Cryptokitties” phenom, it is very difficult to scale base layer blockchains securely. This means that layer 1 (L1) blockchains will have to provide basic, high value, low volume security services such as secure transaction processing, smart contracts and hard money oriented monetary policy, and layer 2 (L2) chains and systems will provide low value, high volume and performance computing, and flexible features and benefits to end users and enterprise.

3. I think at least BTC & ETC are well designed and positioned to occupy the value reserve (BTC) and the Turing complete (ETC) base layer roles. I don’t know what the other ones role will be, maybe privacy or just a diversification alternative for people and businesses like LTC (?)

In the context of a few blockchains surviving at the base layer in the future, I think those select chains will have to be the ones with the strongest security features while following the most stringent blockchain principles. This means not only a sound technical design, focused on trust minimization such as proof-of-work consensus mechanism, but also a disciplined monetary policy.

As to which blockchains will be selected in the end by the market based on their security and specific features, it is difficult to say, but I am confident that Bitcoin will be one of those because of its size, safety, history and significance, and Ethereum Classic as well because it is the only chain that will be proof-of-work, Turing complete, and have a fixed monetary policy:

 
When Ethereum migrates to a proof-of-stake consensus mechanism and sharding, ETC will be the only proof-of-work and Turing complete blockchain with a fixed monetary policy.
4. In the above scenario, a chain like ETH will not able to compete as a safe base layer chain, because “safe enough” is not an option for the use cases that require base layer security: as objective as possible social scalability thru trust minimization.

Ethereum is migrating to proof-of-stake and sharding. Proof-of-stake has two problems, it is built on top of two flawed arguments, that proof-of-work kills trees and doesn’t have finality, and it is based on subjective consensus which is precisely the opposite of what blockchains are seeking to achieve: social scalability by means of trust minimization. On the other hand, one of the basis of blockchain security is that the database has to be replicated throughout all nodes in the network, therefore fragmenting it using sharding unavoidably goes in the opposite direction.

Due to the above, Ethereum proof-of-stake plans have been widely criticized by prominent industry participants and computer scientistsThis means that Ethereum does not qualify as a highly secure blockchain, therefore it cannot compete with truly safe base layer chains such as Bitcoin and Ethereum Classic.

5. However, both ETH, with its flawed strategy, and ETC, with its little resources, are signaling to the world that they want to be positioned in the same niche: be the base layer secure Turing complete chain.

The complementarity that may exist between Ethereum and Ethereum Classic is that Ethereum has huge resources and a larger community, but it is trying to position itself in a segment were it will not be able to compete in the future. Ethereum Classic, on the other hand, is well positioned and designed for the place it wants to occupy, but has little resources and a much smaller community which may make it lag in the market. This means that there is an opportunity for collaboration in a rational way.

6. I see ETH may have an opportunity to be a user and enterprise facing public chain as an L2, PoS and sharded, scalable option if it uses chains like BTC and ETC as security providers in the back end e.g. checkpointing and monetary policy thru pegging on BTC & ETC.

If it’s true that PoS and sharding are not the most secure systems for base layer blockchains, but that those systems offer much higher performance, then Ethereum can perfectly be a consumer and enterprise facing blockchain, providing the features and benefits such users need, but at the same time securing their accounts, balances and smart contracts, by using the services of chains such as Bitcoin and Ethereum Classic for finality and hard money.

7. There’re like 10 or 15 (I lost count) other ETH compatible PoS + sharded + governance + {invention of the day} chains in the market. If ETH & ETC can formulate and agree on a clear strategy as above and communicate it effectively, then all the other chains would become obsolete.

In the context of standards wars as described in the first part of this article, the market needs to eventually decide on a format to minimize coordination and mental costs. For that, users monitor signals from the potential providers to see if they are meeting the desired requirements to become such standards. Important signals are that the technology is correctly designed to satisfy security and performance needs, that liquidity is growing in the form of other users adopting the standard, and that the format has a true chance of becoming the winner. A clear strategy that leverages the advantages of both the ETH and ETC chains would go a long way assuring users, while all other competing or substitute alternatives would become much less relevant in front of such advancements.

8. This is b/c currently we’re in standards war. However, if ETH & ETC can coordinate to be truly complementary chains (security provider + performance provider) one on top of the other, w/ clear roles and value added, then that would be the definitive winning signal to the market.

Ethereum’s roadmap already includes a vertical fragmentation of the blockchain into shards and a horizontal subdivision in layers with a beacon chain at the base, shards in the middle, and Raiden and/or Plasma layers on top, where these two last ones are the final solutions to consumer and enterprise scalability in the medium to long term.

 
Ethereum 2.0 Roadmap. Source: Vince Tabora on Hackernoon.

Since a proof-of-stake beacon chain will not be sufficiently secure to support the whole structure above (note it’s a security consideration, not scalability) either it could be replaced with pegging shards directly to Ethereum Classic, or the beacon chain itself could be pegged to ETC to obtain the security services of a proof-of-work and fixed monetary policy base layer.

 
Ethereum Classic as a base layer security provider, and Ethereum Beacon Chain, shards, and Raiden and/or Plasma as definitive scalability and high performance solutions.

That is a smart and rational design choice that ETH engineers can analyze working together with ETC engineers, while truly complementing, therefore benefiting, both networks.

Conclusion

9. PS: If both chains continue to try to be the base layer secure Turing complete chains, then they will continue to compete for their life in this standards war, together with all the other imitators, because very few, if not one or two, in this segment will survive.

The current state of affaires is that there are a lot of gestures and signs of collaboration between Ethereum and Ethereum Classic. However, those interaction don’t seem to have a concrete vision and strategy, other than trying to suck network effects from each another, to reach any specific and constructive goals for both chains. The truth is that if ETH and ETC both want to be base layer networks, then one of them will likely die in the effort. Today ETH has a scalability plan that is more adequate for L2 blockchains, money and community momentum, while ETC has the correct design, security and monetary policy. A sincere and much more productive plan and future can be envisioned if they leverage their strengths.

Ethereum Classic (ETC): Model Decentralized ECIP Site

 
In this article I describe an idea for a general model for ETC development teams to have as a sample to create their team ECIP sites. Also, independent non-developer teams or entities can host such sites so that more places can serve as aggregators and repositories for the decentralized ECIP system.

This model is based on Wei Tang’s ecips.that.world site, the 24-ECIPURI specificationZachary Belford and Shane Jonas’ StarIP Standard, the ECIP-1000 process by Wei Tang which is based on Luke Dashjr’s BIP process, and a pending archiving proposal by Tomasz Zdybał.

The General Lifecycle of an ECIP:

 
The ECIP lifecycle.

As it can be seen above an ECIP generally goes through four stages in the decentralized ECIP process:

  1. Numbering: To minimize conflict between team ECIPs, a deterministic numbering system that hashes their preambles’ metadata is created so that each ECIP can be unique.
  2. URI: To facilitate search and discovery, every ECIP is designated a specific URI in the format ecips.teamdomain.tld/ecip-proposalnumber or github.com/teamname/ecips/ecip-proposalnumber. Also, known.json and specs.json files are created and hosted to facilitate their aggregation.
  3. Process: Just as the old ECIP process, all teams follow the presentation, rationale, status and discussion process to propose and accept or reject changes to the ETC consensus rules.
  4. Archiving: In the new decentralized ECIP process all ECIPs are stored in each teams repositories after acceptance and merging. However, to guarantee their continued existence, authenticity and availability, in case teams migrate, quit, or delete ECIPs for any reason, a general ecosystem archiving system is needed. This archiving system will be proposed in the near future.

Model Site Structure:

 
Components of the model site for hosting and aggregating decentralized ECIPs.

As seen above, the model site has three sections represented by the columns:

  • Home: It is the home of an ETC development team ECIPs or an independent ECIP aggregator. As in all improvement proposal sites in crypto (BIP, EIP, old ECIP, etc.), the home describes the process and shows the steps to submit, discuss, approve or reject ECIPs.
  • Local team’s ECIPs: This section hosts the local team’s ECIPs, has a page for each one, and indicates where the discussion for each ECIP takes place.
  • All aggregated ECIPs from all other teams: This section aggregates and shows all ECIPs that form, together with the Yellow Paper, the basis for all consensus rules in the ETC protocol. Each aggregated ECIP title and description points to the original ECIP referenced, which may be hosted locally or in a remote team’s website. Independent of where the ECIPs are located, they all have discussion pages or sections that may be hosted on Github, for example.

To facilitate aggregation, each ETC development team’s site also contains a known.json file directory of “known” ECIP directories and a specs.json file directory with all the ECIPs and their critical data.

At then end of the lifecycle of all ECIPs that are accepted and merged (and perhaps rejected, withdrawn and deferred, as well) they need to be archived in the “archiving” step at the bottom of the diagram to assure their immutability, authenticity and long term integrity and availability. These archives can be hosted by all ETC development teams and other entities.

As it can be seen in the diagram above, all teams, and everybody else for that matter, can participate, discuss, create pull requests, issues, fork and merge any other team’s ECIPs.

To see an example, the model site structure above is based on Wei Tang’s ECIP site at That.World: https://ecips.that.world/


The model decentralized ECIP site above is hereby presented to the ETC ecosystem and is open for discussion. This and other topics about the decentralized ECIP process can be located at:

StarIP: https://github.com/BelfordZ/starIPs/issues

24-ECIPURI: https://github.com/ethoxy/specs/issues/4

ECIP Process — ECIP-1000: https://github.com/ethereumclassic/ECIPs/blob/master/ECIPs/ECIP-1000.mediawiki

Discord #ecips channel: https://discord.gg/h8X9gB

Ethereum Classic (ETC): Putting Together the New Decentralized ECIP Process

 
In a previous article I wrote about decentralizing the Ethereum Classic Improvement Proposal process (ECIP) using the StarIP Standard by Zach Belford and Shane Jonas, ETC core developers at ETC Labs Core, which proposes a deterministic numbering system so ECIPs can be located in different team repositories while minimizing conflicts. Then, Wei Tang, Rust developer at Parity Technologies and ETC contributor, built the 24-ECIPURI system which solves the search and discovery problem of having ECIPs in different places.

Both of the above systems build upon the existing, but centralized, ECIP process which works using Github’s software versioning system. In this article I will describe how the three components mentioned above (the StarIP, 24-ECIPURI and old centralized ECIP process on Github) can be put together to serve as ETC’s new decentralized ECIP process. This compilation work was done with Zach Belford, Yaz KhouryTomaz Karizand Anthony Lusardi, amongst other contributors of the ETC ecosystem.

 
Putting together the old centralized ECIP system on Github, the StarIP Standard and the 24-ECIPURI search and discovery system.

A. Deterministic Numbering Using the StarIP Standard:

The process uses the ECIP “preamble” format, but uses the metadata in it to hash it and then present it in a simple yet deterministic numbering form to minimize conflicts across ETC developer teams’ proposals. The steps are:

1. Defining the preamble metadata format:

The preamble metadata is the first step developers do to write an ECIP and borrows the format from the existing ECIP process. Below is an example:

Preamble metadata:

Title: Byzantium on block 696969
Author: Santa Clause <a@b.c>
Discussions-To: a@b.c
Status: Draft
Type: Standards Track
Created: 2020–05–25
Replaces: kRau7PZs
Superseded-By: ZxftDmL3

2. Hashing and Numbering:

The above preamble metadata is hashed using SHA-3-512 to create a hex hash, which is encoded into BASE58, the address format used by Bitcoin. Then, the last 8 characters are used as the ECIP version number, of which the last 4 are used as a human friendly proposal number:

Preamble hash:

dca43940494f871c98774d0589902f9feabaa25231fd42309046cfc95ac7463744232b580d3007116f3ed9e65472ec444e6ac145f8803c33e518874518276ed7

Preamble hash in BASE58:

5QriUGKsjSwa73E7KKQYjysBfwqCzNY21f6iUSxQwqN8yvKAEtcT9nzvWKHdHdt6zsJmrWXhJJGCZESa6z9ekMre

Version Hash:

6z9ekMre

Proposal Number:

kMre

3. Preamble with proposal number and version number:

This is the preamble format including the numbering system:

ECIP: kMre
Title: Byzantium on block 696969
Author: Santa Clause <a@b.c>
Discussions-To: a@b.c
Status: Draft
Type: Standards Track
Created: 2020–05–25
Version: 6z9ekMre
Replaces: kRau7PZs
Superseded-By: ZxftDmL3

The sample preamble above, although it contains the new ECIP and version numbers, is still not finalized as it needs to contain the URIs as explained in the section below.

B. Search and Discovery Using the 24-ECIPURI Specification:

The above system accomplishes the goal of standardizing ECIP preambles and numbering them deterministically. The 24-ECIPURI system makes it easier to search, discover and follow ECIPs. The steps are:

1. URI Standardization:

If a developer team decides to use their own location for managing their ECIPs the standard URI is:

ecips.teamdomain.tld/ecip-proposalnumber

Using the example of the preamble in section A, the URI would be:

ecips.santaclaus.com/ecip-kmre

If a developer team were to decide to use Github then the URI would be:

github.com/teamname/ecips/ecip-proposalnumber

Using the example of the preamble in section A, the URI would be:

github.com/santaclaus/ecips/ecip-kmre

As Wei Tang mentions in his proposal, the domain part of the specification URI acts as the specification’s registry.

2. Finalized ECIP Preamble with URIs:

Using the example in section A, adding the URI format above and a discussion section, this is the resulting finalized ECIP preamble format:

ECIP: kMre
Title: Byzantium on block 696969
Author: Santa Clause <a@b.c>
Discussions-To: a@b.c
Status: Draft
Type: Standards Track
Created: 2020–05–25
Version: 6z9ekMre
Replaces: kRau7PZs
Superseded-By: ZxftDmL3
URI: ecips.santaclaus.com/ecip-kmre
Discussion URL: github.com/santaclaus/ecips/ecip-kmre/issues/1

The “Discussion URL” will usually be the comments sections and system used on Github which supports branching, pull requests, comments, issues and merging.

3. Authoritative Specifications and Aggregation:

24-ECIPURI includes two standard components, the “well-known” locations directory and the “authoritative specification” in the form of a specs.json document that can be hosted in an independent directory, Github or IPFS.

This is an example of an actual specs.json document:

 
Specs.json document example from 24-ECIPURI.

Below is an example of an ECIP independent aggregation site at ecips.that.world by Wei Tang:

 
ECIP aggregation page at That.World by Wei Tang.

C. Preserving the Old ECIP Process on Github or Future Software Versioning Platforms:

As it may be seen in sections A and B above, both StarIP and 24-ECIPURI use the Github platform for software versioning. In the same manner, all ECIPs from all teams should go through the original process described in the old ECIP process on Github or whichever versioning platform may be used in the future. This includes the contributing policies and ECIP status terms as showed in the old standard process diagram:

 
Old ECIP process stays the same.

Conclusion:

With the StarIP deterministic numbering standard, ETC developer teams can now start proposals in their own Github repositories, following the same standard ECIP process as before, while other developers and ecosystem participants can still view, contribute, discuss and fork their proposals into their own repositories.

When ETC developer teams finish conducting open and public discussions about ECIPs, they can signal their readiness and acceptance of proposals by merging them into their local ETC clients.

Although the new decentralized ECIP process presented in this article may have some extra steps for teams when starting ECIPs to ensure discovery while minimizing numbering conflicts, the positive tradeoff is that Ethereum Classic, as an ecosystem, is replacing a centralized process with few admins, with a decentralized improvement proposal process that is much more open, therefore, more aligned with blockchain principles in general and ETC’s ethos in particular.

It is important to note that although the system is decentralized, it still requires that ETC developer teams follow minimal standards when proposing consensus changes using the ECIP process. Those standards are:

  • A preamble metadata format with required information
  • A common hashing and numbering mechanism
  • Including the numbering in the preamble
  • Certain URI standards when using independent or Github servers
  • Common known.json and specs.json file formats with common known directories
  • A final preamble format including the ECIP URL and discussion URL
  • Using the old ECIP contributing policies and status terms

The new decentralized ECIP process above is hereby presented to the ETC ecosystem and is open for discussion, which can be located at:

StarIP: https://github.com/BelfordZ/starIPs/issues

24-ECIPURI: https://github.com/ethoxy/specs/issues/4

Discord #ecips channel: https://discord.gg/h8X9gB

Observations About Paul Sztorc’s Bitcoin “Security Budget in the Long Run” Essay

This is the original post by Paul Sztorc: http://www.truthcoin.info/blog/security-budget/

“This image from 2013 FINCEN Congressional testimony hopefully makes it clear”

It was very useful to read that essay because it helped organize in my mind two things: That the bitcoin currency unit is one part of Bitcoin and that the rest of the platform is like a “rail” to transfer that unit, and that “security budget” is a very good way of analyzing and thinking about the “energy ball” that protects Bitcoin.

However, when reading the article I agreed with some concepts, but had some objections about others. This is my list of observations:

“Bitcoin’s “security budget” is the total amount of money we pay to miners (or, if you prefer, the total amount spent on mining — they are the same thing).”

I agree with this statement and I think it is very important to have the “security budget” present when analyzing monetary policy (or trying to stop all monetary policy changes in my case). For example many researchers have proposed compensating node operators or developers for their work out of the same budget, but it is obvious that the energy ball, or the total hashing power dedicated to mining and protecting a chain, would be reduced.

“The dual nature of Bitcoin (as both a money-unit, and a payment-rail) has confused people since Bitcoin was first invented.

This is the other part of the essay that I find very useful as it helps clarify that Bitcoin is a system with several components, each one with different mechanics and economics, and that correctly deconstructing them will make their analysis much better and perhaps more rational.

As to the duality of “money-unit” and “payment rail” I think that is true, but not exactly as Paul describes it. In particular, that the Bitcoin platform is a transfer “rail” is true, but, as Nick Szabo pointed out, there can be highly secure base layer rails that are used for high value expensive settlement transfers and there can be less expensive and less secure rails that can be used for low value high frequency payments. In the traditional banking system, Fedwire and Visa can be examples of the former and the latter.

While the two are mixed into the same “security budget”, the block subsidy and txn-fees are utterly and completely different. They are as different from each other, as “VISA’s total profits in 2017” are from the “total increase in M2 in 2017”.

Totally agree. The sources of funding of the security budget are very different. The market dynamics of funding the Bitcoin network primarily through fees is different, may have competitors and substitutes in the “pure value transfer” segment of the market, and requires its own analysis and proper unit economics projections. This doesn’t mean though, as I write below, that the economics of the fee market will be insufficient or that any potential solution is fine.

Transaction fees are explicitly priced in BTC. But, unlike the block reward, they do react to changes in the exchange rate.

True. The block rewards are fixed, determine total BTC supply in the long run and are product-centered, meaning that the market (miners, hashing power, developers, investors, BTC price, etc.) adjusts to that given supply variable, not the other way around as in Ethereum, for example, where the lead developers regularly change the supply to adjust to market conditions or their desired economic or technical agenda.

On the other hand, transaction fees are market-centered, meaning that they go up and down adjusting to supply and demand.

As the exchange rate rises, a given satoshi/byte fee rate becomes more onerous, and people shy away from paying it.

I am not sure this concept is true, at least as seen in the last few years: as Bitcoin went up in value, transaction fees (and volume) also went up in value, and vice versa. Of course people will think twice before paying $50 for a single transfer that was $0.50 for the same transaction a few weeks before, but compensating factors are that fees are usually proportional to the value being transferred and that now there are alternatives such as Lighting Network.

But it is the reverse when we consider transaction fees and “btc-block-bytes”: Altcoin-blockspace is a pretty good substitute for Bitcoin-blockspace.

I disagree that block space is a generic commodity, therefore a transaction in Bitcoin is totally replaceable by a transaction in any altcoin or L2 system for that matter. Up to a certain extent, and in different proportions, users will tend to tradeoff low transaction fees for standards and safety. This is because there are several types of costs that will induce the world to select very few chains in the future: security costs, exchange costs, and coordination costs.

Security costs: It is not the same to move value using the Bitcoin network or using any altcoin or L2 solution. This will create a market for high value, highly secure transfers in Bitcoin, e.g. central banks, governments, interbank, corporate and other large value payment users, who will gladly pay very high fees. For those who don’t need such security or for low value transfers there will be of course cheaper alternatives in other chains or in L2 solutions as mentioned above.

Exchange costs: When senders and receivers want to store value in Bitcoin, but need to transfer them, it will not be frictionless to move from BTC to an altcoin, send it for a lower fee, and then pass it back to Bitcoin on the other side. Between exchange commissions and spreads there will be an indifference point beyond which it will be better to pay for Bitcoin fees. Not only that, but the security dynamics mentioned above also change substantially. If Bitcoin is a very good store of value, transfers will occur within Bitcoin precisely for the same reason it is a good store of value.

Coordination costs: Just because you can create N altcoins does not mean they are all going to survive. Because they are all not going to survive, there will be a limited competing block space market in the world. This is because our minds are limited and we will not think about 250 cryptocurrency names, transfer fees, the subsequent 250 prices, and go selecting the cheapest one each time we move value. Our brains will only support understanding the value of 3 to 5 coins at most, and we will be comfortable using them interchangeably up to a certain point. If this is correct, then, together with the security and exchange costs considerations above, there will be a limited amount of coins in the future, with a limited amount of block space and transaction capacity. This means that the cost of sending value will be distributed between the surviving chains in proportion to value and safety requirements.

We see that BTC’s crossing of the “1 USD per transaction line”, in May of 2017, coincides with the rise of Altcoins. We also see that the “pressure” of late 2017 quickly canceled itself out, and then some. Finally, we see that this release-of-pressure coincided with a sudden (and unprecedented) decline in BTC-transactions.

I disagree that the rise in fees in 2017 was a function of a block space market demand and competition. I think that bubble was actually a race to buy the “store of value” side, which created the BTC rise and subsequent fall when the bubble pierced, which is normal in free markets. Then the fees came down to historical rates again just because the demand for the store of value diminished after the hype.

Similarly, I think that the sudden multiplication of altcoins and ICOs during the period was a race to mimic the wealth creation that happened in Bitcoin, not necessarily millions of people suddenly using blockchains to transfer money around the world and seeking to minimize those fees. In other words, the coincidence of altcoin and ICO proliferation with the 2017 crypto bubble was a generalized gold rush (and in many cases a fraudulent money grab by many altcoin and ICO creators), but not a rational pricing dynamic and arbitrage of block space through transaction fees. Going forward, the pattern of seemingly unlimited alternative tokens, new block space as alternative “rails” in unlimited chains will be extremely reduced for the reasons explained in the previous points.

To me, this data refutes the theory that users will pay high BTC fees willingly.

As the data is not well interpreted, that is, that the bubble was a “store of value run” and not a block size and cost competition, the above argument is not true, in my opinion. Users, depending on the value they need to transfer and safety needs, will gladly pay for different gradations of block security and costs. This includes layer 2 systems.

If the consumer is cost-conscious, and will only pay the lowest tx-fees, then how can we get those numbers up?

As explained above, the consumer is cost conscious, but has a coordination need, mental limitations and therefore will count with a limited selection of alternatives. The numbers on the selected few chains that will survive in the future will be distributed according to their economic benefit and function: store of value vs Turing complete, high vs low value, high vs low security, etc.

The real question to raise volumes on Bitcoin and the selected few chains that will prevail will be whether they are competitive with current centralized systems, which they are, but not necessarily whether they will be viable or not due to an imaginary unlimited block space market.

…[merged mining side chains]send all txn-fees they collect to Bitcoin miners. Under Blind Merged Mining, they do this without requiring any users or miners to run the sidechain node software.

Although public blockchains are permissionless, I object to promoting merged mining because it creates “super-miners”. Super-miners are pools or direct miners who provide their block creation and security services for multiple chains with the same equipment at the same time as envisioned by Paul and other entities promoting them. This will create a situation where the miners will become the Facebooks, Googles, Apples and Amazons of the future. If they mine for multiple chains, and they have the prerogative of selecting what chains can be merged-mined or not, they will have an equal permissioning power as the Apple App Store, or the Google Play Store, for example. Also, they will be so large as compared to the corresponding node operators in each chain that they will likely be able to dictate rule changes in the future with little resistance as strategies as UASF will be insignificant compared to their power.

[Conclusion 1] To deter 51% attacks, Bitcoin needs a high “security budget”.

Agreed, but I think there will be proper security budget financing through fees, and 51% attacks are not that catastrophic anyway. Especially to create a potential monster as super-miners. I don’t think that we have to reach astronomic hash rates to compete with the pentagon, for example. If the Pentagon wanted to do a significant 51% against an enemy, first they would have to buy a substantial amount of BTC to do so, which would be good for Bitcoin, second they would have to use that value to send it to the enemy and then double spend it, third they would have to respond publicly for such an attack as the rest of the world at that point, including American reserves, tax payers and savers, will be invested in BTC. Lastly, if the enemy is not that stupid, they will wait for several days, weeks or months of confirmations to consider a transfer by their supposed foe finalized.

Remember that the “security budget” or the “energy ball” that protects Bitcoin does so for just the tip of the chain. That is, out of the current ~567,000 blocks that the current chain has, the miners with their hashing power secure the chain in 6 or so blocks, or a little more depending on each user’s security preferences, after which point it becomes exponentially difficult, even with all the hashing power in the network, to actually reverse the chain.

The above shows that 51% attacks are not the monster that everybody thinks. In the Ethereum Classic community we know, we actually lived through that! [Please read this to learn from our experience!]

[Conclusion 2] Today’s tx-fee revenues are not high enough; we must ensure that they are “boosted” in the future.

Yes, they are not high enough presently, but I think they will be higher just for the sheer value and volume that will go through Bitcoin, and the few chains that will succeed in the future. The solution, other than continuing to build the public blockchain stacks as in the current roadmaps, I think will be that the world will move to use blockchains for many functions and the fees will be enough and well distributed between the prevailing networks.

Ethereum Classic and the Permissionless Fallacy

 

 

Recently Ethereum Classic (ETC) has been going through several crises and controversies. Some of those involved the kind of circular problems that Nassim Nicholas Taleb mentioned in his article “The Most Intolerant Wins: The Dictatorship of the Small Minority” where he wrote the following rhetorical questions:

“Would you agree to deny the freedom of speech to every political party that has in its charter the banning the freedom of speech?”
“Should a society that has elected to be tolerant be intolerant about intolerance?”

As the above “freedom of speech” and “tolerance” dilemmas, in the blockchain space there are similar dilemmas, one of which is related to “permissionlessness”. To illustrate it, an analogous rhetorical question when referring to permissionlessness would be something like:

“If a blockchain is permissionless, should participants have permission to do things that undermine permissionlessness?”

My answer to the above questions is the same one I use to object to people when they say “free markets means no rules or the law of the jungle”. That is not true, the truth is to the contrary: Free markets are free because they are dependent on very strict rules that have to be followed and enforced. For example, free markets depend on strong property laws, contract laws, in some cases specific times and places where transactions have to be conducted, settled and in what form, information transparency rules, and the thorough enforcement of these and many other systems.

In the same way, freedom of speech, tolerance and permissionlessness are strict rules, sometimes encoded in constitutions, the law or culturally ingrained in social norms, that have to be thoroughly enforced and actively defended.

This is how I define the permissionless fallacy in the blockchain space in general:

“Because a blockchain is permissionless that means that anything can be done, even if it undermines permissionlessness.”

However, the correct argument is:

“Because blockchains are permissionless, anything that undermines permissionlessness must be stopped.”

Of course the permissionless fallacy is presented in not so direct, but much more subtle forms and flavors in real life!

Some Cases in ETC:

In Ethereum Classic in particular, it has been argued that requesting to be an admin in the community repo on Github and then removing all other admins is ok because it was permitted in the Github terms of service.

More recently, a developer team decided to fork the community Ethereum Classic Improvement Proposal process (ECIP) because ETC’s software is open source and in the open source industry forking is a social norm, therefore forking the ECIP is perfectly fine.

In the last few days another member of the community was re-floating the idea of creating a foundation or several foundations because they can have tax advantages and that motivates people to donate money for development, thus potentially solving the lack of financing for such important activities in ETC.

All of the above are different forms of permissionless fallacies. The fact that an admin can revoke other admins, that anything can be forked in the open source software industry, and that anyone can form a foundation if they want to does not mean that it is perfectly fine to do all those things, even if they have ancillary benefits, if they undermine permissionlessness.

The Question is: How are Permissionless Fallacies Resolved?

Whether the underlying action is good or bad, right or wrong, popular or controversial, or beneficial or catastrophic, permissionlessness does create an environment of freedom that makes it difficult to overcome permissionless fallacies.

In my experience in the blockchain space it seems the situation depends on two dimension: severity and ecosystem size.

For example if some developer teams are building bridges, wrappers or doing some collaborations with the teams of other chains which have no interest in benefiting ETC, but those activities benefit the other chain in the form of signaling in the context of a standards war, but not ETC, that would not be as severe as integrating into a mainstream client, bypassing the improvement proposal process, a new arbitrary change in the monetary policy which significantly undermines the immutability guarantees of the network and significantly changes economic incentives, and somehow convincing miners and node operators into deploying it.

On the other hand, when a blockchain is small as ETC is, with a growing, but still not sizable ecosystem, it is much easier to capture some community resources under the cover of permissionless fallacies than in a huge network as Bitcoin worth tens of billions of dollars, which has many participants, including a large developer base, enormous hashing power, and economically large full node operators, in many regions in the world. This is because in a large ecosystem it is either much easier for the natural forces of the social layer to prevent undesirable actions, or such actions are so insignificant relative to the size of ecosystem that it doesn’t matter anyway.

Conclusion: Moving Forward in ETC

As to a couple of the particular events and permissionless fallacies mentioned in this post that have presented themselves in the last few months in ETC, I think it is unlikely KryKoder will ever return the Github organization and restore the previous admins. Similarly, and for different reasons, it is unlikely that the officials or developers of the company will ever give a reasonable explanation for that action. I think at this point the community must move on.

However, it is very plausible that a unified yet decentralized ECIP process will emerge from the recent Github admin and improvement proposal controversies. This could even be a net positive for ETC because the KryKoder actions may have led to a more advanced and decentralized improvement proposal process, which will be more advanced and adapted to secure blockchain consensus changes than the Bitcoin Improvement Proposal process (BIP) and the Ethereum Improvement Proposal process (EIP).

Nevertheless, that a bad actor may have contributed, in a perverse way, to a positive change in the ecosystem does not mean that that bad actor is not such. This means that ETC must continue to remain vigilant and always defend itself as best as possible from permissionless fallacies. Secure, proof-of-work, public blockchains are, and will always be, under constant social attack.

The Star Improvement Proposal Standard for Ethereum Classic’s ECIP Process

 

In my article “Why Ethereum Classic Needs a Single and Unified Improvement Proposal Process — ECIP” I laid out the reasons why, as the title reads, I think there needs to be a unified ECIP process in Ethereum Classic (ETC), but the same implied having a single centralized repo location which is not agreeable to some core developers in the community.

After several conversations with Zach BelfordETC Labs Core engineer, he explained to me the reasons for their preference to work in their own repo called the Ethereum Classic Labs Improvement Proposal process (ECLIP), showed me a very didactic video by Brian Cantril, ex-Sun Microsystems and expert in the open source software industry, where part of their philosophy is well laid out, and proposed to me to consider the Star Improvement Proposal Standard (StarIP) that him and Shane Jonas, also ETC Labs Core engineer, envision for consolidating the Ethereum Classic Improvement Proposal process (ECIP) which has been described by many as cumbersome and thus very inefficient.

I found the idea very innovative and particularly suited for Ethereum Classic’s needs for the following reasons:

  1. When consulting about the ECIP matter, Bitcoin core developers who manage the Bitcoin Improvement Proposal process (BIP) and other notable Bitcoiners expressed that it is impossible and somewhat against blockchain ethos to stop others from forking the BIP or ECIP processes, however undesired, because they are permissionless open source systems.
  2. Zach, Shane, Stevan Lohja and other ETC Labs Core engineers have expressed they will not use the current ECIP process because they find it constrains their work and they feel uncomfortable with its centralized location and administration.
  3. As explained in the video mentioned above, those of us who wish to force the current ECIP process on all core developers may incur in “anti-pattern” behaviors such as “forkaphobia” and “governance-orgy” that may drag ETC’s open source process backwards rather than restoring it (a case in point is reason 2 above).
  4. When Zach explained his decentralized StarIP idea, I liked it and we decided to collaborate presenting it as a show of good faith between opposing sides in the debate and because the idea is genuinely innovative.
  5. After chatting with Zach, I believe him and the ETC Labs Core team are quite independent from DFG, focused on improving ETC and not capturing the network.
  6. As the options ETC has at this point are either to continue to try to force others to use the ECIP and risk further fracture, to continue to work with the ECIP and ECLIPs separate and uncoordinated processes, or to try this innovative and more decentralized StarIP system, I decided to support this last option.
  7. As will be seen in the section below, the Star Improvement Proposal Process as applied to the ECIP process in ETC is still a single and unified process as I advocate, the only difference is that the repos for the posting of ECIPs, their discussion and merging are in separated repos of each client development team instead of a centralized one. Also, the process is simplified because “merging” by a single team means “acceptance” or a sort “voting by adoption” for a particular rule change.
  8. Power is not granted to any team, even if they have dominant market share with their client implementation, because merging, thus changing rules locally, is not in itself a “protocol change” as node operators and miners still hold the power to adopt, or not, the new version of the client and consensus rules.

Rationale for Supporting the StarIP Standard for the ECIP Process:

How Bitcoin’s BIP process works today:

 
BIP process.

As it’s seen in the slide above, the process generally consists of a consensus rule change proposal, a discussion, acceptance or rejection of the proposed change, and finally merging the changes that were accepted. The process before merging into the implementation is sometimes called the “standard” or “protocol” definition and the merging action is called the “implementation”.

The criticism of the BIP process is that both the process and the “reference” implementation are located in a central repository with a few selected and trusted admins who not only move the process forward, but also have the power to admit or remove other admins and members who participate in the process.

Also, the mechanism by which BIPs are accepted or rejected is somewhat subjective as it depends on a few people gauging consensus by reviewing the objections and support for each proposal and not by any other more objective process.

How Ethereum’s EIP process works today:

 
EIP process.

The EIP process is practically identical to the BIP process and has been criticized for the same centralization reasons. The only difference is that the Ethereum yellow paper and the EIPs that are accepted are not only used to update the “official” implementation, but what happens to that implementation serves as the leading case for many other implementations as Ethereum has been much more open to client diversity.

How the Ethereum Classic ECIP process works today:

 
Current ECIP process.

The current ECIP described above is very similar to the EIP process, therefore the BIP process. As it may be seen, ETC also has client diversity, but the same criticism of centralization applies to the ECIP process, which is, in fact, the main reason ETC Labs Core decided to create their parallel ECLIP process.

The Proposed StarIP for the ECIP process:

 
Proposed ECIP process.

The proposed StarIP based ECIP process above is decentralized and simplifies the decision making process by having developer teams express their preferences by merging or not merging the proposed changes into their implementations. This is more objective than just reviewing comments in a discussion and guessing consensus by a group of admins.

Additionally, the new ECIP process keeps an efficient identification and tracking system of ECIPs as they will be numbered using the “ECIP” acronym as a prefix, and a hash algorithm number for the title for the suffix. Also, all teams must use the same numbering, pull request and merging format on Github as explained in the Readme file:

 

All client development teams, the ETC community and the public in general will be able to see all ECIPs, so it’s a transparent process. I think it is very likely that aggregation services will be created to manage this more deconstructed format for ECIPs.

Balance of Power — Node Operators and Miners Ultimately Decide:

As described in point 8 of my rationale above, this new improvement proposal process does not necessarily grant undue power to single developer teams with very popular ETC clients (e.g. Parity, which has ~61% market share in the ETC node market). This is because, as described by Luke Dashjr, Bitcoin Core developer, the general process of proposing, discussing and accepting new changes to blockchain protocols in general, and BTC and ETC in particular, is much more ample than just the ECIP and merging mechanism:

 
Source: Luke Dashjr website: http://luke.dashjr.org/education/bitcoin/2018/bitcoin-changes/bitcoin-changes.pdf

As it may be seen in the slide above, the ultimate step of deploying any changes, even if discussed and accepted by all or some developer teams by merging in their own clients, no matter how popular those clients may be, ultimately depends on node operators and miners who actually run the software and rules they select that make the actual live operating network work.

This power by node operators and miners has important implications because they balance such power not only in the ECIP process level but also in the operating network level by:

  1. Not deploying rules they don’t agree with.
  2. Deploying clients with low node market shares and rejecting others that may have abused their power, even if they had large node market shares.
  3. Participating in the rule change preliminary debates and ECIP discussion process per se by expressing their preferences and concerns in advance.
  4. Internally rejecting blocks created by some miners and distributed by some nodes who may have adopted undesired consensus rule changes created and pushed by specific teams who may have not gotten much voluntary consensus in the ECIP.

Potential Questions and Objections to This Proposal:

Here I list some objections that I have already read in some forums and social media. These and more objections may be discussed and will be answered by the sponsors in the StarIP repo’s issues section on GitHub:

  • Search and discovery of ECIPs may be difficult as they are spread across many team’s repos.
  • The necessary discussion for each ECIP may be inefficient as teams need to find new changes in other team’s repos.
  • Not all BIPs are related to consensus rules, and BIPs are not client-specific. How are informational or procedural ECIPs processed?
  • How do we know if all teams will comply with the standard if they can just start ECIPs, debate them internally and just merge them without consulting to anyone else?
  • Using voting or majorities is not good for blockchains, but is this a democracy? What happens when people want a change that was only merged by a minority of teams? What if 50% of teams accept and merge an ECIP and the other 50% doesn’t? If an ECIP has more than 50% of teams merging it, does that mean it is forced to the rest of the network participants? [Answer here]

Conclusion:

As Ethereum Classic is a decentralized and permissionless blockchain, and the decision making processes for defining its protocol standards and implementations are open source, evidently it becomes difficult and even counterproductive, as seen by recent events, to try to force all developer teams to actually use the same centralized repo for proposing and implementing changes.

However, given that the ETC network is unique because it is a global network of nodes and miners who need to reach the same exact conclusion about the same exact state every 15 seconds, according to the same exact set of rules, it is imperative that all developer teams work under the same improvement proposal standard.

Since the options ETC has are either to possibly fragment itself, continue to work separately with little coordination, or perhaps work in a single and unified ECIP process, using the proposed Star Improvement Proposal Standard, I have decided to support this last initiative.

Conversation with Bitcoin Developers About How to Handle Corporate Forks of the BIP and ECIP Processes — Recap

 
 

Given the current crisis in Ethereum Classic about the creation of a parallel Ethereum Classic Improvement Proposal process (ECIP) called Ethereum Classic Labs Improvement Proposal process (ECLIP) by ETC Labs Core, one of the main development companies in the ecosystem, it was consulted with some Bitcoin developers and notable Bitcoiners what was their opinion if an analogous situation happened with the Bitcoin Improvement Proposal process (BIP).

This is a recap of the conversation on Twitter:

Donald McIntyre: Hi @NickSzabo4 @eric_lombrozo @LukeDashjr@pierre_rochard @nic__carter et al, if Blockstream were to create their own Blockstream Bitcoin Improvement Proposal process (BBIP) would that be ok in Bitcoin? What do you think about this?: https://medium.com/@TokenHash/why-ethereum-classic-needs-a-single-and-unified-improvement-proposal-process-ecip-457b3fefc54d

Pierre Rochard: Bitcoin is permissionless, so yes that would be ok. Would it get traction and efficacy? Personally imho I would predict not, for all sorts of different reasons

Donald McIntyre: “Bitcoin is permissionless, so yes that would be ok” yes that’s the argument ETC Labs is using. Opponents, including myself, don’t deny that, but reject the attempt to control protocol development by one corporate entity.

*****

Eric Lombrozo: There’s nothing to stop them from doing it if they want. I would probably discourage people from using corporate-centric processes for protocol standardization, as it is just inviting capture. But people are free to run whatever software they want.

Donald McIntyre: “But people are free to run whatever software they want” yes, i guess the last layer of defense is what are the rules that are actually adopted by miners and node operators

Eric Lombrozo: Some people might gravitate towards a more corporate-centric protocol standardization process, but I don’t think the heart of the movement will. Better for them to fork off early so as to not continue to distract those who have a longer term vision.

Eric Lombrozo: Also, note that I am not opposed to corporate-centric processes in general. But when it comes to protocol standardization I strongly believe in interoperability. Even moreso when it comes to currency.

Donald McIntyre: what is meant by “interoperability” here? public chain to public chain? private chain to public chain? other, something else?

Donald McIntyre: as an organizational description of ETC, there are 3 companies that maintained nodes, there are no nodes maintained by volunteers as in BTC however, until recently they all followed the specs of yellow paper and ECIPs to build their clients (there’s no ‘reference client’ in ETC)

Donald McIntyre: now, one of the companies decided to create its own ECIP channel and ignore the rest of the community, including the Github repo and the ECIP process…the main argument is “we don’t want to depend on the community, they can follow us if they want”: https://github.com/etclabscore/ECLIPs/pull/2#pullrequestreview-202791681

Donald McIntyre: so, there is more at the meta level, a capture power play the normal ethos of “permissionless” and “anyone can fork”, even though true, are serving the attacker

Eric Lombrozo: If people really want to fork, you have no realistic way to stop them from doing so. The real question is whether their fork will gain any traction.

Donald McIntyre: “you have no realistic way to stop them from doing so” [thumbs up] [thumbs up] [thumbs up]

Hanakookie: There is no way to stop a fork. ETC can do what they want. And if those companies feel they don’t need support from their community they are doomed anyway.

Donald McIntyre: [thumbs up] [thumbs up] [thumbs up]

*****

Luke Dashjr: They kind of already did (BOLTs). It’s somewhat frustrating.

Eric Lombrozo: FWIW, I would consider consensus-level changes to be of special significance. I agree that a more unified standards process is desirable, but at higher levels of the network stack there’s less concern for strict compatibility.

Luke Dashjr: Not saying it’s the end of the world, just kindof rude at least.

Omar Shibli: Yeah like W3C, IETF.. world class asset deserves world class structured organization, I’m bit radical pardon me, just a silly idea, my two satoshis.

Omar Shibli: Open participation, radical public transparency of course.

******

As per Bitcoiners consulted that participated with likes, Nic Carterliked Eric Lombrozo’s first statement and Nick Szabo liked all of Eric Lombrozo’s statements.

Open Letter to Blockchain Developers: Opportunity to Work on Ethereum Classic (ETC)

I’m not going to lie to you: Things are tough right now in Ethereum Classic because a single group (DFG/ETC LABS/ETC LABS CORE) with ample funding is controlling a significant share of the ETC ecosystem: they hired and fund the only core development team, fund many startups who build dapps on ETC, and are part of the ETC Cooperativetogether with DCG of Barry Silbert, another large investor in the ETC community.

In general the main economic groups in the ETC ecosystem, DFG, DCG, IOHK and ETC Cooperative, are very coordinated and aligned:

 
Corporate groups on the ETC Labs home page.
 
The above photo was taken in February of 2019 in Denver at the ETHDenver conference (notations in red are mine).

However, due to this situation I think there is an opportunity for a credible and independent team of good engineers with sound blockchain principles (volunteering, self funded or VC funded) to enter the ecosystem with a significant prospect for success because the mere presence of such team would balance power in the community, be very welcomed and supported by many, and get a significant chunk of market share in any future open source business related to ETC (e.g. Red Hat or Blockstream style).

I see the way this may be done successfully by such a team would be by:

1. Taking up or starting development of the ETC native client, which is Classic Geth.
2. Taking an active role in managing the ECIP process.
3. Managing the ‘ethereumclassic’ Github organization.

All of those ecosystem resources above are being or have practically been abandoned by DFG/ETC LABS/ETC LABS CORE because they will be working on a different repository, a multi-geth client, and want to have their own resources branded with their name, like in the case of the ECLIP process. No new teams or devs have come voluntarily other than a few individuals on a part time basis, very likely because of the bear market and perhaps because they see ETC as a small and risky network.

However, ETC is a huge opportunity in the blockchain space because of its trust minimization ethos and is sticking to PoW and Turing completeness, which is a unique positioning as Ethereum, Cardano, EOS, Tezos, and the other smart contract chains are all just PoS “decentralization theatre”, in my opinion.

ETC’s huge potential value:

 
ETC is the only network with highly secure smart contracts at the base protocol layer. PoS, DPoS and PoA do not belong in base layer consensus security. They can only be useful in L2 solutions for scalability and performance. Security and sound money can be provided by base layer PoW chains.

If you are interested in pursuing this opportunity, please don’t hesitate to contact me as I could help you with some introductions and guiding you in the community, and several others would be very open to welcoming you as well.

Thank you for your attention!

Code is Law.

 

Why Ethereum Classic Needs a Single and Unified Improvement Proposal Process — ECIP

 

In light of the recent corporate capture attempt of Ethereum Classic by ETC Labs, some in the community are asking themselves whether it is a problem of the improvement proposal process itself, or if several processes can be accommodated to satisfy all parties. In this article I write about why there should be a single and unified improvement proposal process.

As Bitcoin’s Bitcoin Improvement Proposal process (BIP) and Ethereum’s Ethereum Improvement Proposal process (EIP), Ethereum Classic also has an improvement proposal process called the Ethereum Classic Improvement Proposal process (ECIP).

The reason why all sound and secure public blockchains, or at least those who claim to be so, have unified improvement processes was stated by Satoshi Nakamoto himself:

“I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep, that a second implementation would be a menace to the network.” Source: Bitcointalk.com.

Of course Satoshi was responding to the idea of building a second implementation of the Bitcoin client, but the underlying philosophy of high coordination and alignment of the ruleset is totally applicable to the process of making decisions to change the protocol as well.

So much so, that when Amir Taaki realized this he created the BIP process in 2011. Amir wrote:

 
The keywords by Amir Taaki above are: “concise”, “primary mechanism”, “community input”, “author is responsible for building consensus”.

What I am referring to here is that the improvement proposal process in any public blockchain has the same hazards and risks as implementing a new client as Satoshi warned. As an illustration of this, I will rewrite Satoshi’s phrase, but rewording it to adapt it to refer to the improvement proposal process:

“I don’t believe a second, compatible [improvement proposal process] of Bitcoin will ever be a good idea. So much of the design depends on all [clients being built based on the same identical ruleset and] getting exactly identical results in lockstep, that a second [improvement proposal process] would be a menace to the network.”

In the case of the EIP process description, which follows the example of the BIP process, they took the work of specifying the various (and complex) steps in more detail, which I think shows that any deviations or alternative channels only risk distracting from what should be the focal point of what the actual technical changes and an ensuing functional debate should be:

 
EIP steps.
 
EIP process diagram.

Needless to say is that, with the amount of steps and focus the community needs to concentrate and coordinate for sensitive protocol changes, it is entirely plausible that malicious players could use alternative channels, and the fragmentation, confusion and mental cost they create, to introduce undesired changes and increase the chances of splitting the network. Attacks using this strategy of fragmentation have been attempted before, some successfully and some not, including Bitcoin Unlimited, Bitcoin XT, Bitcoin Classic, BCH and BSV (note that the great majority of these attacks on Bitcoin were done by who were once trusted and friendly community constituents!).

The above is true even if the malicious players’ intentions were only to capture the development process without necessarily the intent of splitting or undermining the network itself.

In the case of Ethereum Classic’s ECIP, it is practically identical to that of Ethereum, and by extension that of Bitcoin, therefore pursues the same objectives:

 
As it can be seen above, the ECIP process of Ethereum Classic is practically identical to that of Ethereum, and it even has the relevant Ethereum EIP’s as part of its base code implementations and changes.
 
ECIP process diagram.

It is important to note as well that the ECIP process in ETC is not a centralization device as some confuse or try to confuse the community about. That is as a fallacious argument as saying that prompt coordination of core developer teams to fix emergency bugs are a centralization point in blockchain networks.

What people who argue the above don’t understand, or don’t want to understand, is that the same incentives that drive developers, miners and node operators to participate in a blockchain network following its decentralization rules are the same incentives that drive them to fix any bugs or solve any emergencies that may undermine such decentralization. Therefore, blockchain developers swiftly coordinating to solve catastrophic bugs or fix network failures DOES NOT MEAN centralization, in fact it means the opposite, a strong incentive to continue enforcing decentralization. Exactly the same logic applies to the BIP, EIP and ECIP processes.

 
A “bait ball” is a group of fish who instinctively swim to the center of the school to minimize their exposure to predators. The resulting “ball” seems like a top down designed device. However, each is acting individually and selfishly in a decentralized manner, but they seem like a coordinated group, even if there is no centralized authority nor top down leadership.

Finally, the ECIP process is not the only “structured” and “rigid” step there is in the decision making process in ETC. The larger process is much broader and may start a long time before any improvement proposal is even written. This shows how open the general process is and even gives all participants, technical or not, the chance to contribute and debate.

As Luke Dashjr explained, the BIP document (the ECIP document in the case of ETC) is in practice the third step in the decision making process for changes in the protocol:

 
Source: Luke Dashjr website: http://luke.dashjr.org/education/bitcoin/2018/bitcoin-changes/bitcoin-changes.pdf

Conclusion:

Blockchains are decentralized systems that consist of nodes achieving consensus on the exact same identical rulesets at very frequent intervals on a global scale. The fact that they have to achieve this exact same conclusion does not mean centralization. To the contrary, this emergent, bottoms up consensus mechanism is absolutely decentralized, each participant voluntarily contributes and accepts the results, this is called “rough consensus”.

In the same manner, any improvement proposal process of any highly secure blockchain in general, and the ECIP process in ETC in particular, must be a single and unified process to minimize misinterpretations, security holes, errors and even potential attacks.

The Corporate Capture of Ethereum Classic by ETC Labs

On February 18th, 2019 Tomasz Zdybał, a core developer at TRON and volunteer developer on Ethereum Classic (ETC), noticed that the “core developer” team in ETC, a company called ETC Labs had created a parallel corporate Ethereum Classic Improvement Proposal (ECIP) which they named after their brand Ethereum Classic Labs Improvement Proposal (ECLIP).

The purpose of this highly unusual action became apparent when browsing the comments in one of their ECLIPs where they mention the ETC community as “separatists” as if it were like ETA, the Basque guerrilla group in Spain, or a subversive minority somewhere in the world.

Not only that, but in a comment one of their employees, who goes by the name of “classiclab”, wrote this:

 
Comment by ETC Labs employee “classiclab” on GitHub.

The problems with the statements above are:

  1. That the ‘ethereumclassic’ repo in GitHub IS the ETC community recognized repo after an attack by the GitHub KryKoder user, who is also an employee of ETC Labs (to be clear, DFG, their parent company) who had hijacked the ‘ethereumproject’ repo, which was the original ETC organization in GitHub.
  2. That ETC Labs is officially refusing to cooperate with the ETC community and arbitrarily going their own way.
  3. That they are positioning themselves as some kind of superior leader in the ETC blockchain community and forcing the rest of the community to ‘follow their lead’.
  4. That they will go forward with their arbitrary roadmap without paying attention or ‘depending’ on the community.
  5. That they WILL include the deprecated and captured ‘ethereumproject’ repo in GitHub.
  6. That they only acknowledge the Go-Ethereum client, which is the deprecated and captured Classic Geth client in that repository, as the canonical one, instead of the one in the ‘ethereumclassic’ repository.

Needless is to say is that not only all the actions expressed and taken by ETC Labs above are absolutely contrary to the ETC community ethos in particular, but also to any public blockchain modus operandi and procedures in general.

ETC Labs is in a frank long term campaign to capture development of ETC:

But the above was not an isolated action by DFG/ETC Labs/ETC Labs Core. This corporate group has been in a long term campaign to capture ETC.

Following are the series of actions DFG (parent company of ETC Labs), ETC Labs (a San Francisco based incubator) and ETC Labs Core (their core development arm) have done in the last ~12 months in their process to implement their corporate capture of the ETC blockchain network:

  1. March 2018: Captured the ETC community in China from the local community lead, Roy Zou.
  2. October 2018: Promised funding to ETCDEV (the previous core development company) and told Igor Artamonov (ETCDEV’s founder) to not look for funding elsewhere.
  3. November 2018: Installed ‘KryKoder’ in the Ethereum Project repository in Github, by tricking it’s admins, and then excluding all the admins, including the ones that gave them access.
  4. November 2018: Defunded ETCDEV and poached all developers.
  5. December 2018: Announced to the community that they defunded ETCDEV and poached all developers “for the good of ETC”.
  6. December 2018: Announced to the community that the Ethereum Project in GitHub will be returned to the community only after an ETC Foundation is startedand access will only be given to those in the foundation.
  7. December 2018: Acknowledged all their malicious actions above, and promised again they would return access to more admins, but this time “in a democratic manner” and that would happen “soon enough”.
  8. February 2019: Created the ECLIP (Ethereum Classic Labs Improvement Proposal) to bypass the community ECIP process, stated that they will not cooperate with the community, stated that the community must follow ETC Labs lead, and only recognized ‘ethereumproject’, controlled by KryKoder, as the only valid GitHub repository and defined the deprecated go-ethereum client there as the “canonical client”.

Conclusion:

The ETC community is still small and, in this bear market, lacks funding from volunteer investors or other sources to initiate new core maintenance and development projects or pay new core developers quickly. This is because there are no leaders, foundations, pre-mines, treasuries, protocol taxation or any other financing gimmicks that so much contaminate other centralized projects. However, the downside is that this attacker (DFG/ETC Labs/ETC Labs Core) is well financed, has a large and experienced developer team and may complete a full capture of the network.

We have only one option: we must resist this attack.

As readers may appreciate, the worst that has happened to ETC in the last year were not the 51% double-spend attacks, but an attack to capture the network by what was at one point an internal ‘trusted’ and ‘friendly’ community member. But don’t worry, ETC is a cockroach and we will prevail.

Post Mortem Meeting — Ethereum Classic (ETC) — January 2019 Reorg Attacks

First post-mortem meeting of the ETC community, Jan 9th, 2019

Summary

Today we conducted a call on Discord at 5PM UTC to go over the main points about the recent reorg attacks on ETC, analyze the community reaction, and diagnose possible solutions and next steps.

Below is a timeline of significant activity and an outline of what was discussed.

A Timeline of Significant Activity

As it may be seen in the image below, the miner identified as “Private Pool 0x3ccc8f74” on GasTracker.io started its first attack on January 5th of 2019 through 6th and lasted 7 hours. Then, the same miner performed a second attack on January 6th through 7th that lasted 12 hours.

 

The first indication of a problem (see image below), which was interpreted by the community at the time as a local problem of the service provider, arose when the wallet and exchange Coinbase announced that it had disabled deposits and withdrawals due to “unstable network conditions” on the ETC blockchain.

 

The next day, January 6th, Twitter user @Pierre_Rochard asked me, @TokenHash, an ETC community member, if there was a deep reorg on Ethereum Classic the day before.

 

After this interaction, many other members of the ETC community started to check in different sources what was the status of the network.

In parallel, on January 6th, another ETC community member, and leader of the ETC community in China, Roy Zou, noticed that there was chatter in China about a miner with more than 50% hash power in the ETC network. See image below.

 

On January 7th, Mark Nesbitt Security Engineer at Coinbase, posted a blog post with a full explanation of their view of the attacks. Below is the image they used to describe it.

 

The full Coinbase blog post can be found here:

https://blog.coinbase.com/ethereum-classic-etc-is-currently-being-51-attacked-33be13ce32de

The resulting actions detected by Coinbase in the attacks were that ETC 219,500 were stolen through double spends on block reorgs in 15 transactions.

On January 9th the security firm SlowMist confirmed the information provided by Coinbase and provided more details about specific accounts of the victims, which were several exchanges, and the accounts used by the attacker. The report may be found here:

https://medium.com/@slowmist/the-analysis-of-etc-51-attack-from-slowmist-team-728596d76ead

Outline of What Was Discussed in the ETC Post-Mortem Meeting

We were more than 20 members of the community, the meeting was led by Zach Belford, @Belfordz, ETC lead developer, and included members from the IOHK and ETC Labs Core teams, other volunteer ETC developers, the ETC Cooperative, other members of the community at large, and one journalist from CoinDesk.

The day before we had consulted with the founder of ProgPow, Kristy-Leigh Minehan@OhGodAGirl ‏, about possible alternatives for ETC including integrating ProgPoW.

Below is a list of the topics we touched.

1. A high-level summary of what happened

Which services and customers were affected?

How long was the issue?

  • The issue was from 1/5/2019 to 1/7/2019
  • Included at least 15 double spend transactions and at least ETC 219,500 stolen
  • Coinbase discovered reorg on block #7245623
  • January 04, 2019 Beijing time — block #7249343 — *potentially ongoing*

Who was involved in the response?

  • Roy Zou ETC Consortium
  • Coinness
  • IOHK
  • ETC Co-op
  • Donald McIntyre
  • ETC Labs

How did we ultimately fix the problem?

  • We have not
  • Recommend increase confirmations: We suggest 2,500 to 5,000 blocks to achieve the same guarantees as 1 to 2 Bitcoin blocks; and more if dealing with large transactions. Essentially waiting until the cost to mine blocks to reorg is greater than the cost of what you’ve received
  • Dissemination of accurate information
  • Research mitigation techniques

2. A root cause analysis

What were the origins of failure?

  • No root cause internally in the system. External factors: ETC, as any PoW blockchain is vulnerable to a 51% attack by miners, who can initiate reorgs enabling double spend transaction
  • Malicious ‘bad actor’ miner
  • Insufficient hash rate given the number of confirmations users were typically waiting
  • In summary: ETC is still a relatively small PoW blockchain with a mining algorithm that is compatible with larger chains such as Ethereum so attackers can rent hash power on NiceHash to reorg the blockchain

Why do we think this happened?

  • We don’t know right now

3. Steps Taken to Diagnose, Assess, and Resolve

What actions were taken?

  • Check GasTracker, examine blocks, look at miner distribution
  • Blockscout reorg tracker
  • Mining info from https://investoon.com/mining_pools/etc
  • Coordinated analysis through ETC Communications and Social Media Channels (Discord, Twitter)
  • Analysis to confirm double spends — Coinbase & Gate.io
  • Raising confirms — started in Discord, some then mentioned on Twitter

4. Learnings

What went well?

  • Community came together pretty fast in Discord
  • Shout out to GasTracker, Blockscout, and Etherhub! (they got hammered and never went down)
  • Coordination was handled well, Roy Zou was in contact with a security firm Slow Mist from the start
  • The ETC community didn’t try to minimize/downplay the situation
  • Tooling for detection are being conceived already
  • The network worked as designed and didn’t break
  • This post-mortem, our commitment to improvement

What didn’t go well?

  • No security alert nor contact information in the ETC community
  • No alert system — exchanges, miners, wallet operators and other stakeholders had no contact points to initiate alerts or receive feedback from the developers or community
  • Unable to quickly confirm victims of double spend
  • Blockscout reorg data was spotty
  • Retroactive security of the network, no preemptive systems exist
  • Echo’ing non facts and giving energy to conspiracy theories

5. Next Steps:

We wrote a list of options and priorities for the ETC community and developers to debate, write ECIPs if necessary, and implement over the near future:

  1. Create a monitoring and alert system for ETC so attacks may be seen faster to alert the ecosystem.
  2. Continue the recommendation for users and operators to use a significantly higher confirmation time, 2500 to 5000 depending on the type of transaction.
  3. Study the possibility of implementing deep-reorg-protection.
  4. ECIP1043: The purpose of this ECIP is to set a limit on the maximum size of the DAG to its initial state and no longer increase it on an epoch schedule.
  5. We will not apply any changes hastily without proper research and analysis and will continue to whether the storm.
  6. The above + wait for ETH to change to ProgPoW or PoS; making ETC the dominant chain in that PoW niche.
  7. Change PoW algo to be dominant in a new PoW niche and minimize NiceHash renting attacks.
  8. Two of the options under analysis are ProgPoW and Keccak256 (ECIP1049).
  9. We will not reorg the chain or revert the events on chain under any circumstance.

We communicated the above list to the community at large. See image below.

 

In following posts I will update the community of the steps above we are taking. Many other community members will be informing as well of the process.

Why I Am Still Optimistic About Ethereum Classic (ETC)

…even after the recently successful double-spending attacks.

 
The attacks by “private pool 0x3ccc8f74” are the two green bubbles above.

In the past I have argued that if Bitcoin were to suffer a 51% attack, that would be the end of the experiment. This was in the context of Vitalik Buterin and Vlad Zamfir saying that BTC’s proof of work (PoW) security is the same as Proof of Stake’s (PoS) because, in the end, if there is a reorg, Bitcoin would fork to correct the reorg making it a subjective consensus security model just as Casper’s PoS. (Of course I don’t agree with them, even in the current circumstances.)

So, now that ETC has been successfully attacked, these are the questions I make:

  1. Is this the end of the ETC experiment?
  2. Is ETC’s Lindy effect back to zero? Or, does the network have marginal value other than its [currently low] security threshold?
  3. If it does have marginal value, would a change of PoW mining algorithm to a niche that no other chain uses (so that it’s the dominant chain within that “algo niche” and attackers can’t rent hashing power in the NiceHash market — as referenced by Charlie Lee’s tweet below) be a good idea?
  4. The tradeoff of option 3 above is that miners would have to mine exclusively for ETC and there would be no compatibility to jump from chain to chain, so this may reduce their interest in mining ETC.

If I am assessing the situation correctly, the reason that the current breach was possible was because:

  1. The ETC network is still small.
  2. As stated above, it shares the same mining algorithm as other larger networks, e.g. Ethereum, making it vulnerable to 51% attacks through renting compatible hardware with the same algo.

However, I think there is still an opportunity for ETC for several reasons:

  1. It is a proof of work, Turing-complete blockchain, with the cryptocurrency and smart contracts both fully integrated in the base layer.
  2. The above value proposition is different and more secure (provided that it gains significant size in the future) than all competitors as Bitcoin is not Turing-complete and requires sidechains for smart contracts, and all the other Turing-complete blockchains are either PoS or some other BFT consensus mechanisms, some including treasuries and voting, which are all significantly less secure than proof of work.
  3. The ETC ecosystem is still very focused on immutability as a core value, not having any formal governance mechanism, and guaranteeing emergent decision making thru free adoption of the network and rule changes.
  4. ETC has a fixed monetary policy.
  5. ETC is unique and the only blockchain in its niche.
  6. ETH, which currently shares the same proof of work +Turing complete niche, will very likely migrate to PoS and sharding which are both less secure technologies.
  7. Although Bitcoin is highly secure, it is unlikely that the world will use only one base layer blockchain to build all systems on top.
  8. The above is especially the case if that implies merged mining and drivechains which will create risky “super-miners” in that ecosystem.

Bear in mind that the current attacks ETC suffered are not a function of a flawed internal design or a ‘hack’ to the system. It was a double-spend mining attack and a breach of security which is a formal assumption in its design, which is vulnerable to 51% attacks, as in any other proof of work blockchain, including Bitcoin.

Conclusion:

My personal opinion is that what happened is a significant setback, but I think ETC still has a unique positioning as a PoW + Turing-complete network with an active community with sound principles. The question is whether a recovery in the medium or long term is plausible or if the network, unless it grows significantly, is perpetually vulnerable, therefore unusable.

I think that continuing to build the stack as planned (a secure PoW base layer, with layer 2 sidechains, plus developer tools, continuous efficiency gains and adding of new features in the long term) will get ETC closer to the long term vision of a blockchain perfectly suitable for secure decentralized computing.

With the above in mind I think the best path is to explore a mining algorithm change to put ETC in a unique, incompatible PoW niche. Even if that implies a tradeoff as miners will have less optionality to point their infrastructure to different chains depending on the profitability of the day.

EDIT 1/9/2019: The ETC community is working on a post-mortem and contingency plan to deal with the recent attacks mentioned in this post. I have changed my position about a mining algorithm change as a PoW change as described above may not be necessary. So, I am open for ETC to stay with the current mining algorithm and/or implement other changes to mitigate this situation.

Formal Science vs Applied Science in ETC

 
The first part of the Discord conversation.

[The following is my opinion about the conversation above in the Ethereum Classic (ETC) Discord, but because it is too long for a group chat, I post it here for easier reading.]

Regarding Meredith Patterson, I think she may be a good complement to ETC (again, ETC is permissionless, so I still think she should just start working rather than doing formal intros) because she seems to be more dedicated to the theoretical side [1].

However that role is not related, therefore is no proximate replacement of ETCDEV, as in “willing to step up and take point on ETCDEVs role”, in any way. It is much more likely a complement.

The differences between Meredith’s team work and ETCDEV’s work are:

1. Formal science vs applied science: Meredith does LANGSEC which seems to be largely research and theory. ETCDEV is primarily engineering, meaning building stuff using best practices, much of which are learned thru research and theory, first, from teams such as Meredith’s.

2. Planned vs ad hoc: Going thru the process of long research processes to come up with master-plans is useful, but blockchains, as the internet, are collections of teams dispersed around the world with different plans, goals and time preferences. It is impossible to establish centralized or generalized methodologies. They just have to learn by losing money. In the meantime, ETCDEV is far ahead in that game, building concrete solutions (such as Emerald, SputnikVM and Orbita) and establishing a clear vision for its own practice: blockchain and virtualization for decentralized computing, IoT, robotics, and smart contracts. Everything on top of ETC (see image below).

 

On the other hand, Meredith’s complexity vs simplicity concept is very valuable, in my opinion. I agree with the proposal to keep things as simple, thus as comprehensible by humans as possible. That is ETCDEV’s strategy on the engineering side, to breakup things into modules and keep them as lean, simple and efficient as possible.

In summary, the combination of theory and engineering is good for ETC, I do think the ecosystem lacks theory, especially more diverse sources, but one is not a replacement of the other.

Lastly, other than advocating for LANGSEC in general, I didn’t see that Meredith advocated for immutability or other blockchain principles per se [2]. It seems that LANGSEC applies to whatever blockchain philosophy an ecosystem adheres to, it’s more of a “making sure it works as intended” approach, regardless of what the intent or principles are.

References & sources:

[1] This is the LANGSEC website Meredith Patterson links to from her Twitter profile: LANGSEC: Language-theoretic Security: http://langsec.org/

[2] Meredith’s presentation at ETC Summit 2017: ETC Hong Kong summit | Meredith Patterson: https://youtu.be/rqqdFufARXA

Update 12–8–2018:

Update 12–10–2018:

  • Meredith has a deep understanding of game theory and evolutionary game theory. I think this is very valuable for ETC as well: https://youtu.be/jWxtTsRJOYg