Pm: Ethereum Core Devs Meeting 54 Agenda

[Souptacular]

Ethereum Core Devs Meeting 54 Agenda

• Meeting Date/Time: Friday 1 February 2019 at 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream Link
• Livepeer Stream Link

Agenda

1. Roadmap
   a) Constantinople - Ropsten fork?
   b) Istanbul Hardfork Roadmap
   c) Outlook: PoS finality gadget on PoW chain (Serenity)
   d) ProgPoW audit?
2. Working Group Updates
   a) Ethereum 1.x Stanford Meetings Overview
   b) State Rent
   c) EWasm
   d) Pruning/Sync
   e) Simulation
3. Testing Updates (time allowing)
4. Client Updates (time allowing)
   a) Geth
   b) Parity Ethereum
   c) Aleth/eth
   d) Trinity/PyEVM
   e) EthereumJS
   f) EthereumJ/Harmony
   g) Pantheon
   h) Turbo Geth
   i) Nimbus
   j) Mana/Exthereum
5. Research Updates (time allowing)

[lrettig]

For the record, this is my recollection of how we arrived at 7.28M, feel free to tweak if I've gotten anything wrong:

1. @vbuterin suggested six weeks, which he said would put us around block 7.25-7.3M.
2. A couple of folks including myself asked if we could do it sooner, but the consensus was that we wanted a bit more time for updating tests, maybe rolling out on a new testnet, etc.
3. @5chdn proposed Feb. 27, which falls on a Wednesday, and also happens to be during a quiet week between ETHDenver and EthCC.
4. I used a simulation script to look at predicted block times and numbers, with the latest block height, difficulty, and timestamp. All of the details were shared to AllCoreDevs, starting here.
5. I did sensitivity analysis on network hashpower and current average blocktime. Based on this analysis I expect block 7.28M to occur between 00:00 and 09:00 UTC on 2019-02-27, the target date,

@naikmyeong we agreed that it makes sense to target upgrades to occur mid-week so it's more likely developers will be online and so that people aren't forced to work weekends.

[5chdn]

1. March 1 is a Friday
2. Epoch does not matter
3. It's decided already

[RSAManagement]

I made this reddit post:
https://www.reddit.com/r/ethereum/comments/aiy5ns/uncle_rates_more_node_efficiency_or_less/
and this spreadsheet:
https://docs.google.com/spreadsheets/d/1SZn6_MuOciDI_B20KqqeHtpK9yAhHIgGdpVH-SDLRnU/edit?usp=sharing

because I'm seriously worried and scared about how uncle rates are going down.
Uncle rates are going down linearly since mid 2018, so it is hard to say that is because of more efficient nodes, one of the most important bug in this area was fixed just recently ( parity client, #9954) .

So i think that the problem is more and more centralization on the ethereum blockchain for two reason:
1) falling price in fiat currency (less minig reward in fiat currency)
2) asics mining

The first issue is something that could be adjusted by economic incentives (disincentives) given enough time BUT if we are experiencing ( and I think so) a massive switch on asics mining every single day with ethash is very dangerus for the future of the entire project as a truly decentralized blockchain.

In my opinion the ProgPow (or other asic resistant algos) implementation actually is the most important issue by far, even far more the important CostantiNOPEles saga. Please take it in consideration.

[5chdn]

Could you elaborate how you connect uncle rates with ASICs?

[RSAManagement]

@5chdn sure, I know in deep a medium sized mining farm with a good ( i think) efficiency and actually they are in the position to quit ether mining or swich to asics, .
I think that the actual reward/difficulty ratio for GPU mining is telling that there are more and more players that are mining with "better" hardware than GPU only and thatthis GPU unconfortable enviorment started with asics arrival on the market, not only because the price drop.
I'm sorry because I can't produce in deep analysis with numbers and clearly the actual low ether mining reward for GPU miniers could be just temporary.
In my experience Asics are the foundation of big centralized mininig farms, expecialy if there is one or two producers/miners/stakeholders, bitcoin is an example of what I mean.

Big miners are more efficient, they use professional or custom services for transactions and new blocks propagation, I suppose that how the actual uncle rate is dropping is directly related with more centralizzation over big mining farms that are using asics mining.

[5chdn]

Big miners are more efficient

But we would see their hashrate somewhere, and I don't see any significant portion that could be a new ASIC mining farm here:

• https://etherscan.io/stat/miner?range=7&blocktype=blocks
• https://etherscan.io/stat/miner?range=7&blocktype=uncles

If these farms use some of the existing pools, I don't see how this should impact uncle rates.

The five biggest unknown miners from that chart that could be indeed mining farms, accounting for 4.1371% of the network hashrate. This does not allow the conclusion that they are the main driver behind reduced uncle rates.

[RSAManagement]

The five biggest unknown miners from that chart that could be indeed mining farms, accounting for 4.1371% of the network hashrate. This does not allow the conclusion that they are the main driver behind reduced uncle rates.

Good point, so we can speculate that the linear uncle rate reduction is because of:
1) better blocks and transaction propagation because of better propagation services used by mining pools.
2) better blocks and transaction propagation, and faster DB handling because of better nodes topology.
3) less medium sized or little GPU miners

I don't know how many asics farms are connected with pools so I can't give any opinion on it, but in my experience point 3 remain an issue. Anyway I would be really glad to be wrong.

[bmann]

I'm not sure when / where to put this on the agenda, so please let me know if there is a better spot for this,

I worked to support @AlexeyAkhunov in putting together a post-Stanford EthRoadmap AMA on Feb 6th. See https://ethereum-magicians.org/t/eth-roadmap-ama-webinar-feb-6th-8am-pst-1700-utc-1/2518 for details. Consider this a call for participation, I think @AlexeyAkhunov is talking to some of you about presenting.

Given the shifting schedules of Constantinople / Istanbul, is it useful to plan ahead for the rest of the year and start making plans for any in-person meetings? I have suggested an in-person meeting the day after ETHCC in Paris here https://ethereum-magicians.org/t/eth1x-istanbul-prep-meeting/2396

I realize that's only ~6 weeks from now, so tight timing that may not be worth it. If people want to plan further ahead, I'd be happy to help support the process.

[atlanticcrypto]

I'd like to directly refute RSAManagement's claims here.

The uncle rate has been dropping substantially due to pre-fork adoption of new Parity/Geth client versions across the network. It was a blanket rollout of the better block propagation technology over a short window of time. It is not driven by some special "better propagation services used by mining pools" - the competitive technology advantages you believe exist at the large miner level are big foot sightings. You would be embarrassed at the way many of these firms/facilities operate.

I'm not sure how lowered uncle rates is a scary thing - it theoretically increases total network throughput via lowered block times and higher miner reward per block.

[salanki]

I second @atlanticcrypto's experience. I attribute lower uncle rates to better client code and less gas per block than during the peak a year ago.

[AndreaLanfranchi]

I'm quite surprised next agenda does not include any discussion about possible PoW algo change.
My personal feeling is that a considerable audience of individual miners is awaiting for a clear statement whether this path will or won't be considered as a future implementation: the no-committal attitude experienced until now is, imho, damaging the image of ethereum.
Any statement (for or against) must be quickly achieved: any decision is better than this hanging around.
My two cents.

[Daft-Wullie]

I second the opinion expressed by @AndreaLanfranchi in the post above.
I personally like ProgPOW but at this point i feel like what most hobbyist miners like me who do it mostly to support the network want more than anything is clarity on this issue. Even if ProgPOW is deemed non viable it should be evaluated in the near future.

[AndreaLanfranchi]

Apparently there is a deliberate intention no to face the matter.
Originally ProgPoW topic was in agenda and then silently removed.

[Souptacular]

Some of us already said in the previous meeting that we shouldn't be the ones making the decision because it is political and not technical. I'll add it back so I can potentially outline the 3rd party audit we are organizing.

[Daft-Wullie]

Thanks @Souptacular that is much appreciated altho i don't understand how it is a political decision since the goal and rationale for being asic resistant is enshrined in the ETH Whitepaper.
Personally i would not mind a rejection of ProgPoW on technical grounds(lack of testing, diverting too much dev resources, CPU verification taking longer etc) but i'm kinda flabbergasted by how special interests groups are manufacturing a false sense of contentiousness about the end goal of progpow.
Still a comprehensive 3rd party audit is a welcome initiative.

[AndreaLanfranchi]

Thank you @Souptacular for your comment. At least we know (now) that some kind of auditing is going on.
This, nevertheless, in my very personal opinion, tombstones any value in AllCoreDevs meetings and related streams: they're becoming only a report on the current status on "researches" most people (unless highly skilled) don't understand.
I (mistakenly) thought the team had decisional powers (like eg. for issuance reduction) but apparently this matter has greatly involved powerful lobbies.
What disturbs me is the lack of clarity and consistency.

Thanks anyway.

[gcolvin]

We seem to have no established social practices for making "political" decisions. From my point of view politics is about coercion. It's what a community resorts to when it can't achieve consensus but doesn't want to "fork".

[AndreaLanfranchi]

@gcolvin Wasn't the issuance reduction a "political" decision ?

[gcolvin]

