Hey all! I have an important topic for discussion.
We ran into issues starting the ProgPoW audit. We had a hardware partner who specialized in ASICs who was going to work with Least Authority to perform the hardware parts of the audit. They are no longer participating in the audit so we are looking for other auditors for the hardware portion. We have some good candidates, but this effectively delays the start of the audit much more than we anticipated. Because of this I am unsure if the audit will be complete before Istanbul. On top of that I am not sure if anyone has sorted the funding situation in order to build an open source ProgPoW miner.
We have 2 options:
Delay ProgPoW until the hardfork after Istanbul.
Have ProgPoW as it’s own hardfork to be implemented once the audit is done.
This is not an ideal situation at all, but despite our best efforts it is what we have before us.
This post was also posted in the AllCoreDevs Gitter chat (https://gitter.im/ethereum/AllCoreDevs) for further feedback.
I think a lot of people on both sides of this issue have discussed having this proposal implemented in it’s own fork to prevent contention from interfering with the long list of proposals for the Istanbul fork.
Obviously that is not ideal, since it involves a lot of coordination outside of a fork window, but I think the next fork is likely to have something related to the Beacon chain finality gadget (unless that is it’s own fork as well). I would prefer having this one proposal be it’s own chain in between scheduled hard forks instead of pushing this to the next one.
Maybe it’s time to leverage @shemnon’s hard fork schedule proposal…
A GPU based GPL licensed miner exists for 0.9.2. It’s not the most optimized miner, but it’s ballpark, enough for a hobbyist. It shouldn’t take much to upgrade it to 0.9.3 or whatever recommendations come out from the audit.
And by non-ASIC, we mean client implementation, which is arguable the most important part that everyone is worried about when they asked for the audit. It also happens to be the smallest and not require special hardware expertise to evaluate.
There’s also the issue of validating that the cryptography was used properly. And that is not a client implementation issue. Going from keccak-1600 to keccak-800 is one example of a non-trivial crypto change that would require a second set of eyes to say “that was done correctly.”
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.
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.
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.
