leaf

1.1 Basics of Cryptography#

Hashing

The range is large enough: 2**256

It needs to satisfy the following three properties:

collision resistance: The ability to resist hash collisions.
hiding: The ability to hide input information, meaning that it is impossible to deduce the input or its patterns from the hash result.
puzzle friendly: Ensures the difficulty of mining; apart from brute-force enumeration, there are no shortcuts; pow (proof of work).

Asymmetric Encryption

During transactions, the private key signs, and the public key verifies.

1.2 Private Key and Address#

Randomly generate a private key, and then a series of public keys can be generated through elliptic curve multiplication.

Bitcoin does not directly use the public key as an address but performs a series of transformations:

A = RIPEMD160(SHA256(K))

A: Address
K: Public Key

Subsequent encoding will be done in base58 or similar formats. In short, the public key and address are one-to-one; the address can be calculated from the public key, but not vice versa.

1.3 Core Data Structure#

Hash Pointer: H not only saves the address pointing to the structure but also needs to save the hash value of the target.
Blockchain

It is a linked list composed of blocks that use hash pointers.

The block header is 80 bytes, and since the block must contain transactions, generally speaking, the block is hundreds to thousands of times larger than the block header.

It can be observed that each block header always contains the hash value of the previous block, so any modification to a block will cause the hash values of subsequent blocks to change. Therefore, by checking the hash value of the latest block, it can be determined whether the data of all previous blocks has been tampered with.

The hash of the current block is calculated by the miner and does not exist within the blockchain system. When a node receives a broadcast of a new block, it only needs to calculate the hash of the current block and verify whether it meets the difficulty requirement; it does not need to be provided by the miner. However, to efficiently query data at the application layer, an index mapping block hashes to block data will be maintained.

Genesis Block: The first block, the head of the blockchain, hardcoded in the code.

Block Height: The genesis block is 0, and each new block increases the height by one.

Mining: In simple terms, it is about trying different Nonce values (Timestamp and Merkle Root can also be used, explained later) so that the current block hash H(block header) <= target, meaning there must be a certain number of leading zeros (for example, 000000000000000000040b38097e0a61ef1ad31b184c908a738cfff013c094b2).

Merkle Tree

Stores transaction data in blocks.

Similar to a binary tree, but with two differences:

Using hash pointers.
Only leaf nodes store transaction information; intermediate nodes store the hash of the hashes of the left and right child nodes.

Online Course Knowledge Points:

Section Two:

Bitcoin is known as a cryptocurrency.
The content on the blockchain is public, including block addresses and transfer amounts.

Bitcoin mainly utilizes two functions from cryptography: 1. Hashing 2. Signing

1. The hash function used in cryptography is called a cryptographic hash function: It has two important properties:
   ① Collision (referring to hash collision) resistance: For example, x≠y but H(x)=H(y), where two different inputs produce the same output, which is called a hash collision. This is inevitable because the input space is always larger than the output space. Given x, it is difficult to find y unless brute-force solving is used.
   The purpose of this property: To obtain a digest of a message.
   For example, if the message is m, the hash value of m is H(m)=digest. If someone wants to tamper with m while keeping H(m) unchanged, it cannot be done.
   Hash collisions cannot be artificially manufactured or verified; they are based on practical experience.
   ② Hiding: The calculation process of the hash function is one-way and irreversible (it is impossible to deduce x from H(x)). The hiding property requires that the input space is large enough and distributed relatively evenly. If it is not large enough, a random number is generally concatenated to x, such as H(x||nonce).
   The purpose of this property: Combined with collision resistance, it is used to achieve digital commitment (also known as the digital equivalent of a sealed envelope).
   The predicted result is used as input x to calculate a hash value, publish the hash value, and hiding allows people to know the hash value without knowing the predicted value. Finally, x is published; because of the property of collision resistance, the predicted result is tamper-proof.

In addition to these two properties required in cryptography, the hash function used in Bitcoin has a third property:
③ Puzzle friendly: Refers to the fact that the hash value's budget is unpredictable in advance. If the hash value is 00...0XX...X, it is still impossible to know in advance which value is easier to compute to achieve this result; it still requires trying one by one.

In the process of Bitcoin mining, it is essentially about finding a nonce; the nonce, combined with other information in the block header, serves as input, and the resulting hash value must be less than or equal to a specified target value. H(block header)≤target. The block header refers to the block header, which contains many fields, one of which is a random number nonce that we can set. The mining process involves continuously trying random numbers to ensure that the hash of the block header falls within the specified range.

Puzzle friendly means that there are no shortcuts in the mining process; to make the output value fall within the specified range, one must try each value one by one. Therefore, this process can also serve as proof of work.

Mining is difficult, but verification is easy (difficult to solve, but easy to verify).

The hash function used in Bitcoin is called SHA-256 (secure hash algorithm), and it satisfies the above three properties.

Opening an account in the Bitcoin system:
Create a public-private key pair (public key, private key) locally, which constitutes an account. The public-private key pair comes from asymmetric encryption technology.

Information exchange between two people can utilize keys (encryption keys). A encrypts the information and sends it to B; upon receipt, B uses the key to decrypt it. Since the same key is used for both encryption and decryption, it is called symmetric encryption. The premise is that there is a secure channel to distribute the key to both parties in communication. Therefore, the disadvantage of symmetric encryption is that key distribution is inconvenient, as it can easily be eavesdropped on the network. Asymmetric keys use a pair of keys instead of one; encryption uses the public key, and decryption uses the private key. Both encryption and decryption use the recipient's public and private keys. The public key does not need to be kept secret, while the private key must be kept secret, but it only needs to be stored locally and does not need to be shared with the other party. The public key is equivalent to a bank account number; others can transfer money as long as they know the public key. The private key is equivalent to the account password; knowing the private key allows one to transfer money from the account. The public and private keys are used for signing.

If A wants to transfer 10 bitcoins to B, A places the transaction on the blockchain. How do others know that this transaction was initiated by A? This requires A to sign the transaction with their private key, and others receiving the transaction must verify the signature using A's public key. The signature uses the private key, and verification uses the public key, still belonging to the same person. The probability of generating the same public-private key pair is extremely low, so creating a large number of accounts to steal others' accounts is not feasible.

We assume that when generating the public-private key, there is a good source of randomness; the generation of the public-private key is random. If the random source is poor, it may produce the same public-private key. The signature algorithm used in Bitcoin requires a good random source not only when generating the public-private key but also during each signature. If there is a single instance where the random source used for signing is poor, it may leak the private key.

Section Three: Bitcoin's Data Structure#

A regular pointer stores the address of a structure in memory. If P is a pointer to a structure, then what P contains is the starting position of that structure in memory. However, a hash pointer not only needs to store the address but also the hash value H() of that structure. The advantage is that from the hash value of this hash pointer, one can not only find the position of the structure but also detect whether the content of that structure has been tampered with, because we have saved its hash value.

The most basic structure in Bitcoin is the blockchain, which is a linked list composed of blocks. What distinguishes the blockchain from a regular linked list is:
① It uses hash pointers instead of regular pointers (B blockchain is a linked list using hash pointers).

The first block of the blockchain is called the genesis block, and the last block is the most recently produced block. Each block contains a hash pointer pointing to the previous block.
How to calculate the hash pointer of a block: It is to take the entire content of the previous block, including the hash pointer inside, and hash it together. Through this structure, a tamper-evident log can be achieved. If someone changes the content of a block, the hash pointer of the subsequent block will not match, because the hash pointer of the latter block is calculated based on the content of the previous block, so the latter hash pointer must also be changed, and so on. The last hash value we keep will also change (see the attached image ①).

