Remove Ethereum Classic

[vorot93]

Given continued negative publicity from ETC stakeholders...

https://twitter.com/etc_core/status/1281657991113125891?s=21 https://twitter.com/yazanator/status/1281606788677328896?s=21

...as well as the lack of meaningful story behind Classic right now (not immutable anymore)...

http://consensus.corepaper.org/wiki/Contention_of_Phoenix_(new)

...supporting Classic is more trouble than what it's worth.

Perhaps it's time for a divorce.

[vorot93]

Moderator note: this discussion may get heated, but I encourage everyone to stay civil and within the confines of our Code of Conduct.

[gitr0n1n]

You might want to adjust the name to "Closed Ethereum" :). Please don't think we all didn't see this PR coming with your actions.

These social attacks on the ETC network by these ETH development teams is why Hyperledger Besu and Core-Geth were recommended during the Phoenix hard fork. Meanwhile Ethereum Classic, the original Ethereum network, continues to keep it moving like the decentralized honey badger it is. Due to the permissionless nature of the network, you're always welcome to join back and contribute in the future. Best of luck to you.

[antsankov]

I would like to voice my disapproval of this Pull request.

While I am not an official member of the OpenEthereum development team, I have experience working with Parity to prove that a Keccak256 Proof of Work network (called Astor Testnet) is possible for Ethereum Classic, in support of ECIP-1049. I found the Parity client to be easy to use, with good mining infrastructure, and a high degree of reliability. OpenEthereum inherits this strong pedigree.

Why do I believe that OpenEthereum should continue to support ETC:

1. It is mutually beneficial for ETH and ETC to maintain similar tooling and compatibility, because it offers choices for developers and network participants to simply cross-deploy their products. Exchanges, Mining Pools, Dapp Developers, Wallets, can all use similar OpenEthereum nodes to support different networks and increase the capacity of the Ethereum Standard (similar to Unix or SQL) to run decentralized applications for the EVM.

2. Both ETH and ETC are very compatible. One of the primary purposes of the three hard forks (Atlantis + Azatlan + Phoenix) was to establish total EVM compatibility between the two chains, with the idea that consensus will switch to PoS on ETH and will stay PoW on ETC. This gives Dapp Developers the ability to deploy the same apps on multiple chains. There are many users who are attracted to ETC's policy of capped supply (210 million), and dedication to Proof of Work. It is the vision of Ethereum at the very beginning and that inspired its creation: a turing-complete layer on top of Bitcoin. That vision is worth preserving.

3. I would like to address directly the claim made by Sorpass that the immutability guarantee of ETC is broken. Everybody involved in this discussion should take 15 minutes to read the ETC Declaration Independence form 4 years ago and determine if you stand with the principles. There are six core principles, but the two main ones relevant here are:

• code is law; there shall be no changes to the Ethereum Classic code that violate the properties of immutability, fungibility, or sanctity of the ledger; transactions or ledger history cannot for any reason be reversed or modified

• forks and/or changes to the underlying protocol shall only be permitted for updating or upgrading the technology on which Ethereum Classic operates

ETC was created because of user's refusing to run the DAO bailout code they viewed as a form of memory-corruption of the blockchain. Where, the chain was rolled back, the cryptographic hashes from genesis were no longer valid, and the Ether involved was forcibly moved against the explicit code of a smart contract deployed on that chain. The response is a form of network-imposed seizure, in which developers decided to take a user's funds, even though the user had followed the contract exactly as written.

What Phoenix does, and where Sorpass accusation comes from, is upgrade the op-code pricing to align with ETH's, which themselves were changed based on possible attacks we have seen in the wild now that Ethereum is over 5 years old. Nowhere in the Declaration of Independence does it say that we need to freeze the EVM forever - as a technologist I think that is a foolish idea: the JVM upgrades, Linux upgrades, PostgreSQL upgrades. However, when you upgrade your Linux distribution, you are guaranteed that it will not try to over-write your files, and that is why ETC still claims immutability.

I sincerely hope OpenEthereum will choose to continue supporting Ethereum Classic, as well as Ethereum.

[sorpaas]

@antsankov Talking about immutability, I'd refer you to this gist, of a partial list of smart contracts broken by Phoenix. https://gist.github.com/sorpaas/72ce0618829849901e0f83bf43738ecb

There's nothing wrong with a pragmatic approach of immutability, as in Ethereum. In fact, like you, many would argue that it has advantages. However, doing so also means that we must honor the majority consensus, which ETC is the only exception in our currently supported blockchain list.