I felt like a central banker afterwards.

[AndreaLanfranchi]

@gcolvin Like it or not also in this case you will feel uncomfortable. Either you decide in favour, or against or do not decide at all.

[gcolvin]

@AndreaLanfranchi I agree. I understand there were technical reasons for the issuance reduction, but they were beyond my expertise. Unless there are technical reasons to prefer GPUs over ASICs it's a difficult decision for us to make. But someone has to make it.

[AndreaLanfranchi]

@gcolvin

But someone has to make it.

You nailed it !
All I am saying it's a waste of time to delay further. A go or no-go are needed now. An audit process will take months to complete trying to establish fixed points of reference on economies and power balances which are changing day by day, hour by hour. As said elsewhere act NOW (in favour or against) ... do not promise an action will be taken "in future" ... this is no decision at all and keeps miners hung by their fingers to wishful thinking.

[jean-m-cyr]

@gcolvin

But someone has to make it.

Who then? The position EF is taking, that it will only exercise technical influence, seems untenable. Any grouping of more than two individuals will include 'politics'.

[AndreaLanfranchi]

@jean-m-cyr

here is the response
https://twitter.com/hudsonjameson/status/1090643066556420096

[salanki]

An audit process by a 3rd party is supported by the community and a good idea. Much like the issuance reduction however the decision to change PoW needs to come from the ETH devs. Decisionmaking can’t be outsourced to a third party.

[holiman]

Decisionmaking can’t be outsourced to a third party.

I agree. I think it's a decision we need to make. We should take in all available signals, discuss until all questions are answered and until people feel they know what they need to know -- but the decision needs to be made, we can't just keep postponing it.

[OhGodAGirl]

One of the things that has been most baffling to me is how we come to consensus in the Ethereum ecosystem. Isn’t the point of mining to vote with your hashpower? If the community does not mine on the ProgPoW chain, they will not support it. They will not switch to it. That’s it. That’s how you let the community vote: you put it in, and the longest chain wins.

Proof-of-work was engineered to put an end to the stress of consensus. You simply let people vote - with their hashpower. ProgPoW could be initiated and application developers simply build on the longest chain.

We’re reinventing consensus mechanisms again.

One GPU. One vote.

Food for thought.

[AndreaLanfranchi]

That would be a chain split. I think we should all try to avoid it

[OhGodAGirl]

The chain splits anyway. Hence a fork. But the longest chain is adopted by the network, and the users and developers keep using and building on that chain.

Ethereum is an ecosystem of developers. It is up to the developers to decide what they support. The users will follow the developers.

[gcolvin]

@cartercarlson

I haven't seen many developers vocally support ProgPow that don't somehow directly or indirectly benefit from it

The discussions I've seen here have had far more to do with centralization, the health of the network, and the original intent of ETHHash. It's not clear that these factors are strong enough to outweigh all the others. The fact that GPU vs. ASIC has financial consequences for miners is part of makes this decision so hard.

Ethereum's end goal is PoS

vs.

1. c) Outlook: PoS finality gadget on PoW chain (Serenity)

Someone please tell me if I'm wrong, but PoW isn't going away any time soon. If it's going away eventually I'd like to know when and how.

[AndreaLanfranchi]

The road to PoS is still long. As correctly reminded PoW isn't going to disappear anytime soon.
Due to this PoW must be protected to prevent any dominance by specialized hardware manufacturers cause the power they may gain could be used in future to stop the migration to PoS.
Any dominant position, by its nature, fights to keep the status quo

[Sonia-Chen]

An audit can add methodical rigor that is lacking: environmental impact / power consumption, fairness between Nvidia and AMD chips, exclusion of Chinese miners, business motivation of authors (main supporter being CTO of a large farm whose major customer is coingeek), verification slowdown (loss of computational asymmetry), claims of ASIC resistance.

Disclosure: We currently work on an upcoming Ethash machine (launched at ETC Summit), and have conflicts of interest in any PoW discussion. We are happy to contribute our thinking. Strong leadership/governance should take control of this issue and find the best solution with largest community support. We are fairly predictable: We make chips (machines) whenever there is a paying customer, and we think that adds security to the network.

[MoneroCrusher]

With regards to ProgPoW I believe I got a great idea for which I'm crafting an EIP for (if IfDefElse don't support it in their official ProgPoW).
I trust that the ProgPow devs know that ProgPow will break all current ASICs.

However there are still two problems:

1. HBM ASICs will very likely resurface
2. Objectively speaking, it will favour Nvidia if we take status quo as baseline that has billions of investments in AMD infrastructure (which is controversial to say the least)

My solution makes

1. Economically less- or even uninteresting
2. Decimate that problem completely

Solution:
Take ProgPow and deploy it in a 3-step process which is _very_ easy with its few lines of codes and easy reprogrammability.

1. Introduce ProgPow_v1 ASAP, but only with 10-15% additional core utilization in comparison to Ethash. This will brick all current ASICs and still keep AMD as the majority infrastructure as it currently stands (and how it has been the past 5 years)
   Also introduce

PROGPOW_PERIOD: 50 -> 5 or 10
PROGPOW_CNT_CACHE: 12 -> 11
PROGPOW_CNT_MATH: 20 -> 18

And equalize the x3 /x4 difference in 32 bit mul in Nvidia/AMD GPUs with the potential solution suggested by OhGodAGirl, as recognized even by herself, favours Nvidia as it currently stands.

1. In the Istanbul HF introduce ProgPow_v2 but with 25-35% additional core utilization in comparison to Ethash
2. In the HF after Istanbul introduce ProgPow_v3 with the current proposal of core utilization.

Given Ethash's memory hardness, ASICs likely wouldn't get created for the 10-15% batch because they'd have to be taped out & ROI'd until Istanbul HF which is impossible. Likely also not for the 25-35% batch, but with a higher likeliness put into production with the final ProgPow specification, meaning even if ASICs get created, GPUs will have at minimum a full year of better cost-effectiveness than potential ASICs. This slow-ramp up also creates further risk for ASIC producers as they never know for sure how the next (or final) fork really is going to end up (and tweaked). Higher risk of business means smaller chance of ASICs.

Additionally the slow ramp-up in power would allow for farm owners to plan in more power and do their upgrades over time. An overnight increase like ProgPow_v3 does is a strain on many network owners' instrastructures and many people would likely hit or get near their installed power limits. Unfortunately this solution still increases power, but at least newly released devices will get more efficient at solving the same problem. People have time to make hardware adjustments, doing an overnight switch from one architecture to another would cause a rapture in the Ethereum community.

With the laid out plan you will get majority support of the network. In the beginning it will be very much like Ethash, aligning itself with the majority of the current network infrastructure, over time with each fork, GPUs with stronger compute replace the older cards that are now still viable but will not be anymore anyway by the time that will happen, so it's really a win for everyone this way, except for ASIC manufacturers,

[gcolvin]

@OhGodAGirl

Ethereum is an ecosystem of developers. It is up to the developers to decide what they support. The users will follow the developers.

Yes. We generally can't afford to develop multiple versions of multiple clients and let the hashpower decide. So the developers have to decide what to develop somehow. And in the end it's people who decide what to do with their hashpower anyway. It takes a community of developers, users, and more to keep a blockchain up and running, so choosing not to go with what the developers decide is a big risk.

@Linzhi
I'd love to have that information. Soon. I'm probably not alone. So failing a full audit, whatever it is you already know or surmise.

@AndreaLanfranchi
Yes, PoW must be protected, but I don't think anyone is expert enough in economics and psychology to know for sure what the effects of ASICs now would be on PoS later. But I think we can make a call soon, and change it later if the effects aren't good.

My call would be ProgPoW, and @MoneroCrusher just made it seem easier, but I'd defer to those more knowledgeable. That is, I wouldn't block consensus either way. I'd suggest we take the Yes/No/Over-My-Dead-Body poll tomorrow morning to see how far apart we are _before_ further discussion.

It would be nice if someone else could make the call, but as of now there isn't anyone else. I'd love to see a better way to develop community consensus, but until then we are the dictators, and should try to be benevolent. Refusing to decide is not a viable option.

[AndreaLanfranchi]

@MoneroCrusher agree with all your plan but please stop saying AMD has to be kept the king in ethash mining. The objective of ProgPow is to level all GPUs.
If there's a king to be kept then we don't need to do absolutely nothing and keep the status quo. AMD mining will die due to ASICS anyway

[MoneroCrusher]

@AndreaLanfranchi I'm not saying this just like that, but because with a big change like that you want to align with the majority and not the minority of the network, so it goes as smoothly as possible.
Check current GPU distribution on Ethos, the most used mining OS amonst hobby miners:
http://ethosdistro.com/versions/
It shows AMD is around 70% of the network in this sample.

 101970 Radeon RX 470
  82663 Radeon RX 580
  59013 Radeon RX 570
  25701 P104-100
  21628 P106-100
  19602 GeForce GTX 1060 6GB
  18516 GeForce GTX 1070
  15059 P102-100
  13915 Radeon RX 480
   8828 GeForce GTX 1060 3GB
   7525 GeForce GTX 1050 Ti
etc

