Fully in support of needing a (well-defined and scoped) audit before moving forward with ProgPoW
And included in that audit we should look into the ASIC-resistance claims of ProgPoW and see if they actually stand up to scrutiny. See recent detailed write-up by Linzhi:
https://medium.com/@Linzhi/eip-1057-progpow-open-chip-design-for-only-1-cost-power-increase-eip-1057-progpow-d106d9baa6eb
I guess most of us would like to avoid to trade our ship’s 
diesel engine for that experimental new different technology diesel engine or maybe even warp drive w/o having a clear understanding of the risks associated with that.
This change might have a broad effect in multiple dimensions and various groups have various incentives to either oppose or favour it. That’s to some extend also the problem and should be carried to a different battlefield (“political discussion”). I see people criticising every aspect of the ProgPoW discussion(s) for various reasons and hidden agendas, even the scoping gets its fair share of critics but unfortunately only the minority appears to be contributing or even working on an objective solution, still everyone would like to have one.
If it is likely that ProgPoW happens for whatever reason that might be we should make sure to fully understand the risks, be prepared and treat them appropriately (this includes potentially agreeing on accepting risks if the community wishes to do so - given it permits others to reduce their own risk e.g. by withdrawing their stake from the system). Accepting risks w/o knowing them feels like a bold move - not sure if that would be seen as a trust building exercise. Not doing security due diligence is negligent as summarized by @tvanepps:
Funding: The problem with peer-to-peer relationships appears to be that responsibility (e.g. in preserving the future of the ethereum ecosystem) is distributed across so many people that in the end nobody feels responsible - most people waiting for the others to make a move. It is even kicking off “why should I/groupX fund this” discussion ignoring the fact that we are in this all together. I wonder if this will work out in the end.
Since we’re already discussing security here I’d like to remind people that @boris set up a security discussion slot at the Istanbul & ETH1x Roadmap Planning Meeting - April 17th & 18th in Berlin. Participate, criticise AND contribute/discuss potential solutions.
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.
ASIC resistance claims analysis is part of the audit proposal: https://github.com/ethereum-cat-herders/progpow-audit/blob/master/Least%20Authority%20-%20ProgPow%20Algorithm%20Audit%20Proposal%20(v2).pdf
I’d kindly like you to list all the risky changes, along with some evaluation (chance of exploitability / impact if exploited) that have been merged in the clients over the last 12 months (or more if you like). Chance of exploitation is a “?” in progpow, and impact if exploited is beyond imagination.
Copying this here for reference in the hopes that it makes the discussion a bit less fragmented. ProgPow discussed on the AllCoreDevs Gitter: https://gitter.im/ethereum/AllCoreDevs?at=5c9e6a374de4296efc201237
Ideally, let’s keep the discussion here, but I wanted to share the parallel one that happened.
Exactly. If an audit is needed for all “critical” EIPs across the board, we should explore how to ensure that happens, what “critical” means, and how to fund it on a regular basis.
Just take a look at the hard fork meta EIPs. Most of the changes affect the VM, and so have much higher risk than a change to the PoW algorithm.
Also, please define what “exploit” means.
Here’s a few:
The Mitigation for all 3 of these is that we just fork back the old code, which is the same as any other EIP. This is hopefully caught beforehand by extensive testing. If it’s not, this is our mitigation.
Yes, it incurs huge overhead costs, but so did Constantinople, and with the intense amount of eyes on this particular proposal, I expect it to have less show-stopping bugs than most other proposals in recent history (otherwise those against would’ve found something by now). If you disagree, look through the proposal and find some bugs. If you don’t feel comfortable doing that, you contribute money to the audit and we get some professionals to do that for us.
Security isn’t magic. It’s hard work. It requires money. This EIP is no different than the others in having problems with funding or security review. If it’s a showstopper for this EIP, I propose all progress on Istanbul EIPs should be stopped until we figure out a way to make sure all get the level of attention and expert review that this one is getting.
Most of the issues surrounding ProgPoW have been entirely political in nature. Based on our (Whiteblock) preliminary evaluation of ProgPoW, I think that basic benchmarking would likely be fairly useless. Most of the code I reviewed in ProgPoW appeared to be harmless at face value, but one thing I saw that really concerned me (not sure if this has been changed since or not) is how it handles randomization. If anything, this should be thoroughly vetted and highly scrutinized. Frankly, I’m surprised no one has brought this up yet (to my knowledge). I’ve kept out of these discussions as much as possible because I don’t want to get involved in a political war, so I’ll just leave it at that.
It would be absolutely, positively, foolhardy to implement ProgPoW without an audit.
Needless risk.
Let’s not do it.
Well, this is my biggest worry - that this change can dominate the next upgrade (or two, if it does not end up going to the first one, or three) for all the wrong reasons. Not because it is urgent, or something is broken, but because someone wanted it and someone else said “Yeah, OK, why not”.
Summary of the entire problem with EIPs right here.
Will you fund security reviews for all EIPs?
They all affect the operation of the network just as much as this one does. Why does this proposal need special treatment? We have the same mitigations in place (forking back to the original) available to us as we do for any other mistakes that get made!
I definitely think an audit is necessary, but I also think audits are necessary for every EIP, not just politically contentious ones.
And that pre-audit decision was never made or not articulated clearly - precisely what I was afraid of!
Cross post from https://gitter.im/ethereum/governance
“I care about rational arguments.”
“Phil Daian’s essay is rather convincing. It would have been more useful before January.”
This seems sort of comical. Sorry to single you out @gcolvin, but here you’re basically admitting to not caring about rational arguments and excusing yourself for making the decision without considering them.
Much rational. Such logic.
As for @mhswende’s arguments (My stance on Progpow):
Community. As far as I’ve seen, most signals point to ‘the community’ wanting to go ahead with progpow.
This is the signaling argument you don’t like, right? Also our discussion over the last week points to more contention than I most ProgPow proponents expected. Most of us didn’t even realize that the ProgPow decision had “been made” back in January.
Known “evils”. If we switch to progpow, we will keep the ‘same’ ecosystem of miners around.
Who cares? The GPU miners will have their issuance reduced in the coming year anyways as PoS starts to provide finality for the PoW chain.
In my view, a hardfork which updates ethash-hashimoto to ethash-progpow will be the simplest fork we have ever done.
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.
Ethereum has historically been aimed to be ASIC-resistant… to me, this means that the ‘conservative’ route forward is to keep this model. And conversely, if we are to change this model, then the burden of proof for why we should change this model is on the progpow opponents.
Yea, we should allow ASICs temporarily because:
We’re well on our way to PoS securing the PoW chain, so the ROI on this change is negative for the community (due to coordination cost), and only positive for GPU miners. The ASICs will lose their relevancy over the next 1-2 years.
ASICs do not represent an existential risk at this time, and I don’t understand the fear that ProgPow proponents have of ASIC manufacturers trying to impede PoS. Like, let’s say we start to see more miner centralization, and then they attack the PoS transition by not going along with the fork… who in their right mind would want be on the centralized miner chain instead of the PoS chain, or at least the PoW chain secured by PoS in the meantime?
audits are necessary for every EIP, not just politically contentious ones.
This is a change in the core algorithm (never been done on Ethereum). It seems like a full order of magnitude more risky than the typical EIP change.
That’s the big point of contention I don’t think people understand. In terms of raw technical risk, it is actually fairly small. Most of the implementations have been completed in under a week, and the engineers are fairly confident in them at this point. There is huge execution risk, in that a small mistake could have a major impact. Execution risk is purely short term. If we do a good job, test it, and get it right, that risk does not carry over longer term.
At this point I agree an audit would be a good part of an overall security strategy for this EIP, and a good part of reducing the potential for high impact to the network. The audit proposal, as written today, is extremely broad as far as security audits typically go, including evaluating such claims as “providing better decentralization”. I wouldn’t modify the proposal at this point, but I would say that the majority of the claims to be evaluated have largely been debated and discussed in the community at large and most have been resolved, at least to my knowledge. These claims have very little to do with the software codebase, which is a software security firm’s primary expertise. I expect the debate to continue afterwards, but at least we can all get happy with the code being as well-crafted as possible.
A majority of EIPs affect the core consensus algorithm through EVM execution, which is notoriously difficult to get correct, hence the massive test suite that we have. Many EIPs are way more difficult than this change. We are absolutely underfunding security review across the board for EIPs.
So you are barking at me here too.
If you had understood the discussion on ethereum/governance after your selective quoting you would gotten that I learned that I was mistaken about the date of the paper, that I had seen the same arguments in other places, that those arguments weighted some factors differently than I did, and that there were other arguments that I and others considered that Phil did not. In the end, after over 7 months of discussion on public forums I chose to support ProgPow.
Now you come along four months later questioning my rationality and intelligence.
Please, stop trolling me or get out of here. (@jpitts)
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:
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.
https://twitter.com/ameensol/status/1111777587695501312
Also here are some screenshots of the notes from the core devs calls.
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.
