What has to be done to get ProgPoW on Ethereum

EIPs
,
1

  1. The ProgPoW OpenCL and CUDA implementations have to be integrated to ethminer as the second PoW algorithm next to Ethash.

  2. One of the stratum protocols must be modified to include information about the mining algorithm. I believe that fixing the block number when the switch will happen is too risky, especially when the mining workers do not receive the block number, just the epoch seed hash.
    For that I propose modifying the EthereumStratum by NiceHash. I think the new spec deserves a separate EIP.

  3. Also the “getWork” JSON-RPC based protocol should be modified to include the information about algorithm. This is the language (sometimes the only one) many Ethereum clients speak.

  4. The ProgPoW verification code must be added to many libraries, including:

2 Likes
2

About point 2 the fixing of block number is not only “risky” … it’s impossibile.
ethminer is an ETHASH miner thus allowing mining on any “Ethereum like” chain (ETC, ELLAISM, PIRL etc).
Only options are

  • either integrate the work notification payload with the required algo (on the fly switch)
  • or provide ethminer with a new cli argument to start mining on specific algo (cold switch)
3

Yes, I had some kind of “cold switch” in mind. E.g. ethminer --progpow-from-block 9000000 or ethminer --ethereum-mainnet.
But it still looks much more messy that receiving this information from a pool.
Besides, having a stratum protocol capable of switching algorithms is not bad by itself.

I mostly wander how chains like Monero or Bitcoin Interest did this.

4

If mining NiceHash, unless they provide a specific port for ProgPow, it’s mandatory to have algo signalled in stratum notification.

5
  1. ProgPOW stratum and getWork implementation must be implemented to one of the following open source mining pool implementation

And yes I think merging different stratum specification into 1 will be a good idea :smile:

6

Bitcoin Interest brought the entire network down for almost a day.

This sounds like a miserable idea, but would it be possible/how hard would it be to have a window of 5,000 blocks where both algos were in effect - so the network could slowly transition instead of a simple drop dead point for the algo.

Regarding the open source pool code, I have had the OEP software developer do custom builds for us in the past (including the recent Parity rpc convention change). As soon as there is a spec, we can work with him on implementing it.

7

If you guys need different hardware to test, let me know and I can provide.

1 Like
8

Where can we actively follow the improvements being made? There is a big chunk of the mining community dependent on this progress. Please inform me/us.

9

Hello everyone,
I’ve finished writing the official specification for ProgPoW.
It is still not peer-reviewed, so we need a bit more time until its finished.
The specification can act as a starting point for core developers to implement ProgPoW for their respective client.

Feedback would be appreciated!

greetings, Marius

10

Hi Marius,
The spec doesn’t clearly state the license it and the code it includes is under. It would be really useful to explicitly state that and ensure that the license is very permissive - EIPs typically use CC0 which would be ideal.

Thanks,
Adrian.

1 Like
11

What needs to be done as of today? Do all the needed clients have working implementations so that a ProgPoW hard fork can happen today?