Immutability doesn't mean, like you said, freeze the opcode gases forever. There're millions of ways to solve the issue, such as account versioning. ETC could have just applied account versioning together with Phoenix and nothing would have been controversial at all. I'd also want to point out, that the arguments many ETC folks right now are using when discussing immutability, such as all-forks-break-immutability or your EVM-must-be-frozen-to-preserve-immutability-which-is-impractical, is pro-DAO argument -- the main rationale for pro-DAO is simply being pragmatic.

Anyway, I think immutability is only one of the issues here, and arguably not the primary issue. The primary and practical issue is rather that we don't believe there are good will any more in ETC community to maintain a multi-client ecosystem as lately the hostility towards other teams has been building up. This is not only just for OpenEthereum, but also internally among ETC Labs and ETC Coop (Labs' "gross mismanagement" accusation of Bob, multiple "take-over" attempts, surprise Atlantis announcements, etc). And I think for OpenEthereum we'd better get out of those weird chaos as none of the maintainers really have significant interests in ETC any more.

As of today, OpenEthereum and MultiGeth still collectively shares ~70% of Ethereum Classic's node count. However, the strange hostility in the past six months made us doubt whether ETC need a multi-client ecosystem any more, and may be better off with a one-client dominance ecosystem which you would more easily implement changes and avoid dealing with or completely ignoring oppositions (like it happened in Phoenix). We have been quite tolerant towards any hostility coming from ETC in the past, but it has been happening more and more frequently and more and more similar to plain trolling and personal attacks. A quite unfortunate example is Afri Schoedon's public aggressions.

[BelfordZ]

Punishing your users because Wei's REDACTED got the best of him? OK bye.

[oldcryptogeek]

:popcorn:

[sorpaas]

@BelfordZ For OpenEthereum ecosystem, being able to get rid of those unnecessary distractions like those ridiculous hostilities (your post is an example) would allow OE to deliver better quality software for users we care about (Ethereum users and all the other networks we support).

I feel sorry for ETC users. However, as I said above, given that there seems to be no good will in ETC to support a multi-client blockchain ecosystem, and with the constant blaming going on (not only just for OpenEthereum, but also internally among ETC Labs and ETC Coop), you may just be better off switching to a one-client dominance ecosystem, in which you would more easily implement changes and avoid dealing with or completely ignoring oppositions (like it happened in Phoenix).

[BelfordZ]

etc is just as immutable as it ever was etc devs still will never revert transactions. etc will continue to have multiple clients.

You say you feel bad for ETC users, yet you've been trying to attack them for the better part of 2020 - all because no one wanted your account versioning proposal. The only one to feel bad for here is your users. The poor devs who thought openethereum would be a good client to build... now having to do the leg of switching to https://core-geth.org/

[vorot93]

@BelfordZ

I have great respect for your work on OpenRPC in general and on JSONRPC spec for eth namespace. But personal attacks on OpenEthereum developers are unprofessional and only devalue your efforts. I very much ask you to stop before I have to resort to measures we will all regret later on.

[BelfordZ]

@vorot93 noted.

[sorpaas]

I don't want to engage in the fights, but it's quite interesting that @BelfordZ mentioned that ETC does not want account versioning. As far as I know, account versioning was a constant theme during all recent hard forks in ETC, and there were multiple attempts and asks to include it. I previously pushed it back due to development deadline concerns. Still in post-Phoenix hard fork discussions, I saw a few developers putting backward compatibility and account versioning on their next hard fork wish list. Perhaps everyone has already changed their minds.

Either case, it's indeed true that I'll not be providing any development support (specification or implementation) on ETC's backward compatibility or account versioning.

[sorpaas]

@BelfordZ I think @vorot93 has warned you about those personal attacks. I'm going to warn you again. Please stay constructive, or we may consider taking actions. If you really want to do accusations or blaming, at least do it with facts and truths.

[Georgi87]

The reason for me to approve this PR is to allow us/Gnosis to focus our development efforts on Ethereum mainnet. It has been a challenge to ensure the client works well for one network and we have no capacity to split any resources across different networks. We appreciate any help fixing issues for Ethereum mainnet and related testnets but want to encourage ETC users to switch over to multi-geth.

[bobsummerwill]

Thanks for the clarity, @Georgi87.

And thanks to everyone who has contributed to Parity-Ethereum / OpenEthereum over the years.

Parity maintaining support for both ETC and ETH was very much appreciated by many ETC end-users, with the codebase still used by nearly 50% of end-users on ETC.

Multi-geth is dropping ETC support too, but both core-geth and Hyperledger Besu are both viable options which we will be recommending to end-users. Best wishes.