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 reverse-engineer the input or its patterns from the hash result.
puzzle friendly: Ensures the difficulty of mining; apart from brute-force exhaustion, 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 through elliptic curve multiplication, a series of public keys can be generated.

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

A = RIPEMD160(SHA256(K))

A: Address
K: Public Key

Subsequent encoding will be done in base58 and 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 target's hash value.
Blockchain

It is a linked list composed of blocks using hash pointers.

The block header is 80 bytes, while the block must contain transactions, so generally, 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 lead to changes in the hash values of subsequent blocks. 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 current block's hash and verify whether it meets the difficulty requirement, without needing the miner to provide it. However, the application layer maintains an index of block hashes to block data for efficient data querying.

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 the block.

Similar to a binary tree, but with two differences:

Uses 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 referred to as a cryptocurrency.
The content on the blockchain is public, including the addresses of blocks and the amounts transferred.

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 collisions) resistance: For example, x≠y and H(x)=H(y), where two different inputs yield the same output, which is called a hash collision. This is unavoidable 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 is to compute a digest for 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 is impossible to do so. Hash collisions cannot be artificially manufactured or verified; they are derived from 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 sufficiently large and uniformly distributed. If it is not large enough, a random number is generally appended to x, such as H(x||nonce). The purpose of this property, combined with collision resistance, is to achieve digital commitment (also known as the digital equivalent of a sealed envelope). The predicted result is taken as input x, a hash value is calculated, the hash value is published, and hiding allows people to know the hash value without knowing the predicted value. Finally, x is published, and due to 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: The budget for the hash value 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 for this result; it still requires testing one by one.

The process of Bitcoin mining is essentially about finding a nonce, which, along with other information in the block header, serves as input. 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 during the mining process; to make the output value fall within the specified range, one must test each value individually. 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:
A public-private key pair (public key, private key) is created locally, which constitutes an account. The public-private key pair comes from asymmetric encryption technology.

Information exchange between two parties can utilize keys (encryption keys). A encrypts the information and sends it to B, who decrypts it using the key. 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. 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. The 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 transmitted to 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 his private key. After others receive this transaction, they need to verify the signature using A's public key. The signature uses the private key, and verification uses the public key, which still belongs to the same person. The probability of creating 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 there is a good source of randomness when generating the public-private key pair. The generation of the public-private key pair is random, and if the random source is poor, it may produce the same public-private key pair. The signature algorithm used in Bitcoin requires a good source of randomness not only when generating the public-private key pair but also for every subsequent 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 stores 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 benefit is that from the hash value of this hash pointer, one can not only find the location 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 (A 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 is the hash pointer of a block calculated? It is the hash value of the entire content of the previous block, including its hash pointer. 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 retain will also change (see the attached image ①).

② In a regular linked list, any element can be changed without affecting other elements. However, in a blockchain, changing one element affects the entire chain, 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 retain the most recent few thousand blocks. If older blocks are needed, they can be requested from other nodes in the system. Some nodes may be malicious; how to determine this? Here we need to use a property of hash values: If another node gives you a block, how do you 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 the attached image ②, where the bottom layer is data blocks, and the three upper layers are internal nodes that are hash pointers, with the top layer being the root node, which can also have a hash called the root hash).
Another concept is the binary tree.

The benefit of this structure is that as long as the root hash value is remembered, any modifications to any part of the tree can be detected. The differences are: ① It uses hash pointers instead of regular pointers.

In Bitcoin, the blocks are 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 individual transactions. Each block consists of two parts: the block header and the block body. The block header contains the root hash value, which is the root hash of the Merkle tree composed of all transactions contained in the block. 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 function of the Merkle tree:

① It provides Merkle proof.
Nodes in Bitcoin are divided into two types: full nodes (which store the entire content of the block, including both the header and body, with specific transaction information) and light nodes (such as Bitcoin wallets on mobile phones) (which only have the block header).

This raises a question: How can a light node prove that a certain transaction has been written into the blockchain? This requires the use of Merkle proof: finding the location of the transaction (one of the blocks in the bottom row), and the path from that block up to the root node is called the Merkle proof.

