Ethereum Core Devs Meeting 54 Agenda
Souptacular opened this issue · 134 comments
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
- Roadmap
a) Constantinople - Ropsten fork?
b) Istanbul Hardfork Roadmap
c) Outlook: PoS finality gadget on PoW chain (Serenity)
d) ProgPoW audit? - Working Group Updates
a) Ethereum 1.x Stanford Meetings Overview
b) State Rent
c) EWasm
d) Pruning/Sync
e) Simulation - Testing Updates (time allowing)
- 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 - Research Updates (time allowing)
For the record, this is my recollection of how we arrived at 7.28M, feel free to tweak if I've gotten anything wrong:
- @vbuterin suggested six weeks, which he said would put us around block 7.25-7.3M.
- 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.
- @5chdn proposed Feb. 27, which falls on a Wednesday, and also happens to be during a quiet week between ETHDenver and EthCC.
- 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.
- 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.
- March 1 is a Friday
- Epoch does not matter
- It's decided already
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:
- falling price in fiat currency (less minig reward in fiat currency)
- 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.
Could you elaborate how you connect uncle rates with ASICs?
@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.
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.
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:
- better blocks and transaction propagation because of better propagation services used by mining pools.
- better blocks and transaction propagation, and faster DB handling because of better nodes topology.
- 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.
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.
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.
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.
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.
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.
Apparently there is a deliberate intention no to face the matter.
Originally ProgPoW topic was in agenda and then silently removed.
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.
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.
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.
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".
@gcolvin Wasn't the issuance reduction a "political" decision ?
I felt like a central banker afterwards.
@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.
@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.
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.
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'.
here is the response
https://twitter.com/hudsonjameson/status/1090643066556420096
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.
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.
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.
That would be a chain split. I think we should all try to avoid it
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.
@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.
- 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.
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
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.
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:
- HBM ASICs will very likely resurface
- 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
- Economically less- or even uninteresting
- 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.
- 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.
- In the Istanbul HF introduce ProgPow_v2 but with 25-35% additional core utilization in comparison to Ethash
- 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,
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.
@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
@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.
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
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.
We don't have 2 or 3 years of PoW on eth. Maybe 1 and a half
Anyway I'm not pushing for this technicalities. What I would like to see is a go or no-go now
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?
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
- We don't know that. Personally I believe we won't be on PoS in 12 months to 18 months.
- 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.
I'm ignorant, @AndreaLanfranchi but if the PoW chain is iced what is the point of staking ETH on it?
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.
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.
@gcolvin this is the plan to force migration to Ethereum 2.0
@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
@AndreaLanfranchi My proposed solution is vendor neutral. Please re-read my posts if that doesn't crystallize.
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?
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.
@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.
All current proponents of progPOW fail to understand these two points:
-
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:
-
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.
@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.
@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.
@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 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.
@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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
Just gonna leave this here:
https://www.reddit.com/r/ethereum/comments/alqolj/why_eth_need_to_be_asic_resistant_and_adopt/
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.
-
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.
-
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.
-
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.
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.
- 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.
@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.
@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.
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.
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.
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.
@Sonia-Chen please ... your well-mannered effort to try be supportive is genuine and real like Unicorns.
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.
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.
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.
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.
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.
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
In any case, arguing about it here does nothing to advance the cause...
@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..
@jean-m-cyr Why shouldn't we evaluate alternative, potentially better solutions in here?
See what I mean ?
"Divide et impera"
@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.
Re read above (linzhi). Carefully. Take a deep breath and think who's dividing.
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?).
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 ?
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
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.