ELI5: Gregory Maxwell’s Inhibition Proposal

Truth be told, I don’t know if I can explain this to a 5 year old. This is a fairly technical proposal and assumes a lot of technical knowledge which isn’t obvious even to technical people. I’m sure you have questions, I’ll try to answer what I think you’d ask.

What is this proposal?

Greg Maxwell emailed the bitcoin-dev list to present a proposal about requiring a witness commitment to the coinbase transaction as a soft-fork.

The coinbase transaction is the transaction with the reward for miners when they find a block with sufficient proof-of-work. The new proposal requires something called a “witness commitment” which is 38-bytes long. The witness commitment is specified in BIP-141 (aka Segwit) and contains the Merkle Root of the witness transaction id’s. More on that in a minute.

What motivated the proposal?

Apparently, some miners have used something called ASICBOOST to find the proof-of-work faster. ASICBOOST is a clever way to compute the proof-of-work which requires roughly 20–30% less work/energy. It’s speculated that they’re opposing Segwit because of their ASICBOOST advantage.

What’s ASICBOOST?

Warning: Technical details follow

ASICBOOST is a way to calculate the SHA256 hash a bit faster using some aspects of how SHA256 is calculated. Specifically, the proof-of-work is always done on the 80-byte block header. SHA256 always splits up the data into 64-byte chunks. Since the header is 80 bytes, that makes 1 64-byte chunk and another 16-byte chunk. If either chunk can be calculated ahead of time, this would be a major advantage to calculating the SHA256 faster.

If you look at the Bitcoin block header specification, the first 64 bytes are the version (4 bytes), previous block hash (32 bytes) and 28 of the 32 bytes of the Merkle Root, which is sort of a fingerprint of all the transactions in the block.

The other 16 bytes are the rest of the Merkle Root (4 bytes), Timestamp (4 bytes), Bits (4 bytes) and Nonce (4 bytes). What’s interesting is that Timestamp and Nonce can be specified to be anything the miner wants. Bits are determined during retargeting, which happens every 2 weeks. Thus, the miner can know 12 of the 16 bytes necessary to compute SHA256 hash. The only thing left that the miner doesn’t know ahead of time is the last 4 bytes of the Merkle Root. If they did know this ahead of time, most of the SHA256 can be calculated once instead of many times, thus creating the proof-of-work faster.

The miner can know these 4 bytes ahead of time by what we’ll call grinding. They can essentially create a lot of Merkle Roots until they get a collision on the last 4 bytes. That is, they want to find Merkle Roots that have the same last 4 bytes. This can be done by rearranging transactions, changing the Coinbase transactions, etc. Essentially doing this allows the miner to precompute parts of the SHA256 hash, making calculating the proof-of-work faster.

The key here, however, to making this calculation faster is in being able to compute the Merkle Root really fast. This means that the transactions included in the block cannot affect other transactions. Unfortunately, Segwit breaks this.

How did Greg Maxwell find out?

He reverse-engineered some mining equipment.

I don’t get it, how does changing the coinbase transaction make ASICBOOST not work?

It turns out that the requiring the Coinbase transaction to have a witness commitment makes the advantages of ASICBOOST go away (for the most part).

Warning: more technical details

This is because the witness commitment has another Merkle Root called the Witness Root Hash. This includes all transactions, not just Segwit transactions, but assumes the coinbase transaction has a hash of all 0’s. This means that calculating the Merkle Root is less efficient since the Coinbase transaction has to change anytime any transaction is changed even slightly, including changing position. That means more SHA256 hashes have to be calculated, including the entire Merkle Path up to the Merkle Root for the Coinbase transaction. This matters because normally, changing one side of the Merkle Tree doesn’t affect the other, but in this case, changing the right side of the Merkle Tree changes a large chunk of the left side which contains the coinbase transaction.

Thus, way more calculations are required and render the ASICBOOST advantage null.

But what if Segwit doesn’t activate? Would this proposal change anything?

In case Segwit doesn’t activate, the proposal would still require the witness commitment of the transactions (remember, this is calculated with all transactions in the block). This should nullify most of ASICBOOST’s advantages on its own without Segwit.

Why would anyone want to do this?

To quote Gregory Maxwell:

On the above basis the potential for covert exploitation of this vulnerability and the resulting inequality in the mining process and interference with useful improvements presents a clear and present danger to the Bitcoin system which requires a response.

Adopting Segwit means the ASICBOOST advantages go away. This makes Segwit less attractive for miners and hence, it’s speculated that they’re opposing Segwit for this reason.

This proposal is a way to remove ASICBOOST as a factor for miners to oppose not just Segwit, but a lot of other improvements that require coinbase commitments (fraud proofs, weak blocks, etc).