The attached image three shows a small blockchain, illustrating a Merkle tree for a block, with the bottom row containing transactions. Suppose a light node wants to know if the yellow transaction in the image is included in the Merkle tree. The light node does not have the transaction list or the specific content of this Merkle tree, only the root hash value. At this point, the light node requests a full node to prove that the yellow transaction is included in this Merkle tree using Merkle proof. 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 compute 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 combines it with the adjacent red hash values to compute the upper green hash value. It continues this process until it computes the root hash value of the entire tree. The light node then 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 hash values provided by the full node in the Merkle proof are the hash values used along the path 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 (only the hash values along this path can be verified; 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 combined 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? This is called 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 only these leaf nodes exist, thus 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 and sorted in ascending order by hash value. To find the transaction being sought, one first calculates a hash value and checks where it would be if it were included. For example, if it falls between the third and fourth nodes, the proof provided would require both the third and fourth leaf nodes to go up to the root node. If the hash values are all correct, the final hash value calculated at the root node would also be unchanged, indicating that the third and fourth nodes are 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, it indicates that it does not exist. Its complexity is also logarithmic, but the cost is that sorting is required. The sorted version is called a sorted Merkle tree. Bitcoin does not use this sorted Merkle tree because it does not need to prove non-existence.

This section discusses the two 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 there are cycles, there is a problem: their hash values cannot be calculated, and a fixed hash value for a 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 a double spending attack. Decentralized currency must 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. ② It relies on the data structure of the blockchain. The issuer A of Bitcoin has the right to create coins (createcoin). If A issues 10 bitcoins, A(10) gives B and C each five → B(5) C(5). This transaction requires A's signature to prove it has A's consent (designed by A). It must also indicate where the 10 bitcoins spent came from.

Refer to the attached image four: The money in the second box comes from the coin issuance transaction in the first box.

In the Bitcoin system, each transaction contains two parts: input and output. The input part must specify the source of the coins, while the output part provides the hash of the recipient's public key. Some transactions are more complex; for example, C's source of funds is from 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 we 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 is it necessary to indicate the source of the coins? To prove that the coins are not fabricated out of thin air and have a record, while also preventing double spending.

Now let's look 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 recipient's 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, an e-commerce website that accepts Bitcoin payments can publicly disclose its address or public key.

Does A need to know what information B has? 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 made with the private key, and verification is done with the public key (note not to confuse this with the previous knowledge where encryption uses the recipient's public key and decryption uses the private key), so each node in the blockchain must verify independently.

How can one know A's public key? In fact, it is included in the transaction. When inputting, not only must the source of the coins be specified, 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 coin issuance transaction in the first box already contains the hash of A's public key, so in the transaction in the second box, A's public key must match the previous hash.

In the Bitcoin system, the verification process described above is implemented through executing scripts. Each transaction's input includes a segment of script that specifies the public key. The output of each transaction 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 executed to see if it can be executed smoothly. If it can be executed, it indicates legality. This is 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 of Bitcoin's protocol is being used (version), the pointer to the previous block in the blockchain (hash of previous block header), the root hash value of the entire Merkle tree (merkle root hash), and two fields related to mining: one is the target value for mining difficulty (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 hash of the previous block's header, so the earlier diagram, where an arrow points from one block to another, is incorrect; some books may have arrows pointing to the top of a block. When hashing, all parts of the block header are hashed.

The block body contains a list of transactions.

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

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

How is the content of the blockchain written into the blockchain? Each node, each account can publish transactions, which are broadcast to all nodes. Some transactions are legitimate, 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 everyone 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 Bitcoin's application but can be used for understanding:
A simple example of distributed consensus is a distributed hash table. 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' corresponding to 12345, i.e., 'xiao'→12345, then others on another machine must also be able to read this value, which 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, 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, then 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 is guaranteed to be consistent, meaning that each member's understanding of the consensus is the same. However, in certain situations, this protocol may never reach consensus, which is a small but objectively existing possibility.

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

The first solution is voting. First, it should be determined which blocks have voting rights; some memberships have strict requirements. In this case, a voting-based solution is feasible. However, creating accounts in the Bitcoin system is very easy; even if one person generates a public-private key pair, others cannot know. Only when a transfer occurs 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.

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

The so-called right to keep accounts refers to the right to write the next block into the Bitcoin ledger. Only the node that finds this nonce and gains the right to keep accounts has the authority to publish the next block. Other nodes receiving this block must verify its legality.

For example, they check whether the contents filled in the block header are correct; the block header contains a field called nBits, which is actually an encoding of the target value. They 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, they then check the transaction list in the block body to verify that each transaction is legitimate: ① It must have a valid signature ② It must not have been spent before. If any of these conditions are not met, the block cannot be accepted. If all conditions are met, it is still not necessarily accepted.

If a new block is generated, how does one know where to insert the new block? It is determined by the pointer of the generated block. A problem may arise, as shown in Figure 5 (the fourth video at the 65th minute), where these two transactions indicate A transferring to B and A transferring to himself. This situation is not double spending; to determine whether a transaction is double spending, one checks whether the coins in this branch of the blockchain have been spent. As shown, until the third block, the coins have not been spent, so this transaction is legitimate. Although this transaction is legitimate, 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.

Under 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 suitable and then tries various nonce values. If two nodes find a suitable nonce at nearly the same time, they can both publish the block, resulting in two equally long 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, depending on their position in the network, may hear about one new block before another, leading them to accept that block.

How to determine if a block has been received? The Bitcoin protocol uses implicit consent; if the block is extended downwards, it is considered to have recognized the published block. For example, if a new block is generated after one of the blocks, it indicates recognition of this new block.

Temporary forks of equal length will last for a period until one fork prevails. The chain that generates a new block first is the longest valid chain. The other becomes an orphan block. These two new blocks may each pull in miners, with the stronger hash power winning, sometimes based on luck.

The benefit of competing for the right to keep accounts is that the first node to gain this right has some power to decide which transactions are written into the next block. However, this should not be set as the motivation for competing for the right to keep accounts, so a mechanism has been cleverly established: block rewards (block reward).

The Bitcoin protocol stipulates that the node that gains the right to keep accounts can have a special transaction in the published block: the coinbase transaction. In this transaction, a certain amount of Bitcoin can be issued.

Returning to the earlier question of 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 Bitcoin. This transaction does not need to specify the source of the coins.

So how many coins can be created? 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 prevails, the other orphaned block's bitcoins are ineffective, and other honest blocks will not recognize them.

What consensus must be achieved in the Bitcoin system? A decentralized ledger must achieve consensus. Who can decide the content of the ledger? Only the nodes that gain the right to keep accounts can write. How to gain the right to keep accounts? By solving pow (mining). Voting is based on computational power, which can be represented by how many nonce values can be tested per second. How to prevent Sybil attacks? By voting based on computational power, even if many accounts are created, it will not enhance computational power.

The process of competing for the right to keep accounts in Bitcoin is called mining, and Bitcoin is referred to as digital gold. The nodes competing for the right to keep accounts 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 maintain a data structure called UTXO (unspent transaction output). There are many transactions on the blockchain; some outputs of these transactions may have been spent, while others have not. The collection of all unspent outputs is called UTXO.

A transaction can have multiple outputs. If A gives B 5 bitcoins, and B spends them, while A also gives C 3 bitcoins, and C does not spend them, 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 generated the output, as well as 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 determine whether a newly published transaction is legitimate. Therefore, full nodes must maintain the UTXO data structure in memory to quickly detect double spending.

Each transaction consumes some outputs and 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 preserved in UTXO again. If D never spends them, this information must be permanently retained in UTXO. It may be that D does not want to spend them, or it may be that the private key has been lost.

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 published the block.

Block rewards cannot be the only incentive for mining; why must the node that publishes the block package 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 package my transaction into the block, I will give you a tip. Transaction fees are generally small, and some simple transactions may not have 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 the entire system produces a new block approximately every 10 minutes.

In addition to Bitcoin's 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 transactions must specify the source of the coins, while the account-based model does not.

As shown in image ⑥ (fifth section video at 16 minutes), 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 the 686 transactions).
The last line: block reward (the main incentive for miners).
The fifth line: block number.
The sixth line: block 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 the block header.
The second line: the hash value of the previous block header.
(Note: The hash value is calculated only for the block header.)
The common feature of these two hash values is that they both have a string of zeros in front. This is because the target value set, when represented in hexadecimal, is a long string of zeros in front. Therefore, any block that meets the difficulty requirement must have a long string of zeros in the hash value of the block header.
The fourth line: the Merkle root is the root hash value of the Merkle tree composed of the transactions included in this block.

As shown in image ⑥ (see fifth section video at 20 minutes), the data structure of the block header:
The last line is a 32-bit unsigned integer. The nonce has 2^32 possible values. Given the current mining situation in Bitcoin, it is very likely that even after testing all 2^32 possible values, a suitable one will not be found. So what other fields in the block header can be adjusted?

As shown in image ⑦, the description of each field in the block header (see the fifth video at 21 minutes):
The first line: the version number of the Bitcoin protocol (unchangeable).
The second line: the hash value of the previous block's header (unchangeable).
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: target value (encoded version) (can only be adjusted periodically according to the requirements in the protocol).
The sixth line: random number.

When mining, simply changing the random number is not enough; the root hash value can also be changed.

As shown in image ⑧ (see the fifth video at 23 minutes), 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 commitment 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 ⑨ (see the fifth video at 24 minutes), it corresponds to the Merkle tree whose root hash value is in the last block header. The transaction in the lower left corner is the coinbase, and after changing its field, its hash value changes, which then propagates up through the structure of the Merkle tree. Finally, 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, and 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^96.

Therefore, in 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 ⑩, an example of a regular transfer transaction (see the fifth video at 26 minutes):
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 and have not been spent, which will be stored in UTXO.
In the right table, the first line: total amount of inputs.
Subsequent lines: total amount of outputs, 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 about pairing the input and output scripts of the same transaction, but pairing the input scripts here with the output scripts of the previous transaction that provided the source of the coins. If the input and output scripts can be concatenated and executed smoothly without errors, then the transaction is legitimate.

As shown in image eleven, it is the process of solving the puzzle.
Note: When calculating the hash, only the contents of the block header are used, while the specific information of the transaction is not 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. 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 experiments. At this point, a Poisson process can replace the Bernoulli process. What we are really 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 overall block generation time of the system, not the block generation time of each miner). Specifically, for each miner, the time it takes to mine the next block depends on the miner's hash power as a percentage of the system's total hash power.

If a person's hash power accounts for 1% of the system's total hash 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 truncate it 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 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 might occur? Miners with strong hash power will have a disproportionate advantage. Because miners with strong hash power 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 in Bitcoin has no practical significance other than competing for hash 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 hash power; as long as the majority of hash power is in the hands of honest nodes, the system's security can be guaranteed.

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

Assuming that the majority of hash power is in the hands of honest miners, what kind of security guarantees can we obtain? Can we ensure that the transactions written into the blockchain are all legitimate? 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 right to keep accounts will not fall into the hands of malicious nodes.

For example, if good miners account for 90% of the hash power and bad miners account for 10%, then there is a 10% probability that the right to keep accounts will fall into the hands of malicious miners. What will happen then?

First, consider the first question: Can they steal coins? Can they transfer money from someone else's account to themselves? No, because they cannot 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 the right to keep accounts, 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 that the normal valid chain be extended, so the block generated by M is not a legitimate block and thus becomes orphaned. The cost to M is significant because they lose the block reward and do not steal any money.

The second question: Can they spend coins that have already been spent again (i.e., double spending)? If they write the transaction M→A into a block, and now they have gained the right to keep accounts, they can publish another transaction transferring this money back to themselves, i.e., M→M'. This is clearly double spending, and honest nodes will not accept this block.

If they want to publish this block, they can only attach it to the block preceding the one containing the M→A transaction. Note: The position of the block is determined when mining; because the hash of the previous block header must be filled in the block header, they must recognize it from the beginning, rather than waiting to gain the right to keep accounts before recognizing it.

Thus, the two generated blockchains are both legitimate. Refer to image twelve (the fifth video at the 56th minute). To see which chain other nodes extend downwards, the last one to succeed is the one that becomes orphaned.

What is the purpose of such an attack? If the transaction M→A produces some irreversible external effect, and then M→M' rolls back the transaction M→A, 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 being written into the blockchain, believing that the payment was successful, and thus delivers the goods to M. After receiving the goods, M initiates another transaction to transfer the spent money back to themselves, then extends the chain downwards from the longest valid chain. The result is that M has obtained the goods while also recovering the money spent, achieving the goal of double spending.

How to prevent such attacks? If the block containing the M→A transaction is not the last block, the difficulty of this attack will greatly increase. If M wants to roll back the M→A transaction, they must attach it to the block preceding it and find a way to become the longest valid chain. This is very difficult. Because honest nodes will not extend the block generated by M, as it is not the longest valid chain. Therefore, the method to prevent such attacks is to wait for several more blocks, or to wait for several confirmations.

When the M→A transaction is just written into the blockchain, we call it one confirmation. The blocks added afterward are called two confirmations, three confirmations, and so on. In the Bitcoin protocol, the default is to wait for six confirmations. Only after six confirmations is the M→A transaction considered immutable. This requires waiting for how long? The average block generation time is 10 minutes, so it takes about an hour.

The blockchain is an immutable ledger, but does this mean that the 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 have been 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 online shopping, where you publish a transfer transaction during payment, informing the e-commerce site that you have already transferred the money. The e-commerce site runs a full node or delegates a full node to listen for transactions on the blockchain. After receiving the transfer transaction, it verifies 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 risky, as 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 sends 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 delivery, meaning there is a certain processing time.

Returning to the earlier question: If a malicious node gains the right to keep accounts, what other bad things can they do? Can they deliberately not write certain legitimate 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 the right to keep accounts must publish those transactions into the block. However, this situation is not a big problem because these legitimate 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 situations where legitimate transactions are not included; this may be due to a high volume of transactions during that time. The Bitcoin protocol stipulates that each block has a size limit, which cannot exceed one megabyte. Therefore, if the number of transactions is too high, some transactions may have to wait until the next block to be published.

Could this situation occur? If the block containing the transaction M→M' is on a shorter chain, it could secretly generate more blocks than the upper chain, and then wait for the upper chain to be published before publishing, thus surpassing the upper blocks. This method is called selfish mining.

Under normal circumstances, when a block is mined, it is immediately published because if it is not published, others may publish it, and then the block reward will be lost. Selfish mining involves hiding the block and not rushing to publish it; this is a means of forking.

However, the probability of success for this is not high because malicious nodes originally have a low proportion of hash 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 one block and publishes it, then A's two unpublicized 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 (provided A has sufficient hash power).

However, this also has downsides. If A mines a block and believes they can quickly mine another block before others, but someone else mines the first block, then A must immediately publish after others do 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. Nodes communicate via TCP, which helps penetrate 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 information and will delete you after a while.

The design principle of the Bitcoin network is simplicity and robustness, rather than efficiency. Each node maintains a set of zero-degree nodes, and message propagation in the network takes the form of flooding. 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 is about the same speed as transferring to someone in the U.S.

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 of a transaction, it adds this transaction to the collection and forwards it to other nodes. Afterward, 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 legitimate.

Here, there may be conflicting situations; you may 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 write it into their collection, and when they receive the second transaction, they will not write it into the collection because it conflicts with the previous transaction, thus deeming it illegal. If both 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 containing 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 must also be deleted. If A→C has already been written into the blockchain, then A→B becomes an illegal transaction, resulting in double spending, which is a conflicting situation. It is possible that a node that first received A→C quickly mines and publishes a block.

The propagation of newly published blocks in the network has many methods, similar to the propagation of newly published transactions. Each node must check the legality of the block's content and 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 used by the Bitcoin system is very bandwidth-intensive, and bandwidth is a bottleneck. Based on the 1MB block size limit, a newly published block may take tens of seconds to propagate to most of the network, which is already 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 forward messages according to the requirements of the Bitcoin protocol.

Some nodes may not forward what should be forwarded, leading to some legitimate transactions not being received, while 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 difficulty of mining. Adjusting the 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^256. Adjusting this proportion, i.e., the ratio 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 computed hash to have at least 70 leading zeros, this is a simplified explanation, as the target value is not just a series of zeros; it starts from a certain position, and the rest becomes ones.

The difficulty of mining is inversely proportional to the target value, with the formula: difficulty = difficulty_1 * target / target. The above refers to the target value corresponding to a mining difficulty of 1, where the minimum mining difficulty is 1, corresponding to a very large target value.

That is, the larger the target, the easier it is to mine. Thus, a very large number divided by the current target value gives the current mining difficulty. Therefore, 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 hash 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 became shorter and shorter? For example, if a block is generated in less than a second, the time it takes for the block to propagate in the network may take tens of seconds, and the underlying Bitcoin network may take tens of seconds to allow other nodes to receive it. Before other nodes receive this block, they will continue to extend down the existing blockchain. If two nodes simultaneously publish a block, a fork will occur.

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

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

If there are many forks later, a transaction in a previous block may be subject to a fork attack, as malicious nodes will attempt to roll it back. Because with more forks, the hash power will be dispersed, increasing the probability of success for malicious nodes. At this point, malicious nodes may not need 51% of the hash 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 set; 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 the block generation time significantly decreases, Ethereum must design a new protocol called Ghost. In this protocol, these forks and the orphan blocks generated after the longest valid chain cannot be discarded; instead, they must also be rewarded, which is called uncle reward. Ethereum must also adjust mining difficulty to keep the block generation time at 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 time actually taken to generate 2016 blocks, while expected time refers to the time expected to generate 2016 blocks, which is 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 lower to make block generation easier. Therefore, the target value calculated by this formula will increase, resulting in a decrease in difficulty.

In practice, both upward and downward adjustments have a fourfold limit. If the actual time exceeds eight weeks, then we can only calculate according to four times when using the formula, and the target value can increase 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 every time 2016 blocks are mined. If there are malicious nodes that deliberately do not adjust, what will happen?

If a node does not adjust and publishes a 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, which would require 32 bytes to store directly. nBits in the header only has four bytes, so it can be considered a compressed encoding of the target.

If a malicious miner does not adjust when it should, the legality check of the block will fail. 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 exploit the system by designing an excessively large target value to make mining easier, that block will not be accepted.

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

As shown in the seventh video at the 27th minute, the changes in mining difficulty are basically synchronized with the growth of hash power, which aligns with the design goal of adjusting mining difficulty to keep block generation time stable. Note that this graph shows mining difficulty, not target value.

As shown in the seventh video at the 27th minute and 27 seconds, the recent six-month difficulty adjustment curve clearly shows distinct steps. Every two weeks, the difficulty increases by one step, 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. This is not a good sign, as it suggests that interest in the currency is gradually diminishing. Continuous occurrences of this situation indicate that the currency will be eliminated.

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

As shown in the seventh video at the 28th minute and 36 seconds, the recent six-month block generation time also maintains around 10 minutes.

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

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

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

Most nodes in the Bitcoin network are light nodes. If one is 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 valid block that 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 to mine down 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, as well as 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 you continue mining the original block or stop to mine a newly assembled block, the probability of success is the same. As long as you have not yet mined a nonce value that meets the requirements, it does not matter how long you have been mining.

Even if you mine a legitimate block and publish it 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 conflicting situations, such as others simultaneously publishing some legitimate 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 follow the protocol, and will not accept transactions without valid signatures. Without these, the cryptographic guarantee is useless.)

