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 24 Agenda #22

Closed
Souptacular opened this issue Sep 4, 2017 · 11 comments
Closed

Ethereum Core Devs Meeting 24 Agenda #22

Souptacular opened this issue Sep 4, 2017 · 11 comments

Comments

@Souptacular
Copy link
Contributor

Souptacular commented Sep 4, 2017

Ethereum Core Devs Meeting 24 Agenda

Meeting Date/Time: Friday 9/8/17 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

Reminder: Metropolis is now split into 2 hard forks: "Byzantium" first and then "Constantinople".

  1. Metropolis updates/EIPs.
    a. Any "subtleties" or questions we need to work out.
    - EIP96 = PR210 contains three different hex code for the BLOCKHASH contract, but there should be at most two (runtime code and initcode). [Yoichi]
    - EIP #603: Add ECADD and ECMUL precompiles for secp256k1. See this comment for details and request to add to Constantinople. [Matthew D.]
    b. Updates to testing.
    c. Details and implementations of EIPs.
    1. Updates from client teams.
    - geth - https://github.com/ethereum/go-ethereum/issues?q=label%3Ametropolis+is%3Aclosed
    - Parity - Byzantium release openethereum/parity-ethereum#4833
    - cpp-ethereum - [META] Byzantium implementation progress aleth#4050
    - ethereumJ - Byzantium release ethereumj#923
    - ethereumJS
    - yellowpaper - Byzantium changes yellowpaper#229
    - pyethapp
    - Other clients
    2. Determining gas prices for new opcodes & pre-compiles [Martin HS/Arkadiy]
    d. Review time estimate for testing/release.

  2. EIP 706: Snappy compression for devp2p - very simple change yet reduces sync bandwidth by 60-80%. [Peter]

Please provide comments to add or correct agenda topics.

@pirapira
Copy link
Member

pirapira commented Sep 4, 2017

One subtlety: EIP96 = PR210 contains three different hex code for the BLOCKHASH contract, but there should be at most two (runtime code and initcode).

@mattdf
Copy link
Member

mattdf commented Sep 4, 2017

I'd like to bring up ethereum/EIPs#603 - the only curve being added to Byzantium/Constantinople is alt_bn128 and limiting the network to that has some disadvantages:

  • No JS implementation of that curve (and not many easy-to-use implementations in general)
  • Curve is more complicated as it has groups G1 and G2 and knowing which one to use and how to use them leads to more mistakes if you're just trying to use it as a non bilinear curve
  • Basically completely unsupported by the community compared to secp256k1
  • With just alt_bn128 opcodes smart contracts are unable to manipulate transaction signatures for native ethereum transactions, which is a big drawback as if you did have those opcodes you could do cool things like check aggregate signatures and whatnot

There are many smart contracts right now that use a solidity secp256k1 eclib that assumed that secp256k1 opcodes were going to be added in metropolis, and rewriting them (correctly) to use alt_bn128 is non-trivial if you don't understand the properties of that curve.

I think it's worth considering adding this EIP for Constantinople, it's an easy 5 line addition in the major clients as they already have to support secp256k1 by default, and the curve itself has been heavily profiled and studied so there shouldn't be any surprises in terms of gas costs. It would be beneficial to the smart contract dev community to add a curve that has wide support in terms of libs and tooling, as well as it being the curve that native txs use for sigs in Ethereum and many other major cryptocurrencies (which is useful if you're implementing relays/pegs).

@mkalinin
Copy link
Contributor

mkalinin commented Sep 4, 2017

@Souptacular could you be so kind and include ethereum/ethereumj#923 in agenda, it shows progress of Byzantium implementation in EthereumJ

@Souptacular
Copy link
Contributor Author

@mkalinin Absolutely. Updated!

@Souptacular
Copy link
Contributor Author

Added @pirapira and @mattdf items to agenda.

@karalabe
Copy link
Member

karalabe commented Sep 7, 2017

Unrelated to Metropolis, but I'd like to suggest discussing a devp2p EIP that's very very simple yet reduces sync bandwidth by 60-80% ethereum/EIPs#706.

@5chdn
Copy link
Contributor

5chdn commented Sep 8, 2017

Just a heads-up for today: http://www.cahf.co/

@karalabe
Copy link
Member

karalabe commented Sep 8, 2017

Nice

we will issue 10% of pre-mine inflation for “Develop and ‘storing value’” stake. (This will be 1% inflation of total supply). Once we mine our stake ‘privately’ and check that there is no further problem on the chain, we will make our repository ‘public’ and release our CAHF geth node.

TL;DR private mine 10% for "development", which will cover copy-pasting Geth commits. 👍

@5chdn
Copy link
Contributor

5chdn commented Sep 8, 2017

This whole proposal is so ridiculous! I don't know where to start.

@TheCryptoMines
Copy link

Wow... I personally believe this is also ridiculous, while I was championing the other side of the issuance reduction with many other miners, this is taking it too far. I'm not a fan of HFs with new chains coming online, I believe it devalues the entire community by doing so but I also have to say this, you made a change without consulting the part of the community it most affected. You talk all the time about community consensus yet did no due diligence with the community into this change other than 'a few reddit posts' as Hundson repeated many times and an outdated, extremely biased carbon vote from a completely different EIP.

You then proceeded to justify the change in an extremely underhanded way, that it pays miners the same post fork than what they got before due to your negligence by not pushing back the difficulty bomb when it should have been done. When you finally do try to explain why it is happening and give reasoning around it (after multiple attempts by us to have you do so), you tell us 'Well it's too late to change anything now either way as testing is in progress' so we really have to take those reasons with a grain of salt. This is what happens when you put yourselves forward as a team who works on community consensus and then ignores a massive part of it.

While I do hope this dies out quickly and we can all continue to work together, united behind ETH and the ETH community, I really do hope you guys have learned from this for future updates.

@Souptacular
Copy link
Contributor Author

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

7 participants