② A regular linked list can change any element without affecting other elements. However, in a blockchain, changing one element affects the entire structure because only the last hash value needs to be saved to determine whether the blockchain has changed and where it has changed. Therefore, Bitcoin does not need to save the content of all blocks; it can only keep the most recent few thousand blocks. If earlier blocks are needed, they can be requested from other nodes in the system. Some nodes may be malicious; how to determine this? Here, a property of the hash value is used, as follows:
When another node gives you a block, how to determine if it is correct? Calculate its hash value and compare it with the hash value of the retained block.

Another structure in Bitcoin is the Merkle tree (see attached image ②, where the bottom layer is data blocks, and the three upper layers are internal nodes that are hash pointers; the first layer is the root node, and the root hash of the Merkle tree composed of all transactions contained in each block exists in the block's header).
Another concept is the binary tree.

The advantage of this structure is that as long as the root hash value is remembered, any modification to any part of the tree can be detected.
Their difference: ① It uses hash pointers instead of regular pointers.

In Bitcoin, each block is connected together using hash pointers, and the transactions contained in each block are organized in the form of a Merkle tree. The bottom row of data blocks represents each transaction. Each block is divided into two parts: the block header and the block body (block header, block body). The block header contains the root hash value, and the root hash value of the Merkle tree composed of all transactions contained in each block exists in the block's header. However, the block header does not contain the specific content of the transactions; it only has a root hash value, while the block body contains a list of transactions.

The role of the Merkle tree:

① Provides Merkle proof.
Nodes in Bitcoin are divided into two types: full nodes (which save the entire content of the block, i.e., both the block header and body, with specific transaction information) and light nodes (for example, Bitcoin wallets on mobile phones) (only block headers).

At this point, a problem arises: how to prove to a light node that a certain transaction has been written into the blockchain? This requires the use of Merkle proof: find the location of the transaction (one of the blocks in the bottom row), and the path from that block to the root node is called the Merkle proof.

The attached image three shows a small blockchain; this image illustrates a block's Merkle tree, with the bottom row containing the transactions. Suppose a light node wants to know whether the yellow transaction in the image is included in the Merkle tree. The light node does not have the list of transactions or the specific content of this Merkle tree; it only has a root hash value. At this point, the light node sends a request to a full node, asking for proof that the yellow transaction is included in this Merkle tree. After receiving this request, the full node only needs to send the three hash values marked in red in the image to the light node. With these hash values, the light node can locally calculate the three hash values marked in green in the image. First, it calculates the hash value of the yellow transaction, which is the green hash value directly above it, and then concatenates it with the adjacent red hash value to calculate the upper green hash value. It continues concatenating and calculating the upper green hash value until it can calculate the root hash value of the entire tree. The light node compares this root hash value with the root hash value in the block header to determine whether the yellow transaction is in this Merkle tree.

The few hash values provided by the full node in the Merkle proof are the hash values used from the location of the yellow transaction to the root of the tree. After the light node receives such a Merkle proof, it only needs to verify from the bottom up, ensuring that the hash values along the way are correct (during verification, only the hash values along this path can be verified; other paths cannot be verified, meaning that the red hash values in the image cannot be verified).

Is this unsafe? If the yellow transaction is tampered with, and its hash value changes, can the adjacent red hash values be adjusted so that their concatenated hash value remains unchanged? No, according to collision resistance, this is not possible.

Merkle proof can prove that a certain transaction is included in the Merkle tree, so this proof is also called proof of membership or proof of inclusion.
For a light node, what is the complexity of verifying a Merkle proof? Assuming there are n transactions at the bottom layer, the complexity of the Merkle proof is θ(log(n)).

How to prove that a certain transaction is not included in the Merkle tree? That is proof of non-membership. The entire tree can be sent to the light node, and upon receiving it, the light node verifies that the construction of the tree is correct, and that the hash values used at each level are correct, indicating that these leaf nodes are the only ones present, proving that the transaction being sought is not included. The problem is that its complexity is linear θ(n), which is a relatively cumbersome method.

If certain requirements are placed on the arrangement order of the leaf nodes, such as sorting by the hash values of the transactions. Each leaf node represents a transaction, and the content of the transaction is hashed once, sorted in ascending order by hash value. To find the transaction being sought, one first calculates a hash value to see which position it would occupy if it were included. For example, if it is between the third and fourth positions, the proof provided would require both the third and fourth leaf nodes to reach the root node. If the hash values are all correct, the final root node's calculated hash value will also not have been altered, indicating that the third and fourth nodes were indeed adjacent points in the original Merkle tree. If the transaction being sought exists, it should be between these two nodes. However, if it does not appear, then it does not exist. Its complexity is also logarithmic, with the cost being the need to sort. The sorted Merkle tree is what is called sorted. Bitcoin does not use this sorted Merkle tree because it does not need to prove non-existence.

This section discusses two of the most basic structures in Bitcoin: the blockchain and the Merkle tree, both constructed using hash pointers. In addition to these two, hash pointers can also be used in another aspect.

As long as a data structure is acyclic (non-circular linked list), hash pointers can replace regular pointers. If it is circular, there is a problem: their hash values cannot be calculated, and a fixed hash value block cannot be determined.

Bitcoin's Consensus Protocol#

The difference between digital currency and paper currency is that it can be copied, which is called double spending attack.
Decentralized currency needs to solve two problems: ① The issuance of digital currency ② How to verify the validity of transactions to prevent double spending attacks.

The answer: ① The issuance of Bitcoin is determined by mining.
② Rely on the data structure of the blockchain.
The issuer of Bitcoin A has the right to mint (create coin). If 10 bitcoins are issued, A (10) gives B and C five each → B (5) C (5). This transaction needs A's signature to prove it is agreed by A (designed by A) and also needs to indicate where the 10 bitcoins spent came from.
Refer to the attached image four; the money in the second box comes from the minting transaction in the first box.

In the Bitcoin system, each transaction contains two parts: input and output. The input part must indicate the source of the coins, and the output part must provide the hash of the recipient's public key.
Some transactions are more complex, such as C's source of funds being the second and third boxes, which must be clearly identified.

Image four constitutes a small blockchain. Here, there are two types of hash pointers: one connects the various blocks, forming a linked list, which is what was learned earlier. In this image, there is also a second type of hash pointer, which points to a previous transaction to indicate the source of the coins. Why indicate the source of the coins? To prove that the coins are not fabricated out of thin air and are recorded, while also preventing double spending.

Now, looking at the second box where A transfers money to B, this transaction requires A's signature and B's address. In the Bitcoin system, the receiving address is derived from the public key. For example, B's address is obtained by hashing B's public key and then undergoing some transformations.

How does A know B's address? The Bitcoin system does not have a function to query the other party's address; it must be obtained through other channels. For example, a certain e-commerce website that accepts Bitcoin payments can publicly disclose its address or public key.

Does A need to know what information B has about A? B also needs to know A's public key, which represents A's identity. Not only B, but all nodes need to know A's public key. The signature is signed with the private key, and verification is done with the public key (note not to confuse this with previous knowledge, where encryption uses the recipient's public key and decryption uses the private key), so every node on the blockchain must independently verify.

