Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ethereum Core Devs Meeting 44 Agenda #52

Closed
lrettig opened this issue Jul 27, 2018 · 12 comments
Closed

Ethereum Core Devs Meeting 44 Agenda #52

lrettig opened this issue Jul 27, 2018 · 12 comments

Comments

@lrettig
Copy link
Contributor

lrettig commented Jul 27, 2018

Ethereum Core Devs Meeting 44 Agenda

Meeting Date/Time: Friday 10 August 2018 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Livepeer Stream Link

Constantinople Progress

Agenda

  1. Testing
  2. Client Updates
  3. Research Updates
  4. Three competing EIPs to delay the difficulty bomb and/or reduce the block reward:
    a. EIP-858 - Reduce block reward to 1 ETH per block.
    b. EIP-1227 - Delay bomb and change rewards to 5 ETH.
    c. EIP-1234 - Delay bomb and change rewards to 2 ETH.
  5. Constantinople
    a. EIP 1014 Issues
    b. EIP 1218: Simpler blockhash refactoring. We are looking for a reason to implement this or anyone who will champion this. Otherwise we will drop it.
    c. EIP 1283/EIP 1087: Net gas metering for SSTORE operations: 1283 is an alternative to 1087 created due to issues Parity was having implementing 1087. Read 1283's motivation seciton of the EIP.
    d. EIP-1109: Remove call costs for precompiled contracts.
  6. Fellowship of Ethereum Magicians Update (didn't get to this on the last call)
@5chdn
Copy link
Contributor

5chdn commented Jul 30, 2018

Regarding 4) here are some resources from the community which might be interesting to read before discussing it.

@ghost
Copy link

ghost commented Jul 31, 2018

Please consider adding EIP-1276 as a part of discussion!

@jbaylina
Copy link

jbaylina commented Aug 2, 2018

Could you consider EIP-1108 and EIP-1109 ?

@sorpaas
Copy link
Contributor

sorpaas commented Aug 7, 2018

Please consider adding EIP-1283 to the discussion as well. This is an alternative for EIP-1087. For parity-ethereum, we are having some issues implementing EIP-1087 as is, and we think EIP-1087 may be a potential optimization blocker. You can read more on this in EIP-1283's Motivation section.

@Souptacular
Copy link
Contributor

@eosclassicteam disabling the difficulty bomb was rejected at the last core dev call so there is no reason to bring it up again at this time.

@jbaylina we discussed 1108 last meeting. See notes here.
Would you like to be on the next call to discuss 1109?

@sorpaas Added.

@jbaylina
Copy link

jbaylina commented Aug 9, 2018

Thank you @Souptacular ! Good discussion for EIP1108. And yes, I'll be glad to join the call!

@winsvega
Copy link

Writing an update here.
I suggest to drop blockhash refactoring if this is the case, because we already have a lot of changes.

extocodehash tests list: https://docs.google.com/spreadsheets/d/1xat7UI8GtB4ZGVdlK5_XQSHJZaMThi4SrlcL8XMZb5Q/edit?pli=1#gid=1811198384

create2 tests list:
https://docs.google.com/spreadsheets/d/1xat7UI8GtB4ZGVdlK5_XQSHJZaMThi4SrlcL8XMZb5Q/edit?pli=1#gid=1872446916

please add your ideas as a comments to the list. (right button -> comment)

Please confirm the implementation of this EIP
https://eips.ethereum.org/EIPS/eip-1014
the hash will affect contract creation address. which will affect all the tests.

Retesteth update:
Retesteth now support client configurations. You could set configs and bash script that retesteth will use to manage the RPC socket. Or you could set TCP socket and external ip address. retesteth could execute tests on all provided clients from command option like

retesteth -t RPCTests -- --clients="eth, parity, geth" 

@chfast
Copy link
Contributor

chfast commented Aug 10, 2018

Partial net sstore tests: ethereum/tests#483.

@gumb0
Copy link
Member

gumb0 commented Aug 10, 2018

Decision on the formula for CREATE2 address is needed - option 1 vs option 2 vs RLP-encoding each component ethereum/EIPs#1014

@holiman
Copy link

holiman commented Aug 10, 2018

@gumb0 re that address, two questions to resolve, as I understand it:

  • Use initcode VS hash of initcode
  • Prepend with 0xff VS use an RLP-schema to ensure that preimages don't collide with 'classic' address creation

@jpitts
Copy link
Member

jpitts commented Aug 10, 2018

Links for the Fellowship of Magicians update:

@lrettig
Copy link
Contributor Author

lrettig commented Aug 10, 2018

Closing in favor of #54

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests