EIP-ProgPoW: a Programmatic Proof-of-Work

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.

T’was mostly rhetorical, and this is my research

Wait, is this directed at me? Hahaha, if you actually read past the first sentence you can see I’m supporting the exact opposite. Don’t be cringe.

@CryptoBlockchainTech With a handle like yours and a mining background you should be able to find the flaw in my math almost immediately, considering that I’ve never mined anything in my life.

You an start by expressing your thoughts on the posts looking to change POW algos. Here are two recent posts:

These are discussions about changing POW and not about ProgPow