So how can A's public key be known? In fact, it is included in the transaction. When inputting, not only must the source of the coins be indicated, but the public key must also be provided. This creates a security vulnerability: what if B's accomplice forges this transaction? In fact, the output of the minting transaction in the first box already contains the hash of A's public key, so the public key in the second box's transaction must match the previous hash.

In the Bitcoin system, the verification process mentioned earlier is implemented through executing scripts. Each transaction's input includes a segment of script, including the process of providing the public key, which is also specified in the input script. Each transaction's output is also a segment of script, and to verify its legality, the current transaction's input script must be concatenated with the output script of the previous transaction (the transaction providing the source of the coins) and then checked for successful execution. If it can be executed, it indicates legality. Bitcoin Script.

This image simplifies the transaction system; in reality, each block (corresponding to each box in the image) can contain many transactions, which together form a Merkle tree. Each block is divided into a block header and a block body.

The block header contains macro information about the block, such as which version (version) of Bitcoin's protocol is used, the pointer (hash of the previous block header) pointing to the previous block in the blockchain, the root hash value of the entire Merkle tree (merkle root hash), and two fields related to mining: one is the target difficulty value (target), and the other is the random number nonce.

The target here is what was mentioned earlier: the hash of the entire block header must be less than this target value, i.e., H(block header)≤target. The block header stores the encoding of this target value (nBits). It is important to note that the hash of the previous block only calculates the block header of the previous block, so the earlier drawing, where an arrow points from one block to another, is incorrect; in some books, the arrow points to the top of a block. When hashing, all parts of the block header are hashed.

The block body contains a list of transactions.

Previously, a content was simplified: each node needs to verify all transactions. In reality, nodes in the system are divided into full nodes (which save all information of the blockchain, verifying each transaction, so full nodes are also called fully validating nodes) and light nodes (which only save block header information). Generally speaking, light nodes cannot independently verify the legality of transactions.

For example, whether a transaction is double spending, light nodes cannot verify it because they do not store previous transaction information. Most nodes in the system are light nodes; this lesson's content mainly targets full nodes because light nodes do not participate in the construction and maintenance of the blockchain, only utilizing some information from the blockchain for queries.

How is the content in the blockchain written into the blockchain? Each node, each account can publish transactions, which are broadcast to all nodes. Some transactions are legal, while others are illegal. Who decides which transactions should be written into the next block? In what order should they be written? Can each node decide for itself? If each person maintains a blockchain locally, the uniformity of the blockchain cannot be guaranteed, and the content of the ledger must achieve distributed consensus.

The following notes are not closely related to the application of Bitcoin but can serve as understanding:
A simple example of distributed consensus is a distributed hash table (DHT). For instance, if there are many machines in the system, they collectively maintain a global hash table.

What content needs to achieve consensus? The key-value pairs contained in the hash table. If someone inserts a key-value pair on their computer, 'xiao' corresponds to 12345, i.e., 'xiao'→12345. Then others on another machine should also be able to read this value; this is called a global hash table.

There are many impossibility results in distributed systems, the most famous being the FLP result. These three letters are the initials of three experts' names, and their conclusion is that in an asynchronous system (where network transmission delays have no upper limit), even if only one member is faulty, consensus cannot be achieved.

Another famous conclusion is the CAP Theorem. (CAP refers to the three desired properties of distributed systems: Consistency, Availability, and Partition tolerance). The content of this theory is that any distributed system, such as a distributed hash table, can satisfy at most two of these three properties. If one wants the first two properties, the third property cannot be obtained.

A well-known protocol for distributed consensus is Paxos, which can guarantee consistency, i.e., the first property. If this protocol reaches consensus, then this consensus must be consistent, meaning that each member's understanding of the consensus is the same. However, in certain cases, this protocol may never reach consensus, which is a small but objectively existing possibility.

Consensus in Bitcoin:
One problem that consensus in Bitcoin needs to solve is that some nodes may be malicious. Assuming that most nodes in the system are good, how can consensus be achieved?

The first scheme is voting. First, it should be determined which blocks have voting rights; some memberships have strict requirements, and in this case, a voting-based scheme is feasible. However, in the Bitcoin system, creating an account is very easy, and even if one person generates a public-private key pair, others cannot know. Only when transferring money do others know. Therefore, some people can continuously create accounts, and when the number of accounts exceeds half of the total, they gain control, which is called a Sybil attack. Thus, the voting method is not feasible.

The Bitcoin account cleverly solves this problem by voting based on computational power rather than the number of accounts. Each node can locally assemble a candidate block, placing the transactions it considers legal inside, and then start trying various nonce values (which occupy 4 bytes) to see which one can satisfy the inequality H(block header)≤target. If a certain node finds a nonce that meets the requirements, it gains the right to keep the account.

The so-called accounting right is the right to write the next block into the Bitcoin ledger. Only by finding this nonce does the node that gains the accounting right have the authority to publish the next block. After other nodes receive this block, they must verify the legality of this block.

For example, check whether the contents in the parentheses of the block header are filled in correctly; there is a field in the block header called the nBits field, which is actually an encoding of the target value. Check whether the nBits field is set according to the difficulty requirements specified in the Bitcoin protocol; whether the inequality holds. Assuming all requirements are met, then check the transaction list in the block body to verify that each transaction is legal: ① It must have a valid signature ② It has not been spent before. If any one of these does not meet the requirements, this block cannot be accepted. If all conditions are met, it is still not necessarily accepted.

If a new block is generated, how to know where the new block is inserted? It is based on the pointer of the generated block. There may be a problem, as shown in image 5 (fourth video, 65 minutes in), where these two transactions indicate A transferring to B and A transferring to itself. This situation is not double spending; to determine whether a transaction is double spending, one looks at whether the coins in this block have been spent on the branch. As shown, until the third block, the coins have not been spent, so this transaction is legal. Although this transaction is legal, it is not on the longest valid chain (longest valid chain). This is called a forking attack. Therefore, the received block should extend the longest valid chain.

In normal circumstances, the blockchain may also experience forks: two nodes simultaneously gain the right to keep accounts. Each node locally assembles a block it considers appropriate and then tries various nonce values. If two nodes find a nonce that meets the requirements at almost the same time, both can publish the block, resulting in two equal-length forks. Both of these are the longest valid chains; which one should be accepted? In the Bitcoin protocol, by default, each node accepts the one it received first. Therefore, different nodes may hear about one of the newly generated blocks first, and they will accept that block; some nodes may hear about another block first and accept that one.

How to determine if a block has been received? The Bitcoin protocol uses implicit consign; if the block continues to expand downwards, it is considered to have recognized the published block. For example, if a new block is generated after one of the newly generated blocks, it indicates that the new block is recognized.

Temporary equal-length forks will last for a period until one fork wins. That is, whichever chain generates a new block first will be the longest valid chain. The other one will be called an orphan block. These two new blocks may each attract others, with the two blockchains seeing which has more computational power; sometimes it also depends on luck, which will determine the winner.

The benefit of competing for accounting rights is that the first node to gain accounting rights has a certain power to decide which transactions to write into the next block. However, these should not be set as the motivation for competing for accounting rights, so a mechanism is cleverly established: block rewards.

The Bitcoin protocol stipulates that the node that gains accounting rights can have a special transaction in the published block: the minting transaction. In this transaction, a certain number of bitcoins can be issued.

This brings us back to the earlier question: who decides the issuance of currency? The coinbase transaction is the only method for issuing new bitcoins in the Bitcoin system; subsequent transactions are merely transfers of bitcoins. This transaction does not need to specify the source of the coins.

