Ethereum Core Devs Meeting 36 Agenda

[Souptacular]

Ethereum Core Devs Meeting 36 Agenda

Meeting Date/Time: Friday 04/06/18 at 14:00 UTC (http://www.timebie.com/std/utc.php)

NOTE: SOME AREAS OF THE WORLD RECENTLY HAD DAYLIGHT SAVINGS TIME

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Testing
2. EIP 712: Add eth_signTypedData as a standard for machine-verifiable and human-readable typed data signing with Ethereum keys.
3. EIP 665: Add precompiled contract for Ed25519 signature verification.
4. EIP 958: Modify block mining to be ASIC resistant.
5. EIP 960: Cap total ether supply at ~120 million.
6. EIP process updates.
7. Research Updates.
8. Metropolis.
9. Client updates.

Time permitting:
10. EIP 908: Reward for clients and full nodes validating transactions.

Please provide comments to add or correct agenda topics.

[danfinlay]

The live stream link only links back to this issue.

[oberstet]

I would like to ask for short time slot to bring up EIP 665.

Just present the proposal and ask for first feedback:

• Is that interesting? Is there support?
• What needs to be done to get the ball rolling?

PS: I am ready to do more work (implementations .. possibly in Python, C++, Go), but I guess it makes sense to get some first feedback first before starting in the wrong direction or with no support.

@Souptacular ^: was hinted to approach you directly.

[pipermerriam]

I would like to discuss forking for improved ASIC resistance: EIP 958

[RSAManagement]

Hallo regarding the next Metropolis HF, I would like you to consider a more granular series of Hard Forks (maybe one more, two instead of one) because in my opinion the ethereum node topology need a massive client upgrade. New clients do have better db handling and other networking desirable feature like snappy compression EIP 706.

So probably a more granular Hard Forks Series worth the effort.

[Buttaa]

Can EIP960 be discussed?

I think Vitalik made some good pro arguments and Nick some good contra ones.

Also the Idea to add a decay curve instead of making it complicated with a hard cap is probably easier to implement ( source )

[Souptacular]

@danfinlay Fixed! Thanks for letting me know.
@oberstet Added.
@pipermerriam Added.
@RSAManagement Good idea. I think that there are some people in favor of granular hard forks, but the EIPs we currently have that are accepted and require hard forks is not very many. Because of that and the laser focus on client improvements, casper, and sharding it is difficult to dedicate time for a hard fork for a few EIPs that are less important arguably. I'm sure the idea of granular hard forks will be brought up again though.
@ButtaTRiBot Added.

[AlexeyAkhunov]

Update on Turbo-Geth (I will not be able to join the meeting again, unfortunately):

Currently working on the reorg capability. There are two parts to the reorg - database and trie. Database part is easy, because turbo-geth stores list of keys updated at each block, so it can delete them in bulk. Trie part is more complicated, because, unlike original geth, it cannot maintain multiple forks of the state at the same time. Therefore, the trie has to be rewound to the fork base before the fork can be applied. Ditched the original plan of marking trie nodes with block numbers where these nodes were created. The reason - it makes interaction with the hashfile (32Mb file storing hashes of level 5 of the trie) very complicated. Instead, the reorg in the trie will be implemented by playing backwards the state updates. This required a substantial change in how trie updates interact with the database, and incidentally, led to further decoupling of database and the trie. It will also further speed up block import.

Rebased to the go-ethereum master as of 2nd of April.

I shall be talking about Turbo-Geth at Edcon

[jamesray1]

It would be good to talk about rewards for clients and full nodes: ethereum/EIPs#908.

[fubuloubu]

Summary for "EIP Process Updates"? (Just links to EIP website)

[Souptacular]

@fubuloubu We are in the process of automating parts of the EIP process and clearing up the confusion around EIP 1.

[Souptacular]

@jamesray1 We will if we have time. I have added it to the agenda.

[fubuloubu]

@Souptacular I'm assuming the "clearing up confusion" part has been discussed, is there links to the discussion(s)?

Automation is 👍

[jamesray1]

@fubuloubu some discussion here: ethereum/EIPs#956

EIP website and automation: ethereum/EIPs#940.

[jamesray1]

For an update from Drops of Diamond, I'm working on the SMC in Vyper, and @ChosunOne is working on a CLI, with functions for the proposer and collator, and interfacing with the SMC. I'm also reviewing the latter, and will work on Rust development once the SMC is ready. We have tasks to do outlined in the issues and projects. https://github.com/Drops-of-Diamond/diamond_drops

[krtschmr]

Just a quick headsup: The Monero network upgrade dropped a lot of hashrate. Even tho a few legit miners forgot to update (they are coming back currently) the network will end up dropping approx 60% hashrate.

Now it's time to shine for Ethereum

[B5m3M]

I'd just like to hear about the Casper testnet. I see that it's still not working properly, and there seems to be an issue since 1 month - the issue was mentioned last meeting.

Setting up a node for me is impossible, I'm not sure about others?! I often feel like that progress is far behind the talks/hearings of the Ethereum team. There are endless talks on youtube about Sharding and Casper - I think you should concentrate rather on what is developed as of now and what is possible to do now, instead of having all these future/visionary outlooks.

Thank you, I'm looking forward to hear your pov.

[Souptacular]

@B5m3M your concerns will likely be addressed during the meeting.

[jamesray1]

I think the discussion on the max cap was interesting, I think the points in favour of a max cap outweigh the points against it, e.g. the proposed implementation is simple with putting funds from the pre-sale in a contract and using that as a reference for the max cap to calculate fees.

Thanks for the mention! We've also discussed having a DAICO and were seeking feedback on that. https://www.reddit.com/r/ethereum/comments/8a76a4/seeking_feedback_on_holding_a_daito_decentralized/. I'll consider putting recorded meetings publicly but I'll talk to the other two collaborators, @ChosunOne and @ltfschoen about that first. We have a Gitter lobby for discussion: https://gitter.im/Drops-of-Diamond/Lobby.

What's the timeframe for the casper TFFG hard fork? I know it's hard to say and there are testnet issues, but you suggested putting off Constantinople changes into Casper.

[pipermerriam]

the proposed implementation is simple with putting funds from the pre-sale in a contract and using that as a reference for the max cap to calculate fees.

I missed this part, can you dump that here?

[jamesray1]

@pipermerriam https://youtu.be/SoPfoNpqG0k?t=4297. For others, the start of the discussion was around here: https://youtu.be/SoPfoNpqG0k?t=3620.

We basically just premine maxcap - current_eth_supply into some particular address and this could be address 0. Whenever we're paying rewards we subtract the balance in ETH from that account and that account's remaining balance is used as the constant multiplying factor.

[CryptoBlockchainTechnologies]

Please see my new thread I have started asking all GPU miners to unite in a ETH mining boycott next week.

https://www.reddit.com/r/ethereum/comments/8ab31z/calling_all_gpu_miners/?ref=share&ref_source=link

As you have heard the Ethereum Foundation developer team decided that the ASIC mining is not a threat. They have ignored the overwhelming community support to make a change to prevent ASIC mining. It appears Vitalik is more concerned about saving his legacy of having developed a successful ASIC resistant algorithm instead of protecting Ethereum. The proposed change was very small and could have been completed in a few weeks with very little interruption to the development team.

In response to this inaction we are calling on all of the GPU miners to unite from 4/9/2018 until 4/13/2018 and switch to mining another coin. If enough miners stop mining Ethereum during this time it will only leave the ASIC miners in control of the network.

This is a standoff now between the ASIC miners and the GPU miners. The Ethereum Foundation does not see ASIC mining as a threat, let's call their bluff and see if they are right. Now is the time to stand together as a community. #NoETHGPUMining

[jamesray1]

@CryptoBlockchainTechnologies your comment is very misleading. The general consensus was not to have an immediate hard fork as there is no immediate threat of a 51% attack. The miners aren't super efficient. We could include EIP 969 or maybe even a better proposal that the community comes up with into the next hard fork (maybe Constantinople, or maybe those changes will be rolled back until Casper TFFG), with other changes.

[ChrisIDEA]

Smart Contract Miners.

[ChrisIDEA]

what about Plasma Cash?

[mohsenghajar]

I think since Casper + new reward calculation are going to be in one hard fork, the supply cap can go with them also as it shows good synergy.