Today, the BIP110ers picked a new proof of work algorithm, it was a mess.Today, the BIP110ers picked a new proof of work algorithm, it was a mess.

There have been no blocks on the BIP110 chain since block 961633 was mined two days ago. There do not seem to be many miners who are interested in mining on that chain and therefore the chain is stalled. Under current rules, it needs to reach the next difficulty adjustment before things will get easier -- and that adjustment is 2014 blocks away.

In response to this, Luke Dashjr announced that BIP110 would be hard forking to introduce a new proof of work algorithm.

If hard forks are on the table, you might wonder why they didn't just use a fork to change the rules around mining difficulty so they could get their chain going again. Unfortunately, with only 2% (or less) of the hashrate mining on their chain, they would be an easy target for other miners to cause chaos on their chain (eg doublespending, reorgs, splits).

Changing the proof of work algorithm defends against this threat by reducing the advantage of the ASICs operated by Bitcoin miners today (which are optimized for SHA256).

How to do a fair selection of the new POW algorithm?How to do a fair selection of the new POW algorithm?

This is not a new problem. Bitcoiners have long observed that whoever does the picking of a new POW algorithm has the potential to collude with ASIC manufacturers to produce a new line of ASICs for the new algo or to simply stockpile chips that are suitable for the new algorithm. There are many ways to do it, but they all end of looking a lot like a premine.

So it's good if you make your choice in a way that is demonstrably fair.

The first attemptThe first attempt

This is Luke Dashjr's first announcement about the proof of work change:

source

The hash Luke included at the end of that message corresponds to the following mapping:

• 0 SHA3x
• 1 BLAKE2s
• 2 BLAKE2s
• 3 BLAKE3x2
• 4 SHA3x
• 5 SHA3x
• 6 BLAKE2b-256
• 7 SHA3x
• 8 BLAKE2b-256
• 9 BLAKE2b-256
• a BLAKE2s
• b BLAKE3x2
• c Eaglesong
• d BLAKE3x2
• e BLAKE2b-256
• f Eaglesong

When the next testnet4 block was seen, the last character of the blockhash would pick which of these algorithms was going to be used for BIP110's new proof of work method. By including the hash, Luke demonstrated that the list was created before the block was found so hopefully the block would be a fair source of randomness.

Testnet4 woesTestnet4 woes

Unfortunately, Testnet4 has much lower difficulty than Bitcoin. Additionally, it has a rule that allows a block to be mined at difficulty 1 in the event that no block has been found for twenty minutes.

It seems that no testnet4 block was mined for 20 minutes prior to Luke Dashjr's designated time. This meant that at 1400 UTC, difficulty was set to 1 for mining the block that would decide BIP110's new proof of work algorithm -- and a number of blocks were mined simultaneously.

This led to quite a bit of confusion.

And to a dilemma: should they try again? Should they wait for the chain split to resolve and a heaviest chain tip to emerge? Should they wait for six blocks?

Because Testnet4 difficulty is significantly lower than Bitcoin, it quickly became evident that someone could attempt to influence the outcome of the results by mining on the tip of the chain whose crucial block selected a preferred algo.

Luke tried posting some new set of criteria which would be revealed at some time (presumably soon?). This however also failed to work:

This new method was then revealed to be:

Which eventually resulted in the selection:

This apparently is the same proof of work algorithm used by Siacoin, so there are already some ASICs manufactured for mining on it -- which is a good thing?

Is there a better way to do this?Is there a better way to do this?

I was hanging out in the BIP110 Discord for most of the day, observing this process. I don't think it went terribly well. There was a lot of confusion and a lot of frustration. One thing that definitely stood out is that Luke was calling the shots here and the BIP110 community was largely looking to him for a decision.

It got me to thinking though: how would we go about a fair proof of work change that didn't get gamed?

I remember Matt Corallo talking about such a change a few years back when he was writing about MEVil. And many other Bitcoiners have mentioned "firing the miners" by changing the proof of work algorithm. It's sometihng we keep in our back pocket as if we (noderunners) could use it as a cudgel to keep the naughty miners in line.

Watching the BIP110ers struggle with this today made me realize that it is easier said than done.

How would you go about enacting a fair proof of work change?How would you go about enacting a fair proof of work change?