So how many coins can be minted? Initially, when Bitcoin was first launched, each published block could generate 50 BTC (BTC is the symbol for Bitcoin). The protocol stipulates that after 210,000 blocks, the initial block reward will be halved to 25 BTC. After another 210,000 blocks, it will be halved again.

Therefore, when one block wins, the other orphaned block's bitcoins are useless, and other honest blocks will not recognize them.

What consensus does the Bitcoin system need to achieve? A decentralized ledger must achieve consensus. Who can decide the content of the ledger? Only nodes that gain accounting rights can write. How to gain accounting rights? By solving pow (mining). According to computational power, votes are counted; computational power can be represented by how many nonce values can be tried per second. How to prevent Sybil attacks? By counting votes based on computational power, even if many accounts are created, it cannot enhance computational power.

The process of competing for accounting rights in Bitcoin is called mining, and Bitcoin is referred to as digital gold. Nodes competing for accounting rights are called miners.

Implementation of the Bitcoin System#

The blockchain is a decentralized ledger, and Bitcoin uses a transaction-based ledger model. The system does not display how much money each account has.

Full nodes in the Bitcoin system must maintain a data structure called UTXO (unspent transaction output). There are many transactions on the blockchain; some transaction outputs may have already been spent, while others have not. The collection of all outputs that have not been spent is called UTXO.

A transaction can have multiple outputs. If A gives B 5 bitcoins, and B spends it, while A also gives C 3 bitcoins, and C does not spend it, then the 5 bitcoins do not count as UTXO, while the 3 bitcoins do. Each element in the UTXO collection must provide the hash value of the transaction that produced the output and its position in that transaction. These two pieces of information can locate the output in the UTXO.

What is the purpose of the UTXO collection?
To detect double spending. That is, to check whether a newly published transaction is legal. Therefore, full nodes must maintain the UTXO data structure in memory to quickly detect double spending.

Each transaction consumes some outputs and also generates new outputs. Looking at the previous example, although the 5 bitcoins spent by B are no longer in UTXO, if he transfers them to D and D does not spend them, then these 5 bitcoins must be saved in UTXO again. If D never spends them, this information will be permanently stored in UTXO. It may be that D does not want to spend them, or it may be that he lost the key.

Each transaction can have multiple inputs and multiple outputs, and the total amount of inputs must equal the total amount of outputs. That is, total inputs = total outputs. Therefore, a transaction may come from multiple addresses and may have multiple signatures.

Some transactions may have total inputs slightly greater than total outputs.
For example, if the input is 1 bitcoin and the output is 0.99 bitcoins, the remaining 0.01 bitcoins are given as a transaction fee to the node that publishes the block.

Block rewards cannot be entirely considered as mining rewards; why must the node that publishes the block pack your transaction into the block? They also need to verify the legality of your transaction; if there are many transactions, the bandwidth used will be considerable, and the network propagation speed will slow down. Therefore, block rewards alone are not enough.

Thus, the Bitcoin system has designed a second incentive mechanism: transaction fees. That is, if you pack my transaction into the block, I will give you a tip. Transaction fees are generally small, and some simple transactions may have no transaction fees.

How long does it take to mine 210,000 blocks? About 4 years. The average block generation time designed by the Bitcoin system is 10 minutes, meaning that a new block will be generated approximately every 10 minutes.

In addition to this transaction-based model, there is also an account-based model, such as the Ethereum system. In this model, the system must explicitly record how much currency each account has.

The transaction-based model of Bitcoin has better privacy protection. The downside is that Bitcoin's transfer transactions must specify the source of the coins, while the account-based model does not.

As shown in image 6 (fifth section video, 16 minutes in),
An example of a block:
The first line indicates that this block contains 686 transactions.
The second line: Total output XXX bitcoins.
The fourth line: Total transaction fees (the sum of the transaction fees for 686 transactions).
The last line: Block reward (the main motivation for miners).
The fifth line: The block's serial number.
The sixth line: The block's timestamp.
The ninth line: Mining difficulty (the mining difficulty must be adjusted every 2016 blocks to keep the block generation time around 10 minutes).
The second to last line: The random number attempted during mining.

On the right:
The first line: The hash value of this block's header.
The second line: The hash value of the previous block's header.
(Note: The hash value is only calculated for the block header.)
The common point of the two hash values: both have a string of zeros in front. This is because the target value set is represented in hexadecimal, which is a long string of zeros in front. Therefore, any block that meets the difficulty requirement will have a hash value that calculates to a long string of zeros.
The fourth line: The Merkle root is the root hash value of the Merkle tree composed of the transactions contained in this block.

As shown in image 6 (see fifth section video, 20 minutes in) block header data structure:
The last line: a 32-bit unsigned integer. The nonce has 2 to the power of 32 possible values. Given the current mining situation in Bitcoin, it is very likely that all 2 to the power of 32 values have been tested without finding a suitable one. So what else can be adjusted in the block header's data structure?

As shown in image 7, the description of each field in the block header (see the fifth video, 21 minutes in):
The first line: The version number of the Bitcoin protocol (cannot be changed).
The second line: The hash value of the previous block's header (cannot be changed).
The third line: The root hash value of the Merkle tree (can be changed).
The fourth line: The time the block was generated (can be adjusted); the Bitcoin system does not require particularly precise time and can be adjusted within a certain range.
The fifth line: The target value (encoded version) (can only be adjusted periodically according to the requirements in the protocol).
The sixth line: The random number.

During mining, it is not enough to only change the random number; the root hash value can also be changed.

As shown in image 8 (see the fifth video, 23 minutes in):
The coinbase transaction has no inputs; it has a coinbase field where any content can be written. It can also write the hash value of the commit in the digital commitment. It can also write the content of predicting the stock market mentioned in the first section; the content of the coinbase is not checked by anyone, and you can even write your feelings.

What is the use of this field?

As shown in image 9 (see the fifth video, 24 minutes in):
This corresponds to the root hash value of the Merkle tree in the last block header; the transaction in the lower left corner is the coinbase, and after changing its field, the hash value on it changes, which then propagates up along the structure of the Merkle tree. Ultimately, this leads to a change in the root hash value in the block header (the Merkle root is part of the block header). The four bytes of nonce in the block header are not enough; there are other bytes that can be used, such as the first eight bytes of the coinbase field as an extra nonce, thus increasing the search space to 2 to the power of 96.

Therefore, during actual mining, there are only two layers of loops: the outer loop adjusts the extra nonce in the coinbase field. After calculating the root hash value in the block header, the inner loop adjusts the nonce in the header.

As shown in image 10, an example of a regular transfer transaction (see the fifth video, 26 minutes in):
This transaction has two inputs and two outputs.
In the upper left corner: the output here is actually the input, referring to the previous transaction's output.
In the upper right corner: the outputs here are unspent, meaning they have not been spent and will be stored in UTXO.
In the right table, the first line: total input amount.
Going down: total output amount, and the difference between the two.
Below the two tables: it can be seen that both inputs and outputs are specified in script form.

In the Bitcoin system, verifying the legality of a transaction is accomplished by pairing the input scripts with the output scripts and executing them. Note: It is not pairing the input scripts and output scripts in the image, as these two scripts are from the same transaction. It is not pairing the input and output scripts within the same transaction but rather pairing the input script here with the output script of the previous transaction that provided the source of the coins. If the input and output scripts can be concatenated and executed without errors, then the transaction is legal.

