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 ...
"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 ...
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, ...
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 ...
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 ...
There are a number of issues here, with different answers.
Can Merkle trees use a commutative operation in general to combine hashes?
Yes, but only if they aren't intended to commit to the order of the leaves.
Clearly when a commutative operation is used, [A,B,C,D] and [D,C,A,B] will hash to the same thing. This is not a problem if the Merkle root is ...
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, ...
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 ...
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
Smart pool miners
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
/ \ / \
Say a block consisting of these 10 transactions, noted by their txids at indexes 0 to 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 ...
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. ...
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 ...
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 ...
Your instinct is correct: a full node can lie-by-omission to a light client and deny them proof that a transaction was included in a block. This is a well-documented vulnerability of SPV wallets and the only mitigation really is to connect to more peers (you only need one "honest" peer).
This problem is also somewhat addressed by BIP157 aka "...
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, ...
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.
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 ...
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 ...
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.
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 ...
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 ...
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:
Now you arrange them in a tree, by using the bits of the key hash as split conditions:
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 ...
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 ...
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 ...
RSA accumulators are far harder to implement correctly
RSA accumulators need a trusted setup (someone, or multiple someones, must come up with a sufficiently large integer that is the product of 2 primes, and then throw those individual primes away). Bitcoin is generally designed to avoid trusted parties.
For a 128-bit security level, you need at least 3000 ...
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.