For example: When you go to the bank to withdraw money, you must present valid identification according to regulations before the bank staff can give you the money. A valid identification is equivalent to a cryptographic signature, and 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, these are not sufficient; bank staff must be conscientious and not give money to those without valid identification. Only when these two conditions are met can it be ensured that others cannot take money from your account.

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

Thus, mining transitioned to the second generation of equipment: GPUs. The efficiency of GPUs compared to CPUs has improved significantly, primarily 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, while 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 this to the popularity of deep learning, but 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 hash 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 use ASIC chips for mining, which are chips specifically designed for mining. They have no extra logic and are designed solely for Bitcoin mining and hash value calculations. Their cost-effectiveness is the highest; these chips can only mine one specific cryptocurrency unless these 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 takes about a year, but compared to other general-purpose chips, the development speed of ASIC chips is already very fast.

During such a long production cycle, if the price of Bitcoin experiences drastic changes, the initial investment in research and development may become worthless. 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 is also becoming increasingly fierce, and customized ASIC chips may become obsolete in just a few months. When an ASIC miner is first launched, most of the profits are earned in the first two months after its release, as it has the strongest hash power among similar products. After that, as stronger mining machines appear, it may be phased out. Therefore, the timing of purchasing ASIC miners is crucial, and they now often require advance reservations. Some unscrupulous manufacturers, after producing ASIC miners, do not immediately provide them to consumers but instead use them for mining for a period to earn Bitcoin, and only after the most profitable golden time (the first two months) has passed do they deliver the miners to users. When there is a sudden increase in hash power in the Bitcoin system, it indicates that a large company has produced a new ASIC miner. Thus, in the mining frenzy, those who truly profit may not necessarily be the miners but rather the large manufacturers selling the miners.