As shown in image eleven, this is the process of solving the puzzle.
Note: When hashing, only the contents of the block header are used, while the specific information of the transaction is not included in the block header. The block header only contains the root hash value of the Merkle tree, which already ensures that the transaction has not been tampered with.

The mining process can be seen as a Bernoulli trial for each nonce attempted. Each random Bernoulli trial constitutes a Bernoulli process. One of its properties is memorylessness.

The probability of successfully trying a nonce is very small, requiring a large number of trials. At this point, a Poisson process can replace the Bernoulli process. What we are truly concerned about is the system's block generation time, which follows an exponential distribution. A coordinate axis can be drawn, with the vertical axis representing probability density and the horizontal axis representing block generation time (the entire system's block generation time, not each miner's block generation time). Specifically, for each miner, the time it takes to mine the next block depends on the percentage of the miner's computational power relative to the system's total computational power.

If a person's computational power accounts for 1% of the system's total computational power, then out of 100 blocks generated by the system, one block will likely be mined by this person.

The exponential distribution is also memoryless. The characteristic of the probability distribution curve is that if you cut it off from any point, the remaining part of the curve is the same as the original. For example: if it has been ten minutes and no one has found a valid block, how much longer do we need to wait? The average wait time remains ten minutes, regardless of how long has already passed. The future mining time is independent of how long has already been mined. This process is also called progress-free.

If there is no progress-free property, what phenomenon will occur? Miners with strong computational power will have a disproportionate advantage. Because strong miners have done more work in the past, after trying many unsuccessful nonces, the probability of success for subsequent nonces will increase. Thus, progress-free is a guarantee of fairness in mining.

The block reward is the only way to generate new bitcoins in the system. The bitcoins generated form a geometric series. 210,000 * 50 + 210,000 * 25 + 210,000 * 12.5 + ... = 210,000 * 50 * (1 + 1/2 + 1/4 + ...) = 21 million.

The puzzle solved by Bitcoin has no practical significance other than competing for computational power. The scarcity of Bitcoin is artificially created.

Although the mining process of solving the puzzle itself has no practical significance, it is crucial for maintaining the security of the Bitcoin system. Mining provides an effective means of voting based on computational power; as long as the majority of computational power is held by honest nodes, the security of the system can be guaranteed.

Although mining rewards are decreasing and difficulty is increasing, the competition for mining has become increasingly fierce in recent years because the price of Bitcoin has soared. When the block reward reaches zero, will there be no motivation to mine? No, because there is still the incentive mechanism of transaction fees.

Assuming that most computational power is held by honest miners, what kind of security guarantee can we obtain? Can we guarantee that the transactions written into the blockchain are all legal? Mining only provides a probabilistic guarantee; it can only be said that there is a relatively high probability that the next block will be published by an honest miner, but it cannot guarantee that the accounting rights will not fall into the hands of malicious nodes.

For example, if good miners account for 90% of the computational power, and bad miners account for 10% of the computational power, then there is a 10% probability that the accounting rights will fall into the hands of malicious miners. What will happen at this time?

First, consider the first question: can they steal coins? Can they transfer money from someone else's account to themselves? No, because they have no way to forge someone else's signature.

Assuming M is malicious and wants to transfer money from A's account, they would publish a transaction from A to M, but this transaction requires A's signature. Although M has gained accounting rights, they do not know A's private key, so they cannot forge the signature.

If M forcibly writes the transaction onto the blockchain, honest nodes will not accept this block because it contains an illegal transaction. Therefore, honest nodes will continue to mine along the previous block, generating new blocks to replace the illegal block, and other honest blocks will continue to mine along this legitimate block. Bitcoin requires the expansion of the normal valid chain, and the block generated by M is not a legitimate block, so that block is orphaned. The cost to them is significant because they lose the block reward and do not steal any money.

The second question: can they spend the same coins again (i.e., double spending)? If they write the transaction M→A into a block, and now they have gained accounting rights, they can publish another transaction to transfer the money back to themselves, i.e., M→M'. This is clearly double spending, and all honest nodes will not accept this block.

If they want to publish this block, they can only attach it to the previous block that recorded the transaction M→A. Note: The position of the block is determined when it is first mined because the hash of the previous block header must be filled in the block header. Therefore, they must determine this at the beginning, rather than wait until they gain accounting rights to decide.

Thus, the two blockchains generated are both legitimate. Refer to image twelve (fifth video, 56 minutes in). It depends on which chain other nodes continue to expand downwards; ultimately, one will win and the other will be orphaned.

What is the purpose of this attack? If the transaction M→A produces some irreversible external effect, and then M→M' rolls back the transaction M→A, then M can profit from it.

For example: when shopping online, M purchases some goods, and the website accepts Bitcoin payments. M initiates a transaction to transfer money to the website. The website listens for the transaction written into the blockchain, believing the payment is successful, and thus gives the goods to M. After receiving the goods, M initiates a transaction to transfer the spent money back to themselves, and then extends the chain below into the longest valid chain. The result is that M has obtained the goods and also recovered the spent money, achieving the goal of double spending.

How to prevent such an attack? If the block containing the transaction M→A is not the last block, then the difficulty of this attack will greatly increase. If they want to roll back the transaction M→A, they still need to attach it to the previous block and find a way to become the longest valid chain. This difficulty is very high. Because honest nodes will not continue to expand along the block they generated, as it is not the longest valid chain. Therefore, the method to prevent this attack is to wait for several more blocks or to wait for several confirmations.

When the transaction M→A is just written into the block, we call it one confirmation. The blocks added afterward are called two confirmations, three confirmations, and so on. The default in the Bitcoin protocol is to wait for six confirmations. Only with six confirmations is the transaction M→A considered immutable. How long does this take? The average block generation time is 10 minutes, so it takes about an hour.

The blockchain is an immutable ledger; does this mean that any content written into the blockchain can never be changed? As analyzed above, this analysis is only a probabilistic guarantee. The content just written into the blockchain is still relatively easy to modify. After a period of waiting or after several blocks are confirmed, the probability of tampering decreases significantly (exponentially).

In fact, there is also a concept called zero confirmation (the specific location can be seen in the fifth video at 62 minutes and 26 seconds). This means that the transfer transaction has been published but has not yet been written into the blockchain. That is, the transaction M→A has been published, but the block containing M→M' has not yet been mined.

This concept is similar to the example of e-commerce shopping, where during payment, you publish a transfer transaction to inform the e-commerce site that you have already transferred the money. The e-commerce site runs a full node or entrusts a full node to listen for transactions on the blockchain. Upon receiving the transfer transaction, it must verify the legality of the transaction (valid signature, not previously spent), and it may not even need to wait for the transaction to be written into the blockchain. This operation sounds very risky; the transaction has just been published and has not yet been written into the blockchain. In fact, zero confirmation is still quite common in practice. Why?

There are two reasons for this:

1. The default setting of the Bitcoin protocol is that nodes receive the first transaction they hear. Therefore, at the zero confirmation stage, if the node that received M→A then publishes the transaction M→M', there is a high probability that honest nodes will not accept it.
2. Many shopping websites have a certain time interval between payment success and shipping, i.e., they have a certain processing time.

Returning to the earlier question: if a malicious node gains accounting rights, what else can they do? Can they deliberately not write certain legal transactions into the blockchain? That is, the published block deliberately does not include certain transactions. This is possible.

The Bitcoin protocol does not stipulate that nodes gaining accounting rights must publish those transactions into the block. However, this situation is not too problematic because these legal transactions will definitely be written into the next block; there will always be honest nodes willing to publish these transactions.

