search

ethereumjs / ethereumjs-block

Project is in active development and has been moved to the EthereumJS VM monorepo.
https://github.com/ethereumjs/ethereumjs-vm/tree/master/packages/block
Mozilla Public License 2.0
42 stars 49 forks source link

HF Muir Glacier Difficulty bomb delay #87

Closed evertonfraga closed 4 years ago

evertonfraga commented 4 years ago

This PR delays the difficulty bomb, as specified by https://eips.ethereum.org/EIPS/eip-2384.

Should be tested in conjunction with https://github.com/ethereumjs/ethereumjs-common/pull/75.

Closes https://github.com/ethereumjs/ethereumjs-block/issues/79.

holgerd77 commented 4 years ago

Can you squash these commits into 2-3 logically fitting commits once ready so that we have a cleaner commit history?

Also we have to again decide what we want to do along the still unpublished 3.0 release, see https://github.com/ethereumjs/ethereumjs-block/pull/74.

Would you want to give this a try to integrate the 3.0 release into the VM along the changes here on a relatively short-term basis (sorry, I still don't have the capacity, this will get better from mid-January onwards) - so until early next week or so?

Or should we backport these changes analogue to what Sina did here https://github.com/ethereumjs/ethereumjs-block/pull/77 for the v2.2.1 release? If I get this right, this would mean to branch off from the release/v2.2.1 branch and do a PR with bumped release version, changelog and the changes from here and the do a release from the PR branch without merging.

evertonfraga commented 4 years ago

Re commits: absolutely. In fact I can rebase from master and just add the relevant commits on top of it. I imported this PR from the old one and GH web interface messed with the history.

I will look into the history and will try to have a solution by early next week.

Thanks for being responsive!

holgerd77 commented 4 years ago

Or should we backport these changes analogue to what Sina did here #77 for the v2.2.1 release? If I get this right, this would mean to branch off from the release/v2.2.1 branch and do a PR with bumped release version, changelog and the changes from here and the do a release from the PR branch without merging.

Had again another look at the commit history, and I would still have a tendency to do this as a v2.2.2 release within a process as described above, the v3.0.0 release is really a beast with updates necessary on the blockchain library + requiring major releases there and for the VM. Think this would be very much too much squeezed into this last week and at the same time I think the more important thing is to get a MuirGlacier release out before Christmas, this is already a bit tight with this patch release version (very much manageable though).

Eventually we even want to do this a bit on a quick-and-dirty level and not include all these CI changes on these old branch but just take/cherry-pick the 2 out of 3 content commits from this PR and put them on top of the branch and see if the Travis Node tests are working together with a confirmation note from along PR submission that browser tests have been successfully run locally.

@evertonfraga What do you think? Does this make sense? Can you then prepare a PR accordingly?

evertonfraga commented 4 years ago

Makes sense, I’ll prepare them on Monday.