Live data from Hacker News

Ethereum Fork Fails on OpenEthereum

github.com

31–40 of 108 posts

Re: Ethereum Fork Fails on OpenEthereum

#31

Satoshi wrote in 2010: "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. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

"In a different blockchain they go by different rules" yeah no shit, of course.

Ethereum is not Bitcoin because Ethereum doesn't want to be Bitcoin, otherwise Ethereum wouldn't have existed in the first place. That's like complaining that GCP is not following the advice of AWS "leaders", of course they are not gonna do that, otherwise they would work together, not on two different projects...

Also, no matter what Satoshi wrote in 2010, multiple implementations of Bitcoin does exist today, most of them relatively stable: https://en.bitcoin.it/wiki/Clients

And the integrity of the network is not harmed by multiple clients either, just harms the users of that client, not other clients so not sure what the harm is. Yes, it's difficult, but so is a lot of problems in the cryptocurrency space.

Re: Ethereum Fork Fails on OpenEthereum

#32
post #24
post #16

Earlier quoted context omitted.

386 files changed? This has to include more than just the fix, right?

Looks like they've extracted it to a separate hotfix PR here: https://github.com/openethereum/openethereum/pull/366

Shouldn't at least a unit test be added before accepting a pull request?

We're talking about 15% of a 300 billion dollar currency.

I have written tests for smaller things than that.

Re: Ethereum Fork Fails on OpenEthereum

#33

Satoshi wrote in 2010: "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. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

I think this depends on how good the specs are. I agree that if we look at other examples of separate implementations, this would support this argument (see Browsers for example). But on the flip-side, ETH 2.0 - the proof of stake work, released very good specs and now we have working implementations in Go, Java, Nim, Rust and more. All working right now since the launch that happened in December 2020

Re: Ethereum Fork Fails on OpenEthereum

#34

Satoshi wrote in 2010: "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. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

bitcoind is the most used implementation by far, but there are others that work fine, like btcd

The more significant difference seems to be Ethereum is far more complicated (a Rube Goldberg machine, as critics like to say) and has trouble coordinating hard forks.

A hard fork of Bitcoin is considered a different network, so it’s no longer an issue.

Re: Ethereum Fork Fails on OpenEthereum

#36
post #19

Earlier quoted context omitted.

This is not true, and I can say that because I work on Geth. We take great care to ensure that all clients behave according to the specification, and Geth has had similar faults in the past.

Surely it doesn't matter what the specification says? If the majority of the hashpower is using an implementation which deviates from the spec, then the blockchain will follow that code and not the 'correct' version. By the time the devs have fixed the bugs, it will be too late and too costly to roll back the chain and reverse all the subsequent transactions.

In theory you're right, yes. If the majority of the hashpower runs a specific version with specific consensus rules, then that version of the chain would "win".

But in reality, developers and others write the specification, which gets implemented in the clients and when a new version is available, the miners usually upgrade to the new version without any qualms what so ever. So in practice, the specification is what controls the network, as developers writing the clients implement things from the specification.

Re: Ethereum Fork Fails on OpenEthereum

#37

Satoshi wrote in 2010: "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. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

Is there some central aggregation point of ~everything (or in that spirit) that SN wrote, across all the various forums and such? I feel like I finally need to dig in and read all of that.

Re: Ethereum Fork Fails on OpenEthereum

#38

Satoshi wrote in 2010: "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. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

> the wise guidance of Satoshi is regularly ignored.

They are basically producing a competing product. Why should they ought to copy the exact formula of their competitors? How can they hope to be better than Bitcoin by doing everything the same way?

Re: Ethereum Fork Fails on OpenEthereum

#39
post #19

Earlier quoted context omitted.

Theoretically there’s a protocol standard, and every client implementation is equal. Functionally, whatever Geth does is the actual standard because a supermajority of nodes run Geth.

This is not true, and I can say that because I work on Geth. We take great care to ensure that all clients behave according to the specification, and Geth has had similar faults in the past.

Can geth provide the same traces that OE does? I need to be able to detect when some internal tx sends ETH to one of my accounts and learn the txid...

Re: Ethereum Fork Fails on OpenEthereum

#40

Satoshi wrote in 2010: "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. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint." https://bitcoint…

it's interesting how dogmatic this is
Post reply on HN