In fact, even under normal operation of the blockchain, there may be cases where legal transactions are not included; this may be due to too many transactions during that time. The Bitcoin protocol stipulates that each block has a size limit of no more than one megabyte. Therefore, if the number of transactions is too large, some transactions may have to wait until the next block to be published.

Will this situation occur? If the block containing the transaction M→M' is on a shorter chain, it can still secretly generate more blocks than the above and then publish it after the upper chain is announced, thus surpassing the few blocks above. This method is called selfish mining.

Under normal circumstances, when a block is mined, it is published immediately. The reason is that if you do not publish, others may publish, and then you will not receive the block reward. However, selfish mining is about hiding it and not rushing to publish; this is a means of forking.

However, the probability of success is not high because malicious nodes originally have a low proportion of computational power, and generating more blocks is very difficult.

The above is one of the purposes of selfish mining; it has another purpose. If A mines two blocks without publishing them, and B mines a block and publishes it, then A's two blocks will invalidate B's block. The benefit of this is to reduce competition because while A is mining the second block, others are still mining the first block (the premise is that A has sufficient computational power).

However, there are also downsides; if A mines a block, thinking they can quickly mine another block, but someone else mines the first block, then A must publish immediately after others publish to compete for the block reward.

Bitcoin Network#

Bitcoin operates at the application layer (application layer: Bitcoin blockchain), and its underlying layer is a network layer (network layer: P2P overlay network).

The Bitcoin P2P network is very simple; all nodes are equal. Unlike some P2P networks that have so-called super nodes or paper nodes.

To join the P2P network, one must first know at least one seed node, and then contact the seed node, which will tell you about other nodes in the network it knows. Nodes communicate via TCP, which is beneficial for penetrating firewalls. When you want to leave, you do not need to do anything; you do not need to notify other nodes; just exit the application. Other nodes will not hear your message, and after a while, they will delete you.

The design principle of the Bitcoin network is simplicity and robustness rather than efficiency. Each node maintains a collection of zero-degree nodes, and message propagation in the network adopts a flooding method. When a node first hears a message, it propagates it to all its zero-degree nodes while recording that it has already received this message. The next time it receives this message, it does not need to forward it to zero-degree nodes.

The selection of zero-degree nodes is random and does not consider the underlying topology. For example, a node in California may select a zero-degree node in Argentina. The benefit of this design is to enhance robustness; it does not consider the underlying topology, but sacrifices efficiency, as transferring money to someone nearby and to someone in the U.S. takes about the same time.

In the Bitcoin system, each node must maintain a collection of transactions waiting to be written to the blockchain. If a collection of transactions is waiting to be written to the blockchain, when a node first hears a transaction, it adds this transaction to the collection and forwards it to other nodes. In the future, if it receives this transaction again, it does not need to forward it, thus avoiding the transaction from propagating endlessly in the network. The prerequisite for forwarding is that the transaction is legal.

Here, there is a conflict situation; it is possible that you will have two conflicting transactions broadcast to the network almost simultaneously. For example, A→B and A→C; if these two are broadcast simultaneously, each node will receive the two transactions in different orders based on their position in the network.

For example, if one person first receives the first transaction, they will write it into the collection, and when they receive the second transaction, they will not write it into the collection because it conflicts with the previous transaction, deeming it illegal. If these two transactions spend the same coin, the transaction written into the collection will be deleted.

For instance, if a node hears about a newly published block that contains the A→B transaction, then this transaction can be deleted because it has already been written into the blockchain. If the node then hears about the A→C transaction, what should be done? At this point, A→B should also be deleted. Because if A→C has already been written into the blockchain, then A→B becomes an illegal transaction, thus becoming double spending; this is the conflict situation. It is possible that a node that first received A→C quickly mined and published a block.

The propagation of newly published blocks in the network has many methods, similar to the propagation of newly published transactions. Each node, in addition to checking the legality of the block's content, must also check whether it is in the longest valid chain. The larger the block, the slower it propagates in the network.

The Bitcoin protocol has a size limit of 1MB for blocks. The propagation method adopted by the Bitcoin system is very bandwidth-intensive, and bandwidth is a bottleneck. Given the 1MB block size limit, a newly published block may take tens of seconds to propagate to most parts of the network, which is already quite a long time, so this limit is not small.

It is also important to note that the propagation of the Bitcoin network is best effort. A transaction published to the Bitcoin network may not be received by all nodes, and the order in which different nodes receive this transaction may not be the same. There are delays in network propagation, and sometimes this delay can be long. Some nodes may not follow the Bitcoin protocol's requirements for forwarding.

Some nodes may not forward what should be forwarded, leading to some legal transactions not being received, and some nodes may forward messages that should not be forwarded, such as some illegal transactions being forwarded. This is a practical problem we face.

Bitcoin Mining Difficulty Adjustment#

The smaller the target value, the greater the mining difficulty. Adjusting mining difficulty means adjusting the proportion of the target space in the entire output space.

The hash algorithm used in Bitcoin is SHA-256, which produces a 256-bit hash value. Therefore, the entire output space is 2 to the power of 256. Adjusting this proportion, i.e., the proportion of the target space to the output space, simply means how many leading zeros are required in the hash value. For example, for a 256-bit hash value, if a valid block requires the hash calculated to have at least 70 leading zeros, this is a simplified explanation, as the target value does not mean that the front is all zeros; from a certain position onward, it becomes ones.

The mining difficulty is inversely proportional to the target value, and the formula is: difficulty = difficulty 1 target / target. The above refers to the target value corresponding to when the mining difficulty is equal to 1; the minimum mining difficulty is 1, which corresponds to a very large target value.

That is, the larger the target, the easier the mining. Therefore, in the formula, a very large number divided by the current target value gives the current mining difficulty. Thus, the size of difficulty and target is inversely proportional.

Why adjust mining difficulty? What problems would arise if it were not adjusted? If the total computational power in the system increases, and the mining difficulty remains unchanged, the block generation time will become shorter and shorter.

What problems would arise if the block generation time becomes shorter?
For example, if a block is generated in less than a second, the time required for the block to propagate in the network may take tens of seconds, and the underlying Bitcoin network may take tens of seconds for other nodes to receive it. Before other nodes receive this block, they will continue to expand along the existing blockchain. If two nodes simultaneously publish a block, this will lead to forks.

If the block generation time becomes shorter and shorter, such forks will become the norm, and not only will there be bifurcations, but there may be many forks. For example, if 10 blocks are mined simultaneously, the system may experience 10 forks.

If there are too many forks, it is not beneficial for the system to reach consensus, and it endangers the security of the system. The Bitcoin protocol assumes that most computational power is held by honest miners. The stronger the total computational power in the system, the better the security, because it becomes increasingly difficult for malicious nodes to control 51% of the computational power. If they control 51% of the computational power, they can do many bad things, such as forking attacks.

If there are many forks later, a transaction in a certain block may be subject to a forking attack, as malicious nodes will attempt to roll it back. Because with more forks behind, computational power will be dispersed, increasing the probability of malicious nodes succeeding. At this point, malicious nodes may not need 51% of the computational power; perhaps 10% will suffice. Therefore, shorter block generation times are not necessarily better.

Is a 10-minute block generation time optimal? Not necessarily. Other values can be changed; there should just be a constant range. The Ethereum system has reduced the block generation time to 15 seconds, making Ethereum's block generation speed 40 times that of Bitcoin.

