Ethereum Fork Fails on OpenEthereum(github.com)
github.com
Ethereum Fork Fails on OpenEthereum
https://github.com/openethereum/openethereum/issues/353
107 comments
No.
It’s “just” a client issue, and OpenEthereum is “only” used by ~11% of the nodes. I believe the former name is Parity, which had a major bug related to frozen coins some years ago.
See https://mobile.twitter.com/etherscan/status/1382662485832994...
It’s “just” a client issue, and OpenEthereum is “only” used by ~11% of the nodes. I believe the former name is Parity, which had a major bug related to frozen coins some years ago.
See https://mobile.twitter.com/etherscan/status/1382662485832994...
Although the frozen coins bug wasn't related to the Parity client itself. It was a smart contract multisig wallet made by the same company.
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.
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.
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.
I mean in terms of bugs, rather than a 'rogue' client, i.e. not a deliberate attempt to cause a chain divergence.
If a 'broken' transaction gets accepted by a buggy client, and that buggy client has a majority of hash power, then that transaction is, by definition, not actually broken at all and everyone will be forced to accept it (because it will take too long to write a bug fix and re-write the blockchain history)
If a 'broken' transaction gets accepted by a buggy client, and that buggy client has a majority of hash power, then that transaction is, by definition, not actually broken at all and everyone will be forced to accept it (because it will take too long to write a bug fix and re-write the blockchain history)
In practice if an "official" client has a different interpretation of the spec it must be accepted by other clients.
Like with mentioned OpenEthereum (ex. Parity) here: https://github.com/openethereum/openethereum/blob/582bca385f...
Like with mentioned OpenEthereum (ex. Parity) here: https://github.com/openethereum/openethereum/blob/582bca385f...
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...
https://etherscan.io/nodetracker only shows 55% on geth; I wouldn't call that a super majority.
EDIT: Actually, that page shows 15% on openethereum so we must be looking at different sources. Where did you get 11% on openethereum?
EDIT: Actually, that page shows 15% on openethereum so we must be looking at different sources. Where did you get 11% on openethereum?
No, that was not in this fork, that one is slated for July. This fork was not contentious.
Reading the comments seems more like a technical problem on the consensus protocol of some implementation of eth nodes (in particular openethereum and geth)
Ethereum has different client software, they must all use the same consensus rules: produce/gossip/accept transactions and blocks that follow a certain format and respect certain invariants. When that specification is updated, a hard-fork occurs. It's not a problem if all clients meet the new spec perfectly but sometimes bug happens and different clients disagree on what constitutes the canon chain. This is what happened here: the OpenEthereum client (11% of the network) has had a bug following the Berlin hard-fork (network upgrade). Nodes runnning this client are stalling at a certain block because they don't recognize the new "post-Berlin" blocks as legitimate because of a bug in the implementation.
So are procotol-level changes announced ahead of time with a precise date when they get into force and the clients hard code that date as a transition? Or perhaps a block number is used?
Block number is used.
> Can somebody explain the significance?
These were non-mining nodes, so they were not participating in consensus (block ordering).
The chain did not split and nothing really happened, except cause a temporary outage of a "block explorer" website.
These were non-mining nodes, so they were not participating in consensus (block ordering).
The chain did not split and nothing really happened, except cause a temporary outage of a "block explorer" website.
It is only related to the Parity/OpenEthereum team continuing to have distractions on things more important to them like their own blockchain projects
Nobody should be using their client software
Nobody should be using their client software
Back up and running: https://forkmon.ethdevops.io/
Might take a bit to sync
Might take a bit to sync
It's not fixed yet, the OE instance in forkmon was syncing the whole time and hasn't hit the issue yet.
You sure? Thought it was in a failed state earlier?
I think a block recently processed on OE, that's why it's showing as good.
But yeah, don't think it's fixed yet.
I think a block recently processed on OE, that's why it's showing as good.
But yeah, don't think it's fixed yet.
The fix is in https://github.com/openethereum/openethereum/pull/364
Actually, it's this commit of the PR: https://github.com/openethereum/openethereum/pull/364/commit...
Actually, it's this commit of the PR: https://github.com/openethereum/openethereum/pull/364/commit...
Looks like some really subtle and (as far as I can tell) undocumented aspect of Ethereum internals tripped them up.
They didn't properly implement EIP-2929 (https://eips.ethereum.org/EIPS/eip-2929). I looked at the first section of the code diff in the PR and it matched up with stuff already documented in the EIP, so I wouldn't assume the issue was because of undocumented stuff. Multiple other Ethereum implementations managed to implement the EIP-2929 spec correctly.
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
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.
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.
The right way to fix this is to have an integration test that passes on all other implementations but fails on OpenEthereum, and push this fix afterwards.
People are storing and trading billions of dollars on Ethereum, so I think both automated and manual checking is important. Also an integration test for all branches should be able to find these errors.
People are storing and trading billions of dollars on Ethereum, so I think both automated and manual checking is important. Also an integration test for all branches should be able to find these errors.
[deleted]
My former employer (major exchange) switched from Parity / Openethereum after the last major issue. The Parity devs gave it up when they switched to focusing on Polkadot and the community is not super committed to it. Geth is the safer choice.
Fireblocks (massive institutional settlement platform for crypto-to-crypto and crypto-to-fiat transactions (like bank-size transactions) is on openethereum too -- all the settlements are completely backed up right now and tether is going really bid
Ethereum is THE fork. Original is called Ethereum Classic.
Nope, Ethereum was forked multiple times BEFORE that fork. So Ethereum Classic is not the "original" chain either (if by "original" you mean a chain that can be validated by running software from a time before the first fork).
You are getting downvoted but the internet has a very short memory.
Ethereum's DAO fork and the ETC debacle is why your OG's don't support Ethereum.
Ethereum's DAO fork and the ETC debacle is why your OG's don't support Ethereum.
As they say, the winners write the history books (and also the blockchains)
[deleted]
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://bitcointalk.org/index.php?topic=195.msg1611#msg1611
In ETH land, the wise guidance of Satoshi is regularly ignored.
In ETH land, the wise guidance of Satoshi is regularly ignored.
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 should be removed to maximize network capacity. The limit was only meant to be temporary.
Source: https://bitcointalk.org/index.php?topic=1347.msg15366#msg153...
EDIT: formatting
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 should be removed to maximize network capacity. The limit was only meant to be temporary.
Source: https://bitcointalk.org/index.php?topic=1347.msg15366#msg153...
EDIT: formatting
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 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...
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...
>the coins that come closest are Ethereum, Bitcoin Cash, and Dash.
How come the XRPLedger isn't on your radar? It was build before these other coins existed with the primary goal to be a better bitcoin so it can actually have the properties that p2p cash needs. Like low block time, low fees and high throughput. Its ofc not a fork because forking can not change the fundamental flaws that limits bitcoin. Unfortunately Satoshi was completely wrong on almost everything related to scaling the network.
"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. It never really hits a scale ceiling."
How come the XRPLedger isn't on your radar? It was build before these other coins existed with the primary goal to be a better bitcoin so it can actually have the properties that p2p cash needs. Like low block time, low fees and high throughput. Its ofc not a fork because forking can not change the fundamental flaws that limits bitcoin. Unfortunately Satoshi was completely wrong on almost everything related to scaling the network.
"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. It never really hits a scale ceiling."
What about Litecoin as peer-to-peer electronic cash? I don't see what benefits Bitcoin Cash has over Litecoin. It seems like the original idea for Litecoin was that it could be used more for day to day transactions, by reducing the block time. I question the need for Bitcoin Cash to begin with, when Litecoin was already available. I am curious of your thoughts on that.
I also saw you mentioned Dash. Is there a reason you didn't also include Z-Cash in your short list (I am genuinely curious).
I am aware of the r/bitcoin vs r/btc controversy and understand the r/bitcoin censorship concern. On the other hand, r/btc is not censored but they seem so anti Bitcoin Core / Lightning Network, it looks to me like they don't consider the other side at all.
From what I can tell, the Lightning Network could be a scaling solution. It is awesome to know that many BCH devs aren't opposed to a lightning implementation on BCH. I'd love to see these communities converge.
I also saw you mentioned Dash. Is there a reason you didn't also include Z-Cash in your short list (I am genuinely curious).
I am aware of the r/bitcoin vs r/btc controversy and understand the r/bitcoin censorship concern. On the other hand, r/btc is not censored but they seem so anti Bitcoin Core / Lightning Network, it looks to me like they don't consider the other side at all.
From what I can tell, the Lightning Network could be a scaling solution. It is awesome to know that many BCH devs aren't opposed to a lightning implementation on BCH. I'd love to see these communities converge.
That's the problem, bcashers ignore technical reality.
Actual pro-bitcoin altcoin project like Zcash and Litecoin are ignored for the altcoins that fell into the bcash camp and memes.
Litecoin is a better "bitcoin" than bitcoin cash, and with its move towards Mimblewimble Extension Block's, will have additional privacy that does not exist in bcash. But accepting that would require more a technical understanding of mathematics and cryptoeconomics.
Litecoin is a better "bitcoin" than bitcoin cash, and with its move towards Mimblewimble Extension Block's, will have additional privacy that does not exist in bcash. But accepting that would require more a technical understanding of mathematics and cryptoeconomics.
People are more allergic to words, in this case its brands, then the technical merit
What about Nano?
"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.
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.
> "In a different blockchain they go by different rules" yeah no shit, of course.
That's a terrible summary! It's like saying it's obvious that GM should ignore anything Henry Ford ever said about making cars. There might be good reasons to act differently, but simply being a different organization isn't one.
That's a terrible summary! It's like saying it's obvious that GM should ignore anything Henry Ford ever said about making cars. There might be good reasons to act differently, but simply being a different organization isn't one.
I think you have it backwards. It's more like saying that not every single thing Henry Ford ever said actually describes the best possible way of making cars. Henry Ford was capable of getting things wrong.
I don't think anyone is claiming that Ethereum should do things differently just to be different. The claim is that actually that Ethereum isn't necessarily worse just because it is different.
I don't think anyone is claiming that Ethereum should do things differently just to be different. The claim is that actually that Ethereum isn't necessarily worse just because it is different.
The market itself has shown resilience through all kinds of previously theoretical problems
51% attacked coins dont “crash to zero” because market participants decided it wants to buy them up and attempt double spending. In other cases the proactive disabling of only some off-ramps just creates greater scarcity, ensuring amplified value to the coin being acquired
A lot of what satoshi said can be ignored because the market can simply bear it
These are products which can attract value for reasons satoshi and enthusiasts did not predict, just like any economist fails to predict what actual individual humans will do
51% attacked coins dont “crash to zero” because market participants decided it wants to buy them up and attempt double spending. In other cases the proactive disabling of only some off-ramps just creates greater scarcity, ensuring amplified value to the coin being acquired
A lot of what satoshi said can be ignored because the market can simply bear it
These are products which can attract value for reasons satoshi and enthusiasts did not predict, just like any economist fails to predict what actual individual humans will do
> 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/status/929805462052229120...
Here's a more detailed telling of the events by one of the Decred developers: https://old.reddit.com/r/decred/comments/6wxueo/your_best_pi...
TLDR: Ethereum actually does want to be Bitcoin but that's only because Bitcoin doesn't really want to be Bitcoin anymore. They've dumbed down their protocol. They've dumbed down their infrastructure. Hell, they've even managed to dumb down their users. Ethereum will make a fine Bitcoin.
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/status/929805462052229120...
Here's a more detailed telling of the events by one of the Decred developers: https://old.reddit.com/r/decred/comments/6wxueo/your_best_pi...
TLDR: Ethereum actually does want to be Bitcoin but that's only because Bitcoin doesn't really want to be Bitcoin anymore. They've dumbed down their protocol. They've dumbed down their infrastructure. Hell, they've even managed to dumb down their users. Ethereum will make a fine Bitcoin.
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)
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
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 different programming languages. The whole reason they have multiple clients is to make the network more resilient for moments like this.
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 different programming languages. The whole reason they have multiple clients is to make the network more resilient for moments like this.
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.
And yet the network kept running.
Back in 2016, a denial-of-service attack took down the most popular node implementation. People quickly switched to the second-most popular implementation, and the network kept running without interruption until the popular client was fixed eight hours later.
Back in 2016, a denial-of-service attack took down the most popular node implementation. People quickly switched to the second-most popular implementation, and the network kept running without interruption until the popular client was fixed eight hours later.
I really don't like the "Satoshi wouldn't have liked this" arguments.
Have you ever worked with a really smart, visionary guy who changed his opinion on something? Have you changed your opinion? Satoshi is gone, and we can't just assume what his opinions would be today.
I think death of the author definitely applies here. It's an open protocol. I respect Satoshi as a visionary and inventor, but he does not have the final say.
Have you ever worked with a really smart, visionary guy who changed his opinion on something? Have you changed your opinion? Satoshi is gone, and we can't just assume what his opinions would be today.
I think death of the author definitely applies here. It's an open protocol. I respect Satoshi as a visionary and inventor, but he does not have the final say.
> 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?
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?
I don't think you could call ethereum a competing product, it works fairly differently in a lot of fundamental ways. UDP vs. TCP is more accurate IMO, and those two don't really compete.
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.
Ethereum is a distributed blockchain focusing on smart contracts. ETH is just the cryptocurrency built to power it. The vision is much, much bigger than a mere currency (Bitcoin), even if the roll-out is proving complex.
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.
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.
The real problem with Ethereum client code, is that almost everyone just starting to work on it — and even some people who've been at it for a while — are under the mistaken belief that Ethereum itself is a 100% formalized system, because the Yellow Paper formalizes the behavior of the EVM. They think that as long as their EVM follows the spec, they can't possibly accidentally calcluate a wrong state and end up out-of-consensus with the network.
However, there are (many!) stateful things that happen during Ethereum block-ingestion that occur outside of contract bytecode execution (i.e. not modelled by the EVM abstract-machine.) So even if you implement your EVM "to spec", there's this whole surrounding edifice of block-processing code that has no spec, that everyone's just guessing and "following the leader" on.
IMHO Ethereum badly needs a "Yellow Paper 2" that takes a step back and formalizes the whole block validation+execution flow. On top of that, there could be a C FFI spec for implementations of a "block processor" to follow, with type declarations for the ADTs such a library would consume/produce — making them into, essentially, plugin libraries (where any Ethereum node implementation could plug in any Ethereum block processor engine implementation.) Think "web browser" vs. "rendering engine" (where the "scripting engine" — i.e. the EVM — is just one part of the "rendering engine.")
If such a formal block-processor plugin interface existed, an Ethereum "node" could then just consist of the storage engine, the consensus engine's policy layer (while needing to rely on standardized consensus machinery existing within the block-processor), the P2P protocols, and the RPC backend. I.e., infrastructure code.
Powerfully, this would mean that networks that are essentially forks of Ethereum or which embed an Ethereum node in their network architecture (i.e. everything listed on https://chainid.network/) could all just link in an up-to-date upstream block-processor engine — rather than drifting away from it just because they've necessarily forked the storage+consensus+p2p+rpc code.
However, there are (many!) stateful things that happen during Ethereum block-ingestion that occur outside of contract bytecode execution (i.e. not modelled by the EVM abstract-machine.) So even if you implement your EVM "to spec", there's this whole surrounding edifice of block-processing code that has no spec, that everyone's just guessing and "following the leader" on.
IMHO Ethereum badly needs a "Yellow Paper 2" that takes a step back and formalizes the whole block validation+execution flow. On top of that, there could be a C FFI spec for implementations of a "block processor" to follow, with type declarations for the ADTs such a library would consume/produce — making them into, essentially, plugin libraries (where any Ethereum node implementation could plug in any Ethereum block processor engine implementation.) Think "web browser" vs. "rendering engine" (where the "scripting engine" — i.e. the EVM — is just one part of the "rendering engine.")
If such a formal block-processor plugin interface existed, an Ethereum "node" could then just consist of the storage engine, the consensus engine's policy layer (while needing to rely on standardized consensus machinery existing within the block-processor), the P2P protocols, and the RPC backend. I.e., infrastructure code.
Powerfully, this would mean that networks that are essentially forks of Ethereum or which embed an Ethereum node in their network architecture (i.e. everything listed on https://chainid.network/) could all just link in an up-to-date upstream block-processor engine — rather than drifting away from it just because they've necessarily forked the storage+consensus+p2p+rpc code.
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.
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.
:-) Yes.
Folks threw rocks at Satoshi back in the day too, because they did not understand.
Why are you treating Satoshi like an enlightened prophet?
Because he invented the money that we will use for the next 500 years. Some folks think influential people are worth quoting, in the same way we do about people like Adam Smith, The founding fathers of the United States, Dr King, Karl Marx, etc
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.
Bitcoin.com has the Satoshi Archive (https://www.bitcoin.com/satoshi-archive/) with all his emails and forum posts. Satoshi wanted big blocks, and so BTC largely ignores him or says "We are all satoshi", but there is a ton of wisdom if you go back and read. This was put together by Derek Magill, who is also a good person to follow on Twitter.
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.
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.
Roger Ver had nothing to do with the BCH fork. In fact, he was many months late in showing any public support for it. He was dead silent until it started to look like the core devs were going to reneg on their agreement to support 2mb blocks in exchange for passing Segwit. And as expected, they did reneg on that, immediately after they got what they wanted.
BCH is not Roger Ver. BCH is all of the old school Bitcoiners who still believe Bitcoin can scale like Satoshi intended. And they're a hell of a lot less toxic to interact with.
BCH is not Roger Ver. BCH is all of the old school Bitcoiners who still believe Bitcoin can scale like Satoshi intended. And they're a hell of a lot less toxic to interact with.
I think the us vs them mentality is what is toxic, and I see that on both sides of the Bitcoin scaling discussion.
BCH may not be Roger Ver, but the main reason I don't currently hold BCH is because of Roger Ver. If he wasn't in the picture I would be much more apt to hold BCH. He comes across as very reactive. What's wrong with calling BCH bcash? Does he really need to blow up anytime someone calls it that?
BCH may not be Roger Ver, but the main reason I don't currently hold BCH is because of Roger Ver. If he wasn't in the picture I would be much more apt to hold BCH. He comes across as very reactive. What's wrong with calling BCH bcash? Does he really need to blow up anytime someone calls it that?
I beg to disagree. No oldschool bitcoiner I know (including myself) takes bcash seriously. I would request that you to name any technical public figure that supports bcash. All that is left in this community is new suckers, and antibitcoin non-technical folks. Segwit DID change in blocksize weighting, with a fee incentive model to use segwit. These false antiblockstream tropes should have died out in 2018, but bcashers keep bringing them up, as they lack the technical nuance to understand how the system works.
There will be another weighting change with taproot, which further scales the network by preventing the need to broadcast tx's containing the full script output. This in turn introduces additional privacy in indistinguishably of script outputs.
Its not too late to preserve your money. Ignore the fork noise, and keep stacking (real) sats.
There will be another weighting change with taproot, which further scales the network by preventing the need to broadcast tx's containing the full script output. This in turn introduces additional privacy in indistinguishably of script outputs.
Its not too late to preserve your money. Ignore the fork noise, and keep stacking (real) sats.
Congratulations, you made me come out of retirement purely to disagree with you. No chain more richly deserves death than BTC and BCH is one of the best chains in existence. I'm prepared to sign this message with a Bitcoin key from 2011 if you doubt the fact I've been active that long.
It's the unfortunate and poorly informed post 2017 split BTC adherents who have no idea what's going on. I watched the entire thing unfold first hand and the BCH camp simply has it correct. The fact that the market is largely completely ignorant of this is one of the most glaring indications of just how irrational it presently is.
Until BTC dies, the entire cryptosphere is little more than a joke. Witness the tone very technically proficient but not "in the cult" people like George Hotz have when they're discussing the block size debate; there's no doubt whatsoever that core is utterly wrong, to the point that any suggestion to the contrary is nothing more than a joke. Deep link to the exact part in a recent interview he addresses this https://youtu.be/_L3gNaAVjQ4?t=2635
It's the unfortunate and poorly informed post 2017 split BTC adherents who have no idea what's going on. I watched the entire thing unfold first hand and the BCH camp simply has it correct. The fact that the market is largely completely ignorant of this is one of the most glaring indications of just how irrational it presently is.
Until BTC dies, the entire cryptosphere is little more than a joke. Witness the tone very technically proficient but not "in the cult" people like George Hotz have when they're discussing the block size debate; there's no doubt whatsoever that core is utterly wrong, to the point that any suggestion to the contrary is nothing more than a joke. Deep link to the exact part in a recent interview he addresses this https://youtu.be/_L3gNaAVjQ4?t=2635
I would like to support BCH but everyone I talk to who supports Bitcoin Cash comes across as so divisive on this matter. BTC obviously has an important place in the crypto ecosystem. To discount the price growth of BTC and its importance in the overall awareness of crypto to the public seems short sighted. Price does matter. All of these coins can exist.
They sound divisive on the matter because for over a decade now they've fruitlessly tried to explain the abject idiocy of backing a takeover attempt by a party whose business model is directly focused around constraining on chain capacity to a uselessly low rate, the lower the better, and the uselessly low rate this attack has managed to constrain it to is barely higher than the throughput of a fax machine. Let that sink in; it's 2021 and gigabit internet in developing countries is not that big a deal for context. Fax machines haven't been "fast" since I was a kid and my hair is white now.
The situation is utterly absurd, and watching it unfold first hand over the last decade has been completely maddening. It is zero wonder at all that everybody subjected to that spectacle is not in good humour about having watched it transpire and the only way people can be surprised by that state is a lack of familiarity with the facts of the matter.
The situation is utterly absurd, and watching it unfold first hand over the last decade has been completely maddening. It is zero wonder at all that everybody subjected to that spectacle is not in good humour about having watched it transpire and the only way people can be surprised by that state is a lack of familiarity with the facts of the matter.
What about the arguments that I've heard that Bitcoin Cash / big blocks allow miners to make more money, and that could be why this whole discussion started in the first place?
I understand the argument that Blockstream has some bias, but it seems like there may be bias on the BCH side as well. If that's not the case, could you explain that in more detail?
I understand the argument that Blockstream has some bias, but it seems like there may be bias on the BCH side as well. If that's not the case, could you explain that in more detail?
Is that actually an argument against something though? If change x allowed devs on the apple store to make more money, why would that be an inherent reason to oppose it, for example? All the arguments that I've heard focused around that angle of attack fail to address this issue; there's nothing wrong with miners making money, and in fact it's the design of the system that they should make money, that's how security is paid for. Even the originator of the BTC permanently limited to 1mb meme admits this and constantly uses it to push his own position by claiming that an artificially constrained chain is necessary in order for a "fee market" to develop so that security is directly compensated by usage, whilst ignoring that the original design was indeed to have it directly compensated by usage, but in volume rather than artificial scarcity provoking a "fee market".
In terms of bias on the BCH side, you could argue that because of conditions after the split they've had to take some hits and make rough decisions in a rocky landscape, but even those I think you'd be hard pressed to really disagree with in light of what the options were at the time. When it comes to pre-fork though no; it's simply unequivocally the case that they were right all along. They were outright censored on the main forums from making the very simple points of both technical and historical fact in support of the position that the goal was always to scale on chain and the math works just fine for it, and even having actually executed that and pushed the BCH network to 256mb blocks on scalenet already, the cultists over on BTC just ignore this and pretend like their position has any more merit than it ever did, constructing progressively more idiotic justifications as time goes by and it becomes clear that their narrative of it being impossible to grow a chain faster than a fax machine is exactly what everybody who knew what the underlying numbers were knew it to be to begin with.
In terms of bias on the BCH side, you could argue that because of conditions after the split they've had to take some hits and make rough decisions in a rocky landscape, but even those I think you'd be hard pressed to really disagree with in light of what the options were at the time. When it comes to pre-fork though no; it's simply unequivocally the case that they were right all along. They were outright censored on the main forums from making the very simple points of both technical and historical fact in support of the position that the goal was always to scale on chain and the math works just fine for it, and even having actually executed that and pushed the BCH network to 256mb blocks on scalenet already, the cultists over on BTC just ignore this and pretend like their position has any more merit than it ever did, constructing progressively more idiotic justifications as time goes by and it becomes clear that their narrative of it being impossible to grow a chain faster than a fax machine is exactly what everybody who knew what the underlying numbers were knew it to be to begin with.
Thank you for providing more details. I actually was in support of Bitcoin Cash around the time of the fork, but after some time, something about Bitcoin Cash and r/btc seemed off to me. Bitcoin Core and r/bitcoin seemed to be the more reasonable folks. Roger Ver's attitude in interviews did not help. If anything, his behavior made me think twice about holding Bitcoin Cash at all. I can see that some people feel this same thing about the Bitcoin Core devs though. Craig Scott Wright and the Bitcoin SV split also didn't inspire confidence in the Bitcoin Cash community for me. Anyway, at this point I'm trying to gather more information to see if it's worth buying back into Bitcoin Cash, so I appreciate this.
Mike Hearn, Gavin Andreson, Roger Ver, and countless names I interact with on a regular basis support big blocks and were involved since the beginning. Folks, this what BTC does. Eventually the lies runs out.
"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/1/
At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware.
https://www.bitcoin.com/satoshi-archive/emails/cryptography/...
I find it interesting that these are missing in the Nakamoto Institute's quotes on scaling.
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/1/
At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware.
https://www.bitcoin.com/satoshi-archive/emails/cryptography/...
I find it interesting that these are missing in the Nakamoto Institute's quotes on scaling.
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.
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.
There's no problem - the word farm is being used differently in different contexts. In the quote you posted, farm is in reference to hashpower. You can have many smaller miners (zombie farms, in your quote) that know nothing about the transactions they are mining. That is how mining pools work today. All that is required is one big central node that can validate the transactions and build the block, which is what my quote was referencing with farm.
I don’t think mining pools were what SN had in mind with that quote, although the solution you note fits smaller miners contributing hashpower, and not needing to store a big block.
> I find it interesting that these are missing in the Nakamoto Institute's quotes on scaling.
Here's a source directly from Mike Hearn
https://bitcointalk.org/index.php?topic=149668.msg1596879#ms...
Here's a source directly from Mike Hearn
https://bitcointalk.org/index.php?topic=149668.msg1596879#ms...
Warning: nobody is authoritative on bitcoin.
You do not speak for the bitcoin community on who is and is not speaking for 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.
it's interesting how dogmatic this is
So much for a protocol eh ...
[deleted]
The problematic block https://hash.horse/0xac324366422b3ef181a3f62efd81eee6a3a887c...
Currently says "We couldn't find anything"
Then they might have fixed the block :). Hash horse is just an aggregator across blockchains
What? The problem was with a client implementation, not the block.
There is a sync issue after this block. https://hash.horse/12244294
How do you explain missing funds then ?
And 3.2.3 is now released to use that fix:)
well done
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.
Is this related to the conflict between devs and miners where devs want to reduce the mining fees and miners responded by creating a fork?