# Sound but incorrect change in Merkle-tree

From the whitepaper, The first step in in verifying block validity is:

Check if the previous block referenced by the block exists and is valid.

With regard to a merkle tree propogating change upwards upon a change in any of the comprised notes:

The reason why this works is that hashes propagate upward: if a malicious user attempts to swap in a fake transaction into the bottom of a Merkle tree, this change will cause a change in the node above, and then a change in the node above that, finally changing the root of the tree and therefore the hash of the block, causing the protocol to register it as a completely different block (almost certainly with an invalid proof of work).

Would it not be possible to make a change in the merkle tree such that the present block being verified does not change and hence, is Valid.

• No, because, as you quoted, a small change in the tree will propagate through the entire tree, causing it to be completely different. I found this article by Vitalik to be extremely helpful in understanding. Aug 20, 2018 at 23:41

For an example, let's take a very simply merkle tree, with four identical leafs, `L`.

Our tree looks like:

``````                  hash(A, A)
/          \
A = hash(L,L)        A = hash(L,L)
/      \             /      \
L        L           L        L
``````

Now, if we change the last leaf from `L` to `M`, we get:

``````                  hash(A, B)
/          \
A = hash(L,L)        B = hash(L,M)
/      \             /      \
L        L           L        M
``````

Note how just a single change propogates up through its ancestry, until it reaches the root. Since the merkle root is part of the block header and protected by the PoW algorithm, it is not possible to tamper with any element (even the middle nodes) in a merkle tree without invalidating the block.

• So there is absolutely no change that could be done to any given merkle tree in existence that would make, B = A. I think the word I'm looking for here is something close to a collision for the hash. Aug 21, 2018 at 1:46
• You would need a hash collision, which is currently not believed to be practical for keccak256 or sha256d Aug 21, 2018 at 1:50