Alrighty sir, I will stop trolling you and move on to rational arguments.
This is what you said above:
We have been making risky changes to the client for years now without third-party audits. progPoW has been in the open and under review by experts for almost 11 months now, and experts are still reviewing it. So an audit will good to have, but I can’t see demanding one.
I empathize with the fatigue, I’m feeling it too and I’ve only been doing this for a week.
There are three main reasons why I believe an audit is important:
Safety - As is the first time we’re updating the hashing algorithm, I think we should take extra precautions to make sure it doesn’t do anything unexpected. I believe this is a fair request. The reason Constantinople was delayed was because an audit caught a bug. Why skip it for this?
As I said above, in response to @mhswende claiming the upgrade would be trivial:
If this was really the case, then why is there so much fuss about getting an audit done? Either it’ll be trivial, and we should do it, or it won’t be trivial, and we should definitely do it.
Consensus - From what I can tell, of the people who oppose ProgPow, none of them would be more fine proceeding without an audit. On the other hand, there are many people who support ProgPow that would prefer to have an audit done first. This means the anti-audit camp is a strict subset of the pro-ProgPow camp, and therefore the pro-audit group is by definition the largest group.
Legitimacy - When the “decision” was originally made, it mentioned an audit would take place, and that if any risks were discovered, they would be fixed. If you believe in the legitimacy of that decision, in order to be consistent with all of it, not just the part where we move forward with ProgPow, then you should support an audit. I said as much to @Arachnid on twitter yesterday.
All of you mention wanting to do an audit. And now your (@gcolvin) position is:
an audit will good to have, but I can’t see demanding one.
I don’t think this is a coherent position to have.
I’ll repeat what I said in the OP:
I want to add that I still don’t support ProgPow even if the audit comes back clean, but I would much more willing to accept it if it didn’t feel reckless.
It seems that the fatigue over this issue is causing us to abandon the interest in the audit, but I don’t see any external pressure motivating the urgency of this decision.
I maintain that we should not include ProgPow until an audit has been conducted.
The main thing currently preventing an audit is a lack of funding for it. The more ProgPoW is looked into at a technical level the more people there are who are comfortable moving forward without an audit because they feel the scrutiny has been sufficient.
For those wanting an audit the simplest way to get one is to contribute to funding it.
Can you point me to the available reviews by IC designers? I dont think a lot of the core devs sepcialize in this area, and we additionally want to see the the forecast or estimates into the likelihood of ProgPoW specialized hardware developing, that were supposed to be included as part of it.
Additionally, the horse trade for the decision making was that implementation would occur but under the premise that an independent audit would be performed in support of a final go/no go status. This was to be coordinated by the Ethereum Cat Herders, and they have thus far done a good job organizing, but the funding problem has created delays.
I don’t believe we, who were offered the audit in return for support for a decision, should be solely responsible for the funding that audit. I’ve contributed to the Gitcoin raise, however believe my money would have been more useful elsewhere such as ETH 2.0 clients, or FFG development, both of which provide mitigations for the risks associated with ASIC centralization anyway.
As this proposal disproportionately benefits one interest group (GPU miners) and there has been virtually no demonstration of the pressing need for ProgPoW, I believe funding should come from the proponents or the Ethereum Foundation. As it was core devs who proposed the conditional terms of the decision to include such an audit.
This is a change to the underlying PoW algorithm, and tech that many of the proponents lack expertise in, versus many other EIPs which had the luxury of many competent eyes from a large developer base on them (and still eleventh hour bugs were found). Ethereum does not have a similar electrical engineering/IC designer base. An independent audit seems like a prudent course of action to, at the very least, provide the appearance of appropriate due diligence on both the security, and the merit of the change. One of the driving rationales for the change is the commitment to ASIC resistance. One of the objectives of the audit is to demonstrate just that. Whether ProgPoW does in fact fulfill that objective or not. If it is identified in the course of the audit that it does not fulfill that objective, I believe the need for ProgPoW just be reassessed entirely.
I don’t think there was any IC designers, but many people on the implementation team have sufficient hardware design expertise, especially an understanding of GPU internals, where I believe the concern on the mining algorithm side is met.
The client implementations (again separate from the mining algorithm) were implemented and looked over between the client teams, core devs, implementors, etc. I believe an audit is warranted for the client code, as one small bug could cause a large disruption to the network, however I also feel as though there has been sufficient review where this may be considered largely unnecessary. But what’s $50k amongst friends? (Better than all those people missing something small I suppose).
The audit also proposes reviewing the technical credentials of the mining algorithm (the part outside of consensus that generates data for consensus to work). This would be handy, but risk is lower because this can be iterated on out-of-band and released to miners piecewise as they upgrade their rigs. They will not do this all at once therefore a risk of total network disruption is small. The audit may be beneficial to ensure code quality and obvious errors are caught, but that’s probably had a fair amount of review at this point and honestly running on a testnet is better. Run it for at least a month on Ropsten with significant enough mining occuring and that is good enough to understand how it works in practice.
Lastly, the audit will evaluate the claims that the algorithm has in terms of utilizing the whole GPU (minus FP functions and some other non-standard things), it’s suitability to the task, any inherent inefficiencies with particular devices, etc. This work has largely been done (ProgPoW Benchmarked, by a Ethereum Miner!). More benchmarking and the like couldn’t hurt, but data collection from the Ropsten testnet with the final draft software configurations is probably the best measure of fitness here. Perhaps those who already have done significant data collection can provide their findings to the auditors and reduce the scope of work there.
EIP-1 should be modified to add a required section where the proposer of the EIP is asked to remark on the possible negative side-effects of his/her proposal. This won’t directly solve much, because of course, this type of analysis is nearly impossible, but it would give the Core Devs a way to easily reject EIPs. The problem with the way things currently work is that the Core Devs are put in a position of having to articulate concerns that the proposer of the EIP has neglected to address. What we want is any easy way for Core Devs to reject a proposal. Requiring a well-thought out defense of the idea in EIP-1 might provide a hook for them to do that.
For example, we could add a section to the section called “What Belongs in an EIP.” We could change the words “Each EIP should have the following parts” to “Each EIP MUST have the following parts” and include “Thorough and convincing exploration of negative impacts of this EIP on the EcoSystem.”
Things to be considered in this section might include ‘effect of the EIP on state size,’ ‘effect of this EIP on network propogation,’ ‘analysis of code complexity (effect on workload of core devs),’ ‘necessity of an audit or arguments in support of why it’s not required.’
We want to force people to do the security/cost analysis of their EIP themselves before they make a proposal, but mostly we need to provide an easy way for Core Devs for reject a proposal. “It’s not complete.”
Unrelated: EIPs should enter ‘Rejected’ state after XXX months/weeks of inactivity or failing to become “Final”.
In general, just an assessment of the risks of implementing a proposal, how impactful to the network, etc. Audits are a part of a risk mitigation strategy where their cost may or may not be justified, and which can be mitigated through other activities (testing, peer review, demos, testnet operation). There should be an understanding of the strategy to validate the change before moving forward. Too often it’s an afterthought.
I apologize in advance for what I am going to write, as I respect you and your opinions very much.
I might not be as well informed as you are, but seems the move to POS will be done in stages. Even if POS will finalize the chain, we still need mining until full POS.
POS + sharding, which even Vitalik seems to consider there might be a lot of undiscovered issues with, might experience a lot of delays, so that goal of reaching full POS, which personally I wait for a long time now, might be a few years away from us.
If you think everything will go smooth, I will post how ASIC manufacturers and their customers think this should be done from gitter ProgPoW, as it seems I didn’t get an answer from Sonia and also most people maybe didn’t notice it.
So, from their point of view, a decentralized network needs to negotiate with them the transition to POS, to be done “peacefully”.
I am guessing, and extrapolating it using my logic, same ideas/attitude will apply to any future block reward reduction, and/or any other change that will affect their sales and their customers investment and ROI.
While such radical ideas as Sonia’s can remain marginal when ASICs represent a low % of the network, and maybe even divided in the hands of many, the balance of power will change very fast when a few big entities will control most of the mining in ETH. And those entities will try to decide/interfere not only by mining, but rather they will use any mean necessary, as I feel they started to use now reg ProgPoW, to split the community over it. Wasn’t one of the goals of Ethereum and Ethash to prevent such threats and centralization from the beginning?
As far as I can tell, most people supporting ProgPoW, including myself, have nothing against an audit. I actually feel this step is needed and it will help everybody who has doubts, who cannot spend all his day researching it, who cannot test or understand what this is about, to trust the result of the audit.
But, I do have a problem with how everything has evolved until now, how we had 3 or 4 different grants, (I think two of them for WhiteBlock, which is not even in charge of the audit anymore), how everybody is confused (while actually being on gitter, on twitter, on discord, on github, on reddit, on whatever X is necessary to track the progress of it).
And the last thing that happened, with Eric and Ewan suggesting to trade ProgPoW to miners, against a new issuance reduction for funding Ethereum developement, when the foundation has become even less transparent than before, I am starting to feel that small miners like myself, who mined for POS, who mined on loss during 80 USD, and barely can keep the rigs on now, who spent time testing ProgPoW, who was against the chain split proposed by some trying to push for ProgPoW, who helps run nodes so people can connect to it for free (I do), are not welcomed and nobody cares about us.
I also start to ask myself, big guys like you involved in Ethereum, called stakeholders lately, really any decision taken should satisfy each one of you? Plus the rest of the internet? Even ones that are not related to you at all? Miners really need to take each man out there and explain: why ASICs are bad, why we are on the verge of giving up mining ether, which will lead to centralization probably, why this is a even a threat to you, why the security of a chain is coming from the power consumption to attack it mainly, and not from hashrate.
I am sorry, I feel all those are quite basic knowledge, hell, some of it are even found in ethereum white/yellow paper. And following the same logic, of satisfying everybody, who is taking our opinion into consideration?
We did twitter polls (cannot even remember how many!), and it was YES, even after GPUShack tried to manipulate it, we did coin voting, and it was YES, even after some big stake holders decided to vote with other people’s funds, we did hash voting, and it’s a YES. I also see the trend lately to consider mining and miners as being super highly dooper profitable.
Please plug in a rig, or hell, at least please have a look over whattomine.com or any other source like https://www.coingecko.com/en/coins/ethereum/mining_calculator, and let’s discuss how “profitable” it is.
So in the and, again, with all the respect I have for you, and using you to understand why this is needed for other people with no stake in mining or security of ETH chain, why do we have to convince you, considering the just mentioned signals? You have a stake in mining? You have some other concern, leaving out the governance issue which seems to apply to this, but not other EIPs? Who will take OUR opinion into consideration? Who will satisfy us?
So yes, we find our-self in a dead-end it seems. Same dead-end that might make POS transition harder, under current conditions, and much harder, under Linhzi’s conditions.