After significantly reducing block generation time, Ethereum had to design a new protocol called Ghost. In this protocol, these forks and the orphan blocks (i.e., blocks that are discarded after the longest valid chain is produced) cannot be discarded but must also be rewarded; this is called uncle reward. Ethereum also needs to adjust mining difficulty to keep the block generation time around 15 seconds.

Having discussed why mining difficulty needs to be adjusted, let’s talk about how to adjust mining difficulty. The Bitcoin protocol stipulates that the target value must be adjusted every 2016 blocks, which is approximately every two weeks.

The specific adjustment formula is: target = target × (actual time / expected time). Actual time refers to the actual time taken to produce 2016 blocks, while expected time refers to the time it should take to produce 2016 blocks, i.e., 2016 × 10 minutes.

If the actual time exceeds two weeks, meaning the average block generation time exceeds 10 minutes, then the mining difficulty should be adjusted downwards to make block generation easier. Therefore, the target calculated by this formula will increase, thus decreasing the difficulty.

In practice, both upward and downward adjustments have a fourfold limit. If the actual time exceeds eight weeks, then when calculating the formula, it can only be calculated as four times, and the target value can increase by at most four times.

How can all miners simultaneously adjust the target value? The method for calculating the target is written in the Bitcoin system's code, and it will automatically adjust after mining 2016 blocks. If there are malicious nodes that deliberately do not adjust, what will happen?

If a node does not adjust and publishes the block, honest nodes will not recognize it. nBits is a compressed version of the target in the block header; there is no direct field for storing the target in the block header because the target is 256 bits, and directly storing the target would require 32 bytes. nBits only has four bytes in the header, so it can be considered a compressed encoding of it.

If a malicious miner does not adjust when it should, the legality of the block will not pass the verification. Each node must independently verify the legality of the published block. The verification content includes: nBits, whether the target value is set correctly. If a malicious miner tries to design an excessively large target value to make mining easier for themselves, that block will not be accepted.

As shown in the seventh video at 26 minutes, the total computational power in the Bitcoin system has changed over time. Before Bitcoin became popular, there was a long period where the computational power did not grow significantly; the hash rate was almost zero in the previous years. In fact, the computational power has been growing during those years, but the growth in recent years has been so rapid that the earlier part appears as a straight line. Last year saw a significant increase, which is also reflected in the growth of the hash rate, showing an exponential increase. Even during this golden period, the computational power was not monotonically increasing; there were many fluctuations in between.

As shown in the seventh video at 27 minutes, the change in mining difficulty is basically synchronized with the growth of computational power, which also aligns with the design goal of adjusting difficulty. By adjusting mining difficulty, the block generation time can be kept stable. Note that this graph shows mining difficulty, not target value.

As shown in the seventh video at 27 minutes and 27 seconds, the difficulty adjustment curve over the past six months shows a clear stepwise increase. Every two weeks, the difficulty increases, indicating that more people are mining, and the equipment used is becoming more advanced, reflecting the increasing enthusiasm for Bitcoin. If the opposite situation occurs, such as the mining difficulty decreasing, it indicates that mining is becoming easier, which is not a good sign, as it suggests that people's enthusiasm for the coin is gradually diminishing. Continuous occurrences of this situation indicate that the coin will be eliminated.

As shown in the seventh video at 28 minutes, the daily block generation time can be seen to be stable around 10 minutes.

As shown in the seventh video at 28 minutes and 36 seconds, the block generation time over the past six months has also maintained around 10 minutes.

The formula for mining difficulty: next difficulty = previous difficulty * (two weeks / time taken to mine the previous 2016 blocks) (Note: The previous formula is for the target value, do not confuse it).

Introduction to Full Nodes (eighth video, 31 seconds)#

Introduction to Light Nodes (eighth video, 3 minutes)#

Most nodes in the Bitcoin network are light nodes. If you are only transferring money and not mining, there is no need to use a full node. During the mining process, if you hear that someone has published a block that is legal and extends the longest valid chain, what should you do?

You should stop mining and reassemble a candidate block locally, then start mining from scratch. Because if you continue mining along the newly published transaction, the transactions included in the locally assembled block will change; some transactions may have already been included in the newly published block. Additionally, the contents of the block header will also change, such as the root hash value of the Merkle tree composed of transactions in the block header, and the pointer to the previous block, all of which will change.

Is this a bit of a waste? One property of mining is memorylessness; whether to continue mining the original block or stop to mine a newly assembled block, the probability of success is the same. As long as a suitable nonce value has not been found, how long has already been mined does not matter.

Even if a valid block is mined and published to the blockchain, it does not guarantee victory. It is possible that the block you publish does not ultimately become the longest valid chain; there may be some conflict situations where others may simultaneously publish some valid blocks, or there may be some double spending that you are unaware of, causing some transactions in your block to become conflicting.

How does Bitcoin ensure security? Two aspects: ① Cryptography ② Consensus mechanism

① If others do not have your private key, they cannot forge your signature, so they cannot transfer money from your account. (The premise is that the majority of miners in the system are good and comply with the protocol, and will not accept transactions without valid signatures. If these conditions are not met, the cryptographic guarantee is useless.)

For example: when you go to a bank to withdraw money, you must present valid identification according to the regulations before the bank staff can give you the money. A valid identification is equivalent to a cryptographic signature; the properties of cryptography ensure that others cannot forge your signature, and thus cannot forge your identity. When generating private keys and signatures, there must be a good source of randomness, and the generated random numbers must be sufficiently random. However, this is not enough; bank staff must be sufficiently conscientious and not give money to those without valid identification. Only when these two conditions are combined can it be ensured that others cannot transfer money from your account.

Mining Equipment: The evolution trend of mining equipment is becoming increasingly specialized. Initially, ordinary CPUs were used for mining, such as home computers and laptops. However, buying a computer specifically for mining is very uneconomical, as most of the memory in the computer is idle; mining only uses a small portion of that memory, and most components in the CPU are also idle because the operation of calculating hash values only utilizes a small portion of the instructions in a general-purpose CPU. Hard drives and many other resources are also idle, so as the difficulty of Bitcoin mining increases, using CPUs for mining becomes less cost-effective.

Thus, mining has shifted to the second generation of devices: GPUs. The efficiency of GPUs compared to CPUs has improved significantly, mainly used for large-scale parallel computing. However, using GPUs for mining is still somewhat wasteful, as GPUs are designed for general-purpose parallel computing, and many components remain idle when used for mining, such as those used for floating-point calculations. These components are crucial for deep learning, but Bitcoin operations only use integer mining. Therefore, although the efficiency of GPUs has improved significantly, there is still considerable waste. The price of GPUs has risen rapidly in recent years, with some attributing it to the popularity of deep learning; in fact, many GPUs are used for mining. However, there is good news: as the difficulty of Bitcoin mining increases, using GPUs for mining has become unprofitable, exceeding the computational power range of GPUs, so GPUs can now be used more for deep learning and gaming applications.

Some newly developed cryptocurrencies still use GPUs for mining, but now more are using ASIC chips for mining, which are chips specifically designed for mining, with no extra logic. The entire chip is designed for Bitcoin mining and calculating hash values. Its cost-effectiveness is the highest; this chip can only mine one specific cryptocurrency. Unless two cryptocurrencies use the same mining puzzle.

