A not so hungry client
Previously we discussed that the Blockchain contains the entire history of all Bitcoin transactions since its genesis in 2008. This implies that you can browse and trace back any transactions ever made. If you use the original Bitcoin client, it requires you to download a local copy of it, which will continuously keep growing and growing as new transactions are being added. This may be inconvenient for the average user, since its current size is 50.5GB and it will only get bigger. Especially mobile devices with their limited storage capacity have no way of storing the entire Blockchain.
Luckily there is a variation of Bitcoin clients, that do not require downloading the entire file – thin clients. But how is this possible? In this article I will explain some more ingenious Bitcoin magic.
This is the basic structure of a block making up the Blockchain:
The blue part of each block is the block header. It contains some other values than the ones depicted above, but we need not concern ourselves with them. Importantly it also contains the root hash of all transactions included in the block! The root hash or Merkle Tree is a method of summarizing large amounts of separate data. You can summarize millions of transactions in a tree-like fashion, and the summary will be only one hash long (if it is a SHA256 hashing function, it will be 256bits etc.). Therefore each header includes a fake-proof summary of all transactions in the current block. It is fake-proof, because if someone was to replace a transaction in a block, it will have the consequence of creating an entirely different root hash in the header. This again will have the consequence of creating an entirely different header hash, invalidating the next block, which contains the old hash in its “previous hash” field. All other blocks after it will be invalidated, too, since they build up on top of an now invalid block.
It is this root hash that thin clients make heavy use of. A thin client would only download the headers of the Blockchain, instead of all the transactions as well. Since 99% of the size of a block is made up of transaction data, this “thin” version of the Blockchain is only around 60MB as compared to 50.5GB. Now if the thin client needs information about a certain address, it simply asks another “thick node” about any transactions linked to that address. The thick nodes would scan their copy of the entire blockchain, filter out only the relevant transactions and send them to the thin client. To prevent thick nodes from sending fake data, they would also include additional data, such as the block where each transaction is located and enough information so that the thin client can compute the root hash of this block and verify its validity. Take for example an address, which is associated with transaction 2 in Block X+3 in the graph above:
1. Thin client sends a request to a thick client about the status of address XXXXY.
2. Thick client scans its local copy of the Blockchain and finds all transactions associated with address XXXXY.
3. In this case only one transaction is found: Block X+3, transaction 2, whereby this address receives 10BTC.
4. Thick client sends the entire transaction 2, Hash 1, and Hash YZ to the thin client.
5. Thin client hashes transaction 2, then hashes the result with Hash 1, and then this result with Hash YZ.
6. The result is identical to the root hash of Block X+3, thus the thin client knows it has not been fed with fake data.
7. Thin client calculates the final balance of address XXXXY if there are other transactions associated with it.
8. Thin client now knows that the final balance of address XXXXY is 10BTC.
The thin client is not concerned about any other transactions. It only receives Hash 1 and Hash YZ, since they summarize all other irrelevant transactions inside Block X+3. This is all he needs in order to recalculate the root hash and ensure the information is valid. Recall that it would not be possible for the thick client to send fake values, since the root hash would change. Voila – with only a local copy of the Blockchain headers, the thin client is still able to check the balance of any address.
Of course this does not come without any disadvantages. Some of them are:
1. Even if the thick client can not create fake data and feed it to the thin client, it is still able to omit transaction data. Thus it can omit any transaction, which sends BTC to (or spends from) address XXXXY. The thin client would be left with only the transaction data that a potential attacker wants to supply to him, leading to an inaccurate display of balance.
2. A malicious thick client can decide to not supply any data to certain nodes – a denial of service attack.
3. By sending requests about certain addresses, the thin client exposes which addresses it controls. This can be used for deanonymizing users. A possible solution are so called bloom filters, which do not send requests about a certain address, but rather about several addresses, making it unclear which addresses the client controls. For example a thin client could send a request about the status of all addresses ending with –XXY. This creates some additional network overhead, but mitigates the mentioned risk.
Block explorers are web services, which provide Blockchain data in a user-friendly way. If you are abroad and want to make a quick check on one of your addresses, this would probably be the most convenient way. There are several services, each with a different graphical way of portraying transactions. Even if they may look very contra intuitive and complicated at first, once you spend 10 minutes on understanding the basic structure, these explorers become a very handy tool. Some prominent explorers are
blockchain.info, blockr.io and blocktrail.com.
Let me give you a small demonstration of such an explorer. For this I will use blockchain.info and the random address 15GT7NctuRCnL9YrsuQEjfyXuCUk9tjmjj.
When you search for this address, you will first be shown the total amount of BTC it ever received and the current balance. As of now, there are 0.44047297 BTC on it and this is all it ever received.
Scrolling below you can see all transactions associated with this address.
For example, you can see that transaction 8f89e3afd6f2b96537446c3c80d05f6abbaa18692d106756e9d1093f5e537f60 spent 4.78791674 BTC in total:
0.44047297 BTC were sent to this address and 4.34734377 BTC to 1NarF2q1uvoCUhWoAVRDYwDw4rHomhrSyx. Spent or unspent tells you, whether they still reside on those addresses or are further spent.1C6JJrXjcRzjzLEQMurJ6ssnSUiV7Qr8tY is the address those BTC came from. If you want, you can further trace back, who this address received its BTC from. Clicking on it shows that it received 4.78791674 BTC from 12iXTKDMFhjZMf93WGT8btk8AXE9Bwhw72, whereby 0.49188326 BTC were also send to another address. You can continue going back through the transaction history until you eventually find the point, where the Bitcoins were created – a so called coinbase transaction. This is the reward created for the person who was able to confirm that particular block.