by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 2019 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 2019 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Alex Beregszaszi
@axic
btw, there is no “Constantinople Fix”. It is called “Petersburg”.
Danno Ferrin
@shemnon
Check the reference tests.
Alex Beregszaszi
@axic

The reference tests were not updated because @winsvega argued he doesn’t have the capacity to update it. There is a long debate.

Also, check the meta EIPs for hard fork names :wink:

Danno Ferrin
@shemnon
True, they disagree.
James Hancock
@MadeofTin
And I wouldn't want anyone to think that EIPs that have been discussed for the next fork that includes features is somehow missed. Perhaps I am overthinking it. But articles have already been written about Berlin which we can leave as true if we leave the ice-age fork as an interim fork.
Alex Beregszaszi
@axic

But articles have already been written about Berlin which we can leave as true if we leave the ice-age fork as an interim fork.

Do you have any links? I think this really goes against the EIP-centric process.

Danno Ferrin
@shemnon
The ice age EIP hasn’t exactly gone throught the EIP process. No ACD review, etc.
Alex Beregszaszi
@axic
Do you expect it to go live without a review from “ACD” ?
Tim Beiko
@timbeiko
I think we should at least review it on the next call, FWIW. Ideally, all clients have implemented it and we can just ship it as soon as possible after the call (which is not all that different from EIPs having client implementations before moving to Accepted)
Danno Ferrin
@shemnon
We are also not doing the typical testnet rollout either, we are picking a mainnet block well before ropsten, Rinkeby, and goerli. (side discussion, when do we activate on Ropsten?)
James Hancock
@MadeofTin
Here are a couple. discussing Berlin being spring 2020.
I say we have clients implement Eric's EIP and then we have final decision on next weeks ACD.
We can also decide on Ropsten before that call.
Tim Beiko
@timbeiko
:+1:
James Hancock
@MadeofTin

I think we should at least review it on the next call, FWIW. Ideally, all clients have implemented it and we can just ship it as soon as possible after the call (which is not all that different from EIPs having client implementations before moving to Accepted)

^

Once implmented we can ask people to upgrade straight to the Ice-age fork if they haven't upgraded to Istanbul
Danno Ferrin
@shemnon
Ropsten: 11 dec or 18 dec? i.e. 1.5 or 2.5 weeks after the next ACD call? It would be nice to get both numbers in one patch.
Rinkeby and Goerli don’t need it so they can go straight to Berlin.
Tim Beiko
@timbeiko

Once implmented we can ask people to upgrade straight to the Ice-age fork if they haven't upgraded to Istanbul

Yes, as I’ve said above, we should absolutely point people to a single version for each client. Otherwise, the risk of confusion is huge, especially for Parity which has two version numbers (whch would be 4 if we list both Istanbul and Mountain Glacier versions), but even for others which will only have a minor update (i.e. 1.3.4 vs. 1.3.6 for Besu)

