Mounting Number of Bad Coding Mistakes Haunts The Ethereum Ecosystem

The ongoing debate over the Ethereum hard fork decision has brought some interesting concepts to light. Unfortunately for Ethereum investors and holders, it turns out not all of the hyped projects were created through proper coding. Even the Ethereum code base itself is rather fragile, as showcased by the replay attack vector.

The DAO Was A Mistake, Plain And Simple

On paper, the concept behind the DAO was a very solid one, as it holds a lot of promise. Letting users create their own autonomous organizations on the blockchain is one of the many possible outcomes for the future. Unfortunately, this project was ahead of its time by quite a margin, despite raising over US$150m during their crowdfunding efforts.

It became apparent rather quickly this project was very rough around the edges, though. Attackers managed to drain funds from the DAO not once, but twice due to a vulnerability known to the developers. Despite knowing the risk, the team went ahead and continued to hype their project. A lot of people put money into The DAO, and when funds started going missing, panic ensued.

Luckily, the situation got resolved by the Ethereum developers, even though they should have abstained from intervening. Then again, most of them put a lot of money into this project as well, and they wouldn’t take the financial loss and roll over. Instead, they decided to hard fork Ethereum, removing any censorship-free aspects ever associated with this project.

Hard Forking Was A Bigger Mistake

If every Bitcoin investor who lost money due to a failed project would ask for their money back, there would have been hundreds of hard forks. No one took action when Mt. Gox went under. A lot more money was lost back then compared to The DAO’s problems. Plus, The Mt. Gox issue was not due to sloppy coding.

Hard forking Etheruem to bail out a few people says a lot about the current state of Ethereum. If the developers themselves had not put any money into the project, they wouldn’t have considered hard forking by any means. The only reason they did so is to save their own behinds, and the community just eats up the decision like hotcakes.

After all, this decision was made “by the community”. The same community of which maybe 10% – at best – participated in the vote. The same vote that was easy to manipulate by sending 0 ETH transactions to an address listed on the CarbonVote website. Totally legitimate, of course, why wouldn’t it be?

Replay Attack Needs To Be Fixed ASAP

Which brings us to the latest screw-up by the Ethereum developers: replay attacks. Even before the hard fork occurred, developers were all too well aware an issue could arise where users would execute a replay attack from an older blockchain. That older blockchain eventually turned into Ethereum Classic, which is the same as Ethereum without the hard fork.

Lackadaisical Ethereum developers assumed this older blockchain would be abandoned, instead of fixing the replay attack before hard forking. Alas, we are now in a situation where Ethereum die-hards called Ethereum Classic a scam “that needs to die”. But it is only thanks to the original Ethereum developers Ethereum Classic exists,a s they could not be bothered to prevent the consequences.

All of these issues are very hard lessons to learn in a short timespan. We can only hope the Ethereum developers are held accountable for their irrational decisions and the chaos they have created. The community has a role to play in this as well, even though most of them seem more than willing to pretend like nothing happened.

Header image courtesy of Shutterstock

About JP Buntinx

JP is a freelance copywriter and SEO writer who is passionate about various topics. The majority of his work focuses on Bitcoin, blockchain, and financial technology. He is contributing to major news sites all over the world, including NewsBTC