ProgPoW Audit Delay Issue

Yeah, but the auditors have the expertise to audit this. Also, they’re still inspecting the client implementation. If the miner is broken, someone will just fix the miner. They’re wayyyyy incentivized to do so, plus they can do it without having to hard fork unlike us.

The smart closed source miner teams are already ready for this. Miner software is heterogeneous enough in the wild not to be an existential risk, unlike the client software.

1 Like

Seems like ProgPoW should get as much scrutiny as Ethash did, or less, considering that it’s a derivative. Are we going overboard?

1 Like

They are no longer participating in the audit so we are looking for other auditors for the hardware portion

Would be interesting to explain why the auditors abandoned. I really don’t think professionals abandon a project without any reason.

2 Likes

This is really speculative and bordering on conspiracy imo, there are many external factors that can explain this that have nothing to do with progPow. Of course they don’t abandon for no reason, it doesn’t imply the reason had to do something intrinsic to progPow. Internal things in the company are most likely to be the cause.

I was kind of surprised that a hardware audit was also required. As long as the client implementation is secure won’t the network be secure? Miners are used to making miner software, they will iterate and are also invested in the security of their own software.

So why simply not disclose ?
Any reason like :

  • They don’t have time
  • They don’t understand what to do
  • They consider themselves not competent
  • They asked for more money
  • Whatever …

I’m not speculating but I’m fed up with governance’s lack of clarity

4 Likes

The intent of the “hardware audit” was more to assess the claims by the creators of the algorithm that ProgPoW makes more complete use of GPU hardware than Ethash does. There are a lot of technical claims made, which sound reasonable, but I think opponents wanted an independent assessment of them. We arguably don’t need to pay auditors to do this, anyone with the requisite experience can do this sort of assessment. The problem is finding someone with the requisite experience. Most people in our community don’t have the deep hardware design experience to do this, so we have to rely on the claims of overall chip usage by the designers.

Absolutely, from a software perspective this audit will show that the implementation of the algorithm is secure enough for a public deployment. Mining software can be iterated on, and the overall mining software ecosystem will be heterogeneous enough to protect against catastrophic failure. However, assessing the claims made by the algorithm designers I think is more what people wanted to know about, and this audit will only partially provide that without hardware experts.

Sorry for potentially over reading this. I feel you on lack of transparency. I don’t know where the information disconnect is so hard to know where the the lack of transparency lies.

Thanks for clarifying. Kind of funny to me that progpow is possibly

  1. the most scrutinized mining algorithm in the space. I certainly don’t know of another that will receive audits
  2. The furthest EIP, as far as progress, on the list considered for Istanbul

And also the most likely to be kicked from Istanbul

I know there are commitments that have been made, and respect Hudson’s efforts in keeping them. It still makes me chuckle a little bit.

edit: added a diagram

2 Likes

I’ve stated (too) often that we accepted progPoW in early January and I have never understood how an audit became an obstacle. A hardware audit seems particularly pointless, as if someone knew how to beat progPoW in hardware they’d do better to keep their mouth shut and make some money. I wish we had called this progEthHash–it might have just sailed on through.

8 Likes

Option 3. Release ProgPoW in Istanbul without an audit.

3 Likes

Absolutely. The problems with this proposal are almost entirely social. The audit will help validate the technical implementation, which I think is important given the criticality of this functionality to our overall security, but the audit simply cannot address all the issues that opponents have because they’re mostly social and have to do with trust. I don’t know how to solve that, other than simply educating others on what it’s all about and keeping things fact-based. In the end though, it’s a social decision, and the only tool we have that we know works for this scenario is hard forking. That’s one of the reasons I believe it should be in a separate fork from Istanbul, to make it very clear accepting the update is approving of it.

We could potentially soft fork it… If enough miners adopt it, it’ll be the longest chain. Something of that nature would be interesting.

2 Likes

Ethash, the algorithm ProgPow is aiming to replace, received an audit from Least Authoruty in 2015: ethereum-analyses/PoW.md at master · LeastAuthority/ethereum-analyses · GitHub

My advocacy for ProgPow has always been conditioned on the audit. If ProgPow is going to get into Istanbul without an audit then someone else will need to step up as champion on the calls.

3 Likes

The technical audit as a requirement makes sense.

I also know people think/want the audit to answer a larger set of questions it’s simply not adequate to answer, as they are more philosophical in nature (should we support the current miners by doing this?) or just hard to quantify (when does Ethash ASIC hashrate take over the network?)

Not really clear why Ethash audit was completed successfully by Least Authority single-handed, but ProgPoW audit requires "hardware partner who specialized in ASICs ".

1 Like

Hi from Gitcoin. We are paying out 13k DAI in CLR matching for this grant ( buidlbox ) this week. this is in additoin to the 15805 DAI raised on the grant already.

4 Likes

Did Constantinople get an audit? Will the next hard fork? Is everything getting a long, expensive audit now, or just ProgPoW (despite there being overwhelming support)?

1 Like

We don’t have a process for what deserves an audit. There are definitely examples of past EIPs that should have had an audit, due to deeper complexity that could cause adverse behaviors if not implemented correctly. I think ProgPoW meets the cut for that, because while it is a very simple change, if it is not done correctly it could reek havoc and stall the chain or affect the security of it in some way. So I support the audit.

Regardless, it does seem like some opponents promoted the audit as a method to block implementation into the next fork, hoping for a death through bureaucracy. This is unfortunate because it does have wider support. The audit was reduced in scope to only technical correctness for this reason.

1 Like

I think the request for the audit of ProgPow has set the standard that anything that replaces or significantly modifies the base consensus layer needs an audit (base consensus, not including EVM execution and state syncing, i.e. “payload”). So we should plan now for a beacon chain audit and a beacon chain finality gadget audit and just put those in our mental project plans.

2 Likes

Yup, that definitely seems consistent.