0

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 ?

Improve this question

1 Answer 1

Reset to default
3

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.

Improve this answer
6
  • 1
    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
    May 19 at 18:14
  • "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
    May 19 at 19:33
  • "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
    May 19 at 19:34
  • 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.
    – Pieter Wuille
    May 19 at 19:45
  • 2
    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
    May 19 at 20:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.