What is BTC#
Before I read this white paper, I naturally thought that Bitcoin was just a string of code representing one Bitcoin. But that's not the case. In the entire Bitcoin system, there is no concept specifically used to refer to Bitcoin.
The white paper mentions:
We define an electronic coin as a chain of digital signatures.
We define a chain of digital signatures as a form of digital currency.
When I first read this, it was easy to assume that one Bitcoin equals one digital signature. This leads to a huge question: how do you represent 0.1 BTC?
In the subsequent section "9. Combining and Splitting Value," it states:
Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.
Although it is possible to handle each coin individually, making a separate transaction for every cent would be very inconvenient. To allow for the splitting and combining of value, transactions contain multiple inputs and outputs. Typically, there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment and one for returning change (if any) back to the sender.
In the entire blockchain system, only transaction records are stored; Bitcoin serves merely as a unit of measurement, recording how much BTC was transferred in the transaction record. The wallet address corresponds to the transaction records in the entire blockchain, rather than BTC itself.
What is the process of a transaction initiated?#
In "2. Transaction," the original text is as follows.
We define an electronic coin as a chain of digital signatures. 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. A payee can verify the signatures to verify the chain of ownership.
We define an electronic coin as a chain of digital signatures. 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 appending these to the end of the coin. The payee can verify these signatures to confirm the chain of ownership.
According to the definition of BTC we just mentioned: BTC is just a unit of measurement; what is actually stored on the blockchain is the transaction record.
For example:
Under my wallet address, I have the following three transaction records:
- 0.6 BTC transferred to my address.
- 0.8 BTC transferred to my address.
- 0.3 BTC transferred to my address.
These three transaction records indicate that I have 1.7 BTC in my address. Now, I need to send 1.5 BTC to my friend B.
First, the inputs for this transaction are the three transaction records I own (because 1.5 BTC requires all three transaction records).
Therefore, when the transaction occurs, the first thing to do is to use my private key to attempt to match the digital signatures at the end of these three transaction records to prove that these three transaction records belong to me. Then, the transaction can begin.
Next, the hash of the previous transaction refers to the three hashes corresponding to the three transaction records.
Then, this transaction has two outputs:
- 1.5 BTC transferred to my friend's address.
- 0.2 BTC transferred back to my address (change).
At the end of these two transaction records, it will look like this:
- The hash of the three transaction records + the public key of friend B calculated to obtain a digital signature, which is appended to the end of the 1.5 BTC transaction record.
- The hash of the three transaction records + my own public key calculated to obtain a digital signature, which is appended to the end of the 0.2 BTC transaction record.
This completes a transfer, transferring the ownership of one transaction record to friend B, while the other change returns to me. Verifying ownership only requires attempting to decrypt with the private key. This is what happens during a BTC transfer.
How to avoid double spending?#
What is double spending? Let’s illustrate with an example:
Now, I have 10 BTC, and I plan to send 8 BTC to friend B and 9 BTC to friend C. So, I follow the transaction process mentioned above and successfully construct two transactions, initiating both at the same time. Although we can easily verify whether the BTC belongs to us, we cannot guarantee that the sender does not also want to send those BTC to another person simultaneously.
The problem arises because B and C trust my word, and there is no communication between B and C, making it impossible to determine the order of the transactions.
In reality, the solution to this problem is to introduce a third-party institution, similar to a bank. B and C only trust transfers initiated by this institution, and I can only initiate transfer requests to this institution. Since all transfer actions must go through a central institution, there is no issue of information not being communicated; the institution knows how much money I have, how much I can transfer, and will not allow me to initiate double spending at will, while also clarifying the order of all transfers.
However, the problem is that the introduced third-party institution requires us to fully trust it. Trust is a difficult behavior to regulate; in the above example, we cannot guarantee that I am not colluding with the third-party institution. Even though there are many procedures and protocols in reality to help people trust these third-party institutions, the fact remains: as long as there are human participants in the process, fraudulent behavior is inevitable; it’s just a matter of time.
What BTC aims to do is eliminate this third-party institution and design a transaction system that guarantees security without requiring third-party trust.
"Timestamp Server"#
The first measure is to implement a design similar to a Timestamp Server. Similar to a newspaper, it records a time and specific events, indicating the order of all transactions.
In the block, BTC's blocks include timestamps and link all blocks using hashes.
The hash is calculated as follows: the hash of the previous block + the data of this block = the hash of this block. You can think of it as each block used to record transactions being linked together by hashes. This is why it is called a blockchain.
In this calculation method, the hash value depends on the specific value of the previous hash.
One consensus is that even a slight change in the input value of the hash algorithm will result in a completely different calculated value.
So, if we attempt to modify the first block, the entire hash value will change dramatically. Consequently, the hash value corresponding to the second block will not match at all. To successfully tamper with the first block, you would have to recalculate the second block. This continues for all subsequent blocks. Whether you want to delete or modify history, you must update the data of all blocks.
Every time a new block is added, it enhances the immutability of all previous blocks, ensuring the order of time.
"Proof-of-Work"#
The proof-of-work mechanism in BTC. Each miner expends considerable computational effort to gain the right to write a new block. Only after providing proof of work can a node (miner) write content to the new block.
How is proof of work provided? BTC is designed as follows:
Each block consists of the following parts:
- The hash of the previous block (prev hash)
- All transaction data of the current block (in practice, it should store the Merkle Root)
- Timestamp
- Difficulty target (determines how many leading 0s are required in the hash for proof of work)
- Random number (nonce)
In this, the only thing the miner does not know is the "random number (nonce)." This nonce value is what is known as "proof of work."
In "Proof-of-Work," miners need to solve a mathematical problem: Given the hash value calculated from all content except the random number, determine what the nonce value should be so that the hash value has n leading zeros, with the remaining digits matching the previous hash value. The specific number of leading zeros, n, is determined by the difficulty target.
As for how the difficulty target is generated, I searched for information but have not figured it out yet. I only know that this difficulty target is dynamically adjusted based on the current block generation difficulty of the network.
When the nonce value is calculated by the computer, it can serve as the node's "proof of work," proving that the node has the right to write to the new block, and after writing the block, it can broadcast it to all nodes. Although calculating the nonce value is very difficult, verifying whether this value is correct is quite simple; other nodes only need to substitute it in and check if it equals the expected result.
Calculating the nonce is not a simple task for the computer; it requires considerable computational power to derive the result. Therefore, combined with the earlier "Timestamp Server," if someone wishes to modify a block, the calculation of this nonce cannot be avoided.
If you want to modify the history of a block, you must be prepared with sufficient computational power to recalculate the nonce for all involved blocks. As time goes on, the difficulty target will increase, making subsequent calculations more challenging; the more blocks there are, the harder it becomes to tamper with history.
"Network"#
New transactions are broadcast to all nodes.
Each node collects new transactions into a block.
Each node works on finding a difficult proof-of-work for its block.
When a node finds a proof-of-work, it broadcasts the block to all nodes.
Nodes accept the block only if all transactions in it are valid and not already spent.
Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
New transactions are broadcast to all nodes.
Each node collects new transactions into a block.
Each node attempts to find a difficult proof-of-work for its block.
When a node finds a proof-of-work, it broadcasts the block to all nodes.
Nodes will only accept the block if all transactions in it are valid and have not been spent.
Nodes indicate their acceptance of the block by creating the next block using the hash of the accepted block as the previous hash.
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 proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.
Nodes always consider the longest chain to be the correct one and will continue to work 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 will work on the first one they received but will save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.
Combining the above points, the issue of double spending is resolved.
- If I attempt to initiate two transactions simultaneously in an attempt to double spend, the proof of work + timestamp service design can create a time sequence for the transactions and broadcast them to all nodes. The sequence ensures that double spending cannot be completed.
- If I attempt to complete double spending from different geographical locations, the difficulty of proof of work will make it difficult for nodes to complete two transactions simultaneously.
- Even if two geographically separated nodes manage to write both transactions into blocks at the same time, BTC will experience a fork until the longer fork replaces the shorter one, ensuring that only one of the two transactions can succeed.
Summary#
The double spending problem refers to the same Bitcoin being used for two payments. Bitcoin solves this problem through proof of work and the longest chain principle. When new transactions are broadcast to the network, miners package them into blocks, find a hash that meets the difficulty requirements through proof of work, and add the block to the blockchain.
If two transactions attempt to spend the same UTXO, only one transaction will be included in the block first, while the other transaction will be invalid due to the UTXO already being spent. The longest chain principle ensures that the entire network reaches a consensus, preventing double spending.
Merkle Tree#
The Merkle Tree mentioned earlier. If disk space needs to be saved, the storage of nodes' blocks can omit the specific data. It is sufficient to calculate the hashes of all transactions in the block in the form of a Merkle Tree, calculating a root hash pairwise, eliminating the need to store data, and using the root hash to verify data consistency.
Even if we want to verify a specific transaction on a block, we only need to take the block header to find other nodes on the network that store data, and find the corresponding data of the longest chain node to verify our transaction.
Where did the first BTC come from?#
There is one block that is special; its hash is not linked to any other block, and that is the genesis block. The first BTC was born in this genesis block, with 50 BTC.
As previously mentioned in "Proof-of-Work," each miner node is striving to calculate and obtain the right to write to the block.
First, the miner who successfully obtains PoW will receive a block reward. Initially, the reward for a block is 50 BTC, and it halves every four years. This continues until 21 million BTC are mined. This is the origin of mining and the main source of BTC.
The Bitcoin block reward is halved approximately every 210,000 blocks (about every four years). This design is intended to control the total supply of Bitcoin.
- The first halving (2012): the reward decreased from 50 BTC to 25 BTC.
- The second halving (2016): the reward decreased from 25 BTC to 12.5 BTC.
- The third halving (2020): the reward decreased from 12.5 BTC to 6.25 BTC.
- Future halvings will continue until all 21 million bitcoins are mined.
Secondly, miners who obtain PoW naturally have the right to collect gas for each transaction. The main sources of income for miners are mining and gas.
About Wallets#
In reality, what is stored in wallets is not Bitcoin but the transaction records (UTXO) of Bitcoin. If you want to know how much money is in your address, you actually need to traverse the entire blockchain, find all UTXOs related to yourself, and then sum the data.
This operation sounds slow, but in practice, most wallet software utilizes memory and indexing optimizations to speed up query times. Specific implementation methods may include Bloom filters, address indexing, and other technologies.
Is there more than one transaction in a block?#
Yes.
Transactions are not immediately written into blocks; after they are received and broadcast, they are first placed in the memory pool (mempool).
Then miners select transactions from the memory pool to package, calculate the hash, and then start calculating the nonce value to obtain proof of work (Proof-of-Work).
If the miner successfully finds the nonce value, these transactions will then be confirmed and written into the block.