Ethereum Core Devs Meeting 49 Agenda

[lrettig]

Ethereum Core Devs Meeting 49 Agenda

Meeting Date/Time: Friday 9 November 2018 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Livepeer Stream Link

Constantinople Progress

Agenda

1. Testing
2. Client Updates
3. Research Updates
4. Constantinople/Ropsten HF
   • hardfork timing 1, 2
   • difficulty bomb
5. ProgPoW update
6. Ethereum stratum/mining pool support
   • updating the eth_getWork RPC API with a 4th return value for the block number (@karalabe)
   • EthereumStratum 2.0.0 draft (@chfast)
7. Görli PoA-testnet progress (@5chdn)

[lrettig]

As discussed on today's call, we'll skip the call in two weeks due to DevCon. The next call will be in four weeks, on Nov. 9.

[olalawal]

So miners even on testnet are ignoring the fork? No suprise there
https://ethereumworldnews.com/ethereum-hard-fork-test-goes-awry-no-constantinople-in-2018-developer-says/

Without an algo change I can’t see why ANY non asic miner would accept the fork.

I suspect on mainnet this won’t be and issue since most of the hashrate is heavily centralized witsh asics anyways.

Glhf at devcon

[olalawal]

How is that off topic when its in reference to the failed fork on Testnet ?

[lrettig]

This is not the right place to talk about the testnet hard fork. This issue is for the agenda for the next core devs call. https://ethereum-magicians.org is probably a better place.

[5chdn]

@olalawal you are probably looking for #61

[olalawal]

@5chdn aye , I was as well but still wanted some visibility here as well.

[Shadowfiend]

Question: is there a place where discussion about ProgPoW and when and how it will be released is occurring? Couldn't find anything specifically about deployment in ethereum-magicians, but I know there were some discussions of an additional hard fork after Constantinople.

Asking, of course, as I'm looking to see where EIP-1108 might be slotted in. Happy to bring it up in this next dev call if that's the more appropriate place to discuss it.

[mdaria510]

If hashpower is what you need to properly test progpow next session, I’m happy to contribute a few rigs to the effort and whatever other assistance I can provide.

[aj07]

I would like to participate in the discussion if https://ethereum.karalabe.com/talks/2018-devcon.html#1 team is available. I am curious how, this is happening. and if possible I would like to contribute.
@karalabe Would you please share some thought on this.

[karalabe]

Quoting from my Twitter:

Ethereum was created by rockstar developers. If we want to expand its reach, we need to switch layer 0 over to engineering. To start, I'd like to propose the Ethereum Engineering Effort https://github.com/karalabe/eee (I'll move the repo if there's traction). Curious what you all think!

To better explain what I'm dreaming this could become, I've also added a PoC #Ethereum Engineering Process (EEP) for rolling out consensus updates without breaking everything https://github.com/karalabe/eee/blob/master/eeps/eep-1.md. The other obvious immediately documentable EEP would be the EIP process.

I've been pondering about such a system for a while now. I'm not sure this is the right format, neither am I sure if the community really wants it, but thought I'd bring it up as a proposal that we can debate.

This is something the Ethereum Magicians should steward if there's traction; I definitely won't have time to do it, but wanted to create a starting point so everyone's on the same page.

[karalabe]

Based on mining pool requests, I'd like to propose updating the eth_getWork RPC API (https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getwork) with a 4th return value for the block number.

The rationale is that more advanced miners (Geth and Parity) not only create a single mining package per round, but recreate the block multiple times when some events trigger (new uncle, high value tx, etc). From the outside however, it's impossible to decide whether a new mining work invalidates the old one (new block), or is just an alternative (better block). This is problematic for mining pools because they don't know whether to give rewards for those shares or not.

By adding a fourth parameter returning the block number too, pools can fairly accurately decide if a mining work completely replaces the old one or is just an alternative to it.

Parity already does this, and Geth will ship the next version like this too. Might as well update the specs altogether.

---

eth_getWork

Returns the hash of the current block, the seedHash, boundary condition to be met ("target") and the block number.

Parameters

none

Returns

Array - Array with the following properties:

1. DATA, 32 Bytes - current block header pow-hash.
2. DATA, 32 Bytes - seed hash used for the DAG.
3. DATA, 32 Bytes - boundary condition ("target"), 2^256 / difficulty.
4. QUANTITY - current block number.

Example

// Request
curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getWork","params":[],"id":73}'

// Result
{
  "id":1,
  "jsonrpc":"2.0",
  "result": [
    "0x645080cd2bffef917f7a1260d8da54b929193250d243d0f138481fd6480f7b3a",
    "0x0000000000000000000000000000000000000000000000000000000000000000",
    "0x000010d00eb60cdf4b4361daf59f96eba40e2f8c699adc6780da90bf3ea756d2",
    "0x1"
  ]
}

[5chdn]

4. I suggest we aim for Wednesday, January 16, 2019, at 12:00h UTC which would be around block 7_083_314 for the mainnet hardfork. Just putting down the number here, so we have some base for discussion.

5. If time permits, I would like to give a quick update on the Görli PoA-testnet progress. http://ethstats.goerli.ethberl.in:3000/

[holgerd77]

I think there should be at least one successful fork on a shared testnet before going to mainnet with Constantinople. Not sure if this can be the new Goerli ("Görli", I am so afraid of this "ö" in this name 😄) testnet, probably Afri can give more insight on that.

Another option might be to deprecate the coming-to-ages Ropsten testnet and take the occasion to setup a new PoW testnet and do another test fork there.

If this is a viable option (can't completely judge the overall effort needed to get this in place + communicate this), I would like to make the following adopted timeline suggestion:

December 10th (Monday), 2018:
Start of a new PoW testnet, deprecate Ropsten

January 16th (Wednesday), 2019:
Fork on the new testnet

February 12th (Tuesday), 2019:
Fork on mainnet

[chfast]

About ProgPoW: There are ongoing development efforts to have CPU implementation for verification / test mining in C++, Go and Rust. We are facing some problems: the spec is still being changed and the reference implementation does not produce any test vectors to compare against.