since it is a month from now ... updates on Constantinopel?

since it is a month from now ... updates on Constantinople?

Yes, this meeting will be 3 months after Byzantium, and it would be sweet talk about Fork Release Management again. We discussed earlier that we don't want to start too late talking about EIPs.

In the short term the main issue is if and how is it possible to improve the ethereum database in order to try a bigger max gas limit per block without getting so much uncle blocks. I suggest to continue to discuss this topic until tests will be fully performed and eventually solutions will be founded.

I have been getting a lot of inquiries from my Crypto-community about the POW to POS change with Ethereum. The miners are the most concerned. Could you elaborate on this change, will it happen, when, and why? Several have considered selling their cards now to prevent getting caught in any flood when the change happens.

It will be a gradual swap right?

I agree with @RSAManagement point. Ethereum network is clogged again, and a short term fix is necessary while Constantinople is implemented

I'd like to hear you guys talk a bit about...

1. The Stateless Client Development
2. WASM with regard to
   EVM 2/wasm 105 EIPs#48
   Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN EIPs#174
   EIP-615: Subroutines and Static Jumps for the EVM EIPs#615
   (Maybe Christian has some insight into that)
3. Decision Process on EIPs

Thank you for this open discussion and ethresear.ch so we can participate and get involved.

Edit: Sorry, I referenced the EIPs
Edit 2: After the live stream - Thank you so much guys for discussing this topic - Helped a lot.

I'd like to hear you talk about ethereum/EIPs#603
Our opinion is that privacy on Ethereum is too expensive.

We've developed a ring signature privacy solution in Mobius

With a ring size of 4 it costs 600k gas to Deposit and 3 million Gas to Withdraw, given that the block Gas limit on Ethereum is 3,141,592 (π million) this would have to be spread across multiple blocks and could significantly disrupt other transactions (similar to CryptoKitties) if any privacy technology gained significant popularity.

to the agenda - introducing miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined)

Hallo I find this very interesting discussion on reddit:
https://www.reddit.com/r/ethereum/comments/7pfshh/why_is_8m_gas_causing_so_many_uncles/?st=jcal6fxo&sh=2b52fb4e
It seems that the 2 most important miners pool do generate 51,8% of the blocks and only 12% of the uncles.
There could be 2 reasons:

1. big pool have better hardware/node setups
2. big pool have better propagation route for the blocks they mined

The first issue is already in disucussion, the second issue could be mitigate by a sort of worldwide ethereum relay network. A proper set of high performance, widely interconnected nodes.

We know that the foundation set some bounties to boost some specific scaling methods for ethereum, I do think that build an high performance ethereum relay network could be very helpful to small miners with the final scope is to mantain decentralization. So I propose to set up similar bounties to run one or more relay network and to research how to build the better possible network in term of costs and efficency.

It's questionable whether I'll be able to directly participate in the meeting (though I'll be attempting to listen in). My updates for python-land.

• Implementation of full node sync in py-evm is underway.
• Initial foundation for running py-evm as a stateless client.
• Implementation of simplified Ethereum Gas Station pricing algorithm in progress for web3.py.
• Preparation for alpha release of the py-evm based client.

I assume someone from the research team may give an update on sharding with more details, but sharding research and development continues.

@RSAManagement I suspect those two big miners simply connected their nodes directly using "addPeer", so they propagate new blocks directly to each other.

I would generally oppose encouraging specialised relay networks, because the end effect would be that the network will be more like a concentrated ring of miners and periphery, rather than more like a mesh now. And that would be bad for small independent miners, because if they are not part of the club (or ring), they end up on the periphery, and their blocks are more likely to be uncle-d.

I think it is absolutely urgent to improve the propagation speed every time we see congestion like this, so that the miners have no incentive creating such a ring-relay network. The longer we keep the network a mesh, the healthier ecosystem we will get

1. There have been major issues with transaction propagation out of node with high throughput (infura, Bittrex, etc) I would love to hear if any one has any insight on what could be causing this. See this tweet as one example, but this has been an on going issue over the past month.

Also

2. Updates on scaling, will we see any scaling improvement from Constantanople? Are there going to be any improvements because of CasperFFG? (I expect not in either case but worth asking) I know Plasma and Sharding are far from being implemented.. but would love to hear guesses (best case, worst case) on time frame for any scaling improvements. Many dapp devs have come to the conclusion that the main chain is not able to host their DApp because of gas costs. We are looking to build sidechain solutions to bide our time until we see some further improvements here, but would love to hear your input.

ruffct/stringct implementation I mentioned during the meeting, the paper is still WIP but the implementation follows our latest work: https://github.com/monero-project/research-lab/tree/master/source-code/StringCT-java