A question I get asked often and aim to address in the below is quite simple in nature but complex in answer: how do you deal with changing the past in a blockchain, I.e. what if you changed the values in an existing transaction without re-validating the transaction hash?
To be clear, we are not talking about Bitcoin in this instance, we are simply talking about making a change to a transaction in a blockchain. A transaction being any type of data that someone wishes to store in a blockchain.
So what prevents a user from taking a transaction from an existing block and making changes to this transaction?
It is not possible for an individual to change the value of a transaction after submitting it, not only would this break the lock (hash) of the transaction, if would also change the lock of the block containing the transaction (block hash) and since the block are in a continuous chain, it would break all hashes of all subsequent blocks and transactions contained within, lastly it would change the root hash (Merkle Tree) of the block and transaction.
All a node (user) has to do is check all transactions in a block and check that these transactions have not already been used / spend / written off / discarded (depending on the type of blockchain) and accept the block and proof-of-work / proof-of-stake as valid and thus effectively sealing the block. It then broadcasts this to the rest of the network, where a number of other nodes do the same validation until the block is accepted as part of the chain.
The more blocks are added after the transaction, the more secure the transaction becomes within its block. Making the change after the transaction has been locked in the block renders the transaction hash invalid if you don’t recalculate the hash, when the transaction hash is invalid or recalculated this changes the block hash (which is now invalid) and the root hash (which is now invalid), making it easy and obvious to spot tampering.
To understand this question and its answer in detail, we first need to look at the basic principles of a block in a blockchain:
A blockchain needs a means to keep track of the transactions it contains, they do this by collecting all of the transactions made during a period (minutes / seconds) and collecting them into a list, called a block. It is the miner’s job (in a proof-of-work blockchain) to confirm those transactions and write them into a general ledger, the blockchain.
The general ledger (blockchain) is a long list of consecutive blocks, which can be used to explore and validate any transaction made by the users, at any point. Whenever a new block of transactions is created, it is added to the blockchain, creating an increasingly lengthy list of all transactions that ever took place in the network the blockchain governs.
A constantly updated copy of the blockchain is distributed to everyone that participates, so everyone can always see what is going on.
This general ledger has to be trusted, and here is where the main principle of a blockchain lies, I.e. there is no trust necessary between the participants, actually the participants may not know one another at all. So how do you ensure trust, make sure the blockchain stays intact, and is never tampered with? Through mining.
I’ve outlined how mining works from a non-technical point of view in a different white paper (https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-how-mining-works) so I’m not going to elaborate on that here.
Just to be clear, when we refer to mining here, it isn’t just the work of the mining node but also the work of the other nodes that validate the mined block.
The miners take the individual transactions from the memory pool (mem pool) and add them into a block. The actual means by which they do so and why isn’t covered in this document as it isn’t relevant to the topic.
The process is simply that the miner validates the transaction content (correct public keys, digital signature, etc) and then add them into a block, this block is sealed with a lock (the block hash, the Merkle root and PoW). And the sealed block is distributed to the network.
The nodes in the network validate the transactions in the block, validate the nonce of the block before they accept it and redistribute it for validation by the rest of the network. Once you reach a sufficient percentage of validation, the block will be considered “mined” and added to the block chain.
The steps to run a blockchain network are simple, yet ingenious, as per Satoshi’s white paper: “
Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer.
The tie will be broken when the next PoW is found and one branch becomes longer; the nodes that were working on the shorter branch will then switch to the longer one.”
Validation of transactions occurs in various steps, there is individual validation of a transaction, validation of a block and validation of the Root Hash of the block (Merkle Tree).
In cryptography and computer science, a hash tree or Merkle tree is a tree in which every leaf node is labelled with the hash of a data block and every non-leaf node is labelled with the cryptographic hash of the labels of its child nodes. Hash trees allow efficient and secure verification of the contents of large data structures.
Demonstrating that a leaf node is a part of a given binary hash tree requires computing a number of hashes proportional to the logarithm of the number of leaf nodes of the tree; this contrasts with hash lists, where the number is proportional to the number of leaf nodes itself.
The concept of hash trees is named after Ralph Merkle who patented it in 1979, and most hash tree implementations are binary (two child nodes under each node) but they can just as well use many more child nodes under each node.
Please visit this post on a full clarification of the Merkle Tree: https://steemit.com/blockchain/@iwan.spillebeen/blockchain-decrypted-the-merkle-tree
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in.
He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker.
While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network.
One strategy to protect against this is to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will still want to run their own nodes for more independent security and quicker verification.
If you tried to fake a transaction by changing a block that had already been stored in the blockchain, that transaction’s hash would change which in turn changes the block’s hash. If someone checked the block’s authenticity by running the hashing function on it (which is what validation is), they’d find that the hash was different from the one already stored along with that block in the blockchain. The block would be instantly spotted as a fake. Similarly the root hash of the block would no longer be valid, which allows for quick validation using the Merkle Tree.
Because each block’s hash is used to help produce the hash of the next block in the chain, tampering with a block would also make the subsequent blocks’ hashes wrong. That would continue all the way down the chain, throwing everything out of whack.
Yes, it is possible to download a block and change an individual transaction in that block and introducing this fake transaction and block back into the blockchain as part of a new chain, however this would need to be accepted by the network at large as valid.
Due to the expected size of the network, this would never reach enough support, unless the cheater would overpower the network as a whole and gain a 51% control of all validation. This would enable them to introduce non-existing transactions; not entirely impossible in new chains, but highly unpractical and very costly in terms of processing power and electricity in matured chains.
• Title page “Intelligent Solutions” courtesy of http://www.hloom.com/cover-pages/
• Page header / footer “Abstract blue lights” created by Kotkoa - Freepik.com
Reference material on this subject was actually quite hard to find without diving in to the code itself, but some good examples are:
You can contact me here with any questions, suggestions and / or to discuss the topic of this document:
LinkedIn: https://www.linkedin.com/in/iwanspillebeen/
CryptoPub: https://thecrypto.pub/u/iwan.spillebeen
I write these papers to - hopefully - help make blockchain more accessible to people new to the technology, I don't get paid, nor sponsored to write these papers. If you absolutely feel inclined to donate something to the writing of this document, you can do so at the following address:
• Ethereum / Ether: 0x6E2a1f9baD495B894A2c6F8240918620F899f4E2
Blockchain – Decrypted is written as a series of chapters, aimed at demystifying the various workings of blockchain technology. Where appropriate I use examples from existing or to-be cryptocurrencies, these examples are just that, examples, and do not aim at promoting or otherwise endorsing any given cryptocurrency.
This document does not constitute legal or financial advice and I do not make any guarantees or promises as to any results that may be obtained from using my content. No one should make any investment decisions without first consulting his or her own financial advisor and conducting his or her own research and due diligence. I disclaim any and all liability in the event any information, commentary, analysis, opinions, advice and/or recommendations prove to be inaccurate, incomplete or unreliable, or result in any investment or other losses.
