--snip--
one of the application of a merkle tree is the block header: you need to able to prove the transaction data inside a block didn't change just by looking at the block header... It's impossible to add all transaction hashes to the header, so we use a merkle tree.
This way, when a miner finds a block header whose sha256d hash is under the current target, the block can no longer be changed, since changing any transaction in the block will change the merkle tree and invalidate the block
After reading this, I wanted to understand how a block can be changed or edited if this process is entirely irreversible. Merkle tree as I am guessing is also a chain of blocks containing the info and it keeps growing as the new data is received. What makes it different from the block and its header? So those are different components on the chain.
I'll try to simplify things a bit, but the nature of these things is rather complex, so it'll still require some effort to grasp the simplified explanation.
Let's assume the current blockchain height is 812460. This means, 812459 blocks have been found on top of the first block.
Block 812460 has a block header.
When i'm a miner trying add a block to the blockchain, i'm trying to find the block with height 812461.
In order to do so, i have to find a block header that, when hashed using the sha256 hash function twice, results in a hash that's under the current target.
I create a block header by taking the hash of the previous block's header (812460), the merkle root of 1 Mb of transactions from my mempool (excluding the witness data) and a nonce (next to some other data like the Version, Bits and Time, which i'm going to discard to simplify things a bit). I do a sha256d of this block header, and if my result is OVER the current target, i iterate the nonce and retry (untill i find a nonce for which my current hash is under the target... Offcourse the odds of finding such a header by myself is really small).
The merkle root in the block header i'm creating is built by building a merkle tree out of each of the transactions in the block. If i change anything about one of these transactions (even their order) the merkle root changes. This means that once i find a valid block header, both the previous block and all of the transactions in my current block become immutable. If i would change a transaction in a previous block, the merkle tree of the previous block would change, the block header would change and the odds of the new block header's sha256d still being under the target is really, really, really small... It also means my current block can no longer change (same logic about the merkle tree + the hash of the previous block header is also a part of the current block header).
The end result is an immutable blockchain..
If i ever wanted to change the history by removing a transaction from (for example) block 812360, it's merkle tree would change and i would need to find a completely new nonce that would make the sha256d hash of this header under the current target, and then i would need to re-mine block 812361, 812362,... And i would need to catch up (and exceed) the current tip because otherwise the rest of the network would just reject my alternative chain... In reality, this would cost billions in hardware and power, and it's just not possible economically... That's what makes our blockchain secure
.
The network is programmed to, when faced with 2 alternative chains, pick the one with the most cumulative work... So if i wanted to change history, i'd have to exceed all the work in the current main chain.