I agree that older GPUs will get phased out over time - like I mentioned in my post - but let it happen more naturally and not in one swift move, if you want to have a happy community.

[AndreaLanfranchi]

As I said. We're trying to reduce gap but exactly for the numbers you exposed AMD will keep their position for two reasons. First is numerical, second is the fact that forking out ASICS they will benefit as a consequence even if some Nvidia catch up. There is no loss on AMD due to ProgPow

[MoneroCrusher]

What I'm implying is that going straight for ProgPow_v3 dramatically increases the likelihood of a contentious hardfork. Therefore phase it out like I proposed and let Moore's law make its bid.
Everyone would profit from that, including all Nvidia and all AMD miners.

Then you got an even playing field afterwards and you know what you'll have to expect with each new HF and you get time to make your hardware adjustments and planning over a span of approximately 2-3 years. ProgPow does not offer that ability to the average Joe miner. A phased-out ProgPow would.

[AndreaLanfranchi]

We don't have 2 or 3 years of PoW on eth. Maybe 1 and a half

[AndreaLanfranchi]

Anyway I'm not pushing for this technicalities. What I would like to see is a go or no-go now

[gcolvin]

@AndreaLanfranchi

We don't have 2 or 3 years of PoW on eth. Maybe 1 and a half

What do mean? That PoW will stop working if we don't do something?

[AndreaLanfranchi]

I mean that as soon as Casper has a definitive schedule then difficulty bomb will trigger anyway and will ice any PoW algorithm still in place

[MoneroCrusher]

1. We don't know that. Personally I believe we won't be on PoS in 12 months to 18 months.
2. Assuming it does get implemented within 12-18 months and if the EF and ETH core devs are environmentally conscious, then a simpler fork that bricks current ASICs would be the correct solution in that case and that doesn't unnecessarily waste 5256-7848 GW/h (that's a mid sized nuclear power plant running on full steam for 200-300 days, https://en.wikipedia.org/wiki/Clinton_Power_Station) because ASICs won't re-takeover the network en-masse given the current market circumstances, implying a "hardcore" solution like ProgPow_v3 (+50-60% power) would not be necessary for such a short period.
   But of course 5256-7848 GW/h wouldn't just appear out of thin air, what ProgPow_v3 coupled with the imminent reward reduction would do is instantly centralize all hashing power into the hands of dozen-Megawatt farms with plenty of cheap electricity that your average Joe miner doesn't have.

Anyways, I still stand with ProgPoW + V1-V2-V3 phase out plan, as it's technically easily feasible and GPUs get more efficient over time (just look at the 7nm Radeon 7) and even if PoS gets implemented within 12-18 months, then so be it, the two do not contradict eachother and it doesn't negatively affect any GPU miner. Additionally it gives everyone time to plan things out should PoS take longer than the 12-18 months, and not leave everyone behind except for corporations that have dozen-Megawatt installations.

The only people that I think would be against this would be people that got all excited for their Nvidia GPUs being instant-hash-kings on the originally proposed ProgPow.
The grand majority of GPU owners would favour a phase-out. So in that sense, go with the flow.

[gcolvin]

I'm ignorant, @AndreaLanfranchi but if the PoW chain is iced what is the point of staking ETH on it?

[AndreaLanfranchi]

Sorry @MoneroCrusher but I can't stand all this Nvidia/AMD debate anymore. You don't understand there will be no king at all if no action is taken.

[MoneroCrusher]

I didn't say to take no action.
I say take action and implemented ProgPow in a reasonable 3-step phase-out that is technically very easily achievable and also reaches the same goal but will get overwhelming community support and will therefore be much easier implemented than plain vanilla ProgPow - governance & political wise.

This is the most sensible and fair approach to all parties. And I spent _a lot_ of time thinking about this lately and how to come up with a solution that will please all parties except for ASIC manufacturers.
This is it.

[AndreaLanfranchi]

@gcolvin this is the plan to force migration to Ethereum 2.0

[AndreaLanfranchi]

@MoneroCrusher
You won't get any overwhelming support from the community of miners as long as they're focused on fight each other without understanding the enemy is elsewhere.
They're already dying and only care about the fact AMD is more or less penalized.
This is kind of palm face

[MoneroCrusher]

@AndreaLanfranchi My proposed solution is vendor neutral. Please re-read my posts if that doesn't crystallize.

[gcolvin]

@AndreaLanfranchi

this is the plan to force migration to Ethereum 2.0

I'm ignorant. _What_ is the plan? Last I checked (two minutes) the beacon chain depends on the 1.0 chain. You have to stake ETH on it to become a validator. If 1.0 is iced how can you stake and what do you have at stake?

[atlanticcrypto]

My two cents:

https://medium.com/@brianventuro/saving-ethereum-why-i-stand-behind-progpow-b4679c3089dd

[holiman]

That would be a chain split. I think we should all try to avoid it

I don't know. I think it may be the ideal solution at this point. So,

• If we make sure not to bundle the progpow switch with anything else,
• And agree on a block number,
• And make sure that both Geth and Parity have releases that are capable of switching to progpow at the given block number,

Then let the world decide. At this point, I personally feel that we've already had all the discussions, and it's about time to progress.

I'm not saying that we shouldn't do an audit, the more eyes the better, sure, but I don't have any illusions that an audit will settle any debates or even make a decision easier.

Also, regarding an audit, what is to be audited?

• The technical sanity of Progpow over Ethash?
• Cryptographical analysis of progpow hashing algo in general?
• The feasibility of building progpow in specialized hardware?
• The security of GPU-mining versus specialized hardware-mining?

My point is, there are so many different aspects being discussed, and an audit will only focus on one of these points -- hence why I don't think it will settle anything.

[AndreaLanfranchi]

@gcolvin I'm not saying 1.0 will be iced. Proof of Work on 1.0 will be iced.
Difficulty bomb will drive the transition from PoW sealing (which will become so difficult to be practically only a waste of of electricity) to PoS sealing. Thus the stake on 1.0 has reasons. Blocks will continue to be chained but will be sealed under different rules.

[ASICseer]

All current proponents of progPOW fail to understand these two points:

1. The original proponents of any proof-of-work change will stand to benefit if they are well-prepared to take advantage of it. ProgPOW was first proposed in May of 2018, and it has been 8 months since then. This is plenty of time for the original proponents to develop secret mining optimizations for it, for which the rest of the ecosystem is not privy. This means that, if progPOW is activated, they will be able to spin up optimized farms very quickly. Note that, even though the algorithm is open source, it does not mean that optimizations cannot be made for it. Remember that scrypt, x11, and equihash all had neat little memory-hardness tricks that were supposed to stop ASICs, but they didn't. Which leads me to my next point:

2. Either the original proponents of progPOW (ifdefelse) are stupid (Scenario A), or they think YOU, the listeners are stupid enough to believe their lies (Scenario B). There is simply no room for anything else.

Scenario A: Even though the last 6 years of history has shown that cute little memory-hardness tricks fail to stop ASICs, the progPOW team thinks that they are so smart that they've thought of every single nuance, every single caveat, every single way, for their algorithm to be exploited. Somehow, they are different from every other team. And you know, maybe there are. But, that is extremely unlikely and especially unlikely given that 2/3rds of the team are anonymous with absolutely no track record. We can't verify their previous work even if we wanted to.

Scenario B: The progPOW team is actually smart, so smart that they've already figured out how to optimize hardware for their algorithm, and are spinning a bunch of populist/socialist platitudes to get their algorithm adopted so they can profit off it. You may say, "progPOW is open source", but open-source is not a great argument. All previous algorithms for which ASICs were developed were also open source. If an algorithm change occurs on a popular coin, the secret sauce is in hardware, not software.

[AndreaLanfranchi]

@gpushack what you are missing, imho, is ProgPoW is not an algo. An algo, strictly talking, is a collection of finite operations which repeats itself over and over again. ProgPoW is more a process which creates a new algo for the next 50 (or 30 or 10) blocks. It's an automated way to implement what other "ASIC resitant" efforts try to do with scheduled algo changes every x months.
The advantage of software over hardware is that is immensely faster to change while hardware needs to be re-engineered, industrialized and delivered.

Memory hardness is enforced in Ethash/ProgPoW on behalf of same DAG while it adds computational randomness (though deterministic) to the hash function so every component of a commodity GPU can be fully utilized.

On the other hand we already know there are ASIC manufacturers which have gone beyond the trouble of memory hardness and will optimize further in near future thus the "battle" of "who profits more" is already lost.

[ASICseer]

@AndreaLanfranchi please excuse my saying so, but the fact that you can't figure out how hardware designers may optimize hardware for progPOW speaks more to your lack of competence in this field than in those same designers' ability to do what you say they can't.

[AndreaLanfranchi]

@gpushack mind my words. No one, literally no one ever said it is absolutely impossible to develop an ProgPoW ASIC. It is possible but there are a few caveats: your hardware will end up being more and more like a GPU and (not irrelevant) the time to delivery of such hardware will completely void it's utility.

As @holiman already said ProgPoW won't be eternal as we all know PoS will be the final target.

