55

The idea (as I understand it) is that the Merkle tree allows for you to verify transactions as needed and not include the body of every transaction in the block header, while still providing a way to verify the entire blockchain (and therefore proof of work) on every transaction. To understand this, first understand the concept of a tree. Consider an 8 ...


23

Merkle roots do not verify transactions, they verify a set of transactions. Transaction ID's are hashes of the transaction, and the Merkle tree is constructed from these hashes. It means that if a single detail in any of the transactions changes, so does the Merkle root. It also means that if the exact same transactions are listed in a different order, ...


22

"Figure 7-2. Calculating the nodes in a merkle tree" from Mastering Bitcoin shows the Merkle Root (HABCD) of a list of four transactions: Tx A, Tx B, Tx C, and Tx D: To verify that a transaction—for example, that with hash HK—is a valid transaction (i.e., part of a list of, in this example, 16 transactions with hashes HA, HB, … HP), one need only perform ...


17

Merkle roots are stored in Bitcoin block headers so as to enable efficient membership proofs for transactions in a block, which are necessary for Simple Verified Payment verification (SPV) nodes that only store block headers and not block contents. It is misleading to say that "Without the Merkle root in the block header, we would have no cryptographic ...


13

The Merkle tree allows verifying that a transaction exists in the block without having the entire block, by following its Merkle branch. Among other things this enables: SPV (lightweight) clients Blockchain pruning Smart pool miners


12

To see how it simplifies verification, consider that in order to verify a transaction T is part of the blockchain, the verifier has to get from the transaction hash to the merkle root. If there are n transaction, there are log_2(n) levels to climb in the merkle tree, so to speak. To climb from the transaction T's hash to its parent P, we only need its ...


12

If you have A, HB and HAB you can obviously check whether A fits. As Jestin noted this is essentially a full Merkle tree with two leaves. However, as a thin client, you only have readily available the Merkle root (which is in the block header) and get told about A. The intermediate levels of the Merkle tree are not provided, therefore, to calculate them, ...


10

Reading your question, I suspect the cause for your confusion is around the setting in which Merkle trees are used. I think you are right that in the Bitcoin world, the setting is taken for granted and is not usually explained clearly. Here's my two cents. To understand the efficiency aspect of Merkle trees, consider the two parties that are actually ...


9

As with many things in Bitcoin, it is likely simply because it worked well enough, and such an attack was not immediately obvious. Several of the choices made in the early days of Bitcoin don't have a full justification behind them, and were simply made because it worked at the time without any major, obvious shortcomings. This is one such scenario, as far ...


8

You're thinking that mining a block is a single long computing process, like computing the trillionth digit of pi or something like that. This is wrong. Each attempt at solving a block takes almost no time at all, and each attempt is independent of the others. Miners make many attempts every second. Each attempt has a very small chance of solving the block. ...


8

If there are an odd number of nodes on any level of the merkle tree, the last node is duplicated and hashed with itself.n If there were a Tx4, the diagram would look like this Root (Hash01234444) / \ Hash0123 Hash4444 / \ / \ Hash01 ...


7

Once a miner has found a block, how easy it is for him to add or remove a tx included in that very block? It is impossible. The solved block depends on every byte of transaction data, nothing can be changed. It is important that it be this way. What if I could broadcast a solved block but leave out the transaction where I sent coins to someone else, ...


7

That's not exactly right. It's more like this: ROOT / \ / \ / \ / \ z1 z2 / \ / \ / \ ...


7

You cannot obtain a list of transactions from the merkle tree. The merkle tree root is part of the block header, which as you said, allows quick verification of the proof-of-work. After the block header, each block contains a list of serialized transactions in the order they appear in the merkle tree. A complete block is a block header + list of ...


7

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 ...


6

I believe it's to enable Simplified Payment Verification (SPV). A client who doesn't wish to download the full blockchain can still verify that a transaction exists in the blockchain by confirming that the block headers are linked, and validating the relevant parts of the merkel tree to confirm the transaction really exists in the block.


