ECIP-1049: Change the ETC Proof of Work Algorithm to Keccak256

[p3c-bot]

THIS PROPOSAL IS MERGED DISCUSSION HAS BEEN MOVED TO HERE

What is an ECIP?

ECIP: 1049
Title: Change the ETC Proof of Work Algorithm to Keccak256
Status: Draft
Type: Network
Discussion: https://github.com/ethereumclassic/ECIPs/pull/8
Author: Alexander Tsankov ([email protected])
Created: 2019-01-08

Abstract

A proposal to replace the current Ethereum Classic proof of work algorithm with Keccak-256.

Motivation

• A response to the recent double-spend attacks against Ethereum Classic. Most of this hashpower was rented or came from other chains, specfically Ethereum (ETH). A seperate proof of work algorithm would encourage the development of a specialized Ethereum Classic mining community, and blunt the ability for attackers to purchase mercenary hash power on the open-market.

• As a secondary benefit, deployed smart contracts and dapps running on chain are currently able to use keccak256() in their code. This ECIP could open the possibility of smart contracts being able to evaluate chain state, and simplify second layer (L2) development.

Specification

Reason 1: Similarity to Bitcoin

The Bitcoin network currently uses the CPU-intensive SHA256 Algorithm to evaluate blocks. When Ethereum was deployed it used a different algorithm, Dagger-Hashimoto, which eventually became Ethash on 1.0 launch. Dagger-Hashimoto was explicitly designed to be memory-intensive with the goal of ASIC resistance [1]. It has been provably unsuccessful at this goal, with Ethash ASICs currently easily availalble on the market.

Keccak256 (aka SHA3) is the product of decades of research and the winner of a multi-year contest held by NIST that has rigorously verified its robustness and quality as a hashing algorithm. It is one of the only hashing algorithms besides SHA256 that is allowed for military and scientific-grade applications, and can provide sufficient hashing entropy for a proof of work system. This algorithm would position Ethereum Classic at an advantage in mission-critical blockchain applications that are required to use provably high-strength algorithms. [2]

A CPU-intensive algorithm like Keccak256 would allow both the uniqueness of a fresh PoW algorithm that has not had ASICs developed against it, while at the same time allowing for organic optimization of a dedicated and financially commited miner base, much the way Bitcoin did with its own SHA256 algorithm.

If Ethereum Classic is to succeed as a project, we need to take what we have learned from Bitcoin and move towards CPU-hard PoW algorithms.

At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. - Satoshi Nakamoto (2008-11-03) [3]

Note: Please consider this is from 2008, and the Bitcoin community at that time did not differentiate between node operators and miners. I interpret "network nodes" in this quote to refer to miners, and "server farms of specialized hardware" to refer to mining farms.

Reason 2: Value to Smart Contract Developers

In Solidity, developers have access to the keccak256() function, which allows a smart contract to efficiently calculate the hash of a given input. This has been used in a number of interesting projects launched on both Ethereum and Ethereum-Classic. Most Specifcally a project called 0xBitcoin [4] - which the ERC-918 spec was based on.

0xBitcoin is a security-audited [5] dapp that allows users to submit a proof of work hash directly to a smart contract running on the Ethereum blockchain. If the sent hash matches the given requirements, a token reward is trustlessly dispensed to the sender, along with the contract reevaluating difficulty parameters. This project has run successfully for over 10 months, and has minted over 3 million tokens [6].

With the direction that Ethereum Classic is taking: a focus on Layer-2 solutions and cross-chain compatibility; being able to evaluate proof of work on chain, will be tremendously valuable to developers of both smart-contracts and node software writers. This could greatly simplify interoperability.

Implementation

Work in Progress:

Example of a Smart contract hashing being able to trustlessly Keccak hash a hypothetical block header.

Here is an analysis of Monero's nonce-distribution for "cryptonight", an algorithm similar to Ethash, which also attempts to be "ASIC-Resistant" it is very clear in the picture that before the hashing algorithm is changed there is a clear nonce-pattern. This is indicative of a major failure in a hashing algorithm, and should illustrate the dangers of disregarding proper cryptographic security. Finding a hashing pattern would be far harder using a proven system like Keccak:

Based on analysis of the EVM architecture here there are two main pieces that need to be changed:

1. The Proof of work function needs to be replaced with Keccak256
2. The Function that checks the nonce-header in the block needs to know to accept Keccak256 hashes as valid for a block.