Question is : do we want to spend the remaining time (till PoS will be alive) allowing the proliferation of specialized hardware thus cutting off all gpu miners (which are an important ethereum userbase) or do we prefer to try keep them as loyal supporters ? It's a simple answer to this question I am pushing for.

I'm fine with an acceptance or a denial ... but please let's stop this hanging around.

[MoneroCrusher]

@AndreaLanfranchi

@MoneroCrusher agree with all your plan

So you are not against a 3-phase deployment of ProgPoW, that gives all users time to adapt to changes, did I perceive that correctly?
Let's go the path of least resistance.
@IfDefElse @OhGodAGirl Would you support it? If yes, let's get ahead and get unified community consensus, if not, please describe - from a technical standpoint that everyone understands - why it wouldn't be possible.

[AndreaLanfranchi]

@MoneroCrusher I'll try to be as clear as possible.
I totally do not understand (my limitation for sure) the point of "allowing users to adapt changes". If it is meant to a sort of "let's keep a Rx480 to be hashrate comparable to a 1070 (instead of a 1060 - which is actually the league those cards are in)" we're all (devs and implementers) trying to do our best to reduce the gap.

@ifdefelse already posted a proposal here for reducing compute to the minimum possible while ensuring that every mix[] destination gets written to (this is a constraint).

Also in my recent commit the problems about bogus periods on AMD/OpenCL has been solved and there is a further slight improvement on AMD hr.

This said ... a roadmap of 3 soft-forks which have to happen in the limited amount of time left before PoS is IMHO a total waste of time and resources.

Forgive my brutality but things are this way: either GPU users want and accept a single change (optimized at maximum possible extent in very short time for both major vandors) now or let's all stop any research and or development on this and stop wasting time on a thing that causes too much troubles and suspects. In my opinion it's up to GPU users to choose the lesser of evils.

If I was an AMD miner I'd choose to see improved revenues from the forkoff of ASICS instead of whining for Nvidia catching-up.

[MoneroCrusher]

Now you're doing exactly what you accused me of, comparing "whining" AMD owners to Nvidia, can you please stop this? Are you unpartisan in this, as you seem yourself wanting to appear?

My 3-step approach is vendor neutral. You do realize what 60% additional power implicates? You know that the Clinton Nuclear Power Plant took over $4.25 billion in funds to get realized? ProgPoW would represent exactly 50-60% of that, applied to the current Ethereum network.
Do you believe 60% additional power will just appear out of thin air, "just plug it into the socket"? No, power is very expensive to install, and instantly doing a 60% power increase will not bring back mining to hobbyist miners and small farms, it will instantly centralize the majority of hashing power into 10+MW farms that have plenty of cheap electricity available and that were planned ahead to have much more power available than needed.

