Ethereum Core Devs Meeting 22 Agenda

[Souptacular]

Ethereum Core Devs Meeting 22 Agenda

Meeting Date/Time: Friday 8/11/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.
   • EIP 649: Difficulty Bomb Delay and Issuance Reduction overhaul progress [Afri]
   • Should we defer EIP 96 [Casey]
   • Is EIP 86: Abstraction of transaction origin and signature the only thing going into Constantinople? [Hudson]
     b. Updates to testing.
     c. Details and implementations of EIPs.
     1. Updates from client teams.
        • geth - consensus, core/*: metropolis features go-ethereum#14337
        • Parity - Byzantium release openethereum/parity-ethereum#4833
        • cpp-ethereum - [META] Byzantium implementation progress aleth#4050
        • 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 215 Bitwise shifting instructions in EVM EIPs#215: Bitwise shifting instructions in EVM to replace EIP 145 [Alex B.]

Please provide comments to add or correct agenda topics.

[bitsbetrippin]

Confirm no discussion on backing the difficulty bomb out during this meeting? It's becoming a hot topic for our audience and I would like to give them the latest on this update. Trying to understand the point of leaving the current function of the difficulty increase artificially raising difficulty when you guys have reset expectations of POS until a later date. The difficulty function should of been disabled asap as it was predicated on POS and that associated initiative with Casper. All that is happening now is continued disincentivize without the POS feature. Recommend restoring difficult to be based on network hash power as it has been since Sept 2015. The artificial increase of difficulty function was designed to disincentivize mining and move people over to POS during the required hardfork, which makes absolute sense, however your delay in Casper should delay/pause this effect.

After the next difficulty adjustment Ethereum by and large will no longer be worth the effort mining if difficulty raises at its current rate. The jump on August 1st most seen a 15-20% increase to network difficulty, the next 20% increase driven artificially will nearly put a nail in ethereum in a sub top 3 to PoW mine. I understand your development position is probably not concerned with these matters after following the EIP#649 discussion thread as it were ...however speaking on behalf of a YouTube channel that gets nearly 500k unique views a month on the GPU mining scene, there are a lot of concerned miners on the way this is being handled. If we could better understand your rationale by keeping the difficulty bomb in play, even though you have shelved POS until 2018, we can help get the message out on why. Help us, help you get the message transmitted.

[Souptacular]

@bitsbetrippin
This topic has been discussed in previous core development calls and there are a number of EIPs on the topic. The latest EIP should be this: ethereum/EIPs#669

The topic is discussed in many core dev calls and was discussed call 20 or 21 iirc.

I would love feedback from miners directly, but so far I have not received much negative feedback (or much miner specific feedback at all) in the Reddit threads and EIPs relating to the matter. The major Ethereum mining pool operators I've talked to seem to understand our roadmap and realize the difficulty adjustment changes, why we are extending the ice age, and the eventually of at minimum a hybrid PoW/PoS system which will hopefully transfer into a full PoS system. I'd love more participation and perspective on the subject and the most ideal way would likely be for miners to coordinate to develop an official position that can be posted in the latest EIP thread regarding the difficulty bomb.

[bitsbetrippin]

@Souptacular Thanks for the quick reply. We will review EIP 669 and see where we can contribute to the discussion. From our perspective, we are not going to 'tell' you guys what to do, however ask the very basic question that has been not directly answered.

The difficult bomb is a function with a specific purpose to wean miners off POW in POS implementation. By and large I believe the community understands this and have expected it for a long time. There are a few reasons I believe why you haven't seen any major feedback from 'miners' in general, by comparison to lets say a 'Bitcoin' Miner community. For the most part, Ethereum has a significant distribution of actual individual miners (thousands, potentially tens of thousands) contributing hash power to potentially hundreds of pools (yes, we understand there are 20 or so major pools, with several that have large % of pooled hash power. Because of the distribution, the 'voice' of any one particular miner's perspective may not seem to representative of miner consensus. That being said, you have asked for miner contribution and we will put that message out on our channel that you guys are wanting clear, concise and constructive feedback.

All of that being said, the one thing that does not make sense is this:

Assuming everyone understands what was previously pointed out -Statement: Difficulty Bomb = Based on notional schedule of POS implementation.

If that statement is true, then the moment you guys decided to slip the POS date, a new notional Difficulty Bomb schedule should of been implemented immediately. I.E.

Difficulty Bomb (1 May Execution) -> (Late fall of 2017)
Now with a delay, this schedule should be reset to the same 90-100 day range that the new notional target is. I.E. let the network go back to hash power predicated difficulty. Let market demand/mechanics run the difficulty; not artificial arbitration when the feature of POS is delayed.

Bottom line, people by and large understand and respect the movement to POS, by and large most also understand and also respect the method to wean people off the network with the difficult bomb. That being said, if the POS is delayed, most people do not understand why you would leave the diff. in play as it artificially penalizes individuals mining for no direct reason that was previously discussed. Changing the terms mid course without explaining why you would leave it in play without implementing POS disenchants the community. Market forces will predicate hashpower applied to the network and the built in retarget of difficulty adjust accordingly. I.E. if people are earning a specific amount of ethereum through mining and price goes up, more people get involved which by design raise the difficulty to keep block time locked in as close to its designed rate. Additionally new technology coming out drives more distributed investment for hardware (digital arms race).

Covering a quick rationale of why there would be a slow roll on removing is the burning question. Thanks again for your guy's efforts and we will contribute on the main thread going forward.

[5chdn]

This topic has been discussed in previous core development calls and there are a number of EIPs on the topic. The latest EIP should be this: ethereum/EIPs#669

I'm now overhauling the draft for EIP 649 (in 669) to include/replace ethereum/EIPs#186.

[cdetrio]

I'd like to consider the option of deferring EIP 96 (Blockhash refactoring). EIP 96 is unique in several ways that make its specification, implementation, and testing more complicated than other EIPs:

• The blockhash contract is a novel interface, unlike all existing precompiles and opcodes.
• No existing precompiles have storage, nor do they execute EVM bytecode.
• Calls to the blockhash contract through the BLOCKHASH opcode are unique from calls to all other contracts through the *CALL opcodes. This introduces behavioral edge cases, e.g. that calling the blockhash contract does not increase the call stack depth, or that the call's gas does not contribute to the transaction's gas.
• SUPER_USER calls to a contract at the beginning of a block are an entirely new type of state modification. Currently all state modifications are from transactions or from the coinbase reward; the SUPER_USER call to the blockhash contract is an exception.

In terms of development progress, it seems that EIP 96 has lagged behind (perhaps due to the above factors). As recently as yesterday, improved versions of the contract are still being proposed. Deferring EIP 96 would allow time for further improvements, not to mention testing. And it would expedite the schedule of Byzantium, by reducing the scope.

Additionally, when EIP 96 is completed, the primary benefit is that it will enable more efficient and secure light clients. But that will require an update to the LES specification and implementation, and such an update has not yet begun. So even if EIP 96 were adopted immediately, it would not benefit light client users for some time.

[chfast]

About EIP 96: BLOCKHASH:

1. Bug: insufficient argument value check: Create blockhash_refactoring.md EIPs#210 (comment).
2. Deploy with complete contract state of previous block hashes, avoid 256 block warm up period. Create blockhash_refactoring.md EIPs#210 (comment)
3. Unit tests for the contract: EIP-210: Add BLOCKHASH contract tests EIPs#641, test case for bug 1: ethereum/EIPs@47f6160.
4. Avoid duplicated block hashes being stored: EIP-96: Avoid storing duplicated hashes EIPs#643.
5. Do not use arbitrary gas cost, charge the actual call cost. https://github.com/ethereum/EIPs/pull/210/files#r132653212.

[timxor]

About EIP 198: Create bigint_modexp:

1. It would be great to have more clarity about the remaining requirements for Issue 185: Benchmark modexp precompiled contract in different clients and what remains to be done so we can close this issue up.

cc: @Souptacular @pirapira @holiman @arkpar

[axic]

@Souptacular sorry I didn't mean to pick up 663 in this call again, so it can be removed from today's agenda.

[axic]

Is EIP 86: Abstraction of transaction origin and signature the only thing going into Constantinople? [Hudson]

@Souptacular on the last call we considered EIP215 (bitwise shifting) to be part of that.

[Souptacular]

Closing: https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2022.md