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 36 Agenda #36

Closed
Souptacular opened this Issue Mar 23, 2018 · 25 comments

Comments

Projects
None yet
@Souptacular
Copy link
Member

Souptacular commented Mar 23, 2018

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

This comment has been minimized.

Copy link

danfinlay commented Mar 23, 2018

The live stream link only links back to this issue.

@oberstet

This comment has been minimized.

Copy link

oberstet commented Mar 29, 2018

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

This comment has been minimized.

Copy link
Member

pipermerriam commented Mar 29, 2018

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

@RSAManagement

This comment has been minimized.

Copy link

RSAManagement commented Mar 30, 2018

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.

@ButtaTRiBot

This comment has been minimized.

Copy link

ButtaTRiBot commented Apr 2, 2018

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

This comment has been minimized.

Copy link
Member Author

Souptacular commented Apr 5, 2018

@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

This comment has been minimized.

Copy link
Contributor

AlexeyAkhunov commented Apr 5, 2018

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

This comment has been minimized.

Copy link
Contributor

jamesray1 commented Apr 5, 2018

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

@fubuloubu

This comment has been minimized.

Copy link
Member

fubuloubu commented Apr 6, 2018

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

@Souptacular

This comment has been minimized.

Copy link
Member Author

Souptacular commented Apr 6, 2018

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

@Souptacular

This comment has been minimized.

Copy link
Member Author

Souptacular commented Apr 6, 2018

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

@fubuloubu

This comment has been minimized.

Copy link
Member

fubuloubu commented Apr 6, 2018

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

Automation is 👍

@jamesray1

This comment has been minimized.

Copy link
Contributor

jamesray1 commented Apr 6, 2018

@fubuloubu some discussion here: ethereum/EIPs#956

EIP website and automation: ethereum/EIPs#940.

@jamesray1

This comment has been minimized.

Copy link
Contributor

jamesray1 commented Apr 6, 2018

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

This comment has been minimized.

Copy link

krtschmr commented Apr 6, 2018

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

This comment has been minimized.

Copy link

B5m3M commented Apr 6, 2018

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

This comment has been minimized.

Copy link
Member Author

Souptacular commented Apr 6, 2018

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

@jamesray1

This comment has been minimized.

Copy link
Contributor

jamesray1 commented Apr 6, 2018

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

This comment has been minimized.

Copy link
Member

pipermerriam commented Apr 6, 2018

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

This comment has been minimized.

Copy link
Contributor

jamesray1 commented Apr 6, 2018

@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

This comment has been minimized.

Copy link

CryptoBlockchainTechnologies commented Apr 6, 2018

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

This comment has been minimized.

Copy link
Contributor

jamesray1 commented Apr 6, 2018

@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

This comment has been minimized.

Copy link

ChrisIDEA commented Apr 6, 2018

Smart Contract Miners.

@ChrisIDEA

This comment has been minimized.

Copy link

ChrisIDEA commented Apr 6, 2018

what about Plasma Cash?

@mohsenghajar

This comment has been minimized.

Copy link

mohsenghajar commented Apr 7, 2018

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.

@lrettig lrettig closed this Apr 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.