It seems the issue was in how OpenEthereum handled access lists introduced by EIP2929/2930. They were adding built-in contract addresses to access lists in blocks before those addresses were activated.
Ethereum Fork Fails on OpenEthereum
61–70 of 108 posts
Re: Ethereum Fork Fails on OpenEthereum
#62Satoshi 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?
New implementations are generally regarded as good in the space because they help solidify the underlying protocols and add established libraries and routines in a new programming language.
Re: Ethereum Fork Fails on OpenEthereum
#63Earlier quoted context omitted.
"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 Sat…
> Ethereum is not Bitcoin because Ethereum doesn't want to be Bitcoin, otherwise Ethereum wouldn't have existed in the first place This isn't exactly true. Vitalik only created Ethereum because the new core devs ( Blockstream ) were actively limiting what types of things could be done with Bitcoin. They were moving away from programmable money in favor of "digital gold". Source: https://twitter.com/vitalikbuterin/sta…
Developers have no ability to coerce what software bitcoin users run -- that's the entire point of bitcoin. If a competing developer fails to gain user adoption, it's on them that they haven't convinced users to switch consensus rules. It makes for a convincing inflammatory, but false story, for detractors or grifters though (see the myriad of Bitcoin clones: "Bitcoin" KYC, "Bitcoin" Diamond, "Bitcoin" Cash etc etc)
Re: Ethereum Fork Fails on OpenEthereum
#64Earlier quoted context omitted.
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.
If it's true that Ethereum blocks have any kind of checksum of the expected results, then if the patch has a mistake, I'd think the failure mode would just be that they continue to fail processing the failed block, or they get further but fail to process a more recent block. In that case, then I think it would make sense here to rush out a patch that's been manually checked, and then go back to add some tests.
Re: Ethereum Fork Fails on OpenEthereum
#65Earlier quoted context omitted.
Warning, bitcoin.com is non-authoritative on bitcoin. They went a little mad a few years ago with the big block agenda. They do not speak for bitcoin, and want to push their big block bcash fork. Satoshi proposed 1MB blocks in 2010 as an anti-spam mechanism. He was not against raising it, but it had to be done sensibly. RV and Bitcoin.com forced a non-sensible fork and fell off a cliff.
Warning: nobody is authoritative on bitcoin. You do not speak for the bitcoin community on who is and is not speaking for bitcoin.
Sure, but the network consensus does speak for bitcoin, and it overwhelmingly rejects bcash, bsv and the many other 'false profits'. Count the nodes. Count the hashrate. Count the accumulated work in the chain. Bcash offers simple (broken) solutions to hard problems. Pushing it over BTC is just technical ignorance.
Re: Ethereum Fork Fails on OpenEthereum
#66Satoshi 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…
A lot of people are disagreeing with you, possibly because of your overly-reverential treatment of Satoshi, but I think ultimately this idea makes more sense than some of the commenters here are giving it credit for.
Chrisco writes:
> The whole reason they have multiple clients is to make the network more resilient for moments like this.
But to me, it seems like this was a minor bug in which more contracts were being added to access lists than needed to be. Ultimately, I think that the network could have functioned normally if either this implementation or the Geth implementation was the only one on the network, without causing problems for anyone.
Other sibling comments make reference to the fact that Ethereum is much more complex than Bitcoin. But doesn't this just make it even more suitable for all development energy to be concentrated on a single client, since it's inherently harder to maintain?
Certainly there are benefits to having multiple clients, but I think there are drawbacks as well.
Re: Ethereum Fork Fails on OpenEthereum
#67Earlier quoted context omitted.
In BTC, the wise guidance of Satoshi is also regularly ignored. Here are a few examples Satoshi's Guidance: Bitcoin should function as cash Source: https://bitcoin.com/bitcoin.pdf ( See the title ) Satoshi's Guidance: We shouldn't be limiting transaction capacity to accommodate low performance client hardware Source: https://bitcointalk.org/index.php?topic=532.msg6306#msg6306 Satoshi's Guidance: The blocksize limit s…
Based on this, are you a fan of Bitcoin Cash? I find it interesting how divisive the split in Bitcoin / SegWit / Lightning Network vs Bitcoin Cash has been.
I support any and every coin that aims to build Satoshi's version of peer-to-peer electronic cash. Right now, the coins that come closest are Ethereum, Bitcoin Cash, and Dash. Sadly all three have had to make some big concessions that make them look less like the original version.
I also find the split interesting. I'm most interested in how effectively public perception was manipulated with regards to the split and the reasons for it.
Bitcoin Cash exists solely because of the censorship on r/bitcoin and the bitcointalk forums. When supporters of a high throughput network were silenced, the exodus started. That exodus turned into the fork. You can read more about that here ( https://medium.com/@johnblocke/a-brief-and-incomplete-histor... ) and here ( https://medium.com/@johnblocke/r-bitcoin-censorship-revisite... )
With regards to lightning network, it was pulled into the debate as a deflection from the real issue which was that a few high ranking core devs (after forming Blockstream, a company aiming to make money off of BTC's "scaling problems" ) reneged on their agreement to bump the blocksize to 2mb with the passing of segwit. Those devs realized they could hide behind lightning network and make it's supporters think big blockers were attacking them.
The truth is, very few people in the big block camps are against lightning network. I know many BCH devs that would welcome and even contribute to a lightning implementation on BCH, which for the record would work substantially better because on-chain fees wouldn't make it cost prohibitive to open/close channels or provide liquidity. The only beef with Lightning that big blockers really have is that they don't see it as an alternative to on-chain scaling. This whole BCH vs Lightning war is just a false flag.
Also, while we're all watching the Coinbase IPO with great interest, here's a gem from the golden boy himself that is very much relevant to this discussion: https://blog.coinbase.com/what-happened-at-the-satoshi-round...
Re: Ethereum Fork Fails on OpenEthereum
#68Satoshi 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…
Ethereum is NOT a second, nor compatible implementation of Bitcoin. That would be BCH, LiteCoin, DogeCoin, etc. which are literally forks of BTC. Although those are not exactly compatible either. Ethereum started with its own code base, its own core. It's a completely different concept altogether and its a true 10x innovation on blockchain as a concept. Ethereum has many client implementations built on several differ…
I know. My point is that multiple clients make the network LESS resilient. Moments like this prove it, as the network lost 11% of nodes until it was fixed. Satoshi was correct, multiple implementations are prone to failure, not resilient.
Re: Ethereum Fork Fails on OpenEthereum
#69Earlier quoted context omitted.
Warning, bitcoin.com is non-authoritative on bitcoin. They went a little mad a few years ago with the big block agenda. They do not speak for bitcoin, and want to push their big block bcash fork. Satoshi proposed 1MB blocks in 2010 as an anti-spam mechanism. He was not against raising it, but it had to be done sensibly. RV and Bitcoin.com forced a non-sensible fork and fell off a cliff.
"Non-authoritative" ... this is why BTC people just suck to talk to. Everyone DYOR. It is indisputable that Satoshi wanted big blocks. Here are a couple quotes: The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. https://www.bitcoin.com/satoshi-archive/emails/mike-hearn…
I hear ya. The view is that by references to a large network, split bt SPV and miner nodes, the miner nodes can run expanding blocks and the Rec users just hold block headers, more or less. That implies bigger blocks can occur, will occur at scale, and the miner can roll with it, users are still able to verify, and SN saw nothing wrong with that. Similar evidence as yours exists elsewhere.
I tend to think it’s too easy to cherry-pick SN quotes to make compelling logical cases on SN implying large or small blocks. I don’t think he ever gave a really strong statement on it, in the style the discussion now needs to close it out. As such, he’s not a great source.
I can pick something like this: /the more smaller farms resort to generating bitcoins, the higher the bar gets to overpower the network, making larger farms also too small to overpower it so that they may as well generate bitcoins too./
SN is arguing here, it seems, that the security model holds by enough small farmers, who he equates earlier to recreational users, being able to mine too.
That quote, and your quote, feel fairly at odds with each other! Miners can worry about the block size, they’ll be the super computers with TBs to spare v we need small users to participate in mining too as a key part of the security model, small users won’t have TBd to spare. If we can leave out how this steers into asics, do you note that contrast.
Re: Ethereum Fork Fails on OpenEthereum
#70Earlier quoted context omitted.
Warning: nobody is authoritative on bitcoin. You do not speak for the bitcoin community on who is and is not speaking for bitcoin.
Sure, but the network consensus does speak for bitcoin, and it overwhelmingly rejects bcash, bsv and the many other 'false profits'. Count the nodes. Count the hashrate. Count the accumulated work in the chain. Bcash offers simple (broken) solutions to hard problems. Pushing it over BTC is just technical ignorance.
Yeah that’s hard to miss. Hashrate plays out.