<p>Storing the hash of every transaction in the block header could make the block header much larger than it currently is. Right now the whole header is 80 bytes, and the tx merkle root is 32 bytes of that. You can hash any number of transactions into a 32 byte merkle root, so it works very well as a cryptographically secure compression technique. </p>

<p>I can think of a few effects of larger block headers:</p>

<ul>
<li>SPV wallets would be more resource intensive to run, they would require <em>much</em> more storage and bandwidth. I think computing the merkle branch is probably rarely the hardware bottleneck to be considered when designing wallets. </li>
<li>Miners would be incentivized to mine small blocks. This is because a larger blockheader would mean a larger input value for the SHA-256 hash function, so it would take longer to compute the hash. This is important: the fastest block hash a miner could compute would be one with no transactions in it (other than the coinbase).</li>
<li><strike>You would be able to fit less transactions in a block, since more of the blockspace would be used by the header.</strike> A good implementation would not change the number of transactions you could fit in a block, see Pieter's comments below.</li>
</ul>

<p>There are probably more, feel free to expand on this list. </p>

CC BY-SA 4.0
2018-05-15T16:20:00.063Z
The last argument does not hold. Just because the block header contains all txids does not make every store all of them. That's similar to how the Merkle tree itself is not stored anywhere, but implied by the transactions.
Pieter Wuille
CC BY-SA 4.0
2018-05-16T07:09:30.287Z
@PieterWuille I'm not sure I follow. At the most basic evel: if the max block weight remains the same, and including txids instead of a merkle root makes the header larger, then that leaves less space in the body for transactions, no? I interpreted OPs question as 'why not just a naive implementation that lists all txids in a row'
chytrik
CC BY-SA 4.0
2018-05-16T07:29:25.960Z
They could be part of the block header without storing them (in any situation where you're already storing the transactions too). We could do the same right now with just the root (as it too is implied by the transactiins), but for just 32 bytes it's not really worth it.
Pieter Wuille
CC BY-SA 4.0
2018-05-16T10:25:23.713Z
I understand, thanks. I edited the answer to be more accurate.
chytrik
CC BY-SA 4.0
2018-05-15T10:47:31.663Z
2018-05-16T08:36:21.913Z
2018-05-16T08:36:21.913Z
chytrik
<blockquote>
  <p>I understand that storing transactions' hashes will slightly increase size of a block header.</p>
</blockquote>

<p>That's an understatement. According to <a href="https://bitcoin.stackexchange.com/questions/68811/what-is-the-absolute-smallest-size-of-the-data-bytes-that-a-blockchain-transac">this</a> answer, the minimum transaction size is 60 bytes. A block full of these would make the txhash part of the block header 560kb instead of 32 bytes it currently is. </p>

CC BY-SA 4.0
2018-05-15T11:01:12.743Z
Just to clarify, I am talking about hashes of transactions to store in the header instead of whole transaction. In case a block has 2000 transactions (usually is kind of average these days)  then the block size will increase to 32*2000 = 64 KB when SHA-256 is used to compute hash. Hence it is no way near 560KB.
Noman Aslam
CC BY-SA 4.0
2018-05-15T11:06:32.207Z
if the transaction is 60 bytes long (minimum size) then a block can fit 17476 transactions. Each txid is 32 bytes so 17476 * 32 bytes = 560kb
Mike D
CC BY-SA 4.0
2018-05-15T10:31:23.800Z
2018-05-15T10:31:23.800Z
Mike D
<p>It is not clear to me, why not we can simply store transaction hashes in a block header instead of storing the Merkle root. I understand that storing transactions' hashes will slightly increase size of a block header. However, the transaction verification process will be greatly simplified as one does not have to compute Merkle tree. In that case, one can verify a transaction by simply searching that transaction hash in the header.</p>

<p>Noman Aslam</p>

<transactions><transaction-verification><merkle-tree><block-header>
Merkle root Vs transaction hashes
Noman Aslam
# Merkle root Vs transaction hashes

(Asked by: username_0 on 2018-05-15)

It is not clear to me, why not we can simply store transaction hashes in a block header instead of storing the Merkle root. I understand that storing transactions' hashes will slightly increase size of a block header. However, the transaction verification process will be greatly simplified as one does not have to compute Merkle tree. In that case, one can verify a transaction by simply searching that transaction hash in the header.

username_0 username_0

**Tags:** transactions, transaction-verification, merkle-tree, block-header


---

## 2 answers

### Answer by username_1 on 2018-05-15. Score: 1 | Accepted answer

Storing the hash of every transaction in the block header could make the block header much larger than it currently is. Right now the whole header is 80 bytes, and the tx merkle root is 32 bytes of that. You can hash any number of transactions into a 32 byte merkle root, so it works very well as a cryptographically secure compression technique.

I can think of a few effects of larger block headers:

* SPV wallets would be more resource intensive to run, they would require *much* more storage and bandwidth. I think computing the merkle branch is probably rarely the hardware bottleneck to be considered when designing wallets.
* Miners would be incentivized to mine small blocks. This is because a larger blockheader would mean a larger input value for the SHA-256 hash function, so it would take longer to compute the hash. This is important: the fastest block hash a miner could compute would be one with no transactions in it (other than the coinbase).
* You would be able to fit less transactions in a block, since more of the blockspace would be used by the header. A good implementation would not change the number of transactions you could fit in a block, see username_2's comments below.

There are probably more, feel free to expand on this list.

> **Comments:**
> **username_2**: The last argument does not hold. Just because the block header contains all txids does not make every store all of them. That's similar to how the Merkle tree itself is not stored anywhere, but implied by the transactions.  
> **username_1**: @username_2 I'm not sure I follow. At the most basic evel: if the max block weight remains the same, and including txids instead of a merkle root makes the header larger, then that leaves less space in the body for transactions, no? I interpreted OPs question as 'why not just a naive implementation that lists all txids in a row'  
> **username_2**: They could be part of the block header without storing them (in any situation where you're already storing the transactions too). We could do the same right now with just the root (as it too is implied by the transactiins), but for just 32 bytes it's not really worth it.  
> **username_1**: I understand, thanks. I edited the answer to be more accurate.  

---

### Answer by username_3 on 2018-05-15. Score: 0

> I understand that storing transactions' hashes will slightly increase size of a block header.

That's an understatement. According to [this](https://bitcoin.stackexchange.com/questions/68811/what-is-the-absolute-smallest-size-of-the-data-bytes-that-a-blockchain-transac) answer, the minimum transaction size is 60 bytes. A block full of these would make the txhash part of the block header 560kb instead of 32 bytes it currently is.

> **Comments:**
> **username_0**: Just to clarify, I am talking about hashes of transactions to store in the header instead of whole transaction. In case a block has 2000 transactions (usually is kind of average these days)  then the block size will increase to 32*2000 = 64 KB when SHA-256 is used to compute hash. Hence it is no way near 560KB.  
> **username_3**: if the transaction is 60 bytes long (minimum size) then a block can fit 17476 transactions. Each txid is 32 bytes so 17476 * 32 bytes = 560kb  

---