After doing further analysis it the best way forward to begin work is to implement this change in Multi-Geth instead of any other client. This is because Multi-geth is organized for multi-chain development, it seems to be more recently updated than classic-geth, and it is designed to be used with alternative consensus methods- which is necessary for implementing ECIP-1049.

The area where most of the changes will be in multi-geth/consensus

References:

1. https://github.com/ethereum/wiki/wiki/Dagger-Hashimoto#introduction
2. https://en.wikipedia.org/wiki/SHA-3
3. https://satoshi.nakamotoinstitute.org/emails/cryptography/2/
4. https://github.com/0xbitcoin/white-paper
5. 0xBTC Smart Contract  EthereumCommonwealth/Auditing#102
6. https://etherscan.io/address/0xb6ed7644c69416d67b522e20bc294a9a9b405b31

[saturn-network]

IMO ProgPow would be a better option.

1. SHA3 is super easy to develop FPGA and ASIC miners for.
2. Another hashing function is trivial to add to EVM as a precompiled contract provided there is need for it.

This ECIP could open the possibility of smart contracts being able to evaluate chain state, and simplify second layer (L2) development.

This is already possible and has nothing to do with choosing hashing functions for PoW consensus. What matters is which hashing function was used to link to previous block (block N+1 must contain hash of block N) which is already keccak256 and can remain keccak256 even if you change the hashing function used for PoW in Nakamoto consensus.

If ETH changes to ProgPow IMO ETC should change as well in order to be better positioned to absorb Ethereum's hashrate once ETH switches to PoS.

[drd34d]

@saturn-network I used to be supportive of ProgPoW too but come to realize that if the algo can be programmatic, then so will the next gen of ASIC's. Like an hybrid of FPGA and ASIC. Thus, ProgPoW would be a temporary solution. ETH adopting progpow will definatelly be the necessary incentive for R&D of such hybrid.

Also, @saturn-network I wouldn't trust ETH chain as a verification point, for obvious reasons. Apparently there's a similar application on the Komodo network which used the BTC chain but I haven't read it properly yet.

@p3c-bot - SHA3 ASIC design from 2012

• http://rijndael.ece.vt.edu/sha3/publications/DATE2012SHA3.pdf

[saturn-network]

@drd34d the whole point of ProgPow was to design an algo that uses so many of the GPU features that efficiency gains from a specialized ASIC (that you need to invent and manufacture) would be so little that it would not pay off.

In bitcoin's case, it came out with SHA256 and people developed ASICs for it. In progpow's case it's all upside down - it is an algorithm developed for an already existing "ASIC" chip. The best ASIC for it is a consumer GPU.

Komodo's consensus algorithm is too different to bring it up in this discussion.

What are the obvious reasons to distrust ETH as a "verification point" for how well a mining algorithm performs in the wild?

[saturn-network]

A good counter-point to ProgPow is that since it's relatively easy to own/rent more GPU hashpower (i.e. a botnet or mining pools) then any ProgPow chain will become more vulnerable to 51% than before - and thus ProgPow is a trojan horse.

Perhaps we should embrace ASICs, but make manufacturing them so easy that no one company gets a monopoly on them. If all three of

• ETC picks an easily ASIC'able algo
• ASICs are manufactured my many competing companies without price fixing and are easy to buy and run
• ETC is the top coin on this algo measured by hashrate

then we may consider it secure.

[oberondelafay]

Or ya know. Ditch proof of work all together and go with literally anything else.
ASICs are natural for PoW but problematic because they mean the variable in the marginal cost of production eventually becomes cost of electricity. Ergo mining centralizes rapidly like a neutron star collapsing into a black hole.

[oberondelafay]

As for this particular algo, there's already FPGAs and likely ASICs, plus changing at this point would leave us at the mercy of thin pool of miners. Hence my thumbs down

[p3c-bot]

I accept ASIC development to be an inevitability of a proof of work algorithm. Ethash was intended to be ASIC resistance and it was a failure. In my opinion, that means this approach of ASIC-resistance is prone to failure. Bitcoin has had no double-spends in its entire 10-year existence. For Ethereum Classic to grow in the future I believe:

1. It needs to be the most profitable coin on the Keccak256 algorithm, which it would easily.
2. ASICs need to be decentralized and easy to fabricate to ensure rapid decentralization. This is exactly like how Bitcoin's SHA-256 is very simple for many manufacturers to compete against each other.

The problem with a overly-engineered "ASIC-Resistant" algorithm, like ProgPoW, for example is that we have no idea that it is actually ASIC-resistant, and it's complicated, so if there is a bug in it, the company behind it would have an unfair advantage in producing it and stealth mining.

