Decoding the Bitcoin paper Part 2— Introduction, Transactions, and Timestamp server
This post is the second installment in the Decoding the Bitcoin paper series.
We will talk about the next three sections of the paper — Introduction, transactions, and timestamp server. I suggest you read the preface in part 1 to get the best out of this article.
Glossary
Proof vs Trust
The difference between the two seems trivial to explain as we know these words from English. But historically our systems have been built on trust and we don’t understand the need for proof-based systems.
I recommend you read this post (third point in “A personal example” subsection) if you feel the same.
In the current context, I define proof as a deterministic answer to the question “Do you trust X to get the job done?”
Introduction
This section explains the importance of decentralization by pointing out the flaws in the existing system. These flaws such as control being exercised by the mediator, high transaction prices, etc. gave rise to the need for an electronic system that works on proof instead of trust.
The section further touches upon the problems solved by the paper. The technical part begins now!
Transactions
We define an electronic coin as a chain of digital signatures.
Just this phrase in the paper cost me a few hours to understand what it’s saying.
In a traditional banking system, our account’s balance is stored in a database. This is done so that when we make a payment, the bank can check if we have enough balance to make the transaction.
Once this condition is met, the balance of our account is decreased so that we can not use the same money again. Similarly, when we receive a payment, the balance is increased so that we can spend more in future transactions.
Hence, the balance in the bank’s database serves as the single source of truth. We are trusting the bank to keep this number safe and correct.
On the contrary, bitcoin works on the principle of a chain of transactions. Similar to the traditional system, the amount being promised to be paid should be owned by the payer. How is this done without requiring trust?
Every transaction has certain inputs and outputs. Inputs represent the bitcoins that the payer owns. The proof that the payer owns those bitcoins is given by referencing the transactions in the past where this payer was the payee and therefore received some bitcoins that they can now spend.
We’ll shortly understand this with an example.
The outputs contain the addresses (analogous to bank accounts) of the payees and the amount to be transferred to those addresses. Now, the total amount of bitcoin in inputs should be sufficient to meet the amount in outputs.
We can not use the same inputs for multiple transactions (double spending). If we try to do it, the network will invalidate this transaction as it will see that we’ve used those inputs in a transaction in the past.
Example
I got $5 from Alice, $3 from Bob, and $7 from Charlie. These are transactions that have happened in the past and are provable by the blockchain.
Now, I have to make a payment to two vendors for their services. I owe the first vendor $10 and the second vendor $4.
To make this payment, I will give proof of the previous 3 transactions where I received the money. They sum up to $15. This will serve as my input.
Next, I will provide addresses of those vendors and the amount for them separately as $10 and $4. This sums up to $14. There is still $1 unspent from the inputs which I can send back to myself (analogous to the change remaining when you pay in cash).
You can see this in the third output where the owner has set the output address the same as the input address.
If I don’t pay the change back to myself, it will be used as an incentive for the network to process your transaction. More about incentives later.
Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin.
This part explains what is present inside a block in the blockchain. As we’ve seen in part 1 of the series, the transaction is signed by the payer. The details of what this transaction does need to be in it.
Apart from inputs and outputs, a transaction also contains the hash of the previous block. This is how a chain of blocks is formed. You can read the contents of the previous block by using the 'previous hash' data in the current block to query the blockchain for the block with that hash.
Why do we need the previous block? A block contains multiple transactions. So the order of the blocks also helps determine the order of transactions.
We need to maintain the order of transactions. Why? If Alice pays Bob $10 and Bob pays the same to Charlie, we need the first transaction to come before the second transaction so that Bob has received those $10 before making the payment.
You can see a real block here and a real transaction here.
Additionally, the public key of the next owner is added to the block. This corresponds to the wallet address of the payee.
The remaining part of this section builds upon preventing double-spending. In traditional systems, the central authority would know if someone tries to double spend. But how to do it in blockchain?
We make a rule — Only the first transaction with certain inputs counts, other transactions using those inputs will be rejected. For this, we need two things:
Everyone should know all the transactions that happened in the past
This is needed because we need to reference the previous transactions in our inputs. If we lose the history, there’s no way of proving that you own the bitcoins that you are trying to spend.
Everyone should agree on the order of transactions
This is needed so that in the case where the same inputs are used multiple times, we can reject the second transaction but allow the first one.
This is another reason why the previous hash is included in a block.
Timestamp server
It is a proposed approach for maintaining the order in which blocks are added and having everyone agree to it. Let’s see how it works.
Once the verification process is over, the timestamp server generates a hash. This hash consists of the current block’s data combined with the previous hash generated by the timestamp server (for the previous block) and broadcasts this hash to everyone.
This is done so that when a new transaction comes that is trying to double-spend, it is provable that there already existed a block in the past that used those inputs.
This also reinforces previous blocks; meaning to say that a given block’s genuineness and its order are solidified even more when blocks are added after it. Why?
Multiple nodes are always working to confirm transactions and add blocks to the chain. When a node adds a block, it implies that it has accepted the genuineness of the blocks before it.
If that weren’t the case, the node would add the block after the last block that was accepted as genuine by it. That is not necessarily the last block of the entire chain.
Thus, when more blocks are added after a given block, it implies that more nodes have agreed that that block’s transactions occurred before the transactions in the following blocks thereby solidifying the order.
In this way, we maintain the order of the blocks and have a majority agreement.
Conclusion
- We defined trust and proof.
- We saw how the system of the account balance is different in bitcoin.
- We understood how inputs and outputs are used to make transactions.
- We got to know the importance of maintaining the order of transactions and how it is implemented.
Follow to get notified when the next part comes up.
Connect with me on Linkedin and Twitter.
Previous part: Part 1 — Prerequisites and abstract
