11–20 of 108 posts
Back up and running: https://forkmon.ethdevops.io/ 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.
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.
Can somebody explain the significance? 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?
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...
Earlier quoted context omitted.
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.
Actually, it's this commit of the PR: https://github.com/openethereum/openethereum/pull/364/commit...
Can somebody explain the significance? 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?
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 happ…
Earlier quoted context omitted.
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 happ…
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?
Earlier quoted context omitted.
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.
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...
Can somebody explain the significance? 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?
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...
Earlier quoted context omitted.
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...
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.
Earlier quoted context omitted.
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.
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...