What do you say to a user that has installed the maximum amount of GPUs that they can run in their home (let's say 50 GPUs) and now suddendly power increases by 60% and they can't use a large chunk of their GPUs anymore, because they don't have enough electrons available?

@ifdefelse already posted a proposal here for reducing compute to the minimum possible while ensuring that every mix[] destination gets written to (this is a constraint).

This is for ProgPow_v3. What I am saying is reduce the math in here https://github.com/ifdefelse/ProgPOW/blob/9eec52772cf7b0da99aa08a94eda9c7b6451e730/libprogpow/ProgPow.cpp#L213 to +10-15% (compared to Ethash) in a fork ASAP tagged ProgPoW_V1, then in the Istanbul HF increase core operations to +25-35% of Ethash tagged as ProgPoW_V2 and in the HF after Istanbul implementent the final ProgPoW specification tagged as ProgPoW_V3/final.

This allows users to periodically upgrade their hardware to more efficient hardware that uses less energy (like 7nm litography enables them to) or increase the power output of their electrical installations over time.
An instant ProgPoW_V3 implementation would instantly kick of many users off the net and centralize it into megafarms with cheap power.

This said ... a roadmap of 3 soft-forks which have to happen in the limited amount of time left before PoS is IMHO a total waste of time and resources.

Do you have another argument than this? Because it's false. Doing a 10-15% implementation and a 25-35% implementation is just taking out code that is already there and putting it back over a span of 3 HFs that are on the roadmap already, alternatively, if it makes it easier for you to imagine, you can view it like an increasing DAG.

How is my approach vendor neutral? Check this:
Currently we have ethash which is our baseline and is infested by ASICs and large megafarms
After ProgPoW_V1:
---all ASICs gone, profit increases linearly for every ASIC gone for all vendor devices
After ProgPoW_V2:
---all ASICs still gone, profit still being high for all vendor devices
After ProgPoW_V3
---all ASICs still gone, profit still being high for all vendor devices

Bonus: all participants get the chance to adapt to the ever increasing "difficulty" of this manually applied PoW "DAG" (if you want to imagine it like that).

Do you see any preference for AMD or Nvidia in here? If so, please point me to it, I can't see it.

[atlanticcrypto]

Or you could just sacrifice some hashrate and run at less power? Big farms aren't setup to draw up to TDP. This is never going to be perfect, and as said, if this doesn't happen now it will lose steam and be deemed worthless in the future.

[AndreaLanfranchi]

This whole point is beyond my comprehension

My 3-step approach is vendor neutral. You do realize what 60% additional power implicates? You know that the Clinton Nuclear Power Plant took over $4.25 billion in funds to get realized? ProgPoW would represent exactly 50-60% of that, applied to the current Ethereum network.
Do you believe 60% additional power will just appear out of thin air, "just plug it into the socket"? No, power is very expensive to install, and instantly doing a 60% power increase will not bring back mining to hobbyist miners and small farms, it will instantly centralize the majority of hashing power into 10+MW farms that have plenty of cheap electricity available and that were planned ahead to have much more power available than needed.

What are we talking about ? Energy efficiency or mining distribution ?
If the first ... let's go ASICS without further ado. Full Stop.
If the latter then miners will adjust power consumption to their affordable caps.

Assuming the increase in power drain due to ProgPoW "allows" users to go blindly flat-out is, imho, a naive assumption: miners afaik do their maths to gain a profit over costs.

[AndreaLanfranchi]

All miners deal with limited resources. If electricity was free we'd have 1000x more hashpower than now.
But it's not ! Power cost acts as a limiter exactly as difficulty.

[MoneroCrusher]

What are we talking about ? Energy efficiency or mining distribution ?

Both.

If the first ... let's go ASICS without further ado. Full Stop.

No, that would centralize the network even more.

If the latter then miners will adjust power consumption to their affordable caps.

Now you're exactly saying what I'm saying, hobbyist and smaller miners adjusting their power cap translates into reduced difficulty, reduced difficulty that would instantly get matched by a megafarm with dozens of Megawatts installed paying 2c per kW/h aka. ProgPoW_V3 would instantly make a shift to megafarms.

Or you could just sacrifice some hashrate and run at less power? Big farms aren't setup to draw up to TDP. This is never going to be perfect, and as said, if this doesn't happen now it will lose steam and be deemed worthless in the future.

That's exactly what I'm saying, large megafarms won't do this, small hobby miners will be forced to.

Why is everyone saying this has to happen now? Let's think this through and find a solution that gets majority support and will keep the Ethereum community unified.

IMO a 3-step implementation of ProgPoW would be the solution for that.

Any arguments besides "it has to happen now or everything is lost", which is a overdramatic expression of "I want increased mining profits NOW" because hey, who doesn't?

As I said many many many times, we need a solution that will make the maximum amount of people happy and that will help decentralization, anyone disagreeing?

[AndreaLanfranchi]

Why is everyone saying this has to happen now? Let's think this through and find a solution that gets majority support and will keep the Ethereum community unified.

Because in 5/6 months or more there is no point in enforcing any PoW change. It's not worth the effort. We're aiming to PoS remember.

Eventually this might be a future for ETC ... not for ETH.

[MoneroCrusher]

ProgPoW in a 3-step implementation isn't arriving any slower than ProgPow in a 1 step implementation if we all agree on it.

We can also just do it the easy way, I make an EIP that does my 3-step implementation of ProgPoW that is opposing EIP 1057 that wants to do a 60% power increase overnight.

Please try to guess which way the majority of the network would align with, given a choice?

Edit: I am not advocating for a contentious hardfork, all I'm saying is let's get all behind a solution that will get the most consensus.

[AndreaLanfranchi]

As I said many many many times, we need a solution that will make the maximum amount of people happy and that will help decentralization, anyone disagreeing?

You won't get it. You'll end up trying and trying to satisfy even the most tiny details: and remember oppositors always shout louder. (Look at what we're seeing here).

For me personally either it's a decided a final-go now or (for me) ProgPoW is tombstoned and will abandon it (really without any anger). And AFAIK also ifdefelse's team won't support any longer.

[MoneroCrusher]

You won't get it. You'll end up trying and trying to satisfy even the most tiny details: and remember oppositors always shout louder. (Look at what we're seeing here).

For me personally either it's a decided a final-go now or (for me) ProgPoW is tombstoned and will abandon it. And AFAIK also ifdefelse's team won't support any longer.

Again, I dont understand this "it has to happen now or everything is lost" binary attitude. Let me tell you, Ethereum will survive another 2 months without ProgPoW and if a solution is found in the meantime that will get majority consensus, then even the better.

[AndreaLanfranchi]

ProgPoW in a 3-step implementation isn't arriving any slower than ProgPow in a 1 step implementation if we all agree on it.

Do you realize the amount of time needed to adjust code of "every" software involved in the stack ? Miners, nodes, light clients, verificators in general.
It's a one time shot we can afford. Otherwise there is no point.

[AndreaLanfranchi]

Again, I dont understand this "it has to happen now or everything is lost" binary attitude. Let me tell you, Ethereum will survive another 2 months without ProgPoW and if a solution is found in the meantime that will get majority consensus, then even the better.

Ethereum will survive anyway. It's to be seen if it will fall under control of a totally centralized mining activity (several authoritative figures say "mining is a service ... we don't care where it comes from") or if it will keep an eye on those who contributed to its success (miners).

What is important is to understand that, as in any enterprise, any decision taken when needed is way better than the right decision when it's not needed anymore.

[MoneroCrusher]

ProgPoW in a 3-step implementation isn't arriving any slower than ProgPow in a 1 step implementation if we all agree on it.

Do you realize the amount of time needed to adjust code of "every" software involved in the stack ? Miners, nodes, light clients, verificators in general.
It's a one time shot we can afford. Otherwise there is no point.

Do you realize that the code is already fully there? It's literally (oversimplifying) snipping it out and putting it back in over a 3-step timeframe and would happen at the same time as the main HFs.

You could also do it in such a way that it's just uncommenting additional math in the random math loop function.

// Random math between two input values
std::string ProgPow::math(std::string d, std::string a, std::string b, uint32_t r)
{
    switch (r % 11)
    {
    case 0: return d + " = " + a + " + " + b + ";\n";
    case 1: return d + " = " + a + " * " + b + ";\n";
    case 2: return d + " = mul_hi(" + a + ", " + b + ");\n";
    case 3: return d + " = min(" + a + ", " + b + ");\n";
    case 4: return d + " = ROTL32(" + a + ", " + b + ");\n";
    case 5: return d + " = ROTR32(" + a + ", " + b + ");\n";
    case 6: return d + " = " + a + " & " + b + ";\n";
    case 7: return d + " = " + a + " | " + b + ";\n";
    case 8: return d + " = " + a + " ^ " + b + ";\n";
    case 9: return d + " = clz(" + a + ") + clz(" + b + ");\n";
    case 10: return d + " = popcount(" + a + ") + popcount(" + b + ");\n";
    }
    return "#error\n";
}

My proposal is to go for ProgPow implemented over a 3-step timeline and I would fully support that solution. That is my final word with regards to this matter (if further arguments are along the lines "we need it fast or everything is lost"). I need feedback from @IfDefElse / @OhGodAGirl on its technical feasibility, and if they don't agree with it politically, then I will propose an opposing EIP to EIP 1057.

I'd rather see us (and the majority of the network) behind one solution, it will happen much faster that way, which apparently is your goal.

[AndreaLanfranchi]

Commenting lines it's not a way to do things.
That is the source which goes into a GPU. Validators (eg. ethash library) don't "compile on the fly" and need a deterministic code to adapt to future changes of the source compiled into gpus.

Anyway ... I understand your points and your proposals. I'm not in favour of them.
There is nothing else to say.

[MoneroCrusher]

Commenting lines it's not a way to do things.
That is the source which goes into a GPU. Validators (eg. ethash library) don't "compile on the fly" and need a deterministic code to adapt to future changes of the source compiled into gpus.

Anyway ... I understand your points and your proposals. I'm not in favour of them.
There is nothing else to say.

Let me put it another way:

// Random math between two input values
//case-set x: ProgPoW_V1
//case-set y: ProgPoW_V2
//case-set z: ProgPoW_V3
//case-set original: see below
std::string ProgPow::math(std::string d, std::string a, std::string b, uint32_t r)
{
    switch (r % 11)
    {
    case 0: return d + " = " + a + " + " + b + ";\n";
    case 1: return d + " = " + a + " * " + b + ";\n";
    case 2: return d + " = mul_hi(" + a + ", " + b + ");\n";
    case 3: return d + " = min(" + a + ", " + b + ");\n";
    case 4: return d + " = ROTL32(" + a + ", " + b + ");\n";
    case 5: return d + " = ROTR32(" + a + ", " + b + ");\n";
    case 6: return d + " = " + a + " & " + b + ";\n";
    case 7: return d + " = " + a + " | " + b + ";\n";
    case 8: return d + " = " + a + " ^ " + b + ";\n";
    case 9: return d + " = clz(" + a + ") + clz(" + b + ");\n";
    case 10: return d + " = popcount(" + a + ") + popcount(" + b + ");\n";
    }
    return "#error\n";
}

"Case-set x" will get implemented now, that represents 10-15% additional core utilization + associated power utilization
"Case-set y" will get implemented in Istanbul HF, that represents 25-35% additional core utilization + associated power utilization
"Case-set z" will get implemented in HF after Istanbul, that represents ProgPoW_final core utilization + associated power utilization

A couple lines of changed random maths will generate barely any additional and hard work. A lot of code gets changed during the HFs anyway, a few small lines in ProgPow.cpp and its associated files is not big feat.
If that's the way the majority of the network would support it, why block it?

[Sonia-Chen]

We are asicmakers and can confirm that @MoneroCrusher 's approach (progpow_v1 v2 v3) would probably make it uneconomic to make ProgPOW asics (i.e. would exclude Chinese chipmakers, that is essentially what it is if you say only Nvidia and AMD are welcome). I'm not sure this is a compliment to his idea, but it's a fact. It would be so messy that, most likely, there would be no customers coming to us for a chip. They would wait and see.
We need about 4 million USD and 3-4 months to make a ProgPOW chip that is competitive (anything with ROI < 6 months sells easily).

That is if we decide such a chip is interesting and fits our own long-term ideas. Chipmakers are not idiots running around after random buckets of money. We are actually a decent sized engineering team with some smart folks, you can compare it to a nice-sized crypto software project. Every technical twist and turn that new chip customers come to us for, helps us build our platform for Proof-of-Contribution chips, that is chips that do more than just useless work. We are convinced that in the future there will be protocols that reward direct contribution to the scaling of the network. Rewards for verification, proving, signing, sorting, block speed, etc. Contributing to a network needs to be more economic than attacking the network.

@AndreaLanfranchi in our view, the biggest enemy for GPU miners are not Chinese asicmakers, although they are pretty bad too. The biggest enemy are secret optimizations and access to preferential chip deals that some GPU miners may have over other GPU miners. That is why, from what we see, quite a few independent GPU miners reject ProgPOW. If you want to do something good for them, try to exclude the Chinese (MoneroCrusher's proposal) AND increase the block reward.

The PoW algo decides who gets about 1.6 mio USD every day. Enabling a barely tested algo on a million machines will lead to the biggest chaos in crypto mining history. The original idea was to give that money to whoever can provide the most cryptographic security, not whoever has the best politics and lobbying.

[Daft-Wullie]

Just gonna leave this here:
https://www.reddit.com/r/ethereum/comments/alqolj/why_eth_need_to_be_asic_resistant_and_adopt/

[AndreaLanfranchi]

If that's the way the majority of the network would support it, why block it?

I'm not blocking anything. I don't have the power to.
I'm simply saying I won't participate to that path. That's it.

[W944]

1. Core devs already set a 'political change' precedent with the reward reduction. Therefore, the POW change decision rests squarely within their responsibilities. Devs, please don't hide and act swiftly.

2. ProgPow EIP 1057 has been introduced 9 months ago. The time for "studies" is overdue. By the time there is an agreement on what should be studied and by whom, another half a year will have passed at this rate, not counting the time for the study itself. Wasn't ProgPow green lit at the last dev call already? Who's going to be the impartial third party. If this panel decides ProgPow is bad and a no go, will there be accusations of them being in Bitmain/Lindzi/Asic's pocket? Just like the ProgPow devs are accused of being in nVidia's pocket? There is no solution that satisfies everyone. There will always be resistance by someone and it is inevitable when money is concerned. What then? Back to where we are now.

3. My worry with the proposed 3-part ProgPow change is that if it has taken us so much time and we didn't even do one Pow change, imagine going through this 3 times :) Maybe someone won't want the first step to be 10-15. Maybe they'd like 5%, or 50%. Maybe some other change? At this point we'd be designing an algo by committee. And as described in my second point, everyone wants something else. Might as well take ProgPow in it's current form and skip the extra grief. It's ready now, let's adopt it.

[MoneroCrusher]

I'm not blocking anything. I don't have the power to.
I'm simply saying I won't participate to that path. That's it.

All good then.

1. My worry with the proposed 3-part ProgPow change is that if it has taken us so much time and we didn't even do one Pow change, imagine going through this 3 times :) Maybe someone won't want the first step to be 10-15. Maybe they'd like 5%, or 50%. Maybe some other change? At this point we'd be designing an algo by committee. And as described in my second point, everyone wants something else. Might as well take ProgPow in it's current form and skip the extra grief. It's ready now, let's adopt it.

It's not doing 3 of these, it's taking the current ProgPoW apart and implementing it in 3 steps.
We could do a community vote on what core utilization would get chosen.
I thought 15%, 30% and 100% would be a good approach.

[AndreaLanfranchi]

@MoneroCrusher
Just a technical note though as apparently you've not studied the code so much.
For every math operation you remove you have to increment the DAG accesses (via modulo) as only in this way you can touch all elements in mix[] or the crypto strength of the algo is messed up.
So you're unbalancing the algo making it even more memory hard than it is now.

[MoneroCrusher]

@AndreaLanfranchi I'm not here to argument about technicalities. A 10-15% additional core implementation is possible. Period. A 25-35% core utilization is possible. Period.

[AndreaLanfranchi]

No problem. Go ahead and propose.
In 5 months when you'll be around a table still discussing if it has to be 3 steps or 2 or 5 whith increments of 3% or 5% or 17% or 32% (but only on last saturday of the month) ... well I'll have my glass of wine and will gladly say ... "I told you."
Good luck.

[MoneroCrusher]

When you can set up a Nuclear reactor in your backyard to use an additional 60% power or 600MW for your mining change, call me up, my GPUs will be ready to get plugged in.

I very clearly laid it out and it seems you are following your own agenda here.

I said 3 steps
I said 15%, 30% and 100%

Anything unclear about this?

Good luck to you too.

[AndreaLanfranchi]

I said 3 steps
I said 15%, 30% and 100%

Exactly ... you said ... but apparently you are convinced you'll be able to collect silent and blind consensus around this. You will have to face more than one variant proposal. Anyway ... everyone follow their path.

[AndreaLanfranchi]

@Sonia-Chen please ... your well-mannered effort to try be supportive is genuine and real like Unicorns.

[MoneroCrusher]

Let's plese refrain from personal attacks like that @AndreaLanfranchi. There is a lot of dirt to be thrown, let's not go down that path. Instead focus on what she has to say.

[W944]

Lindzhi is supporting division, to continue with the status quo. They have to recoup their 4 million dollars investment into their Ethash Asic. The longer the community bickers around what to do, and ultimately does nothing, the longer they can mine with their Asics.

[AndreaLanfranchi]

Problem is Linzhi says one thing in public. Totally different things on DM.
So, unless you need to defend anyone only because is approving your path, don't enter this matter.

[salanki]

The problem @MoneroCrusher is that there isn’t enough bandwidth for the developers to argue and analyze everyone’s different implementation ideas. It is easy for you to say “if everyone just agreed with me all will be well”. Obviously, if everyone agreed with each other on every little detail there would be no problems in the world. If we want to get to full consensus on every detail, how the rollout should happen etc. we won’t get anywhere. I think your argument is interesting, and it would be worth discussing if we ie. were Monero that is committed to spend a lot of time continuously on PoW changes. However, that is not Ethereum.

We have to sober up and realize that the options we realistically can count on getting implemented is:

A) Nothing - possible end of GPU mining
B) ProgPoW rollout as it has been worked on for the past 9 months.

[MoneroCrusher]

I am saying if you go down the path of throwing off people's opinions because of who they are and who they are associated with, it will get ugly real fast in here (hinting at potential IfDefElse relations with various entities), so let's not do that. Keep that on Reddit.

We're here to discuss a solution that will get majority consensus, if you don't agree with my proposal, tell me what's wrong with it, because I sure as hell am sure the ProgPoW implementation as it currently stands will cause sheer havoc amonst the community if it were to be implemented and would stand no chance against a 3 phase implementation if the current GPU network owners were to vote on it (hint hint, who wants a 60% power increase overnight?).

@salanki I think your argument is interesting, and it would be worth discussing if we ie. were Monero that is committed to spend a lot of time continuously on PoW changes. However, that is not Ethereum.

Doing a 3-phase implementation of ProgPoW and continually changing PoW are two completely different matters.
It's like saying "I want PoS, but only if it gets implemented in one swift move". So why are we moving to a hybrid system first? This binary type of thinking helps no one.

[MoneroCrusher]

The argument of "but it has been worked on for 9 months" is terrible (and also wrong, it has actively been worked on by the Ethereum devs for 4.5 months, since mid September). If a solution is not good, it's not good. And more often than not, the very first idea is not always the best.
https://en.wikipedia.org/wiki/Theory_of_the_second_best

[jean-m-cyr]

In any case, arguing about it here does nothing to advance the cause...

[Sonia-Chen]

@jean-m-cyr agreed, last message from me but since Andrea said something I believe is not right I have the chance to correct that:

@AndreaLanfranchi
"Problem is Linzhi says one thing in public. Totally different things on DM."
I take this as permission to repost the one unsatisfactory attempt of ours to reach out to you. Until you apologise, we are also not interested in further private messages with you, better keep everything 100% public. You are free to support ProgPOW, it will be an economic disaster for independent GPU miners, and windfall for insider GPU miners. We know that because we know the cost structure of mining, something you cannot see in open source...

..begin DM..
Linzhi: hi Andrea, you there? Do you know where Na Ikmeyong is?

Andrea: Hi. Have no idea ... only thing I know is he/she appears to be from somewhere in Asia (his words). And apparently is inactive since few days right now.

Linzhi: ok! thanks for the reply. I believe 100% you are genuine and not bought by anyone and interested in truth and healthy development of Ethereum etc. I understand you trust progpow and they talked about it for a long time so it's hard for anyone, like us, to come along and just say it's one big scam with really bad actual agenda etc. professional scammers actually. We have started to peel away a few layers of the onion, and I am willing to work with you one by one on these things, and hopefully we are going somewhere. The real story of progpow is that is was invented as a tool to exclude chinese miners, and in return secure access to inside information and special chip deals from nvidia. Proving that is super hard, especially once someone bought into the story. I don't know where you stand right now wrt porgpow, what you think should be done next, or whether you are interested in PoW at all (since PoS is looming on the horizon). I am here to work on PoW, we are a chipmaker and we see a few things that software people just cannot see. Hope Ethereum continues to grow well! if you have questions, please ask. we answer everything to the best of our knowledge, and WITHOUT hidden second agenda (but it is up to the critical investigative mind of anyone, including you, to come to this conclusion!)

Andrea: You have chosen the wrong interlocutor. Sorry but I won't continue this conversation. Regards

..end DM..

[MoneroCrusher]

@jean-m-cyr Why shouldn't we evaluate alternative, potentially better solutions in here?

[AndreaLanfranchi]

See what I mean ?

"Divide et impera"

[MoneroCrusher]

@AndreaLanfranchi There is nothing to be divided and reigned over. Your thinking implies there is a current "owner" of Ethereum.
You don't own Ethereum, I don't own Ethereum, nobody does. Everyone can support the variant they like, this is decentralization after all. The majority consensus shall rule, nothing else.

[AndreaLanfranchi]

Re read above (linzhi). Carefully. Take a deep breath and think who's dividing.

[MoneroCrusher]

There is nothing to be divided, let the majority vote, everyone can make up their own opinion with their hashpower. Propose ProgPoW original & ProgPoW 3-phase roll out and let it clash, see who will win, the EF and Core devs can then continue developing on the majority chain.

With ProgPoW (be it ProgPoW original or ProgPoW 3-phase) implementation there is going to be a chainsplit anyway (do you think ASIC owners will just throw their devices into the dumpster?).

[AndreaLanfranchi]

I won't propose nothing else just because I see what you can't or don't want to see.
Every time things get agitated around the matter ... lobby enters the game and shuffle cards. They need to take time. That's why I'm so fixed on it's now or never.

Also your statement about the split it's quite controversial. Which chain you think the Ef will follow ? Core devs will develop what ?

[AndreaLanfranchi]

Vote what ever you want. If you don't take action within end of February I can assure ethash will be the first and last algorithm Ethereum will ever see

[MoneroCrusher]

Let's say ProgPoW original gets 80% less hashpower than ProgPoW 3-phase deployment. Which chain should in your opinion the ETH devs build ontop of? I'll let the devs decide that.

[AndreaLanfranchi]

On the one with ethash

[MoneroCrusher]

I'll let you in on a secret: the legacy chain will have much more hashpower than any ProgPoW chain will ever have with all GPUs combined. Secret ingredient: ASICs

[AndreaLanfranchi]

With such a valuable information why on Earth would you spend a single minute of your time to propose anything different from ethash ?
Simply to move GPU miners on a dead chain ? Want to become EthereumCrusher ?

[MoneroCrusher]

Very simple: Because the legacy chain will be a centralized shitfest and I stand for decentralization.

Let's assume 80% of the current Ethereum network is ASICs.
Why that much? Because in the past 2 weeks hundreds of thousands of GPUs have left Ethereum and have joined the Grin network, which is very apparent from Ethash Network hashrate chart and Grin hashrate chart increase.

So we have 150 Th/s now with 80% or 120 Th/s being ASICs and 20% or 30 Th/s being GPUs.
Now let's suppose a HF happens, the legacy chain will have 120 Th/s and the ProgPow chain will have 15 Th/s (remember the hashrate halving, not that it matters).

So to an outside observer this might appear as: Legacy 120 Th/s, ProgPow 15 Th/s.
Why: because ASICs can't join the new network and will stay on the old chain, duh. And no, they won't switch over to ETC. They will push for ETH Legacy or whatever they want to name it to artificially uphold the value of their ASICs.
Was that so hard?

One being a centrally controlled chain and the other being a decentralized chain. Supporting the legacy chain is not an option for the EF, if they stand for decentralization, so it will either be ProgPoW original or ProgPoW 3-phase implementation.

My personal bet is that the 15 Th/s would distribute as follows: 13-14 Th/s ProgPoW 3 phase, 1-2 Th/s ProgPoW original.

[AndreaLanfranchi]

If core devs were focused on decentralization we'd not have this conversation and ProgPow would have been live since October.

[AndreaLanfranchi]

My personal bet is that the 15 Th/s would distribute as follows: 13-14 Th/s ProgPoW 3 phase, 1-2 Th/s ProgPoW original.

How may chains do you foresee ? Three ? Oh Lord

[MoneroCrusher]

At a minimum two (ethash/legacy is here to stay as an ASIC chain). If we can't get behind one ProgPoW version, then it's three, with one dying down eventually, so two as well.
The GPUs of the "loser chain" would obviously join the "winner chain" after some time.

[AndreaLanfranchi]

Wow. You're not crusher. You are Terminator

[MoneroCrusher]

That's why I'm advocating of going the way of least resistance/biggest community consensus. ProgPoW original does not represent the interests of the decentralized miner community at large, a ProgPoW 3-phase implementation does.
So, feel free to join me and we can get this through very fast.

There really is no downside to a 3-phase implementation if you're a GPU miner in comparison to a ProgPoW Original implementation - profitability wise - on the opposite, it's better.

If you can name just one, I'll let it rest! This is your chance, instead of trying to belittle me, show me some good argumentation.

[AndreaLanfranchi]

Oh I see. And exactly how many miners you're representative for ? You know your not the first who claims to speak for miners. As you appear to be pre-approved by miners on your 3 step path can you share the numbers of your supporters ?
It's since early January devs try to figure out

[MoneroCrusher]

If you carefully think this through you'll arrive at the same conclusion.
Imagine you're an owner of a GPU card.

There are two paths forward:
temporary ASIC resistance + 60% power increase
better ASIC resistance + 10% power increase for 10 months, +20-30% increase for 10 months and then + 50-60% increase for the following 10 months, while giving you the chance to upgrade power installations and/or buy a more efficient GPU card

Let me know!

[AndreaLanfranchi]

So you basically say you've done those fancy maths which you mean are valid for all miners uh ?

I instead personally think that if a miner thinks to upgrade it's infrastructure targeting Ethereum PoW either know something we all don't know (eg PoS Will never come) or is a complete idiot.

Bye man.
I'm out

[MoneroCrusher]

YES, energy consumption is viewed universally as an expense by all miners that I personally know. And _I'm bold enough_ to assume it applies to all miners across the globe.

You haven't provided a good argumentation why a 3-step implementation of ProgPoW would disadvantage a GPU miner vs. a one time ProgPoW original implementation that increases power by 50-60% overnight.

I'm argumenting that a 3-step deployment will actually dramatically increase decentralization + introduce better ASIC resistance, all the while getting bigger community consensus.

Instead of condescending me for "doing fancy maths", which really are just based on real work benchmarks of current ProgPoW, let me know why you are so fixated on this one "true" ProgPoW? Remember, OhGodAGirl said this is open source, it can and should be modified as pleased by the community.

That's why it was made the way it is, so parameters could be easily tweaked and the community can come up with their own version if they don't like the proposed one.

[AndreaLanfranchi]

I exposed my arguments instead. 3 step adoption relies on the assumption miners would want to upgrade their infrastructure which I consider a stupid thing.

My point instead is very simple. ProgPow is mainly addressed to prevent ASIC dominance for the limited residual life of PoW. As a bonus GPU miners will benefit for a marginal increase of their revenues.
I never, never, had the wealth of GPU owners as main target (note I mine eth a lot) as I am perfectly aware that PoW is a dead man walking. And as a miner I don't share any of your views

[AndreaLanfranchi]

As a miner and as a developer I want Ethereum to take a position as it will give ether a value of consistency. Postponing problems only drains credibility to the whole project

[W944]

@MoneroCrusher You're arguing about the need to delay/split ProgPow into phases because of an increase of power usage. If your cards are locked at 70% power limit now with ethash, and are locked at 70% power limit after ProgPow, thus using the same amount of watts, then where is the increase? There is none.

What you're saying is that to obtain the absolute maximum hashrate, you need to increase your power usage because of the increase of core usage. Ok, but I fail to see how that argument fits into your narrative.

You say we need to go in phases so miners can upgrade their power infrastructure. What prevents them from running their cards at their current power limits with ProgPow, thus fitting into their power allotment, and upgrading their power capacity if they so desire at a later time. After which they can raise their power limit to gain a few mh/s.

If everyone has the same "handicap" of increased power usage (and I use the handicap term loosely) then the playing field is leveled.

In theory going in phases could work. And I would have had been OK with this plan if it was proposed 6 months ago. But we're long overdue for a fix here, and we have a solution ready today. Trying to define those phases by reinventing the algo and getting consensus and software ready pushes us back months.

Instead of doing that, by adopting ProgPow today (and getting lower difficulty today), you will earn more then if we delay ProgPow by a few months, even if you run at the same power limit during those few months.

[MoneroCrusher]

3 step adoption relies on the assumption miners would want to upgrade their infrastructure which I consider a stupid thing.

No it doesn't. It gives them the time to do so if they wish it. Not everyone can just upgrade their power infrastructure overnight. In certain countries you even have to let 2 independent experts look at the installation before it is approved and can be used, which are usually slow to arrive, like you book them and they check in after 3-4 weeks or so.
And not everyone has the money to afford this, especially not smaller farms and hobby miners.

My point instead is very simple. ProgPow is mainly addressed to prevent ASIC dominance for the limited residual life of PoW. As a bonus GPU miners will benefit for a marginal increase of their revenues.

ProgPoW 3-phase out does the same and it increases profits even more than straight ProgPoW_V3 implementation because it uses much less energy that the average hobby miner currently barely can afford to cover (assuming 10c per kW/h).

@W944

If your cards are locked at 70% power limit now with ethash, and are locked at 70% power limit after ProgPow, thus using the same amount of watts, then where is the increase? There is none.

ProgPoW claims to utilize the GPU to a full extent? So you're now saying to artificially throttle it down so I can mine ProgPoW?
In theory it would work, if everyone had to act this way. The reality looks entirely different.
If you limit your GPUs power, this decreases difficulty of the PoW, another miner (mostly a megafarm in Washington state, Canada, Sweden or Iceland with PLENTY of cheap 2-3c per kW/h) will gracefully match that by using more than your specified 70% power limit.

Meaning ProgPoW with a 60% power increase would instantly decrease decentralization and allocate hashrate even further to farms with plenty of cheap electricity, like Genesis Mining.

If everyone has the same "handicap" of increased power usage (and I use the handicap term loosely) then the playing field is leveled.

That's the problem, it doesn't apply to everyone the same. The power increase hits hobby miners much worse than corporate mining entities, the profit margin for a hobby miner is much slimmer because their electricity is more expensive. By even further increasing it you are giving more power to megafarms and taking it away from hobby miners and smaller farms.

A 3-phase deployment would give miners time to buy more efficient machines over time and they have a choice of upgrading their electricity installation or relocating, if they wish to. ProgPoW as it currently stands doesn't give you that possibility, it instantly decides: "you are able to mine, you aren't".
My proposal creates an even playing field, as both megafarms and hobby miners have the chance to upgrade.
Megafarms will usually use their GPUs for a longer time because they got near-free electricity, therefore gives an edge to smaller miners that are micro-economically speaking often times more agile in selling their low quantities of GPUs and buying the latest tech, as I have seen many people doing the past year. Therefore you are giving a small edge to hobby miners like that.

At least we can all agree that the current ASIC infested network is bad for the ecosystem.

[MoneroCrusher]

In theory going in phases could work. And I would have had been OK with this plan if it was proposed 6 months ago. But we're long overdue for a fix here, and we have a solution ready today. Trying to define those phases by reinventing the algo and getting consensus and software ready pushes us back months.

As I have repeatedly stated: this is not reinventing the algo, it's literally taking stuff out and putting it back in over time. Because the current 60% power increase is just too hardcore, sorry.

[MoneroCrusher]

As it currently seems some of you are deep within the "ProgPoW Matrix" and have a binary thinking system of "implement it now or I will cry foul". This sounds a lot like wounded miners desperately trying to recoup their losses.
Let's instead focus on a solution that will not only give you a 6 month fix, because as stated by Linzhi and many others, ProgPoW ASICs will be back fast, but let's do it in a way that GPU miners will be kings until the day PoS arrives, through economic disincentivization of ASICs by slowly ramping up the PoW core utilization - DAG style.

If you need help deciding which choice would be better, try to align your thinking with a miner and ask yourself, would you rather spend 50,000 kW/h until PoS or would you rather spend 80,000 kW/h until PoS, given that the lower energy expenditure comes with a better longer-term resistance to ASICs, too.

I think the majority of the network would agree to use less energy. Do you disagree, @AndreaLanfranchi @salanki @W944 ?

[ASICseer]

I agree with Ethereum core devs that they need to completely step back from this debate and not give it a platform on their dev channels (youtube calls, github issues, reddit posts).

This issue basically decides who gets to mint new coins, and the ETH dev team should not be acting like the US Federal Reserve. They should not be inviting third party developers with unproven codebases into their midst and letting them whisper into their ears.

We can all admit that a lot of money is at stake, and if ETH devs provide a platform for this debate on their channels, they expose themselves to the potential of backhanded dealings, bribery, coercion.

The only way for users to trust developers in the future, is for them to remain completely impartial on this issue.

[AndreaLanfranchi]

@MoneroCrusher if for any reason it would end up majority would not agree with you what would be your position ? You would abstain from further fights ?

[MoneroCrusher]

@AndreaLanfranchi I would join the majority network that offers the best economic incentives to mine.

[AndreaLanfranchi]

@gpushack are you invoking censorship ?

[ASICseer]

No, I’m quoting ETH devs:

https://twitter.com/5chdn/status/1090752365190438912

[AndreaLanfranchi]

thinking system of "implement it now or I will cry foul". This sounds a lot like wounded miners desperately trying to recoup their losses.

This is simply a manipulation. My point is very clear. Do it now or don't do it all and speed process to PoS without wasting any further resources. Time is up

[AndreaLanfranchi]

@gpushack you're quoting one person. Is he the leader who can decide for all ? Afaik @holiman is in the same group and has a very different position

[W944]

ProgPoW claims to utilize the GPU to a full extent? So you're now saying to artificially throttle it down so I can mine ProgPoW?

Why do you need to throttle? You can mine at 10% power limit if you want. You can also mine at 100% if you want. Choice is yours to set your own power expense as you see fit.

If you limit your GPUs power, this decreases difficulty of the PoW, another miner (mostly a megafarm in Washington state, Canada, Sweden or Iceland with PLENTY of cheap 2-3c per kW/h) will gracefully match that by using more than your specified 70% power limit.

So?

Meaning ProgPoW with a 60% power increase would instantly decrease decentralization and allocate hashrate even further to farms with plenty of cheap electricity, like Genesis Mining.

I think you're being a bit dramatic here. Plenty of people would run their GPUs at that 70% power limit anyways, whether it gave them peak hashrate or not. A lower power limit also means lower heat output and less wear on the fans. Look at the equihash guys, plenty on reddit running at 70% power limit.

That's the problem, it doesn't apply to everyone the same. The power increase hits hobby miners much worse than corporate mining entities, the profit margin for a hobby miner is much slimmer because their electricity is more expensive. By even further increasing it you are giving more power to megafarms and taking it away from hobby miners and smaller farms.

You're conveniently leaving out the fact that compared to ethash the profits will be higher even if they don't spend an extra cent on extra power by keeping the same power levels, just by changing to ProgPow and the lower difficulty. Same power costs, more profit. You want to run at full power? Go ahead. You'll spend more on power, sure, but you'll also get more profits. So either way you come own on top versus ethash.

A 3-phase deployment would give miners time to buy more efficient machines over time and they have a choice of upgrading their electricity installation or relocating, if they wish to. ProgPoW as it currently stands doesn't give you that possibility, it instantly decides: "you are able to mine, you aren't".

Why can't you mine with ProgPow at 70% power limit? It seems that it is you that has a binary vision. Either you mine at 100% power limit or don't mine at all?

My proposal creates an even playing field, as both megafarms and hobby miners have the chance to upgrade.

You have not convinced me how ProgPow will prevent either from upgrading.

At least we can all agree that the current ASIC infested network is bad for the ecosystem.

At least we agree on one thing :)

[Wolfgang-Spraul]

At least we can all agree that the current ASIC infested network is bad for the ecosystem.
At least we agree on one thing :)