Some cryptocurrencies, when first issued, deliberately use the mining puzzle of an existing cryptocurrency, such as Bitcoin, to attract more people to mine; this situation is called merge mining. Apart from this situation, other chips can only mine one cryptocurrency. The production cycle of ASIC chips is one year, but compared to other general chips, the development speed of ASIC chips is already very fast.

During such a long production cycle, if the price of Bitcoin fluctuates dramatically, the initial R&D investment may be wasted. Historically, the price of Bitcoin has fluctuated significantly. There have been several instances where the price of Bitcoin dropped by 80% within a few months and then slowly recovered.

If the price of Bitcoin drops significantly, mining may become unprofitable, possibly not even covering electricity costs. Even during the golden period of Bitcoin's development, when prices were continuously rising, mining was profitable. However, competition has also become increasingly fierce; custom ASIC chips may become obsolete in just a few months. When an ASIC miner is first released, most of the profits are made in the first two months after its release, as it has the strongest computational power among similar products. After that, as stronger mining machines emerge, it may be phased out. Therefore, the timing of purchasing ASIC miners is crucial, and they now need to be pre-ordered. Some unscrupulous manufacturers produce ASIC miners but do not immediately provide them to consumers; instead, they use them to mine for a while, earning Bitcoin, and then after the most profitable golden time (the first two months) has passed, they deliver the miners to users. When there is a sudden increase in computational power in the Bitcoin system, it indicates that a large company has produced a new ASIC miner. Thus, in the mining boom, those who truly profit may not be the miners but the large manufacturers selling the miners.

The trend of mining machines is shifting from general-purpose to increasingly specialized; CPUs are general-purpose computing, GPUs are general-purpose parallel computing, and ASICs are specialized computing. Once ASICs become obsolete, they become useless, unlike CPUs and GPUs, which can still perform other tasks. Many people feel this is not good, as it does not align with the idea of decentralization and goes against the original intention of Bitcoin's design. The most democratic situation is that everyone uses their home CPU computers for mining. Later, switching to GPUs creates a lot of noise. Some new cryptocurrencies are designed with alternative mining puzzles. The purpose of designing them is ASIC resistance, allowing general-purpose computers to participate in the mining process.

Another trend in mining is the emergence of large mining pools. A single miner, even using ASIC chips, may find mining profitable on average, but the income is very unstable. The Bitcoin system averages one block every 10 minutes, meaning that when viewed as a whole, all miners will produce a new block approximately every 10 minutes. However, for a specific miner, they may have to mine for a long time, possibly one or two years. This is like a lottery; if they mine a block, it is like hitting the jackpot. Individual miners also face other issues; they must also bear the responsibilities of full nodes (which were introduced at the beginning of this lesson).

Thus, mining pools are introduced. A mining pool organizes these miners into a collective; the architecture of a mining pool generally consists of a full node driving many mining machines. A mining pool has a pool manager, and many miners are connected below. These miners are only responsible for calculating hash values, while the pool manager takes on other responsibilities of the full node. They are responsible for listening for transactions on the internet, packaging these transactions into blocks, and checking whether other nodes have published blocks ahead of time, adjusting accordingly...

ASIC chips can only calculate hash values; they cannot perform other functions of full nodes. The emergence of mining pools also addresses another issue: unstable income. Individual miners' income is unstable, so by working together, they can distribute the rewards once they have earnings.

How should the earnings be distributed? Mining pools generally have two organizational forms: one is like a large data center, with some internet companies having thousands of servers; large mining pools also have thousands of mining machines. If these mining machines belong to the same organization, then how to distribute the income is not important.

However, some mining machines come from different organizations, which is the second organizational form: distributed. Miners and pool managers are not in the same location and may be scattered around the world. When miners join a mining pool, they must follow the communication protocol set by the pool to contact the pool manager. The pool manager assigns the task of calculating hash values to them, and after miners complete the calculations, they report the results back to the pool manager. When the block reward is obtained, it is distributed accordingly.

If miners come from all over the world and are not part of the same organization, how should the benefits be distributed? Is it acceptable to distribute them equally? For example, if each miner mines a block and receives the block reward, then sharing it equally among other miners is not feasible because some miners may slack off. Therefore, the distribution must be based on the contribution of each miner, which also requires proof of work. But how to prove how much work each miner has done?

The reason miners' income is unstable is that mining is too difficult. If the difficulty of mining is lowered, mining will become stable. How to lower the difficulty? The previous requirement was that miners had to find a nonce, and the nonce must calculate the hash value of the block header, which must have at least 70 leading zeros to be a valid block. After lowering the mining difficulty, for example, if only 60 leading zeros are required, the mined block is called a share, which is an almost valid block. After miners mine a share or almost valid block, they submit it to the pool manager. The pool manager uses this block to prove the work done by the miners, but it has no other purpose. Therefore, the pool manager counts how many such shares each miner submits, and when a certain miner truly mines a valid block, the block reward is distributed according to the number of shares submitted by each miner.

Why is this feasible? The probability of a miner mining a block depends on the number of nonce attempts; the more nonce attempts made, the more shares found.

Is it possible for a miner to mine a valid block and not submit it to the pool manager, but instead secretly publish it to receive the block reward? That is, they submit shares but do not submit the valid block? This is not possible because each miner's task is assigned by the pool manager, who is responsible for assembling a block and assigning various nonce values to miners to try. Additionally, merely adjusting the nonce is not enough; the coinbase parameter must also be adjusted. Therefore, the pool manager will assign ranges of nonce values corresponding to different coinbase parameters to different miners for them to try. What does this block contain? The coinbase transaction contains the recipient's address, which is the address of the pool manager. Therefore, if a miner mines a block and does not submit it to the pool manager, they cannot use it because the recipient's address is the pool manager's address, and they cannot withdraw the money. Thus, as long as they follow the tasks assigned by the pool manager, it is impossible to steal the block reward.

If they initially ignore the pool manager's task and assemble a block themselves, secretly changing the recipient address to their own, what will happen? In that case, if they submit shares to the pool manager, the pool manager will not recognize them because the transaction list has been altered, and the content of the coinbase transaction has changed, resulting in a different root hash value of the Merkle tree. In this case, the pool manager will not provide them with proof of work. This means that if miners initially act independently, they are not related to the mining pool.

Although it is impossible to steal the block reward, could someone cause trouble, for example, by submitting a share to the pool manager and then discarding a valid block once they mine it? This is possible; although there is no economic benefit, it could be a mole sent by another mining pool to prevent this mining pool from receiving the block reward. These miners will still receive dividends, which are the block rewards mined by other miners.

As shown in the eighth video at 38 minutes, the distribution ratio of mining pools in various countries shows that Chinese mining pools account for 81% of the world's total, far exceeding other countries. As shown in the eighth video at 38 minutes and 24 seconds, when viewed from the perspective of a single mining pool, in 2014, there was a mining pool called GHash.IO, which accounted for more than half of the global computational power. This caused some panic, as this mining pool's computational power was sufficient to launch a 51% attack. After this was announced, the mining pool voluntarily reduced its computational power to avoid shaking people's confidence in Bitcoin.

As shown in the eighth video at 38 minutes and 56 seconds, the distribution of mining pools' computational power in 2018 appears less concentrated. The GHash.IO mining pool has long ceased operations. Of course, the degree of mining centralization is still quite significant, with several large mining pools accounting for a considerable proportion, but no mining pool occupies more than 50%. This appears relatively safe, but it may only be a superficial phenomenon. If an organization has more than half of the computational power, they do not necessarily need to concentrate all their power in one mining pool; they can distribute it across