Bitcoin Forum
November 11, 2024, 08:33:16 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: txs in blocks: why Merkle tree instead of regular hash?  (Read 1491 times)
Kazimir (OP)
Legendary
*
Offline Offline

Activity: 1176
Merit: 1011



View Profile
April 20, 2016, 09:46:01 AM
Merited by ABCbits (1)
 #1

What's the advantage of using a Merkle tree for the transactions in a block, instead of just a single regular hash (like sha256) for all the tx data?

In theory, there's no difference between theory and practice. In practice, there is.
Insert coin(s): 1KazimirL9MNcnFnoosGrEkmMsbYLxPPob
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
April 20, 2016, 10:27:29 AM
Merited by ABCbits (3)
 #2

Because then I can prove to you that a block contained a particular transaction without sending you the whole block.
Kazimir (OP)
Legendary
*
Offline Offline

Activity: 1176
Merit: 1011



View Profile
April 20, 2016, 12:27:34 PM
 #3

Because then I can prove to you that a block contained a particular transaction without sending you the whole block.
Right, but then wouldn't it be easier to just take one hash of all the txs' hashes? That way you could just send a list of tx hashes, instead of actual tx data, to prove that one or more particular txs are in the block.

Or is the merkle tree a construction to optimize even further on this? So it only requires to send or check one branch of tx hashes up until the leave that includes the intended tx? (I'm not exactly familiar with merkle trees, but I can sort of see how that could work)


In theory, there's no difference between theory and practice. In practice, there is.
Insert coin(s): 1KazimirL9MNcnFnoosGrEkmMsbYLxPPob
domob
Legendary
*
Offline Offline

Activity: 1135
Merit: 1170


View Profile WWW
April 20, 2016, 04:09:23 PM
Merited by ABCbits (1)
 #4

Or is the merkle tree a construction to optimize even further on this? So it only requires to send or check one branch of tx hashes up until the leave that includes the intended tx? (I'm not exactly familiar with merkle trees, but I can sort of see how that could work)

Exactly this.  You only have to send a branch, so it will be on the order of size log(N) if there are N transactions in the block.

Use your Namecoin identity as OpenID: https://nameid.org/
Donations: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS | GPG 0xA7330737
piotr_n
Legendary
*
Offline Offline

Activity: 2055
Merit: 1359


aka tonikt


View Profile WWW
April 22, 2016, 03:07:36 PM
Merited by ABCbits (1)
 #5

It is also to improve mempool management.

If you want to replace one tx inside a block that is being mined, it requires less computation with the merkle tree system.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
cjmoles
Legendary
*
Offline Offline

Activity: 1176
Merit: 1017


View Profile WWW
May 01, 2016, 07:30:37 PM
 #6

I have a similar question: is the Merckle trie the most efficient data structure for blockchain management or might there be a more efficient radix trie?  This is something that has been rolling around in my thoughts lately....Has there been any substantial study done on developing a more efficient system, either real or theorized?  I've been thinking Mandelbrot functions....Anything on that?
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
May 02, 2016, 01:19:12 AM
 #7

I have a similar question: is the Merckle trie the most efficient data structure for blockchain management or might there be a more efficient radix trie?  This is something that has been rolling around in my thoughts lately....Has there been any substantial study done on developing a more efficient system, either real or theorized?
A "merkle tree" is what you need to cryptographically harden a tree. The words "merkle tree" do not say much about the particular tree construction being used.

Most efficient for what?  For simply showing membership, which is all it's used for in Bitcoin, it's very hard to even match a plain binary tree (we do not use a trie) with anything else.

For doing other things, many other kinds of data structure have been proposed at various times.

Quote
I've been thinking Mandelbrot functions....Anything on that?
Perhaps you were looking for the ethereum blog? Please don't waste our time here by asking about random semi-relevant collections of technical terms. ("Hey guys, have you considered using a post-quatum NoSQL skip-list?!? I hear it has webscale!")

cjmoles
Legendary
*
Offline Offline

Activity: 1176
Merit: 1017


View Profile WWW
May 02, 2016, 01:33:39 AM
 #8

I have a similar question: is the Merckle trie the most efficient data structure for blockchain management or might there be a more efficient radix trie?  This is something that has been rolling around in my thoughts lately....Has there been any substantial study done on developing a more efficient system, either real or theorized?
A "merkle tree" is what you need to cryptographically harden a tree. The words "merkle tree" do not say much about the particular tree construction being used.

Most efficient for what?  For simply showing membership, which is all it's used for in Bitcoin, it's very hard to even match a plain binary tree (we do not use a trie) with anything else.

For doing other things, many other kinds of data structure have been proposed at various times.

Quote
I've been thinking Mandelbrot functions....Anything on that?
Perhaps you were looking for the ethereum blog? Please don't waste our time here by asking about random semi-relevant collections of technical terms. ("Hey guys, have you considered using a post-quatum NoSQL skip-list?!? I hear it has webscale!")



No, I wasn't looking for the ethereum blog....interesting project though....I was just thinking about how long it takes my core wallet to synchronize if I leave it closed for a few weeks and was imagining how large the ledger would become years into the future.  It'd be nice to somehow be able to access the information on the blockchain without having to download the entire ledger....that's all.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3542
Merit: 6886


Just writing some code


View Profile WWW
May 02, 2016, 01:35:29 AM
 #9

No, I wasn't looking for the ethereum blog....interesting project though....I was just thinking about how long it takes my core wallet to synchronize if I leave it closed for a few weeks and was imagining how large the ledger would become years into the future.  It'd be nice to somehow be able to access the information on the blockchain without having to download the entire ledger....that's all.
The time to sync the blockchain and index the data has nothing to do with merkle trees. The time to calculate the hash is insignificant compared to the time it takes just to download all of the data.

cjmoles
Legendary
*
Offline Offline

Activity: 1176
Merit: 1017


View Profile WWW
May 02, 2016, 02:18:29 AM
 #10

No, I wasn't looking for the ethereum blog....interesting project though....I was just thinking about how long it takes my core wallet to synchronize if I leave it closed for a few weeks and was imagining how large the ledger would become years into the future.  It'd be nice to somehow be able to access the information on the blockchain without having to download the entire ledger....that's all.
The time to sync the blockchain and index the data has nothing to do with merkle trees. The time to calculate the hash is insignificant compared to the time it takes just to download all of the data.

Yes, that's my point (I think).  The serial nature of the blockchain and the means by which we access and process the information it contains seems to be mismatched.  In other words, would it be possible to insure the validity of the ledger, access its information, and secure the network with a pruned data structure?
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!