@souptacular emailing progpow-audit@leastauthority.com didn’t work for me (delivery failure, you may not have permission, may need to join, group may not be open to posting).
Referring to the initial audit, dated 16 August 2019
Key Omissions
1. Most of the Areas of Concern (p.3) not addressed:
Security of the algorithm: “security” not defined.
Cost of a 51% attack: No reasonable calculation attempted.
Other security risks from a change of PoW: Not attempted.
Impact on “fair mining” and uneven distribution: No calculation.
Possible changes to hash power and miner balance: No data, no calculations.
Other potential effects impacting the ecosystem: Not attempted.
2. No measurement for “centralization” proposed or attempted
How centralized is the 170 TH network today, how could one model the effect of ProgPoW towards centralization?
3. Background and motivation of ProgPoW proponents not considered
The ProgPoW author is CTO of Craig Wright’s hosting company Core Scientific. Together with two anonymous co-authors.
The identities and motivations of the ProgPoW team remain a mystery and were left out of the audit.
Serious consideration of Core Scientific’s and Nvidia’s business interests with regards to ProgPoW are warranted to understand security implications.
4. No definition of “attack” proposed
PoW is a control vector for the entire decentralized network.
Measurement of real-world centralization is a prerequisite for the mitigation of attacks. “Attack” needs to be defined. An optimization of the PoW algorithm, sold in an ASIC, is not an attack in our opinion.
“Attack” is not when someone openly plays by the rules. “Attacks” come from behind. A trojan horse is an attack.
5. Economies of Scale
The audit does not clarify whether economies of scale are seen as positive or negative factors towards decentralization.
Details
1. Random & Pseudo-Random
p.5 “Our review and analysis results in our agreement that the KISS random number generator is sufficient to make the sequence of math in the main loop unpredictable”
KISS is a pseudo-randon number generator. The difference between random and pseudo-random is fundamental. The audit uses the term “random math” 8 times. One would hope that everyone understands that this is pseudo-random and thus predictable.
If it was unpredictable as the audit states, it would be unverifiable.
With traditional PoW one needs to remember that no matter which calculation the algorithm performs, it needs to be verifiable, meaning it needs to derive from a seed.
2. Keccak optimized for 32-bit
p.4 “We examined the hash function, a non-standard instance of the Keccak function that is optimized for 32-bit architectures”
The audit fails to ask the question why the change to the non-standard 32-bit optimization may have been made.
With sufficient and actual study of the business interests of the parties involved and their potential agendas, we came to the conclusion that 32-bit multiplication was pushed under the pretense of it being inefficient on both Nvidia and AMD but that turns out to be a lie as on Nvidia it was only inefficient on Pascal. The algorithm is tuned to still let Pascal utilize full memory bandwidth due to simply sheer compute capacity difference coming partially from higher die size which is why comparing GPUs based on price is being pushed as of late. It’s not a secret that 4xx & 5xx series AMD GPUs are not high-end but because ProgPoW’s compute to memory bandwidth ratio is tuned to match Nvidia GPUs, AMD GPUs are not utilized to their fullest, most importantly losing the full memory bandwidth utilization which is the very basic foundation of the Ethash algorithm.
3. Limiting Efficiency Gains
p.7 “the circumstances in ProgPoW are much more favorable due to the additional random math core”
p.7 “the random math core likely prohibits the build of a light-evaluation based ASIC”
p.8 “the additional use of random math sequences extends the ASIC resistance of Ethash substantially”
These statements support the key ProgPoW claim (from the EIP) that ProgPoW results in “minimal, roughly 1.1-1.2x, efficiency gains. This is much less than the 2x for Ethash”.
Both the EIP claim as well as the auditor’s confirmation of that claim are wrong. The pseudo-random math core increases the efficiency gains an ASIC can achieve, because an ASIC can implement the math logic more efficiently than a GPU.
4. Sarah Osbourne
p.17 “Sarah Osbourne Response to the Linzhi ASIC post”
The audit cites the Sarah Osbourne response in the rather short list of third party resources consulted for the audit.
How can an account that was created the day before the post, and has since only posted that one response purporting to possess highly specific knowledge about ProgPoW and GPU/ASIC design,
not be further scrutinized?
Who is “Sarah Osbourne”, who pays her/him/them, what is the agenda?
If the people that are behind “Sarah Osbourne” are in fact Nvidia or Core Scientific employees, writing under pseudonym has the pleasant side-effect of not even affecting their reputation, shall the response be proven wrong. We would just prove “Sarah Osbourne” wrong, an anonymous one-post-only person from the Internet. Then the next anonymous person would show up with new claims.
What is happening here is FUD marketing. The Sarah Osbourne response is the “D” in FUD - doubt. It’s written to cast doubt over the Linzhi post, and does so effectively.
We have removed the intentionally deceptive Sarah Osbourne post from under our article.
Trust Sarah Osbourne or trust Linzhi or trust neither of us and verify yourself.
5. Asymmetry of Proof and Verification Workloads
p.10 “it would change the amount of cycles required for verification”
The asymmetry in workload between proof and verification is a key attribute of PoW. The audit fails to show to which degree ProgPoW worsens the asymmetry, which impact this has on mobile clients and how one could model the impact of this on the decentralization of the network.
6. Programmatic and Programmable
p.8 “The rationale of extending Ethash into a programmable PoW, by integrating a random math core”
ProgPoW is not “programmable” as in the typical meaning of that word among software developers. It cannot be programmable because it would then be unverifiable.
A real programmable PoW would need to store the program along with the proof, and define a system of verifying that the program was executed in less time than the actual execution, similar to a zk-proof.
ProgPoW adds a convoluted pseudo-random math logic to Ethash.