Hey! :) All minus one please.
We are minority and treated well, but not non-existant. The hashrate is not a political alimony system, but contributes real security to the network. I'm sure we don't want to force PoW by paper and pencil. It would be great for decentralization, but easy to cheat.
Thanks for giving a small minority the chance to speak.

[Edit: Forgot the disclosure: Working for Linzhi, the guys in China are asleep finally...]

[MoneroCrusher]

ProgPoW claims to utilize the GPU to a full extent? So you're now saying to artificially throttle it down so I can mine ProgPoW?

Why do you _need_ to throttle? You can mine at 10% power limit if you want. You can also mine at 100% if you want. Choice is yours to set your own power expense as you see fit.

If you limit your GPUs power, this decreases difficulty of the PoW, another miner (mostly a megafarm in Washington state, Canada, Sweden or Iceland with PLENTY of cheap 2-3c per kW/h) will gracefully match that by using more than your specified 70% power limit.

So?

So centralization

Meaning ProgPoW with a 60% power increase would instantly decrease decentralization and allocate hashrate even further to farms with plenty of cheap electricity, like Genesis Mining.

I think you're being a bit dramatic here. Plenty of people would run their GPUs at that 70% power limit anyways, whether it gave them peak hashrate or not. A lower power limit also means lower heat output and less wear on the fans. Look at the equihash guys, plenty on reddit running at 70% power limit.