The trend of mining machines is moving 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 concept of decentralization and goes against the original intention of Bitcoin's design. The most democratic situation would be for everyone to mine using their home CPUs. Later, switching to GPUs created 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. An individual 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 on average, one block is generated every 10 minutes across all miners. However, for a specific miner, they may have to mine for a long time, possibly one or two years, to find a block. This is akin to a lottery; finding a block is like winning a grand prize. Individual miners also face other issues; in addition to mining, 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 typically involves a full node driving many mining machines. A mining pool has a pool manager, who connects many miners. These miners are only responsible for calculating hash values, while the pool manager handles the other responsibilities of the full node. They are responsible for listening to transactions on the network, organizing 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 the 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 are obtained.

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

However, there are also mining machines from different institutions, 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 want to join a mining pool, they must contact the pool manager according to the communication protocol specified by the pool. The pool manager assigns the task of calculating hash values to them, and after the miners complete their calculations, they report the results back to the pool manager. When the block reward is obtained, it is distributed according to the number of shares submitted by each miner.

How to distribute the rewards? If miners come from all over the world and are not from the same institution, how should the benefits be distributed? Is it okay to distribute them equally? For example, if each miner mines a block and receives the block reward, then dividing 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. 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, it will become more stable. How to lower the difficulty? Previously, miners had to find a nonce that meets the requirement of having at least 70 leading zeros to be considered 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 find 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 use. Therefore, the pool manager counts how many shares each miner submits, and when a certain miner successfully 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 each miner mining a block depends on the number of nonce values they attempt; the more nonce values they try, the more shares they can find.

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. The pool manager is responsible for assembling a block and assigning various nonce values to the miners to try. Additionally, merely adjusting the nonce is not enough; the coinbase parameter must also be adjusted. Therefore, the pool manager will assign different ranges of nonce values corresponding to different coinbase parameters to different miners for testing. What does this block contain? The coinbase transaction includes the recipient's address, which is the address of the pool manager. Therefore, if a miner mines a block, they cannot publish it themselves because the recipient's address is the pool manager's address, meaning they cannot withdraw the funds. Thus, as long as the miners follow the tasks assigned by the pool manager, they cannot steal the block reward.

