ethereum/pm

Ethereum Core Devs Meeting 67 Agenda

timbeiko opened this issue · 12 comments

timbeiko commented

Ethereum Core Devs Meeting 67 Agenda

Deadline for already submitted, non-Accepted, Istanbul EIPs to be considered "Tentatively Accepted"

Agenda

  1. Istanbul EIPs
    • Client implementation updates for Accepted and Tentatively Accepted
    • Last call for "Tentatively Accepted" EIPs
  2. Conformance Testing
  3. Testnet Upgrade & Istanbul Next Steps
  4. Review previous decisions made and action items
  5. Working Group Updates
  6. Testing Updates
  7. Client Updates (only if they are posted in the comments below)
    a) Geth
    b) Parity Ethereum
    c) Aleth/eth
    d) Trinity/PyEVM
    e) EthereumJS
    f) EthereumJ/Harmony
    g) Pantheon
    h) Turbo Geth
    i) Nimbus
    j) web3j
    k) Mana/Exthereum
    l) Mantis
    m) Nethermind
  8. EWASM & Research Updates (only if they are posted in the comments below)
chfast commented

I'd like to have a discussion about EIP-663: Unlimited SWAP and DUP instructions with the respect to these critical comments: https://ethereum-magicians.org/t/eip-663-unlimited-swap-and-dup-instructions/3346/10

I'm for accepting variant C and analyzing existing contracts for compatibility with "multibyte" opcode encoding.

Personally, I cannot attend the meeting (holidays).

chfast commented

I propose to reject EIP-2200 "Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change" because:

  1. After weeks of work it is not even a proper EIP draft: ethereum/EIPs#2200
  2. The replaced EIP-1706 is still a draft.
  3. There are unanswered comments and proposals in the official discussion channels:
axic commented

Random idea: protocol updates focused on a given topic.

Some topics I think could be useful:

  • rebalancing/repricing
  • new opcodes
  • new precompiles

So far different kind of changes were mixed into a single update. I believe the reasoning is that many of those changes should be independent, however if an update is focused on one kind of changes, perhaps there would be a more focused effort in reviewing their effect together.

axic commented

Following that train of though, for Istanbul it would be nice to mostly focus on repricing: 1108, 1884, 2028 – and potentially 2200, 2045 and 2046.

haydenadams commented

@chfast EIP 2200 champion @sorpaas is just on vacation and got caught by some other work and hasn't had a chance to respond. Doesn't seem like a good reason to kill the EIP when it is essentially done aside from documentation

ethereum/EIPs#2200 (comment)

timbeiko commented

@haydenadams for the record, we agreed on the call that we could not have the discussion about 2200 given that both @chfast and @sorpaas weren't on.

haydenadams commented

@timbeiko thanks thats good to hear.

Sorry if I'm being a bit pushy here. This EIP is important for us and I just want to make sure if its rejected its for a very good technical reason and not because someone was offline, there is some missing documentation, miscommunication, not enough funding for work, or any other easily resolvable issue.

  • 👍2
timbeiko commented

No worries, I appreciate your support for it! I think your comment in the ACD gitter is the best way forward, but I'm not sure myself how to answer.

  • 👍1
chfast commented

This EIP is important for us and I just want to make sure if its rejected its for a very good technical reason and not because someone was offline, there is some missing documentation, miscommunication, not enough funding for work, or any other easily resolvable issue.

If it is so important I bet you can make the spec look excellent before next Friday's ACD meeting.

chfast commented

@haydenadams Can you describe your use case in sorpaas/EIPs#1 (comment) in the context of the attached analysis?

haydenadams commented

@chfast honestly it feels like you have a personal reason for wanting to kill the EIP by causing a huge fuss last minute over nothing.

It's not like you brought up any issues during the AMA 3 weeks ago
https://ethereum-magicians.org/t/eip-1283-1706-ama/3467

And you didnt bring up any issues for literally months before that.

It's not like you answered my question in the Gitter about what the issue actually is. This feels intentionally timed to have the highest probability of killing the EIP by causing last second uncertainty and doubt in a process that usually airs on the side of caution

Why do I need to compare my various use cases to some random proposal by Alexey that isn't even an EIP yet? I could come up with as many use cases for the EIP as needed but mutex is as fine an example as any.

Please stop wasting time, playing politics, and sabotaging so I can build dapps with reasonable gas efficiency in 2019.

timbeiko commented

Closed in favor of #119