People running GPUs at 70% would decrease their rewards in relation to megafarms because they won't limit their GPU power usage, thus switching power from hobby to corporate even more.

That's the problem, it doesn't apply to everyone the same. The power increase hits hobby miners much worse than corporate mining entities, the profit margin for a hobby miner is much slimmer because their electricity is more expensive. By even further increasing it you are giving more power to megafarms and taking it away from hobby miners and smaller farms.

You're conveniently leaving out the fact that compared to ethash the profits will be higher even if they don't spend an extra cent on extra power by keeping the same power levels, just by changing to ProgPow and the lower difficulty. Same power costs, more profit. You want to run at full power? Go ahead. You'll spend more on power, sure, but you'll also get more profits. So either way you come own on top versus ethash.

Not disagreeing here but I'm saying ProgPoW 3 phase > ProgPoW original > Ethash. I don't believe people paying 10-15c for power will run at a profit with ProgPoW.
Check my calculation I just did, assuming a conservative 60% of the network being ASICs:

In fact a lot of people have reported and benchmarked over 200W usage for RX 580 at the wall, I'm being very friendly throughout this thread with ProgPoW_original power consumption.

A 3-phase deployment would give miners time to buy more efficient machines over time and they have a choice of upgrading their electricity installation or relocating, if they wish to. ProgPoW as it currently stands doesn't give you that possibility, it instantly decides: "you are able to mine, you aren't".

