Many pages (including Wikipedia) say that it is impossible to modify a transaction which is already in the blockchain included.
But why is it so difficult?
Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up.Sign up to join this community
Each block in the blockchain commits to all of the transactions in the block and the order that they are in. It does this by including the hash of all of the transactions in the block header, which is then part of the data that is hashed for the proof of work.
Modifying a transaction in a block will change the hash of all of the transactions which ultimately changes the hash of the block header. This will likely make the block header's hash have an invalid proof of work. Thus in order to modify the transaction, you would have to redo the block's proof of work, i.e. remine the block.
Furthermore, the block header includes the hash of the previous block. So if you want to change a transaction, you will need to also remine all of the blocks following the block which contains the transaction you modified. Lastly, your set of modified blocks are actually a blockchain fork. In order to get it to be accepted by the rest of the network, your fork will need to have more cumulative work than the current blockchain, which effectively means that your fork needs to be longer than the current blockchain.
Overall, modifying transactions already in the blockchain requires remining blocks, and after a transaction already has a few confirmations, doing this requires immense amounts of computing power. So much computing power is required that modifying blocks is effectively impossible to do.
For answering your question, I would like to refer to this rough Blockchain Data Structure Image. So, what are the contents of each block in the blockchain?
Each block consists of:-
Suppose, now you want to tamper or modify data/transactions of Block3. Once you change the data even by a single bit, the hash of that corresponding block will change too but here's the catch. As you see that, Block4 will be having the old hash of Block3 so it will create a conflict. In this way, the next corresponding block(s) will face complexities and the network will kick that malicious node.
Therefore, it is impossible to modify a transaction which is already in the blockchain included as it's an append-only database.
Hope I had answered your question :)
Keep in mind two things:
Digest functions or hash functions ([see here])1
proof of work - Finding a hash that satisfies some conditions (see here)
Briefly, hash functions take a data structure (of any length) and give it a "fingerprint" in a default size. Minor changes to the input info change the fingerprint wildly.
Proof of work, in Bitcoin requires that you assemble a block (with all the transactions AND the previous block hash) and try out values (in the
nounce field) until you reach a valid hash. It is called proof of work because the only way to reach a valid hash is by trying different inputs (thus working) until you reach it.
So, it is hard to change a tx after it has been confirmed as the latest block references the previous block's hash, which in turn references the previous block and so on. If any data changes in any of those blocks, all subsequent hashes will change, leading the proof of work on all these blocks to become invalid.
The only way is to go all the way back and solve the PoW again for all blocks that had hashes affected.
In order to change a transactions confirmed 2 blocks ago (let´s call it block
t-2), you would need to reassemble that block (
t-2), solve the proof of work for it, then reassemble the subsequent block (
t-1), solve it's proof of work and only then you would be able to start working on block
t. While you were spending energy/work on your new version of block
t-2, other miners were already working hard on block
This race to revert something becomes exponentially more difficult the further back you go in the blockchain. In order to even start such an attack the attacker will need, at least 51% of the hashing power and probably way more the deeper "changing the record" goes.