Ethereum Core Devs Meeting 24 Agenda
Souptacular opened this issue · 11 comments
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".
-
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 - openethereum/parity-ethereum#4833
- cpp-ethereum - ethereum/aleth#4050
- ethereumJ - ethereum/ethereumj#923
- ethereumJS
- yellowpaper - ethereum/yellowpaper#229
- pyethapp
- Other clients
2. Determining gas prices for new opcodes & pre-compiles [Martin HS/Arkadiy]
d. Review time estimate for testing/release. -
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.
One subtlety: EIP96 = PR210 contains three different hex code for the BLOCKHASH contract, but there should be at most two (runtime code and initcode).
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).
@Souptacular could you be so kind and include ethereum/ethereumj#923 in agenda, it shows progress of Byzantium implementation in EthereumJ
@mkalinin Absolutely. Updated!
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.
Just a heads-up for today: http://www.cahf.co/
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. 👍
This whole proposal is so ridiculous! I don't know where to start.
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.