Why can't you mine with ProgPow at 70% power limit? It seems that it is _you_ that has a binary vision. Either you mine at 100% power limit or don't mine at all?

I can, but as I explained in detail, the given up hashrate would land in megafarm's hands, thus it causes centralization towards farms with cheaper electricity, the more electricity an algo uses.

My proposal creates an even playing field, as both megafarms and hobby miners have the chance to upgrade.

You have not convinced me how ProgPow will prevent either from upgrading.

That's fine and I'm sure it's an impossible feat.

At least we can all agree that the current ASIC infested network is bad for the ecosystem.

At least we agree on one thing :)

Cheers!

[MoneroCrusher]

Alright my fingers and my brain hurt from typing so much, as a last word from me for today:

There is zero downturn for any GPU miner with a ProgPoW 3-step deployment. I believe a majority of the current network owners would vote in favour of it because of reduced power constraints.

So let's just all get behind one goal and bring decentralization & hobby mining back to Ethereum. I sure would support that with all my power :)
Good night!

[ghost]

Nice, good luck Ethereum community 😄

[gcolvin]

My two cents:

https://medium.com/@brianventuro/saving-ethereum-why-i-stand-behind-progpow-b4679c3089dd

I didn't know I was an elder statesman, @atlanticcrypto. I thought I was a cantankerous old man ;-)

[MoneroCrusher]

My two cents:

https://medium.com/@brianventuro/saving-ethereum-why-i-stand-behind-progpow-b4679c3089dd

As I stated, ProgPoW is mainly good for megafarms with cheap power. We are not here to accomodate those, which ProgPoW does. We are here to bring back decentralization to hobby miners. It's really not a big difference if the network is owned by a dozen GPU megafarms or a dozen ASIC farms.

Let's focus on bringing back profitable GPU mining to Frank, 19, living in mom's basement, owner of a 12 GPU rig.
Let's not focus on bringing mining profits back to Tom, 43, owner of a 50'000 GPU megafarm with access to 2-3c kW/h electricity.

The GPU megafarm owner will of course still profit from this, but less in relation, which is a good thing. That's why you see ProgPoW pushed by all major megafarms owners, while smaller farm or rig owners are not that fascinated by ProgPoW.

I don't like how this has turned into GPU megafarms vs. ASIC farms.

DECENTRALIZATION is the key word here
A 3-phase roll-out of ProgPoW would achieve that _a lot_ better, check my numbers above.

[lrettig]

Closing in favor of #77