A few individual responses:

@drd34d - That design, of an ASIC is SHA-3, not Keccak256. I have observed the 0xBitcoin community work on Keccak256 miners, like Cosmic. They do not have ASICs and they only have begun research on FPGAs.

@oberondelafay - This ECIP is not about changing the consensus algorithm of the system (PoW vs. PoS). ETC is Proof of work right now, this proposal is about how we actually administer the mining algorithm.

[saturn-network]

@p3c-bot SHA3 and Keccak256 are basically same thing.

Furthermore, FPGA keccak256 mining will definitely be a thing if ETC decides to adopt it before you can say "hard fork". This is not necessarily a bad thing, but the community needs to be aware before the decision is made.

@oberondelafay if you have ideas of what consensus algorithm can guarantee uninterrupted decentralized operation of code is law smart contract platform I'm sure this community would love to hear that. I don't think that we can do better than PoW in this aspect though.

[p3c-bot]

@saturn-network - when it comes to ASICs, even the smallest difference can cause a complete redesign of a chip. Please read the article below, to see exactly what the differences between SHA3 and Keccak256 are (has to do with padding of the input):

https://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use

ECIP-1049 is for Keccak256 to be adopted, not SHA3. I fully expect FPGA mining to become a thing, but believe that it will be at parity with graphics card for at leas 12 months, more likely closer to 24. If we do nothing right now, Ethash is already ASIC'd as it is.

[oberondelafay]

@saturn-network I have ideas. I'm just trying to hammer them into something cohesive and digestible.

I'm trying to sort out this ECIP process and the right way to present things to you guys for discussion and approval. I'm just a user, not a dev. But I use ALOT of currencies and have be doing so since 2009. In that time I've learned a lot of lessons.

What you're doing here is trying to put a bandaid on a broken leg. It won't work, you're only covering up a symptom and not dealing with the fundamental disease.

If ETC remains PoW regardless of algo, it is forever going to have these issues. Changing the algo might have a short term effect, but in the long run these attacks are because it's more profitable to use it as a tool to rape people unawares than to mine it properly and honestly

Even changing from PoW to something else would only be covering a symptom and maybe making it harder to get sicker.

A quick fix to the problem is to add something to official clients so that they do not show coins as received until they are past the longest known re-org and don't show them as confirmed until 2x the longest re-org. If exchanges don't see the coins come in until it's too late for them to re-org out and be double spent, then this pushes the attacker's costs through the roof and makes it untenable to sustain, although they still might be able to pull it off for short bursts with exchanges using custom clients.

However the real problem, the disease so to speak is the price.
It's too low to sustain mining at current reward levels and there aren't enough users using the coin to compensate by using up the vast amount of gas available.

If we want the current attacks to stop immediately and not resume for a long time, it is sufficient to change the block reward by a factor of somewhere between 10x and 100x in order to allow huge quantities of honest miners to come here and be profitable. The number isn't important, just make it higher in dollar terms than ETH is paying.

This will result in higher rates of inflation, thereby pushing down the price overall in the long run. But that inflation is going to be diluted by the number of coins already in circulation. Furthermore, the increased miner presence does translate to increased users and increased decentralization. In short, pay your miners a living wage so they aren't forced to rent out their pickaxes to the bad guys in order to make ends meet.

The second thing to do is start working on bringing more users to the platform. The more users we have the more valuable it is. I'm working that angle, and there aren't any blocking issues on my end so long as gas prices remain reasonable and predictable. Things in the pipeline include a trading card game, an MMORPG, a stablecoin and something I can't discuss right now, but there's nothing like it on ETH or anywhere else for that matter.

But there could easily be more like me, you need to work on getting the word out that ETC is a stable and economical platform for people to build mission critical applications on top of. I can help you with some of that writing because I'm in the trenches and know what challenges they face. But if the blockchain is being used correctly, there isn't any good reason for a company to choose ETH over ETC even with the current attacks.

Final note:
It would be helpful to have equivalents of oraclize and infura if anyone is looking for things to build that would help bring users.

None of this is really relevant to this ECIP though.

[saturn-network]

I think the best path forward with this ECIP would be to launch a keccak256 testnet and invite miners to try it out.

As far as production launch goes, if the testnet works out fine, some sort of public vote should be set up to propose algo switch. If the vote results with a YES answer, then a hard fork date should be set somewhat far into the future, probably 12 months.

