<h2>How does ASICBoost work</h2>

<p>ASICBoost relies on finding multiple block headers that match in the last sixteen bytes. As SHA-256 takes 64 byte chunks of input, this allows to reuse parts of the calculation for the second chunk.</p>

<p>The last sixteen bytes of the block header are composed of the </p>

<ul>
<li>last four bytes of the Merkle root of the transactions</li>
<li>the time-stamp</li>
<li>the difficulty statement</li>
<li>the nonce. </li>
</ul>

<p>Thus, the last twelve bytes are arbitrary and the only difficult part is to get four bytes of the Merkle root to match up. This could be done by actually using the same Merkle root, but then (since the hash of the previous block is fixed) the only remaining field in the header to introduce variation is the the version field! Mining blocks with varying version fields is pretty obvious and corresponds to the <em>overt</em> application of ASICBoost.</p>

<p>For a comprehensive explanation of ASICBoost see: <a href="http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf" rel="nofollow noreferrer">Jeremy Rubin's Notes on ASICBoost [PDF]</a></p>

<h2>Covert ASICBoost</h2>

<p>On the other hand, the <em>covert</em> application relies on finding multiple Merkle roots that collide in the last four bytes. As we know, the <a href="https://bitcoin.stackexchange.com/q/10479/5406">Merkle root</a> derives from forming a Merkle tree on all transactions. A straight forward way of doing this would be to grind the coinbase transaction extra-nonce space. However, each time when you change the coinbase transaction, you have to recalculate the complete left branch of the Merkle tree, which requires an additional 11 to 12 extra hashes for blocks with up to 2048 or 4096 transactions respectively. Obviously, finding a partial collision of the Merkle root would be twelve times faster performed on an empty block.</p>

<p>A more efficient way of finding partial collisions of the Merkle root would be to have a fixed left-side tree, i.e. an unchanging coinbase transaction, and to combine this with various right-sides of the tree. This would then only require a single hash to produce a new Merkle root, and you could immediately check whether you've found the desired collision.</p>

<p>In practice, you could efficiently generate right-side trees by combining several compatible candidate trees a few branches down from the Merkle root in different ways. This is why out-of-order transaction-fees and the absence of dependent transaction pairs could be indicators for the use of covert ASICBoost-usage. This process is highly parallelizable.</p>

<h2>How does SegWit influence ASICBoost</h2>

<p>This more efficient approach is broken by SegWit and many other BIPs, because it requires in the coinbase transaction a Merkle root commitment which is calculated order-sensitively from all other transactions in the block. This means that whenever any transaction in the block is updated the entire left-branch of the Merkle tree needs to be recalculated due to the updated coinbase transaction.</p>

<h2>…and Bitcoin Unlimited?</h2>

<p>To come back to your question: AFAIK, <strong>Bitcoin Unlimited does not require a commitment in the coinbase,</strong> and thus would be compatible with the covert application of ASICBoost.</p>

<p><em>Many thanks go to <a href="http://chat.stackexchange.com/transcript/message/36566848#36566848">David Harding</a> who explained the finer details of the above in chat, from which I've adapted some of the above paragraphs.</em></p>

CC BY-SA 3.0
2017-04-07T09:09:44.200Z
2017-04-11T14:55:14.003Z
2017-04-13T12:47:34.187Z
Murch
<p>In light of the new findings about ASICBOOST from bitmain. Having that segwit disables ASICBOOST, does this mean that Bitcoin Unlimited leaves this ASICBOOST feature intact? Having that segwit disables this ASICBOOST feature, has Bitcoin Unlimited done the same?</p>

<segregated-witness><bitcoin-unlimited><asicboost>
Does Bitcoin Unlimited keep ASICBOOST intact vs going with segwit?
Patoshi パトシ
# Does Bitcoin Unlimited keep ASICBOOST intact vs going with segwit?

(Asked by: username_0 on 2017-04-06)

In light of the new findings about ASICBOOST from bitmain. Having that segwit disables ASICBOOST, does this mean that Bitcoin Unlimited leaves this ASICBOOST feature intact? Having that segwit disables this ASICBOOST feature, has Bitcoin Unlimited done the same?

**Tags:** segregated-witness, bitcoin-unlimited, asicboost


---

## 1 answers

### Answer by username_1 on 2017-04-07. Score: 5 | Accepted answer

## How does ASICBoost work

ASICBoost relies on finding multiple block headers that match in the last sixteen bytes. As SHA-256 takes 64 byte chunks of input, this allows to reuse parts of the calculation for the second chunk.

The last sixteen bytes of the block header are composed of the

* last four bytes of the Merkle root of the transactions
* the time-stamp
* the difficulty statement
* the nonce.

Thus, the last twelve bytes are arbitrary and the only difficult part is to get four bytes of the Merkle root to match up. This could be done by actually using the same Merkle root, but then (since the hash of the previous block is fixed) the only remaining field in the header to introduce variation is the the version field! Mining blocks with varying version fields is pretty obvious and corresponds to the *overt* application of ASICBoost.

For a comprehensive explanation of ASICBoost see: [Jeremy Rubin's Notes on ASICBoost [PDF]](http://www.mit.edu/~jlrubin//public/pdfs/Asicboost.pdf)

## Covert ASICBoost

On the other hand, the *covert* application relies on finding multiple Merkle roots that collide in the last four bytes. As we know, the [Merkle root](https://bitcoin.stackexchange.com/q/10479/5406) derives from forming a Merkle tree on all transactions. A straight forward way of doing this would be to grind the coinbase transaction extra-nonce space. However, each time when you change the coinbase transaction, you have to recalculate the complete left branch of the Merkle tree, which requires an additional 11 to 12 extra hashes for blocks with up to 2048 or 4096 transactions respectively. Obviously, finding a partial collision of the Merkle root would be twelve times faster performed on an empty block.

A more efficient way of finding partial collisions of the Merkle root would be to have a fixed left-side tree, i.e. an unchanging coinbase transaction, and to combine this with various right-sides of the tree. This would then only require a single hash to produce a new Merkle root, and you could immediately check whether you've found the desired collision.

In practice, you could efficiently generate right-side trees by combining several compatible candidate trees a few branches down from the Merkle root in different ways. This is why out-of-order transaction-fees and the absence of dependent transaction pairs could be indicators for the use of covert ASICBoost-usage. This process is highly parallelizable.

## How does SegWit influence ASICBoost

This more efficient approach is broken by SegWit and many other BIPs, because it requires in the coinbase transaction a Merkle root commitment which is calculated order-sensitively from all other transactions in the block. This means that whenever any transaction in the block is updated the entire left-branch of the Merkle tree needs to be recalculated due to the updated coinbase transaction.

## …and Bitcoin Unlimited?

To come back to your question: AFAIK, **Bitcoin Unlimited does not require a commitment in the coinbase,** and thus would be compatible with the covert application of ASICBoost.

*Many thanks go to [David Harding](http://chat.stackexchange.com/transcript/message/36566848#36566848) who explained the finer details of the above in chat, from which I've adapted some of the above paragraphs.*


---

