<p>You are correct that effectively Bitcoin PoW involves computing the Merkle root every now and then in addition to the hash grinding.</p>

<p>However, this is negligable. Even ignoring nTime rolling, the Merkke root computation is just a dozen or so hashes every 2<sup>32</sup>. It's so little because not the entire Merkle tree needs recomputation; just the coinbase transaction is modified, along with n Merkle nodes above it (assuming up to 2<sup>n</sup> transactions).</p>

<p>As far as I know, the burden of Merkle root computation is so low that it is generally done in the miner controller rather than in the ASIC itself.</p>

CC BY-SA 4.0
2019-07-21T11:04:06.003Z
Thank you for your answer Pieter,

I understand that it does not require much compute. But my criticism is towards the added complexity of doing two things to get a new hash, as opposed to one, just using the nonce (and extending it to 64bits).

It seems to me that there is accidental complexity we can shave off here. We can reduce the complexity of the miners, pool operators, RPC interface, stratum.


**Why have we chosen to increase the complexity of the software, rather than increase the nonce to 64bits?**


Thank you for your contributions to bitcoin, I'm a huge fan of yours.
ascendzor
CC BY-SA 4.0
2019-07-21T14:30:38.940Z
@ascendzor Changing the header format like that requires a hard-fork.
CodesInChaos
CC BY-SA 4.0
2019-07-21T16:55:17.400Z
Yes, things would have been slightly simpler if the nonce field was 64 bits in size. As @CodesInChaos points out, this would require a hard fork, and because of that it'll probably never happen. All infrastructure relies on 32-bit nonces, and already includes the complexity of grinding Merkle trees. Convincing the whole world to change that, and the risks for forks while doing so, just isn't worth the gain.
Pieter Wuille
CC BY-SA 4.0
2019-07-21T06:10:46.683Z
2019-07-22T02:21:01.353Z
2019-07-22T02:21:01.353Z
Pieter Wuille
<p>Miners can mutate nonce (32 bits) + time (mutates once a second). This allows for 2<sup>32</sup> (~4 billion) hashes per second. That's not enough anymore for our ASICs as they perform in the TH/s now rather than GH/s. So we allowed miners to mutate the coinbase transaction, but this requires us to generate a new Merkle tree. This means that a miner needs to generate a new Merkle tree every 2<sup>32</sup> hashes. at 1 TH/s The miner must generate a new Merkle tree 250 times per second.</p>

<p>TLDR: Is Bitcoin PoW actually SHA256 + Merkle tree generation? And not pure SHA256?</p>

<p>If I'm correct in asserting that Bitcoin PoW is SHA256 + Merkle tree, does this slow the commoditization of ASICs and therefore slow decentralization, as ASICs now must be more complex than if they did with just SHA256 + nonce mutations?</p>

<proof-of-work><merkle-tree><sha256><bip>
Is Bitcoin PoW actually SHA256 + Merkle generation? Or have I misunderstood coinbase/append?
ascendzor
# Is Bitcoin PoW actually SHA256 + Merkle generation? Or have I misunderstood coinbase/append?

(Asked by: username_0 on 2019-07-21)

Miners can mutate nonce (32 bits) + time (mutates once a second). This allows for 232 (~4 billion) hashes per second. That's not enough anymore for our ASICs as they perform in the TH/s now rather than GH/s. So we allowed miners to mutate the coinbase transaction, but this requires us to generate a new Merkle tree. This means that a miner needs to generate a new Merkle tree every 232 hashes. at 1 TH/s The miner must generate a new Merkle tree 250 times per second.

TLDR: Is Bitcoin PoW actually SHA256 + Merkle tree generation? And not pure SHA256?

If I'm correct in asserting that Bitcoin PoW is SHA256 + Merkle tree, does this slow the commoditization of ASICs and therefore slow decentralization, as ASICs now must be more complex than if they did with just SHA256 + nonce mutations?

**Tags:** proof-of-work, merkle-tree, sha256, bip


---

## 1 answers

### Answer by username_1 on 2019-07-21. Score: 8 | Accepted answer

You are correct that effectively Bitcoin PoW involves computing the Merkle root every now and then in addition to the hash grinding.

However, this is negligable. Even ignoring nTime rolling, the Merkke root computation is just a dozen or so hashes every 232. It's so little because not the entire Merkle tree needs recomputation; just the coinbase transaction is modified, along with n Merkle nodes above it (assuming up to 2n transactions).

As far as I know, the burden of Merkle root computation is so low that it is generally done in the miner controller rather than in the ASIC itself.

> **Comments:**
> **username_0**: Thank you for your answer username_1,  I understand that it does not require much compute. But my criticism is towards the added complexity of doing two things to get a new hash, as opposed to one, just using the nonce (and extending it to 64bits).  It seems to me that there is accidental complexity we can shave off here. We can reduce the complexity of the miners, pool operators, RPC interface, stratum.   **Why have we chosen to increase the complexity of the software, rather than increase the nonce to 64bits?**   Thank you for your contributions to bitcoin, I'm a huge fan of yours.  
> **username_2**: @username_0 Changing the header format like that requires a hard-fork.  
> **username_1**: Yes, things would have been slightly simpler if the nonce field was 64 bits in size. As @username_2 points out, this would require a hard fork, and because of that it'll probably never happen. All infrastructure relies on 32-bit nonces, and already includes the complexity of grinding Merkle trees. Convincing the whole world to change that, and the risks for forks while doing so, just isn't worth the gain.  

---