If they initially disregard the pool manager's tasks and independently assemble a block, 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 it because the transaction list has been altered, and the content of the coinbase transaction has changed, leading to 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 a miner initially works independently, they are not related to the mining pool.

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

As shown in the eighth video at the 38th minute, 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. Thus, in terms of mining pool ratios, China has an absolute advantage in total hash power.

As shown in the eighth video at the 38th minute and 24 seconds, when looking at individual mining pools in 2014, there was a mining pool called GHash.IO, which accounted for more than half of the global hash power. At that time, this raised some panic, as this mining pool's hash power was sufficient to launch a 51% attack. After this incident was made public, the mining pool voluntarily reduced its hash power significantly to avoid shaking people's confidence in Bitcoin.

As shown in the eighth video at the 38th minute and 56 seconds, the hash power distribution of various mining pools 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 portion, but no single pool exceeds 50%. This appears relatively safe, but it may only be a superficial phenomenon. If an organization has more than half of the hash power, they do not necessarily need to concentrate all their hash power in one mining pool; they can distribute it across many pools and concentrate it when they need to launch an attack.

Switching mining pools is very easy for miners. Joining a mining pool involves contacting the pool manager according to the protocol of that pool. The pool manager sends the assembled block information to the miners, who then try various nonce values.

Thus, the dangers posed by mining pools are that if there are no mining pools, an attacker would need to invest a large amount of capital to purchase enough mining machines to reach more than half of the hash power in the system. With mining pools, they may only need a small proportion of hash power; as long as they can attract enough miners and enough unsuspecting individuals to join their mining pool, they can achieve their goals.

Generally, mining pool managers charge a certain percentage of the block reward as a management fee. The pool manager also collects management fees proportionally, either based on the block reward or by taking a portion of transaction fees. Some malicious mining pools may deliberately lower their management fees before