(pt. 4) A Compromise on ECIP-1049: Preserving the Consensus while adopting Keccak256 via Soft Fork.

Compromise is not about losing. It is about deciding that the other person has just as much right to be happy with the end result as you do.

A number of notable things happened last week on the ETC community call. First of all the community chose to reject ProgPoW. This is important because it is clear that this horrendous algorithm is a direct attack on the network by forcing it on substandard cryptography built by the CSW goon-squad. Good riddance!

When it comes to cryptography simpler = better. Less attack surface.

However, we were not able to achieve clear community support for ECIP-1049. Why was this? Those who were against it laid out their case, and the primary concerns we heard were:

• Keccak256 is a good proof of work algorithm, but the risks of switching are too high and potentially risky to perform on a live network.
• If we were designing ETC from scratch, it would make sense to adopt Keccak256, but it is unfair to switch Proof of Work algorithms on a live network.

Now let me first say, I disagree with both of these positions. Given enough time, and with the simplicity of the Keccak256 algorithm, I believe that it would be quite easy to switch over and have majority hash power. ETC generates over $33million (around $100,000 a day) a year in new coins, and this is more than enough to support a healthy mining ecosystem.

But I will concede, this is speculation and there are indeed potential risks in a switchover. They are low, but it is still possible that the mining ecosystem might be unprepared and leave the network vulnerable at the moment of the switch over. Which brings me to a compromise:

ECIP-1049 will be amended to say:

Instead of replacing Ethash with Keccak256 entirely, the network can instead accept both of the hashes as valid for proof of work. A block can be sealed with both Ethash OR Keccak256.

A dual proof of work system, how is this possible without adding lots of complexity to the system?

Well it is actually quite simple. First you need to understand what Ethash actually is — it’s Keccak256, a whole lot of memory intensive stuff for ASIC resistance, and then Keccak256 on the way out.

Part of the requirement for the memory intensive stuff is what’s called a “mixHash” — which is a 256 bit string which can be used to generate the DAG. Becaue Keccak256 does not need a dag (the DAG only exists for “ASIC resistance” purposes) we get this extra 256 bit string which is very useful, you really can fill it with anything you want. So here are the nuts and bolts:

If a miner sees 0x0000 as the first 4 characters of the mixHash — then it checks if the block is sealed with Keccak256, if it is, then the block is valid. If it does not see 0x0000 it checks if it is sealed with Ethash, if it is, the block is valid.

if blockheader.mixHash[0:4] == '0x0000':
   validateKeccak256PoW()
else:
   validateEthashPow()

This allows both sides to get exactly what they want:

• Those in favor of Keccak, can submit work to the blockchain that is considered valid. This means dedicated miners can create chips and ASICs for the network, and defend against potential rogue Ethash mining pools, the same ones that 51% attacked ETC numerous times in January 2019.
• Those in favor of staying with Ethash now know that, if we activate ECIP1049 and we don’t have any Keccak miners on the network, it’s not an issue because everybody can just keep business as usual.
• If ECIP1049 is activated, no new tools need to be written, since now two PoW methods are considered valid as opposed to just one. Everyone agrees that both of these two PoW methods are collision resistant and can function for block sealing.

In fact we believe, this solution qualifies as a soft fork, because Ethash is a composite of Keccak256 plus a lot of other things. By removing the clutter, we are accepting merely a subset of what we used to accept. However, it is not a true Soft Fork, because the client still needs to be updated. I am interested to hear what the community believes on this.

Potential Questions and Critiques:

But this is too complicated, we need to spend years analyzing this to figure it out!

It really isn’t very complicated from a software perspective. Because we are not changing any of the block structure (… now that would be complicated…) . By simply adding a check on the MixHash field, we know when to perform Ethash and when to perform Keccak256.

Since Keccak256 is a subset of Ethash, we’re simply removing the clutter that Ethash added.

Why did you choose 0x0000 as the activate code? Is it the right size

This is a good question. So one advantage of adopting Keccak256 is now block producers and miners can have 256bits to add data to every block. This can be very useful, since it allows things like onchain miner voting, analytics, pool messages — the possibilities are endless!

By taking some of those bits to have to be filled with 0x0000 we reduce that. However, we need to balance with the fact that one out of every 65536 mined Ethash blocks will have this as the first 4 characters of the mixhash (16 possible hex digits to the power of 4 = 65,536). So with this approach, on average 1 out of every 65,536 valid Ethash blocks will be rejected. I believe this is an acceptable number.

How will this affect the flyclient?

Ultimately, with the current situation, there is no flyclient since it is far too expensive to compute Ethash. To build a true flyclient, we need every block to be Keccak256, so it is easy to validate it without having to consider DAGs or Epochs or the other junk that is in Ethash.

If the community actually cared about the flyclient it would have dropped Ethash entirely, but there are many members who say they like the idea of a flyclient, but are unwilling to make the changes that the engineers who are building it are asking for. This means they do not actually care about Flyclient, or possibly don’t understand it fully.

Ultimately, the FlyClient will have to read the first few bits of the mixhash and if it has the activation code, it will activate, if it doesn’t, it will have to deal with Ethash in its own way.

However, I believe overtime more and more miners will start using Keccak256 miners, which means the flyclient can make assumptions about the proof of work model.

I hope that this addresses the concerns of the community and that we can move forward with protecting the network, and adopting the best cryptography possible.