6

The merkle root ensures that transactions were part of the block that is being found. It links the block header to the set of transactions in the block. So if you don't update the merkle root you are not actually confirming the transactions, and you won't be able to collect the fee of the transactions. So the incentive to update the merkle root is the same ...


6

Sure: A leaf (transaction) can be pruned when all of its outputs have been spent. A node can be pruned when both of its children have been pruned. However, Bitcoin Core doesn't implement this kind of pruning. It was built on the assumption that you download and validate all blocks. Because of this, it operates in one of two modes: No pruning (the ...


6

The Merkle tree is not stored anywhere. It is implicitly defined by the transactions in a block. Whenever needed, the portion of it that is needed is computed on the fly using the transaction identifiers.


6

I've read and watch about merkle trees but can't figure out how to implement is_present(element) method. Put the entire contents of the merkle tree in an array. Check that the result of hashing all of the elements equals the root of the merkle tree. (If not, this is not the correct merkle tree.) Check if the element is in the array. This takes O(n) time ...


6

They were never "waiting" in the first place. A miner is incrementing nonces and computing hashes continuously. As soon as a new transaction a2 arrives, it is added to the Merkle tree, the block header is regenerated, and hashing continues with the new block header. It's misleading to call this a "restart", since that implies there was some progress that ...


6

Say a block consisting of these 10 transactions, noted by their txids at indexes 0 to 9: E1AF205960AE338A37174B407EE71067C3CD7F04D48A5CEC7E13F6ECCB61DCBC A314970CD7C647D1CC0A477E1A2122B98205B6924B73001B8DAB20EE81C2F4F7 B08EB9DCE0452A1B1970C4D29E88BDEE07669A2A5D1B08586D7FFA17B2E3F6B5 958B9E94AEA9A485BA494C50FB3192558057F7CAED9705D4B11369F071F10642 ...


5

The first transaction has to be the miner's reward. The other transactions can't be miner rewards. Transactions have to appear after any transactions upon which they depend. Other than that the order is up to the miner. Changing the order of the transactions is one of the things a miner can do to change the block hash once he has tried all possible ...


5

Merkle trees in general can have more child nodes, but the Merkle tree for transactional data in Bitcoin is a binary tree. "Merkle trees are binary trees of hashes." –Bitcoin-Wiki Protocol Documentation "From these txids, the merkle tree is constructed by pairing each txid with one other txid and then hashing them together." –Developer Guide: ...


5

You can use a Merkleized binary trie. You first hash all the elements of your set individually. In this example, I use a 3-bit hash function rather than 256-bit. Let's say you have 5 elements in your set, and they hash to: A: 011 B: 101 C: 111 D: 001 E: 010 Now you arrange them in a tree, by using the bits of the key hash as split conditions: root 0 0 ...


5

In Bitcoin, inner nodes of the merkle tree are constructed by concatenating two 32 byte SHA256d hashes together. The resulting 64 byte value is hashed to get the next node in the tree. The leaf nodes are the transactions themselves. Merkle trees are used to prove that a transaction is part of a block as the merkle root is placed in the block header for the ...


5

There is no known way to do this with the current consensus rules nor does it seem likely except via computationally expensive general ZKP. The normal way to make compact proofs of non-membership is to have a hash tree which is ordered by the key you're looking to prove non-membership on. The proof is just the two neighbors that are greater and lesser than ...


4

Mining is a series of independent attempts at finding a good hash for a block. Since all attempts are independent from each other, modifying the block between one attempt and the other have no negative effect.


4

From the original Bitcoin paper: ... we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work ...


4

There are indeed many new transactions every second. The way miners deal with it is two-fold: If an appropriate proof-of-work is found on any merkle root, simply publish that block and any transactions that did not make it into the block go into the next block (assuming sufficient fees) Otherwise, calculate a new merkle root every so often (varies per miner,...


Only top voted, non community-wiki answers of a minimum length are eligible