It is crucial to the longevity, decentralization, and consequently valuation that we improve the security of the current PoW algorithm by moving to ProgPoW or even something better
I would be persuaded if it could be demonstrated that a seed wider than 64 bits would have favored one GPU architecture over another, and that was why the small seed size was chosen, or for some other defensible reason, considering that weāre talking about cryptography here and itās common knowledge that 2^64 work is not a lot. I never cared that the majority of the creators were anonymous, but now I do think itās a shame that this Class-A mishap wonāt follow their names.
Iāve published a crypto algorithm myself (for purely academic purposes) and when it was shown to have less than the intended strength for keys larger than 128 bits, I didnāt do a quick fix and sweep the issue under the rug (even though I had already disclaimed its security from the beginning).
SHA-1 will always be broken, so will my algorithm, and so will ProgPoW. You canāt use the same name for an algorithm that produces different results. Especially after being in the wild for so long.
The way forward is to choose a new algorithm and deploy it in a reasonable amount of time, not to invoke Schneierās Law or argue semantics about which rectangle-shaped openings are doors and which are holes.
Iām very much a software guy and not a hardware one (Iāve never mined), but I would be open to contributing to the effort to the extent I can, because Iād rather not just be a bitch online, like I am currently, expecting something for nothing.
I fear it is too late to develop an alternative to ProgPoW before ASICs have already come to dominate the network, let alone subject it to as much review as ProgPoW has seen.
If finding and fixing a bug is a reason not to ship software very little software would ever ship. Especially a bug that was not practical to exploit. But if you are convinced that ProgPoW is irretrievably broken please do convince the rest of us - Iām not sure whether you are arguing against the soundness of Ethash or the ProgPoW extension to Ethash.
2 Likes
I agree, something needs to be done in short order. Also there is now an EIP proposal to reduce mining rewards. Any reduction in rewards will only further increase the ASIC dominance of the network as they have a significant cost advantage to GPUs.
My point is that if the developers of SHA-1 years after its initial release into the wild tweaked it, published new test vectors, and insisted in calling it SHA-1, they would be laughed out of the room.
Aside from being unnecessarily confusing, itās deliberately horrible marketing at a time when marketing is the single biggest impediment to Eth shipping a new algorithm. At the very least Ethereum should not refer to this modified algorithm as ProgPoW despite what its authors choose to call it, given its significant perceived baggage.
Or do what SHA-3 did with Keccak: make a trivial change to some constant making āEthash 2.0ā incompatible with New ProgPoW ā fork a variant off and take ownership of it.
Iām not sure I follow you, @esaulpaugh, but the authors donāt currently plan to change the name of the proposed algorithm because a minor exploit was discovered and fixed. The proposal is not yet Final, so is subject to change.
EIP-1057 PR for review ahead of All Core Devs call. Incorporates Andrea Lanfranchiās implementation of the Kik exploit fix.
The reference implementation is on @ifdefelseās repo at
Maybe my math is wrong but using progpow epoch length of 30000 and 13 sec block time, only 2^64 / (30000 * 13) = 2^45 work per second is required to exploit the speedup. For reference, I believe that the bitcoin networkās total work per second recently peaked at around 2^67 (140 exahash) per second.
So it would require a mining pool with 0.00002% (1 / 2^22) the power of the bitcoin network to exploit.
For a very rough idea of the kind of resources weāre talking about, 0.00002% of bitcoinās current market cap is about $50,000. And Mooreās Law is still in effect for this kind of parallel computing.
Is there a good reference for this exploit being minor?
EDIT: Iām not aware of the exploit requiring 2^64 storage, but at $15 a terabyte and letās say 8 bytes per slot, that would cost about $2.2 billion, or 5% of Ethereumās market cap or 0.015% of Chinaās 2019 GDP.
@esaulpaugh ā I call the Kik exploit āminorā because my understanding is that the upshot of the discussion was that:
- The exploit would not allow for chain reorgs or DoS.
- The exploit is not practical or cost-effective.
- If an exploit did succeed it would only impair ASIC-resistance and thus allow for ASICs much faster than GPUs and profitable secret mining.
@jcyr considers it significant in that it was missed by reviews and audits. @OhGodAGirl considers it a bug that has been fixed ā not an unusual thing for software. More discussion here.
Some important references:
kik/progpow-exploit
ProgPOW/issues/51
ProgPOW/issues/54
ProgPOW/pull/52
well it seems to come down to whether the precomputation has to be done every block or only every epoch. if itās every block then that conceivably might limit the attack to nation-state-sized actors, at least for a few years until Mooreās Law catches up. In the cryptography world, thereās no reason you would ever settle for that level of security unless you absolutely had to (e.g. export laws, or to avoid a massive cost such as a backwards compatibility nightmare). And before anyone says anything, yes, preventing 51% attacks is an issue of security.
Anyway, Iām glad that it wonāt be an issue in ProgPoW 2 and beyond.
Though in the absence of a definitive answer to the (2 to the) 64-thousand-dollar question (preferably from a cryptographer), it would be irresponsible for anyone to suggest that the attack isnāt practical. And as the old saying goes, attacks never get worse, only better (supposedly that came from the NSA)
The vulnerability has been fixed. This attack vector is no longer an issue. (Yes, the code can always stand more review and testing.)
What about current state of Ethash in light of the many successful attacks on ETC? What %risk is Ethereum likely to be attacked as ASICs go to end of life at POS considering they now control 45% of hash?
Can we definitively say that original ProgPoW is no longer used anywhere in the wild? I know that some small coins used it as their mining algorithm at one point.
1 Like
Raven is running a slightly modified version of progPoW, @esaulpaugh
1 Like
Who are these people supporting ASICs that have no idea what they are talking about when it comes to GPU mining?
You might want to do a little more research.
There are way too many unknowns there for me to guess at probabilities, @CryptoBlockchainTech.