A Perspective on ProgPoW
A lot of research was done into ProgPoW and to whether it protects the incentives of the network participants (common and commercial miners). We believe it does. We also stand by our initial statement — proof-of-work was created to ensure decentralization. The Proof-of-Work section (4) of Satoshi’s white paper makes this clear:
“If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains.”
ProgPoW addresses the problem of centralization by minimizing the benefit of specialized, secretly-developed ASICs. A simpler algorithm benefits those developing a secret ASIC. Those who say simple algorithms allow competition are misunderstanding the hardware ecosystem. Some have correctly assessed that algorithm simplicity amplifies the advantages of economies of scale, and silicon allocation deals with large players. Readers should assess for themselves who best is able to evaluate the economy and challenges in hardware.
As part of its review process, ProgPoW was submitted to (and reviewed by) both AMD and NVIDIA engineers. The group known as IfDefElse — of which I am a part of — has been actively working with both companies to ensure this effectively closes the efficiency gap that we speak publicly of in our papers and articles. We have also had discussions — as a group, or as individuals — with David Vorick, Howard Chu, and GPUHoarder, seeking advice and input into ProgPoW.
ProgPoW has been designed to be a vendor-neutral proof-of-work, or more specifically, proof-of-GPU. ProgPoW has intentionally advoided using features that only one core architecture has, such as LOP3 on NVIDIA, or indexed register files on AMD.
The OpenCL and CUDA implementations are equivalent, except for one detail: OpenCL uses local memory to exchange the global load address, while the CUDA implementation uses a __shfl instruction to do a direct exchange. We have publicly reached out to AMD and believe we have a method of doing a similar, direct exchange. AMD is actively working with us to optimize ProgPoW for their architectures.
We have been extremely open with the code and work to minimize any first-mover advantages. Networks are free to take the first-mover implementation and make their own optimizations or changes.
Now, let’s talk about my motivations.
As most of the community at scale knows, I have worked independently with many companies on cryptocurrency developments and hardware. OhGodACompany — which is less of a company, and more of a group of individuals banding under a common flag — has provided optimizations, consultancy, sales avenues and friendly discussion for the groups and individuals like Genesis Mining, Nebulous Labs, AMD, NVIDIA, MSI, GALAXY and Sapphire Technology.
We created OhGodAnETHlargementPill, which applies the same sort of optimizations we have previously done to AMD architecture with custom firmware. We have also created Mineority, an all-in-one platform providing hardware-at-scale to smaller miners, leveraging our past experiences and technical-fu to allow individuals to compete with large scale companies and bring back decentralization to the mining community by allowing everyone access to the same hardware, the same software, and the same optimizations.
As an individual, I participate in both Mineority, OhGodACompany, and ProgPoW. I have previously worked for Genesis Mining, and previously consulted for many companies (some of which are listed above). ProgPoW affects my team in that it makes most of the optimizations that Mineority (and OhGodACompany) provides useless. ProgPoW also hurts the work I do in FPGA and ASIC optimization and development. And yet, I support it because it gives networks a fighting chance to figure out what to do with this centralized-hardware situation.
Who would you rather have working on part of a proof-of-work algorithm designed for commodity hardware — someone who has made their living optimizing and designing for this space, or someone who is completely new to it? This was a key point in the article — traditional algorithms are designed by people who don’t have experience in hardware development and design, and thus only think they know how to discourage ASICs.
We — collectively, as Mineority, OhGodACompany, or whatever banner we choose to fly — are, first and foremost, cryptocurrency idealists, and we want to ensure there is a way of protecting networks to allow different consensus methods to exist, and be developed (like Casper FFG) in a space where they will not be attacked by centralized entities.
No matter what, people will always point to whatever business I operate with as having ulterior motives — whether it’s Mineority, or OhGodACompany, or just plain old Kristy Inc. — because cryptocurrency is inherently a space that is built on mistrust in corporations and companies. I am very public in what my motives (and my company’s motives) are: making, creating, and supporting badass shit. And ProgPoW?