James Hancock
@MadeofTin
Lets do that as soon as we have the new numbers
I mean new versions
Tim Beiko
@timbeiko
:+1:
James Hancock
@MadeofTin
I really wish there was a way to do sticky messages in Gitter
Alex Beregszaszi
@axic
Or could use FEM forums for more sticky discussions :wink:
James Hancock
@MadeofTin
That would be good as well. :)
Micah Zoltu
@MicahZoltu
:point_up: November 23, 2019 1:29 AM Yes, very well. :wink: Augur chat turns into non-stop complaints about transaction costs and how Augur will never work because gas prices are too high, etc.
@AlexeyAkhunov
ledgerwatch
@AlexeyAkhunov
@MicahZoltu Yes, that was probably a wrong thing to say
Thomas Jay Rush
@tjayrush
Where does the number to delay the hard fork of 4,000,000 come from? My understanding of the reason for the bomb was to avoid a situation like in Bitcoin where ten people control when to fork. Here’s the scenario — all you’all decide (for whatever reason) that there should be no more changes forever. And whomever has the GitHub permissions to change the code are convinced as well. The rest of the community would then have no recourse. If you think this can’t happen--look at Bitcoin. Forcing ourselves to deliver a fork every so often, even if there are no substantive changes, forces the community to repeatedly come back into agreement...and it give whatever portion of the community that wants to a chance to fork off. A better way to remove the ‘pain’ of the ice age would be to better manage it and make sure it gets modeled better (so we know when it’s going to hit) and include it in forks as a regular course.
James Hancock
@MadeofTin
I would be fine with a 3 million delay as that still give us plenty of time to deal with it. Through the new EIP centric process we hope there to be more forks as the barrier to having an upgrade is lower.
We are still expecting another fork late spring. If that is significantly delayed then I would be more worried about the scenario you lined up.
James Hancock
@MadeofTin
I'll add these reasonings to the Fork EIP as well. ethereum/EIPs#2387
@tjayrush
Would you mind if I copied your reply into the Eth Magicans post?
Jamie Pitts
@jpitts
From time to time I will copy longer convos that happen here into the related FEM Forum post (thx for getting that started), this is def. one of those cases. I can do it later on today @madeoftin if you dont get to it first.
Wei Tang
@sorpaas
An explanatory piece regarding the backward compatibility issues in Ethereum: https://ep.corepaper.org/compatibility/
Feedback appreciated!
ledgerwatch
@AlexeyAkhunov
@sorpaas My general feedback would be quite positive. Now that I understand (or I think I understand) how to go about re-pricing opcodes in the version '1'. And I really want to start some work on the EVM semantics, in order to get such changes specified better.
Thomas Jay Rush
@tjayrush
@MadeofTin No problem. I’ll copy it.
Danno Ferrin
@shemnon
@sorpaas is there a “discussion-to” for your proposals?
Wei Tang
@sorpaas
If you mean comments regarding the article, just create an issue there. https://github.com/corepaper/ep/issues
Indeed, some older ones hosted at specs.that.world don’t have discussion to link. Let me add it.
Thomas Jay Rush
@tjayrush
In this article, I argue that hash rate has nothing to do with why the bomb seems to be going off earlier this time than the last time. I argue that we didn’t set the period back far enough last time. I also argue that the only thing that really matters is the bomb part of the calc, and that the non-bomb part not only doesn’t affect the slowing blocks but that it actually helps the chain get back to faster blocks each time a bomblet explodes. Finally, I argue that if one always sets the period back to the same value (0), then the bomb would be perfectly predictable since it’s a function of fake block number only. It’s all explained here: https://medium.com/@tjayrush/its-not-that-difficult-33a428c3c2c3. I’d really appreciate discussion.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<M H Swende (holiman)> Nice article!
Martin Holst Swende
@holiman
In other news, thanks to @tkstanczak and @gumb0 and @chfast, I've now got aleth and nethermind up on fuzzing, so finally we're up to four evms on differential fuzzing!
Tomasz Kajetan Stańczak
@tkstanczak
kudos @holiman :)
Bob Summerwill
@bobsummerwill

Great article, @tjayrush.

A simpler alternative is just to get rid of the difficulty bomb entirely, like ETC did.
Because the amount of work going into maintaining this thing in ETH is massive, and the original reasoning behind the mechanism does not really make sense anymore.

At the point of POS transition, some group will OBVIOUSLY just remove the bomb and fork ETH1 anyway.

You should not need to coerce anybody to ensure migration to ETH2.
Just watching all of the brain time and developer resources in this last week or so going into working out what is happening, into thinking "Should we get this into Istanbul? Make a new HF in January? How do we coordinate?" etc, makes me shake my head.

ETH does not have to have this problem. Sure - there is an emergency here to deal with, and it needs dealing with.

But the second that is done, please for goodness sake have a public debate and seriously consider yet removing the bomb entirely. What is the ROI here? What is the "win"?

https://ecips.ethereumclassic.org/ECIPs/ecip-1041

For ETC, the motivation for removing the bomb was that there IS no planned transation to POS.
For ETH, the motivation would be to avoid all this heart-ache.

Or just replace it with something massively simpler. Like:

if (blocknumber > N) then difficulty = MAX_INT.
Danno Ferrin
@shemnon
It’s not about coercing anyone who actually wants to spend time maintaining the chain. It’ about making sure a zombie chain doesn’t continue. Since ETC has given up on PoS it actually makes sense for them to disable the bomb. It does increase the risk of zombie chains from forks (like weve sene with ropsten on several occasions)