In the meantime ASIC manufacturers should be invited to develop keccak256 ASICs. ETC should only switch to the new hashing algo if there are plenty of easy-to-buy, commercially available ASICs that cost roughly as much as a desktop GPU ($300 - $500). Launching without commercial ASICs will most likely result in lots of miners abandoning the chain, and at this low-hashrate moment ETC cannot make mistakes. I also heard that when it comes to keccak256 and GPUs, this algo heavily favors NVidia cards, which is also less than ideal.

Otherwise, changing hashing algorithms is just playing favorites - you favor one group of miners over another without much thought put in.

[xaoyaolee]

There is no keccak256 ASIC so far.
We can switch the algo every half year, just like XMR.

[p3c-bot]

@xaoyaolee - agreed, I have researched and currently do not see any Keccak256 ASICs.

@saturn-network - I agree with that approach, we should begin creating a Keccak256 testnet for interested users and miners to start testing on. To do this, I suggest we fork classic-geth and replace Ethash with Keccak256. There are a few next steps:

1. Research Keccak256 Algorithm ( I am currently still working on this)
2. Replace Ethash in classic-geth with Keccak256.
3. Create a testnet for miners to come and use.
4. Monitor progress on testnet and collect data.

[phyro]

Thanks for opening the ECIP!
I'm personally against changing the mining algorithm because it doesn't resolve the issue in the long run meaning we have to become resilient in some other way. I also wouldn't want to be switching algorithms frequently.

[p3c-bot]

@phyro There are two points you are making, one I agree with and one I disagree with:

1. I agree that switching algorithms frequently is a bad idea. Every-time we do this it is very disruptive to the entire community, and changes need to be thoroughly tested in lab conditions before we make a drastic switch. Research has definitively proven that Keccak256 is currently the best hashing algorithm available, hence why it is SHA3 certified. I would trust SHA3 with my life. I am very skeptical Ethash is even safe against a determined opponent like a nationstate.

2. The issue in the long run as I see it, is that friendly miners were not able to have more hashpower than hostile miners. With a more transparent mining algorithm, the market is on a much more level playing field. What Ethash has created is a market where incumbent manufacturers take advantage of poor documentation and confusion to gain a competitive advantage.

Keccak 256 Documentation: https://keccak.team/files/Keccak-implementation-3.2.pdf
Ethash Documentation: https://github.com/ethereum/wiki/wiki/Ethash

[stevanlohja]

I think the intent of this ECIP is to just respond with an ECIP because the ECIP knowingly isn't trying to solve the problems of the claimed catalyst (51 attack). ETC can change it's underwear in some way but it has to have some type of super power than 'just cause'. I reject.

[pyskell]

SHA-3, having a faster less memory intensive algorithm might make ASICs run up against transistor limits sooner, really simplifies the chip, more production. I only have a naive knowledge of this but the maximum speed of CPUs seems to be running up against limits faster than RAM.

I'm personally iffy about changing the PoW algorithm at all (unless an exploit is found) but it's worth noting.

Also in this vein SHA-3 would be much less likely to be exploitable than Ethash due to its long period of development and analysis.

[zmitton]

I have a low-level optimization for the ECIP. It would be preferable to use the specific format (mentioned to Alex at the summit)

// unsealedBlockheader is the blockheader with a null nonce
digest = keccak256(concat(keccak256(unsealedBlockheader),32ByteNonce))
// a "winning" digest is of course the thing that must start with lots of leading zeros
// the "sealed" header is then made by inserting the nonce and re-RLP-encoding

• This optimizes the size of a PoW to be 64 bytes instead of the current 400+ bytes (because the PoW verification only requires the 2 items that were concatenated above)
• It also ensures that the dedicated hardware/software is optimizing specifically keccak, because creating each new "guess" requires the minimal number of "non-keccak" steps (swapping the 32 byte nonce of a 64 byte bytearray). If the nonce was instead just 1 of the rlp items in the header, then creating another guess would entail a new RLP encoding step (of 400+ bytes) for each additional guess. ASICS would have to design RLP into the hardware to compete. Also selfish mining could become an advantage strategy since block headers can vary in size and larger headers would then take longer to mine on.

[tfn020377]

Hopefully this is 100% debunked and rejected by know. Every existing gpu miner with a minimum of 4GB ram can mine etchash, however all the current asic miners, including me, have invest tens to hundreds of thousands of our hard earn money to support the fork to etchash. If we loose our operational hardware to a new algo, we will never spend money on ETC again. The only way to ensure a recoup would be to move back to BTC. We hope our ETC devs realize that.