In this section we look at how a cryptocurrency can be designed. Let’s ignore decentralization for a moment and assume that there is a centralized institution that everyone trusts, such as a central bank, and that this central bank has the power to issue digital currencies. Assuming everyone knows the public key of the central bank, how should the central bank issue digital currency?
Is it okay to issue digital currencies in the same way that paper money is issued? The digital currencies issued are signed with the private key of the central bank, and the public key of the central bank can be assumed to be known to everyone. When a person receives a digital currency, they can verify that it is real. When you buy something, for example, I need to give you 100 dollars, I will send you this digital currency, you verify that it is indeed issued by the central bank, which completes the payment process. Will this program work?
There is no blockchain used here, the public-private key system used here is cryptography – asymmetric encryption algorithms. The problem here is that if I want to buy something and I give you 100 dollars, but I can make another copy, what this digital currency is, is a document. This document has the signature of the central bank, the content of the document can not be forged, but it can be copied, you can make many copies of it. This is not the same as paper money, I give you the paper money, I’m gone, can not spend it twice.
This difference with paper money is called a spend twice attack – also known as a double spending attack. One of the main challenges facing digital currencies is how to prevent double spending.
The solution just now is not working. Let’s improve it, or the central bank to issue digital currency, but each digital currency has to have a number, just like the RMB also has a number, and then the central bank has to maintain a database, which is like a big table, which records each number of digital currency in who.
For example, when a digital currency is spent in my place, I give you the digital currency, you not only have to verify that the digital currency has the signature of the central bank, but you also have to give the central bank to verify that the digital currency before I have not spent. Once the central bank verifies that this digital currency is indeed in my possession, so it is legal for me to use it to make payments, and at the same time the central bank has to modify it, this digital currency is now transferred from me to you.
Then in the future if I want to spend this digital currency again, another person with the central bank to verify the central bank found that it is not right, this digital currency I have already spent out, is no longer in my place, which can prevent the double spend attack.
What’s wrong with this program? It’s too cumbersome. Any payment between two people has to go through the central bank. There is no problem with the correctness of this scheme, and it works that way in practice, but it is a centralized scheme. The issuance of digital currencies is uniformly controlled by the central bank, and every transaction needs to be confirmed by the central bank to prove its legitimacy. So can we get a decentralized program to change the function of the central bank to be done by the majority of users. This is a problem that Bitcoin, the digital currency system, has to solve.
A decentralized currency has to solve two problems. One is the right to issue digital currency, who has the power to decide to issue digital currency. Right now there is no central bank, so how do you decide when the currency should be issued and how much should be issued? The second problem is how to verify the validity of the transaction. How to prevent DOUBLE SPENDING as just mentioned.
Regarding the first question, who issues the currency, this is determined by mining in the bitcoin system. I’m going to talk about that in more detail later, but I’m going to talk about the second problem, which is how to prevent double spending, and the solution to that problem. The solution to this problem is somewhat similar to the one we just described, in that we need to maintain a data structure to detect whether or not the currency has been spent before, and by whom. Only this data structure, not by the central bank to maintain, but by all users to maintain this data structure. The blockchain is used here.
Let’s say there’s a user, A, who has been given the power to issue currency, what we call the right to mint coins, so he issues 10 bitcoins, this is called CreatCoin to A, 10 bitcoins, and writes this first transaction to the blockchain.A gets this coin, transfers it to B and C, giving 5 bitcoins to each of them, and this transaction needs to have a signature from A to prove that it’s been agreed to by A, and at the same time this This transaction needs to be signed by A to prove that it was agreed to by A, and the transaction also needs to show where the 10 bitcoins that A spent came from.
It’s from what’s called a mint transaction, which is the ability to issue currency out of thin air, and the mint transaction has to specify that the coins are coming from the output of the mint transaction. Every transaction in the Bitcoin system consists of both an input and an output. The input part specifies where the coin came from, and the output part gives a hash of the recipient’s public key. For example, if A wants to transfer to B, then it has to state what the hash of B’s public key is.
Then, B can transfer the coins to C and D. Two bitcoins to C, three bitcoins to C, again with a signature, Signed by B. This time, B has to state where the coins came from, where they came from, from the previous transaction. How many coins does C have at this point? C has seven bitcoins. Let’s say C decides to give these 7 bitcoins to E billion.
The origin of C’s coins at this point is a little bit more complicated. 2 of them are from A, and 5 of them are from B. This makes up a small blockchain.
Note that there are two kinds of hash pointers in this place, one kind of hash pointer is to connect between the blocks, string them together to form a chain table, the previous section is this kind of hash pointer.
There is also a second type of hash pointer, which is pointing to a previous transaction, this kind of pointer is to explain the origin of the coin, where it comes from. Why is it important to show where the coin came from? To prove that the coins were not created out of thin air, they are documented, and to prevent double spending. if, now, if B has transferred coins to C and D, and he wants to transfer five bitcoins to F, the signature is still B’s signature, and if you just verify the signature, the transaction looks legitimate, but where did the coins come from? Other nodes receive this transaction, check the block to the source of the coins back to the original source of the coins, these five coins in the previous transaction has been spent out, indicating that this transaction is not legitimate, it will not receive it into the blockchain, which is to detect double spending.
Is there a problem here? Let’s take a closer look at the transfer transaction here, where A transfers coins to B. This transaction needs to have A’s signature, and it also needs to have B’s address. This recipient’s address is calculated by the public key, for example, the address of this transfer, is B’s public key to take the hash, and then after some transformation to get. This address is equivalent to a bank account number, to transfer money to B you need to know B’s address. So how can A know the address of B. B’s public key is public, he will tell A, but he will not tell all the people, there is no need to tell everyone.
In our daily life, for example, I need to transfer money to you, I need to know your bank account number to transfer. How can I know your bank account number. I need you to tell me.
Let’s say I need to buy something and you accept payment by bank transfer. So I’m going to ask you what your bank account number is so that I can transfer it to you, and the bank itself doesn’t provide that kind of lookup, you have to tell me that. The bitcoin system is similar in that A wants to transfer money to B, what’s B’s address, and the bitcoin system doesn’t provide a function to look up someone’s bitcoin address, so you have to get it through other channels. For example, if an e-commerce site accepts bitcoin payments, it can disclose its bitcoin address on its website or disclose its public key, which doesn’t have to be secret anyway. So a lot of bitcoin addresses are just a QR code on the website, and you can scan it to find out the address.
The next question is, does A need to know B’s address, does he have to know anything about A? It has to know if A transferred to B or not, and by how much. This transaction has to be written to the blockchain, however, how can we prove that this transaction has been written to the blockchain? There are actually some conditions that have to be met before it can be written to the blockchain.
Does A have enough coins to transfer. for A to transfer coins to B, he has to have a source of enough coins. the fact that A is pointing to this minted coin transaction shows that A does have 10 bitcoins to transfer. The source of the coins is what A has to prove, not what B has to prove.
B has to know the public key of A. A’s public key represents A’s identity, so it’s important to know A’s public key to know where the coins were transferred from. There is a more important reason why not only B needs to know A’s public key, but all nodes need to know A’s public key, because they need to verify A’s signature. If this transfer transaction is legitimate, it must have A’s signature. As I said earlier, the signature is the process, it is the private key signature, the public key verification. Each node on the blockchain has to be independently verified. Because some nodes may be malicious, so you can not rely on others to verify, I received this transaction, I have to verify that it is legitimate. This coin might not be transferred to me, it’s a transfer between two other people, I’m a bystander, but I have to verify that as well. So everybody needs to know A’s public key.
The question is, how do you know A’s public key, which is the key that A gave out in this transaction. It’s a transaction where A transfers money to B. In his input, A has to state where the coins come from and also what A’s public key is, which is what A says himself.
And is there a problem? Suppose there’s an impostor for A, say named C, and C forges a transfer from A to B. The transaction he uses his own public key, and in his input he uses A’s public key. Then C signs it with his own private key, and another node receives it and verifies the signature with this forged public key. Then it must be right, and assume that the transaction is legitimate, and that is not the same as stealing the money from A’s account. This problem exists, how to avoid this problem?
Each transaction is divided into two parts: input and output. The input part states the source of the coins, and also the public key of this A. The output part gives the recipient’s public key. The output part gives a hash of the payee’s public key, to whom the coins are to be transferred, and a hash of his public key, similar to his address. So where do the coins for this transaction come from? From a mint transaction, which is called a coinbase tx.
The output of the mint transaction contains a hash of A’s public key, and the public key of A specified in the transfer transaction must match the hash of A’s public key specified in the source of the coins. If it doesn’t match, it means that the source of the coins, as you said, is not correct, and the coins were not given to you in the first place. In the example above, if C impostors his own public key as A’s public key, then the public key of this transaction and the hash of A’s public key specified in the output of the previous minting transaction do not match, so the validation will not pass.
The above diagram simplifies some of the details of the Bitcoin system, as it appears that there is only one transaction per block, but the actual system can contain many transactions per block. These transactions are organized into a merkle tree, and each block is divided into two parts, the block header and the block body.The block header contains some macro information about the block, such as which version of Bitcoin’s protocol is being used, a pointer to the previous block in the chain, the root hash of the merkle tree, and two fields. The root hash of the merkle tree, and two fields related to mining. One is the difficulty of mining, target, and the other is the random number, nonce. in the previous section on mining, the puzzle, the hash of the entire block header should be less than or equal to the target, H(block header) <= target. The hash of the entire block header should be less than or equal to the target field value, H(block header) <= target. nBits is an encoding of the target field value stored in the block header. note that the hash of the previous block is only computed at the block header.
Some books illustrate this by drawing the pointer on top, the reason is that only the block header has this hash pointer. You can think of each block as consisting of two parts, the top part is a block header, the bottom part is the block body, block body has a transaction list transaction list. take the hash is to take the block header of all the parts of the hash, the block body is not care about. merkle root hash Merkle root hash guarantees that the transaction list in the block body cannot be tampered with.
The above discussion has a simplified assumption, as if each node needs to validate all the transactions, the actual system nodes are divided into full node full node and light node light node. full node is to save all the information, that is, all the information of the blockchain, and then validate each transaction, so the full node is also known as fully validating node.
Light nodes only save the block header information, generally speaking, light nodes do not have the means to independently verify the legitimacy of the transaction, for example, whether this transaction is double spending, light nodes do not know, because it does not save the previous transaction information, it can not find out. Most of the nodes in the system are actually light nodes, and the number of full nodes is not very large. This series of content is mainly for the full nodes, because the light nodes do not participate in the construction and maintenance of the blockchain, light nodes just use some information of the blockchain, do some query and so on.
What is contained in the blockchain, how is it written inside the blockchain. Every node can post transactions, every account can post transactions, and these transactions are broadcast to all nodes. Some transactions are legal, some may be illegal, so who decides which transactions should be written to the next block and in what order? Is it okay for each node to decide for itself? For example, if I’m a node, and I receive transactions on the Bitcoin network, and I determine which ones are legitimate, and then I package them up and write them to the next block, and I construct a local blockchain, then each node decides on its own, is that okay?
In that case, consistency is not guaranteed. I locally maintain a blockchain, and you locally maintain a school chain, they are not a chain. What is a blockchain? It is a decentralized ledger. Since it is a ledger, the content of this ledger must have a unified content, otherwise, I remember the account and you remember the account is not the same, the last according to which ledger to count? Therefore, with the terminology of distributed system, called the content of the ledger to obtain distributed consensus.
Distributed consensus, a relatively simple example is a distributed hash table. There are many machines in the system to maintain a global hash table, what is the content of the need to obtain consensus here? What needs to be agreed upon is what key-values are contained in the hash table, for example, if someone inserts a key-value into his machine, then someone else should be able to read it out when they go to read it on another machine, which is called a global hash table. There is a lot of theoretical research on distributed consensus, there are a lot of papers in this area, and there are a lot of impossibility conclusions. This is called impossibility results, and one of the most famous ones is FLP impossibility results. these three letters are the first letters of the last names of the three authors, all of whom are experts in distributed systems. Their conclusion is that in an asynchronous system, where there is no upper limit to the network transmission delay, which is called an asynchronous system, it is impossible to achieve consensus even if only one member is faulty.
There is another conclusion, more famously known as the CAP Theorem, which refers to the three properties of a distributed system: C is consistency, A is availability, and P is partition tolerance. The CAP Theorem is that any distributed system, such as this distributed hash table, can only satisfy at most two of the three properties, and it is impossible to satisfy all three properties. For example, if you want consistency and availability, you won’t get partition tolerance, which is the CAP Theorem.
One of the more famous protocols for distributed consensus is Paxos, which maintains a guarantee of consistency, that is, if the protocol reaches a consensus, then the consensus must be consistent. consistent. The consensus of one member will not be different from the consensus of another member, it must be consistent, but in some cases, the Paxos protocol may not be able to reach a consensus. This possibility is relatively small in the actual system, but it exists. These theories have very little to do with the actual application of Bitcoin.