Note: This is a reading note of chapter 3 in the book Bitcoin and Cryptocurrency Technology.
Traditional accounting uses balance based model. In order to validate the balance number, we need to check all relevant transactions and all of them need to be valid in order to make the final balance valid. This validation process can be time consuming and expensive.
Instead, Bitcoin uses transaction based model, which means transaction is used as the unit for validation. A transaction consists of two parts:
- input: the sources of the fund
- output: the receivers of the fund
In order to have a valid transaction, the following two conditions should be met:
- The output value should match the input value. One exception to this rule is the mining reward which is a special transaction where the system creates new Bitcoins.
- The Bitcoin in the inputs should be unspent.
As we can see, there is no concept of "balance of account" in a transaction based model. Another difference is that in a transaction based model all coins are traceable. This is not the case in balance based model. Here is an example:
Suppose we have an account and we make two deposits: $10 and $20. Now imagine we buy a $5 coffee. For a balance based model, we actually don't know the source of the $5 payment. Does it come from the first deposit of $10 or the second deposit of $20? More importantly, how could we know if the account has sufficient fund? This is reason why we need to check all transactions (e.g. deposit, withdraw and transfer) related to this account. With a transaction based model such as the one used in Bitcoin, the purchase of the $5 coffee is a transaction. The output of this transaction is the fact that the coffee shop (the receiver of Bitcoins) receives $5 and the input of this transaction is the source of the fund. For example, we could specify $2 comes from the first deposit and $3 comes from the second deposit. Notice that a deposit is also a transaction.
Here are some of the benefits of transaction based model in Bitcoin:
- change address
- efficient verification
- consolidating funds
- joint payments
Here is an exmaple of a typical Bitcoin transaction summary:
As mentioned earlier, Bitcoin uses transaction based model and the output of a transaction should always match the input. In the above example, the total input value is 0.00875330 + 0.12065394 = 0.12940724 BTC and the output value is 0.11935791 + 0.01004933 (transaction fee) = 0.12940724 BTC.
The data structure of Bitcoin transaction consists of three parts:
- meta data
As the name indicates, the meta data section of a Bitcoin transactions stores meta information such as the hash and the state of the transaction. Note that the hash is the identifier of a Bitcoin transaction.
Input section contains the information about the source of Bitcoins used in the transaction. Each record in the input list points to an output in a different transaction and it also contains a signature indicating that the owner of the Bitcoin agrees with the details in the transaction. The output section is simpler because it only needs to specify the receiver of the Bitcoin.
Notice that when we specify the source or the receiver of Bitcoins in a transaction, we provide more than just the hash value of the source transaction and the address of the receiver. Bitcoin has a built-in script called Bitcoin Script that is used to validate transaction. The script uses a stack based language. It's a simple langue but a powerful one. In most cases, the instructions in a script are used to validate hashes and signatures in a transaction but with creativity we could use it to express all sorts of conditions for a transaction to be valid and this opens the possibility to design smart contracts.
To validate a transaction, we just combine the script in the input section and the script in the output section and execute it. If the execution of the combined script completes without any error, then the transaction is valid.
- Escrow Transactions
- Green Address
- Efficient Micropayments
- Lock time
- Smart contracts
A Bitcoin block consists of two parts
- Header: The header contains two hash pointers. One points to previous block, the other points to the transaction data.
- Hash tree (Merkle tree): This is the data structure used to store transactions.
There are two types of nodes in the Bitcoin network:
- fully validting node: Fully validting nodes store the entire blockchain and track the set of unspent transaction outputs. Only fully validating nodes can verify all transactions in the network. They also need to constantly listen to the network for new transactions in order to be up-to-date.
- ligtweight nodes: Most of nodes in the Bitcoin network are lighweight nodes. Lighweight nodes do not have the entire block chain so it cannot verify all transactions. Instead, they only care about transactions that involve themself and trust fully validting nodes in the network to verify all other transactions.
It might be more difficult that it appears to make a change in the protocol. The problem is that at a given point of time we could have nodes running different version of the Bitcoin software and they need to reach a consensus. There are two types of changes. One leads to a soft fork and the other leads to a hard fork in the block chain. Recall that the blocks in the network forms a tree and it has different branches. The longest valid branch is the main block chain.
What matters is if the new software and old software can reach consensus. If a protocol change is considered valid by the new version of the software but invalid by the old version of software, then it creates hard fork. In this scenario, old code will discard blocks created by new code and the main block chain in their view is the longest branch which only contains the blocks created by old code. On the other hand, new code accepts all valid blocks regardless of who creates them. If the majority of the nodes in the network uses new version of the software, eventually they will build the longest block chain in the network. At this point, there are two main block chains in the system and they are supported by two different groups of nodes.
On the contrary, if a protocol change is considered invalid by the new version of the software but valid by the old version, then a soft fork is created. In this scenario, it is still possible for old and new version of code to reach a consensus on the main block chain. However, the block proposed by old code will be rejected by the new code and the owner of the old code has the motivation to upgrade their software because if the proposed block is rejected, the node will not receive the reward.
----- END -----
©2019 - 2021 all rights reserved