<blockquote>
<p>Why don't just do a SHA256(SHA256(...ALL TXs IN A COMPACT WAY...)) nowadays ?</p>
</blockquote>
<p>Even if the premise of your question (that using the Merkle structure is useless) is true, this isn't something that can just be changed.</p>
<p>Changing how block headers commit to transaction data would be a very invasive change, which would be a hard fork, but would also just break literally every piece of Bitcoin software ever written. Unless not changing this means a near-fatal bug for Bitcoin, this isn't even worth discussing.</p>
<p>This isn't even that. Concatenating the hashes instead of using a Merkle tree is maybe a few milliseconds speedup per block, on weak hardware.</p>
<blockquote>
<p>I know Thin nodes are doing this</p>
</blockquote>
<p>Yes.</p>
<blockquote>
<p>but this is a little bit useless since major branches are required.</p>
</blockquote>
<p>I have no idea what this means.</p>

CC BY-SA 4.0
2023-05-19T18:14:55.763Z
Moreover, all wallets that use the Electrum protocol fetch a Merkle Tree to make sure a transaction is indeed confirmed. It's definitely not useless.
Davidson Souza
CC BY-SA 4.0
2023-05-19T19:33:43.640Z
"which would be a hard fork":
Agreed.

"but this is a little bit useless since major branches are required.":
I was refering to the merkle proof.
Loopite
CC BY-SA 4.0
2023-05-19T19:34:00.327Z
"Concatenating the hashes [...] is maybe a few milliseconds speedup per block, on weak hardware."

This seems incorrect: with an optimized program using SHA256double on ONE core of Intel(R) Core(TM) i9-10900K, you can perform ~1,500,000 HASH/sec. Blocks contain now ~3500 TXs. So if you want to download ~200 blocks/sec, you will have to perform ~2,000,000 HASH/sec. I just want to show you that the limit can be reached easily. With concatenation you'll just have to do 3500 * 200 + 1 = ~700,001 HASH.
Loopite
CC BY-SA 4.0
2023-05-19T19:45:04.520Z
I don't follow your math. Mine is: concatenating is 32 bytes per txid; the current Merkle root structure is (after padding, and accounting for double hash) around 192 bytes per txid. At 3500 transactions, that's 3500*(192-32)=560000 bytes. Unoptimized SHA256 implementations on x86 need around 15 CPU cycles per byte, or 8.4M cycles, which is a few ms at modern CPU speeds. Hardware-accelerated SHA256 is an order of magnitude faster than that even.
Pieter Wuille
CC BY-SA 4.0
2023-05-19T20:48:03.113Z
Just see here: https://pastebin.com/rPyxxeDm. with 1.5 * 10^6 HASHs (double-SHA256) / second.
Loopite
CC BY-SA 4.0
2023-05-19T20:57:35.463Z
Yes, I agree with the roughly 4x faster for the Merkle root checking vs. concatenation (I get 5x faster, even), but that still shouldn't be more than a few milliseconds per block.
Pieter Wuille
CC BY-SA 4.0
2023-05-19T18:08:10.970Z
2023-05-19T18:20:45.483Z
2023-05-19T18:20:45.483Z
Pieter Wuille
<p>What kind of software is going to use a merkle root to know if a transaction is in a block ? I know Thin nodes are doing this but this is a little bit useless since major branches are required.</p>
<p>Why don't just do a SHA256(SHA256(...ALL TXs IN A COMPACT WAY...)) nowadays ?</p>

<transactions><merkle-tree><merkleblock>
Who's exploiting Merkle Root?
Loopite
# Who's exploiting Merkle Root?

(Asked by: username_0 on 2023-05-19)

What kind of software is going to use a merkle root to know if a transaction is in a block ? I know Thin nodes are doing this but this is a little bit useless since major branches are required.

Why don't just do a SHA256(SHA256(...ALL TXs IN A COMPACT WAY...)) nowadays ?

**Tags:** transactions, merkle-tree, merkleblock


---

## 1 answers

### Answer by username_1 on 2023-05-19. Score: 3 | Accepted answer

> Why don't just do a SHA256(SHA256(...ALL TXs IN A COMPACT WAY...)) nowadays ?

Even if the premise of your question (that using the Merkle structure is useless) is true, this isn't something that can just be changed.

Changing how block headers commit to transaction data would be a very invasive change, which would be a hard fork, but would also just break literally every piece of Bitcoin software ever written. Unless not changing this means a near-fatal bug for Bitcoin, this isn't even worth discussing.

This isn't even that. Concatenating the hashes instead of using a Merkle tree is maybe a few milliseconds speedup per block, on weak hardware.

> I know Thin nodes are doing this

Yes.

> but this is a little bit useless since major branches are required.

I have no idea what this means.

> **Comments:**
> **username_2**: Moreover, all wallets that use the Electrum protocol fetch a Merkle Tree to make sure a transaction is indeed confirmed. It's definitely not useless.  
> **username_0**: "which would be a hard fork": Agreed.  "but this is a little bit useless since major branches are required.": I was refering to the merkle proof.  
> **username_0**: "Concatenating the hashes [...] is maybe a few milliseconds speedup per block, on weak hardware."  This seems incorrect: with an optimized program using SHA256double on ONE core of Intel(R) Core(TM) i9-10900K, you can perform ~1,500,000 HASH/sec. Blocks contain now ~3500 TXs. So if you want to download ~200 blocks/sec, you will have to perform ~2,000,000 HASH/sec. I just want to show you that the limit can be reached easily. With concatenation you'll just have to do 3500 * 200 + 1 = ~700,001 HASH.  
> **username_1**: I don't follow your math. Mine is: concatenating is 32 bytes per txid; the current Merkle root structure is (after padding, and accounting for double hash) around 192 bytes per txid. At 3500 transactions, that's 3500*(192-32)=560000 bytes. Unoptimized SHA256 implementations on x86 need around 15 CPU cycles per byte, or 8.4M cycles, which is a few ms at modern CPU speeds. Hardware-accelerated SHA256 is an order of magnitude faster than that even.  
> **username_0**: Just see here: https://pastebin.com/rPyxxeDm. with 1.5 * 10^6 HASHs (double-SHA256) / second.  
> **username_1**: Yes, I agree with the roughly 4x faster for the Merkle root checking vs. concatenation (I get 5x faster, even), but that still shouldn't be more than a few milliseconds per block.  

---

