Ethereum Core Devs Meeting 52 Agenda about pm HOT 48 CLOSED

I'm all for progpow, as I've already said, and in Oct/Nov I hoped to get it into Constantinople when we pushed C into January. However, that would have been only if we had gotten all things working in November, and had a testnet running since then. With the changes to specs and the testnet only up for a few weeks, I think trying to squeeze it into Constantinople would be reckless. I hope to see it accepted, and ideally rolled out within a few months.

I don't think we should wait 9+ months and bundle it with other things. I think this bundle-all-the-things into megaforks is counter-productive.

from pm.

Now, that Constantinople is finalized, I would propose a rough schedule for a subsequent protocol upgrade (a.k.a. "Istanbul"?):

• 2019-01-16 (Wed) projected date for mainnet-hardfork ("Constantinople")
• 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul"
• 2019-07-19 (Fri) soft deadline for major client implementations
• 2019-08-14 (Wed) projected date for testnet-hardfork (Ropsten, Görli, or ad-hoc testnet)
• 2019-10-16 (Wed) projected date for mainnet-hardfork ("Istanbul")

That breaks down to a fixed 9-months cycle to release protocol upgrades accepted prior to the hard deadline in May to mainnet. All proposals accepted after that date should go into a subsequent hardfork nine months later.

Action items for the call:

• Shall we go with a fixed release cycle in the future?
• Are nine months sufficient, or maybe too ambitious?
• Are we calling it "Istanbul"?
• ref karalabe/eee#5

from pm.

Regarding ProgPoW here is a summary of the current status (to my knowledge) of the development efforts:

• Parity and Geth have pending PRs that add support for the ProgPoW algorithm
• There are two distinct CUDA & OpenCL open source miner implementations: https://github.com/AndreaLanfranchi/ethminer and https://github.com/EthersocialNetwork/ethminer/
• On the 11.12.2018 a ProgPoW testnet titled Gangnam has been launched which successfully transitioned from Ethash to ProgPoW on block 3000
• The testnet stalled during the first ProgPoW epoch transition. The root cause for this issue was that the only active GPU miner on the network was using an outdated miner that crashed during the epoch transition. The issue was already fixed on a more recent version. Since then the testnet completed 3 additional epoch transitions without any problems.
• ProgPow support was added to Open Ethereum Pool (an open source ethereum mining pool) https://github.com/gangnamtestnet/open-ethereum-pool.
• Verification benchmarks: A well-optimized implementation should end up being about just 2x slower than the ethash verification as there is twice as much data read per iteration. (source ethereum/go-ethereum#17731 (comment))

Please feel free to amend the list in case I forgot something important

from pm.

Just for sake of precision :

• https://github.com/hackmod/ethminer is quite behind
• @hackmod most recent implementation is https://github.com/EthersocialNetwork/ethminer/ which is also based on my work.
• My implementation is continuos WIP and going through optimization phase.

Worth to mention that with my work ethash and progpow live together nicely sharing the same dag data and smoothly switching from one algo to the other.

from pm.

If ProgPoW is well prepared can't we just enable them on Constantinople Hardfork period with other EIPs? GPU miners wouldn't be able to earn profits with 2 ETH block reward without anti-asic implementation. ( See https://eips.ethereum.org/EIPS/eip-1588 )

from pm.

@naikmyeong You do realize that every light client that does some kind of PoW- Verification has to implement ProgPoW? I haven't seen any implementation (except for Aletha, Parity and Geth) that does it. Additionally every node on the network has to be updated with the new software, every mining pool and every miner. This in itself is already to complicated for a two week timeline. I would therefore also propose a small hardfork with ProgPoW and Stratum 2.0 in mid 2019.

from pm.

From Gitter

Peter Pratscher @ppratscher 10:27
As the gangnam ProgPoW testnet is running smoothly since a few weeks & the mining ecosystem is maturing (open source implementations for cuda & opencl are more or less done, claymore (the dev of the most widely used closed source gpu ethash miner) has also confirmed to add ProgPoW support to his miner) I think it would be a good time to finalize the discussion if Ethereum should switch to ProgPoW during the next core dev call?

Thanks, ideally a go/no-go decision would be the best outcome, including a rougth timeline if it is a go

from pm.

Don't anybody hold your breath for 'Official EF' approval/reject. Don't think there's any such thing

from pm.

I'm calling for a gangnam stress-test day. We could make threads on various forums. If miners want ProgPow they have to provide test data (which they will love to do) so development can be done faster and potential bugs can be detected.
Almost no info is out about it, no wonder gangnam has onyly had 30 MH/s.

What's currently the best & easiest miner?

I'm also calling for a separate mini-POW-HF in 1-2 moths if everything can be concluded in January.

thanks for the great effort devs

from pm.

If ProgPoW is well prepared can't we just enable them on Constantinople Hardfork period with other EIPs?

Constantinopole hard-fork is scheduled for January 16.
There is no chance we can possibly do all the tests for ProgPoW in such a short amount of time.
Yes gangnam test network is working but :

• it's too small (at the time of writing only 10 nodes have announced)
• too low hashrate (31 Mh/s is one rig !!!)
• among major pools only Bitfly has actively participated

We still need to :

• test consensus on high number of nodes (the increased evaluation time of solutions have an impact)
• be sure all major pools and mining implementations do not face any problem on a large chain (1 million blocks at least)
• we have tested on very few epoch changes and periods
• test (with miners that can support algo switching) a simulation of fork
• and lots of other things ...

from pm.

@AndreaLanfranchi I appreciate your comment, but I would also argue that, we already had a plenty of time and now is Jan. 2019, regarding this EIP it has been more than 7 months of development, QA, etc.

Since ProgPoW already have it's testnet I strongly suggest to enable ProgPoW with Constantinople.

from pm.

Friends, this is obviously an important topic to many of us, but this is not the right forum for debate. This particular thread is intended for planning this Friday's meeting, not for in-depth discussion or debate about individual topics. Scrolling through dozens or hundreds of messages makes Hudson's and my life difficult as we need to review everything to plan for the meeting--it makes it hard to find relevant stuff among all of the messages.

I think the Fellowship of Ethereum Magicians forum is a reasonable place to continue the debate--would one of you like to open a thread there instead? Feel free to post the link here if you do. Thanks.

from pm.

I think the Fellowship of Ethereum Magicians forum is a reasonable place to continue the debate--would one of you like to open a thread there instead? Feel free to post the link here if you do. Thanks.

@lrettig I don't think we need an additional forum post for discussion, what I want is that we have an agreement that ProgPoW is being shipped with Constantinople Hardfork. And please read them all cause this requires us to determine miner's life and their decision,

I do agree that the ProgPoW fork should happen as quickly as possible after Constantinople to keep miners happy. Making it a small focused hardfork will make the roll out easier. There are no changes to the protocol that can cause consensus issues as far as I understand, making the ProgPoW HF possibly safer than the Constantinople one is.

@salanki Yes and it must be shipped out without a delay. core clients are 100% ready and there is no reason to hesitate, especially when we are close to next issuance reduction 😂

from pm.

Doesn't matter, Constantinople is final. You are free to propose it for a subsequent hardfork.

from pm.

And since we are 2 weeks before constantinople I believe we can decide go/no-go of constantinople this time.

Give up any hope to see progpow shipped with constantinopole.
There is no time !

from pm.

@holiman his code is perfect and works well. 👍 Apart from delivering ProgPoW with Constantinople, I applaud his efforts. 👏

ProgPoW is great and can be used somehow. New HF is also possible.

from pm.

@naikmyeong from one miner to another, please take a step back and understand the situation here. EIP-1234 was discussed and a decision was made to include it in Constantinople. No amount of arguing, begging or convincing will change the Constantinople hardfork. Pulling a hard-fork two weeks before it goes live to add a new feature would look really bad on Ethereum. You don’t add features last minute in a project like this.

Let’s get together and focus our energy on giving ProgPoW the testing it needs and get a ProgPoW hard-fork scheduled before Istanbul. @AndreaLanfranchi listed a number of things that we can help with. More nodes, more miners on the test net.

I do agree that the ProgPoW fork should happen as quickly as possible after Constantinople to keep miners happy. Making it a small focused hardfork will make the roll out easier. There are no changes to the protocol that can cause consensus issues as far as I understand, making the ProgPoW HF possibly safer than the Constantinople one is.

from pm.

@MariusVanDerWijden I agree, even with everything prepared right now we do not feel confident in switching our pools to ProgPoW in just a two weeks time frame. A small & focused ProgPoW fork in mid 2019 will give the mining ecosystem sufficient time to prepare.

from pm.

@5chdn With EIP-1234? Lol it will cause more than 30% of nethash drop, I am very concerned of the future of ethereum....

from pm.

And since we are 2 weeks before constantinople I believe we can decide go/no-go of constantinople this time.

Recent price drop has caused more hashrate drop than that. And still ethereum PoW is more than secure. Difficulty will adjust as a consequence.

By banning all miners you mean, there will be no GPU miners left on the mainnet

from pm.

@ppratscher I would suggest a new carbon vote for community about shipping constantinople hardfork along ProgPoW, does it makes sense?

from pm.

If the problem is on empty blocks and no QAs, why didn't we enabled ProgPoW on Ropsten instead of creating a new, small testnet?

Just like Constantinople, ProgPoW is fully tested on various ways and it has more than 90% coverage on mining pools & miner softwares and I believe it is ready to roll. ( By using ( Progminer and Ethereum ProgPoW node yes )

Right now implementation of ProgPoW is a matter of time if we decide to enable them on this meeting and I believe miners & community will be on our side of fork. ASIC manufactures will only lose the war if we do.

from pm.

Sure,

You keep self referring to your developments and products.

This is the only working product that I can qualify , it is 100 open source and being served as a fully compiled binary so non-developer users can use them and mine without additional knowledge

The reference miner for ethereum is Claymore's (like it or not) be sure there will be no switch until he/she is ready

That is what we call centralization, we had genoil and now we have ethminer which is fully verifiable, open source and no dev fees, it is not good to serve Claymore a 1% fee from total reward supply ( otherwise he will be a wealthiest dev on earth lol (

Users are lazy and go only for copy and paste: not enough documentation around about new algo and best settings for NVIDIA and AMD.

Miners also care for their revenue, they will learn and try the new settings if they need ( the only thing we need is a proper CS for them )

ProgPoW will "limit" advantage of ASIC: it won't cut them off

ASICs maniplate the network and I think it will be much better if we can separate them to different chain, and at the end they will die with their deprecated chain without selling to anyone 😂

Ropsten had its problems too few months ago: and luckily it was a testnet

Shouldn't we oppose the hardfork for Constantinople also since it didn't passed the so called "massive use" test? 😂

Here is the graph of total nethash and the testnet works without a single problem from epoch switch or nethash reduction

Someone built gangnam network on a voluntary basis - as well as the developers like me implemented the mining software. But there is no official approval of ProgPoW by the EF

EF is the biggest participant of Gangnam testnet and I've heard we had some support by them according to @ifdefelse

I believe you overestimate the numbers. We're no where near to 90% coverage.

I was wrong BTW, it is 100% since we can upgrade the full ecosystem of POW ( Node, Mining Pool, Mining Software ) , what else do we need?

from pm.

This is not a political decision, this is just impossible in the Ethereum hardfork process. I pointed that out earlier in this thread. Please respect that.

Like we did for DAO, EIP-150, and EIP-158? I am not here to make a political decision, I just want to let EF and Core developers know the current problem regards of hash drop and the necessity of ProgPoW, if miners know that there is no ProgPoW with Cons,t I bet they will find the other way to survive 😂 I don't want to see that happen so that's why I am here.

Of course other softwares can follow the roadmap but, we've our core software prepared already that is the important fact of my proposal.

from pm.

Let me take some notes here

Arg.1 Although we had plenty of time with the development of ProgPoW ( 7 months since the announcement of algo & 3 weeks from testnet launch 😂 ) we can't enable them since it is not "tested on real life" and it is not ready since we already have core clients ready but we didn't prepared for "all the other clients" but we did some bug-patch hardforks without them 😂

Arg.2 We didn't prepare for the side-effect of Constantinople and EIP-1234 although we already know there is an asic miner available for ethereum and EIP-1234 will make the situation worse than ever and will allow Mr. Wu's invasion toward ethereum network more easily.

Arg.3 And ProgPoW is likely to be rejected now and afterwards since there will be no GPU miners left to support the fork after they are being bankrupted by asics and the central bank decision to cut the mining rewards without convincing them

Am I right? @vbuterin @5chdn @Souptacular @ppratscher @AndreaLanfranchi @holiman @cryptozeny Do you think so??

from pm.

@naikmyeong from one miner to another, please take a step back and understand the situation here. EIP-1234 was discussed and a decision was made to include it in Constantinople. No amount of arguing, begging or convincing will change the Constantinople hardfork. Pulling a hard-fork two weeks before it goes live to add a new feature would look really bad on Ethereum. You don’t add features last minute in a project like this.

Let’s get together and focus our energy on giving ProgPoW the testing it needs and get a ProgPoW hard-fork scheduled before Istanbul. @AndreaLanfranchi listed a number of things that we can help with. More nodes, more miners on the test net.

I would tell you that your argument here doesn't makes sense, we already had like 7 months of development, testing, ETC. Major miner clients like Claymore and Ethminer's adoption of ProgPoW is on the track and I don't think it blocks the reason of enabling progpow on mainnet, What the problem really is that GPU miners wouldn't survive after Constantinople without ProgPoW, since we've our issuance reduction and according to @5chdn it may be impossible to revert them, If we lose 30% of GPU miners there will be only 30% of GPU miners and 70% of ASIC miners left on the mainnet and I don't want to see my transactions being censored behind the great firewall of china 😂. If you are not a part of Jihan's troll army we should ship ProgPoW with Constantinople together.

from pm.

Could someone review/merge ethereum/EIPs#1642 please?

from pm.

@naikmyeong You do realize that every light client that does some kind of PoW- Verification has to implement ProgPoW? I haven't seen any implementation (except for Aletha, Parity and Geth) that does it. Additionally every node on the network has to be updated with the new software, every mining pool and every miner. This in itself is already to complicated for a two week timeline. I would therefore also propose a small hardfork with ProgPoW and Stratum 2.0 in mid 2019.

More than 90% of clients on ethereum mainnet use Geth / Parity and I don't care the light clients since we already had some forks without caring them and if we block this fork we definitely will lose our war toward Ethash Asics and the army from Mr. Wu. Since Geth / Parity is ready for ProgPoW I assume this is the right time to fork ProgPoW and ban those chinese miners who are trying to manipulate the one-gpu-per-one-vote. ProgPoW should be considered as a vulnerability patch of ethash and we need this asap. Please give some priority on network centralization issue and I believe we can find a way to survive from this ASIC trolling. Personally Stratum 2.0 is not my favor and I expect majority of nodes and clients can prepare for the ProgPoW till next week.

@MariusVanDerWijden I agree, even with everything prepared right now we do not feel confident in switching our pools to ProgPoW in just a two weeks time frame. A small & focused ProgPoW fork in mid 2019 will give the mining ecosystem sufficient time to prepare.

Do you mind of the decrease of your pool's miners ? A small & focused ProgPoW fork wouldn't work after ASICs ban all GPU miners and being a majority hash 😂

from pm.

Being constantly upgraded you can't suggest ethminer from Andrea 😂

from pm.

ps) node is being ready on https://ethereumprogpow.com and we already have our miner implementation on https://github.com/gangnamtestnet/progminer/releases

from pm.

@naikmyeong yes that's the creation time ... but I remind you that it's never been officially accepted.

from pm.

Lol it will cause more than 30% of nethash drop

Recent price drop has caused more hashrate drop than that. And still ethereum PoW is more than secure. Difficulty will adjust as a consequence.

from pm.

Give up any hope to see progpow shipped with constantinopole. There is no time !

We are not giving up any hope for ProgPoW shipped with Cons.t hardfork,

We just want our profit back when we had no asics on ethereum mainnet.

EIP-1234 is very friendly fork for ASIC manufactures since it will REKT GPU miners due to low profitability and we hope ProgPoW will be an only solution for network decentralization and prevent miners leave the ethereum network so we can have our strong foundation of network security.

Here is the screenshots of the miner;s need of ProgPoW bundled on Constantinople hardfork.

I'm all for progpow, as I've already said, and in Oct/Nov I hoped to get it into Constantinople when we pushed C into January. However, that would have been only if we had gotten all things working in November, and had a testnet running since then. With the changes to specs and the testnet only up for a few weeks, I think trying to squeeze it into Constantinople would be reckless. I hope to see it accepted, and ideally rolled out within a few months.

I agree, however this is the problem with profits and I recommend to exclude EIP-1234 otherwise include ProgPoW as an alternative reward plan to GPU miners, without ProgPoW bundled with EIP-1234 it will be only disaster with GPU miners and I expect more than 30% of ethereum miners will be bankrupted.

from pm.

@naikmyeong I share your enthusiasm and passion.
Nevertheless reality is another thing.

I've personally spent a lot of work in implementing ProgPoW into ethminer as well as @holiman in modifying geth and I would like too to see ProgPoW implemented ASAP.

But let's face the truth: no real life test has been performed until now. Gangnam test network is only proving there is 1 miner (or two) working in bundle with a modified (unstable labelled) version of geth and parity which are mininig 99.9% empty blocks.

We have no transactions, not many nodes to share consensus, there are no rigs mining (at the moment of this writing the overall hashrate is 42Mh and my test rig alone is producing 36Mh).

This is not an appropriate test over a chain which holds value for almost 16 billions USD.
Can you imagine what if something goes wrong ? Something we're not imaging as we haven't undergone the heavy stress tests ?

Let's be honest.

At current prices we're at almost double revenue than 1 month ago. Reward cut-off will hit both GPU miners and ASIC miners but be sure will hit harder on the ones who overinvested.

ProgPoW will come, I'm pretty sure ... but not within 15 days.

from pm.

You keep self referring to your developments and products.

I had to learn a few things the hard way:

• The reference miner for ethereum is Claymore's (like it or not) be sure there will be no switch until he/she is ready
• Users are lazy and go only for copy and paste: not enough documentation around about new algo and best settings for NVIDIA and AMD.
• ProgPoW will "limit" advantage of ASIC: it won't cut them off
• Ropsten had its problems too few months ago: and luckily it was a testnet
• Someone built gangnam network on a voluntary basis - as well as the developers like me implemented the mining software. But there is no official approval of ProgPoW by the EF

from pm.

ProgPoW is fully tested on various ways and it has more than 90% coverage on mining pools & miner softwares

I believe you overestimate the numbers. We're no where near to 90% coverage.

from pm.

I like your enthusiasm but I stop here as no one can convince you.
January 16 is too near. Hope the absolutely certain release of Costantinopole without ProgPoW won't leave a too bad taste in your mouth.

from pm.

Sorry ... I meant the Core Devs team.
Up to last public meeting there was NO decision about that.

from pm.

what else do we need?

You cannot expect the entire ecosystem to drop dead in their tracks just to squeeze in a last minute feature you personally desire as soon as possible. Two weeks are not enough to create releases for a dozen different clients, to inform the community of the new available versions, and make sure everyone upgrades their infrastructure. This is not a political decision, this is just impossible in the Ethereum hardfork process. I pointed that out earlier in this thread. Please respect that.

If you want to see that proposal activated on mainnet, you have time till mid May to get this accepted by the community and the core developers.

from pm.

@lrettig where do I get dial in info for the call tomorrow?

from pm.

@annavladi I'll add a YouTube streaming link here shortly. The Zoom call details will be posted to the Gitter channel https://gitter.im/ethereum/AllCoreDevs just before the call.

from pm.

YouTube livestream link: https://www.youtube.com/watch?v=iSc3TbjZu1k

from pm.

@acceleratornetwork No worries 😄

from pm.

@5chdn should/shouldn't EEP-5 be merged with https://eips.ethereum.org/EIPS/eip-233 ?

from pm.

My final request to Ethereum Foundation to ship ProgPoW with Constantinople Hardfork

https://medium.com/ethereumprogpow/my-final-request-to-ethereum-foundation-to-ship-progpow-with-constantinople-hardfork-9a41bf216906

from pm.

Thank you devs!

from pm.

See you in two weeks #70

from pm.

@MoneroCrusher The newest miner is https://github.com/AndreaLanfranchi/ethminer
It can mine both ethash and progpow and can seemlessly switch between algorithms

from pm.