pseudoyu

pseudoyu

Blockchain | Programming | Photography | Boyi
github
twitter
telegram
mastodon
bilibili
jike

Interpretation of Bitcoin Core Technology

Introduction#

In the previous article "Basic Knowledge and Key Technologies of Blockchain", the basic knowledge and key technologies of blockchain were sorted out, while Bitcoin is the most typical application of blockchain. This article will interpret the core technology of Bitcoin. If there are any errors or omissions, please feel free to communicate and correct.

Bitcoin System#

Bitcoin is a digital currency invented by Satoshi Nakamoto in 2009, primarily to resist the centralized banking system. Due to its ingenious system design and security, its value is rapidly increasing. At the same time, because it is not bound to real-world identities and possesses strong anonymity, it has also been used for illegal transactions, money laundering, extortion, and other malicious activities, causing some controversy.

As a decentralized blockchain system, everyone can access it and can maintain a node locally to participate in the Bitcoin network. The following text will also apply the Bitcoin Core client to maintain a node locally.

bitcoin_network_nodes

Nodes are divided into full nodes and light nodes. In the early days, all nodes were full nodes, but as the amount of data increased, Bitcoin clients running on devices such as mobile phones or tablets do not need to store the entire blockchain information, known as Simplified Payment Verification (SPV) nodes, or light nodes.

The Bitcoin Core client is a full node, which will be discussed in detail later. Full nodes are always online, maintaining complete blockchain information; because they maintain a complete UTXO set in memory, they verify the legality of transactions by validating the blocks and transaction information of the entire blockchain (from the genesis block to the latest block); they also decide which transactions will be packaged into blocks; verifying transactions is mining, which can determine which chain to continue mining on, and when there are equally long forks, they will also choose which fork to follow; at the same time, they listen to blocks mined by other miners and verify their legality.

Light nodes do not need to be online all the time and do not need to retain the entire blockchain (which is large), only needing to keep the headers of each block; they only need to save blocks related to themselves, rather than saving all transactions on the chain; because they do not save all information, they cannot verify the legality of most transactions and the correctness of newly published blocks online, only being able to check blocks related to themselves; they can verify the existence of a transaction through Merkle Proof, but cannot confirm that a transaction does not exist; they can verify the mining difficulty, as it is stored in the block header.

Below is an example to explain the transaction verification methods of full nodes and light nodes.

If you want to verify a transaction T located at block 300,000, a full node will check all 300,000 blocks (up to the genesis block) to establish a complete UTXO database to ensure that this transaction has not been spent; while a light node will link all blocks related to transaction T through the Merkle Path, and then wait for blocks 300,001 to 300,006 for confirmation, thus verifying the legality of the transaction.

Blockchain Structure#

The blockchain is a data structure composed of blocks linked in sequence, which can be stored in a single file or database. The Bitcoin Client uses Google's LevelDB database to store data. Each block points to the previous block, and if any block is modified, all subsequent blocks will be affected. Therefore, to tamper with a block, one needs to tamper with all subsequent blocks simultaneously, which requires a lot of computing power, often making the cost greater than the benefit, thus greatly ensuring security.

The blockchain structure includes several core components: Block Size (4 bytes), Block Header, Transaction Counter (1-9 bytes), and Transaction.

The size of the blockchain block header is 80 bytes, storing Version (4 bytes), Previous Block Hash (32 bytes), Merkle Tree Root (32 bytes), Timestamp (4 bytes), Difficulty Target (4 bytes), and Nonce (4 bytes).

The hash value of each block is obtained by performing a double hash operation on the block header, i.e., SHA256(SHA256(Block Header)), and does not exist within the blockchain structure but is calculated by each node after receiving the block, making it unique; in addition, Block Height can also serve as an identifier for the block.

Merkle Tree#

The Merkle Tree is a very important data structure in the blockchain, mainly used to verify large data sets through hash algorithms (also through double hashing SHA256(SHA256(Block Header))). The structure is shown in the following figure:

merkle_tree_example

Using the Merkle Tree method allows for quick verification of whether a transaction exists in a certain block (with an algorithm complexity of LogN). For example, to verify that a transaction K exists in a block, only a few nodes need to be accessed.

merkle_proof_example

Since there are a large number of transactions in the Bitcoin network, this method can greatly improve efficiency, as shown in the following figure:

merkle_proof_efficiency

Because light nodes (such as Bitcoin wallets on mobile phones) do not save the entire blockchain data, they can conveniently search for transactions through the Merkle Tree structure. Light nodes will construct a Bloom filter to obtain transactions related to themselves:

  1. First, initialize the Bloom filter to an empty value, obtain all addresses in the wallet, create a retrieval pattern to match addresses related to this transaction output, and add the retrieval pattern to the Bloom filter;
  2. Then the Bloom filter is sent to various nodes (via the filterload message);
  3. After receiving it, the node will send a merkleblock message containing the block headers that meet the conditions and the Merkle Path of the transaction, along with a tx message containing the filtering results.

During this process, light nodes will use the Merkle Path to link transactions with blocks and use block headers to form the blockchain, thus being able to verify that transactions exist in the blockchain.

Using a Bloom filter will return results that meet the filtering conditions, but there will also be some false positives, so many irrelevant results are returned, which also protects privacy when light nodes request related addresses from other nodes.

Bitcoin Network#

The Bitcoin system operates on a P2P peer-to-peer network, where nodes are equal, with no distinction in identity or authority; there is no centralized server, and the network has no hierarchical distinction.

Each node must maintain a collection of transactions waiting to be added to the chain, with each block size being 1M, so it takes a few seconds to propagate to most nodes. If a node listens to a transaction A->B, it will write it into the collection. If it simultaneously detects a double-spending attack A->C, it will not write it again. However, if it listens to the same A->B transaction or a transaction A->C from the same coin source, it will delete the A->B transaction from that collection.

Bitcoin Consensus Protocol#

As a development system that anyone can participate in, Bitcoin needs to address the threat of malicious nodes. The solution is the proof-of-work mechanism, which is a computational voting mechanism. When a new transaction is generated, it broadcasts the new data record, and the entire network executes the consensus algorithm, i.e., miners mine to verify the record by solving a random number. The first miner to solve the problem gains the right to record, generates a new block, and then broadcasts the new block. Other nodes will add it to the main chain after verification.

Wallet#

As a digital currency system, Bitcoin has its own wallet system, mainly composed of three parts: private key, public key, and wallet address.

The process of generating a wallet address is as follows:

  1. Use the ECDSA (Elliptic Curve Digital Signature Algorithm) to generate the corresponding public key from the private key.
  2. The public key is long and difficult to input and remember, so a public key hash value is obtained through SHA256 and RIPEMD160 algorithms.
  3. Finally, process it with Base58Check to obtain a more readable wallet address.

Transaction Process#

With a wallet (and assets), you can start trading. Let's understand this process through a typical Bitcoin transaction:

A and B both have a Bitcoin wallet address (which can be generated using the Bitcoin Client, as explained above). Suppose A wants to transfer 5 BTC to B. A needs to obtain B's wallet address and then use their private key to sign the transaction of A->B transferring 5 BTC (since A's private key is known only to themselves, possessing the private key means having ownership of the wallet assets); then publish this transaction. Initiating a transaction in the Bitcoin system requires a small miner fee as a transaction fee; miners will begin to verify the legality of this transaction, and after receiving six confirmations, the transaction can be accepted by the Bitcoin ledger. The entire verification process takes about 10 minutes.

Why do miners consume a lot of computing power to verify transactions?

Miners can earn block rewards and miner fees during the verification process. The block reward decreases every four years, so the main incentive later is the miner fee.

Why does verification take 10 minutes?

Bitcoin is not absolutely secure; new transactions are susceptible to some malicious attacks. By controlling the mining difficulty to keep the verification process around 10 minutes, it can greatly prevent malicious attacks, which is merely a probabilistic guarantee.

How does the Bitcoin system prevent double spending?

Bitcoin adopts a concept called UTXO (Unspent Transaction Outputs). When a user receives a BTC transaction, it is accounted for in UTXO.

In this example, if A wants to transfer 5 BTC to B, A's 5 BTC may come from two UTXO (2 BTC + 3 BTC). Therefore, when A transfers to B, miners need to verify whether these two UTXO have been spent before this transaction. If they have been spent, the transaction is invalid.

The following diagram illustrates the flow of multiple transactions and the relevant concept of UTXO.

btc_utxo_example

In addition, UTXO has a very important characteristic: it is indivisible. If A has 20 BTC and wants to transfer 5 BTC to B, the transaction will first take 20 BTC as input and then produce two outputs: one transferring 5 BTC to B and one returning the remaining 15 BTC to A. Therefore, A will again have a UTXO worth 15 BTC; if a single UTXO is not enough to pay, multiple can be combined to form an input, but the total must be greater than the transaction amount.

How do miners verify that the transaction initiator has sufficient balance?

This question seems simple at first glance; one might think of checking the balance like in Alipay. However, Bitcoin is a transaction-based ledger model and does not have an account concept, so it cannot directly check the balance. To know the remaining assets of an account, one must review all previous transactions and find all UTXO and sum them up.

Transaction Model#

The above discussed how a transaction occurs. What parts make up a Bitcoin transaction?

blockchain_bitcoin_script_detail

As shown in the figure, the initial part is Version, indicating the version.

Then there is information related to Input: Input Count indicates the number, and Input Info indicates the content of the input, which is the Unlocking Script, mainly used to verify the source of the input, whether the input is usable, and other input details.

  • Previous output hash - All inputs can trace back to an output, pointing to the UTXO that will be spent in this input, with the hash value of this UTXO stored here in reverse order.
  • Previous output index - A transaction can have multiple UTXO referenced by their index numbers, with the first index being 0.
  • Unlocking Script Size - The byte size of the Unlocking Script.
  • Unlocking Script - The hash that satisfies the UTXO Unlocking Script.
  • Sequence Number - Defaults to ffffffff.

Next is information related to Output: Output Count indicates the number, and Output Info indicates the content of the output, which is the Locking Script, mainly used to record how many bitcoins were output, the conditions for future spending, and output details.

  • Amount - The output Bitcoin quantity expressed in Satoshis (the smallest Bitcoin unit), where 10^8 Satoshis = 1 Bitcoin.
  • Locking Script Size - The byte size of the Locking Script.
  • Locking Script - The hash of the Locking Script, which specifies the conditions that must be met to use this output.

Finally, there is Locktime, indicating the earliest time/block a transaction can be added to the blockchain. If it is less than 500 million, it reads the block height directly; if greater than 500 million, it reads the timestamp.

Bitcoin Script#

In the transaction, the Unlocking script and Locking script are mentioned. So what is the Bitcoin script?

The Bitcoin script is a list of instructions recorded in each transaction. When the script is executed, it can verify whether the transaction is valid, whether the bitcoins can be used, etc. A typical script is as follows:

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

The Bitcoin script is executed from left to right based on the stack, using Opcodes to operate on the data. In the above script language, the data to be pushed onto the stack is enclosed in < >, while the operators prefixed with OP_ (OP can be omitted) do not have < >. The script can also embed data to be permanently recorded on the chain (not exceeding 40 bytes), and the recorded data does not affect UTXO.

In the transaction, <sig> <pubKey> is the Unlocking script, and OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG is the Locking script.

Compared to most programming languages, the Bitcoin script is non-Turing complete, lacking loops or complex flow control. It is simple to execute, and the results are deterministic regardless of where it is executed. It does not save state, and scripts are independent of each other. Due to these characteristics, although the Bitcoin script is relatively secure, it cannot handle very complex logic, making it unsuitable for processing complex business. The smart contracts provided by Ethereum have achieved innovative breakthroughs in this regard, leading to the birth of many decentralized applications.

Mining#

The previous text mentioned mining in the entire transaction process, so let's discuss it in detail.

Some nodes validate transactions to earn block rewards and miner fees, thus generating profits, which is called mining. The block reward is created by coinbase and decreases every four years, from 25 in 2009 to 6.5 now.

Mining is essentially a process of continuously trying random numbers to reach a certain target value, such as being less than a certain target value. This difficulty is artificially set to adjust verification time and enhance security, rather than solving mathematical problems.

Miners continuously try this value, with a very low success rate, but the number of attempts can be high. Therefore, nodes with strong computing power have a proportional advantage and are more likely to solve the problem.

Why does the mining difficulty need to be adjusted?

Because in the Bitcoin system, if the block time is too short, forks can easily occur. If there are too many forks, it will affect the system's consensus and endanger system security. The Bitcoin system stabilizes the block generation speed at around 10 minutes through difficulty adjustments, thus preventing transactions from being tampered with.

How is the mining difficulty adjusted?

The system adjusts the target threshold every 2016 blocks generated (approximately two weeks), which exists in the block header. All nodes in the network need to comply with the new difficulty for mining. If malicious nodes do not adjust the target in the code, honest miners will not recognize it.

Target threshold = Target threshold * (Actual time to generate 2016 blocks / Estimated time to generate 2016 blocks)

At the beginning of Bitcoin's birth, there were few miners, and the mining difficulty was low, mostly using home computers (CPU) for direct mining. As more and more people participated in the Bitcoin ecosystem, the mining difficulty increased, gradually starting to use more powerful GPUs for mining, and some dedicated ASIC (Application Specific Integrated Circuit) mining chips and mining machines were gradually born with market demand. Now, many large mining pools have emerged, aggregating a large amount of computing power for centralized mining.

In this large mining pool system, the Pool Manager acts as a full node, while a large number of miners collectively calculate the hash value, ultimately distributing profits through the proof-of-work mechanism. However, excessive concentration of computing power can lead to some centralization risks; for example, if a large mining pool reaches over 51% of the total network computing power, it can roll back transactions or resist certain transactions.

Forks#

In the Bitcoin system, there can also be situations where consensus is not reached, known as forks. Forks are mainly divided into two types: one is state forks, often intentionally done by some nodes; the other is protocol forks, which means there are some differences regarding the Bitcoin protocol.

Protocol forks can be further divided into two types: one is called hard forks, which involve incompatible modifications to some content of the protocol, such as changing Bitcoin's block size from 1M to 4M. This type of fork is permanent, forming two parallel chains from a certain node, such as Bitcoin Classic, resulting in two different coins.

The other is called soft forks, such as still adjusting Bitcoin's block size, but changing it from 1M to 0.5M. After this adjustment, new nodes will mine smaller blocks while old nodes will mine larger blocks. Soft forks are non-permanent, with typical examples being modifications to the content of coinbase and the forks generated by P2SH (Pay to Script Hash).

Bitcoin Core Client#

Bitcoin Core is the implementation of Bitcoin, also known as Bitcoin-QT or Satoshi-client. This client can connect to the Bitcoin network, verify the blockchain, send and receive bitcoins, etc. There are three networks: Mainnet, Testnet, and Regnet, which can be switched.

It provides a Debug Console to interact directly with the Bitcoin blockchain, with common operations as follows:

Blockchain

  • getblockchaininfo: Returns various status information about blockchain processing.
  • getblockcount: Returns the number of blocks in the blockchain.
  • verifychain: Verifies the blockchain database.

Hash

  • getblockhash: Returns the hash value of the provided block.
  • getnetworkhashps: Returns the network hash rate per second based on a specified number of recent blocks.
  • getbestblockhash: Returns the hash value of the best block.

Blocks

  • getblock: Returns detailed information about the block.
  • getblockheader: Returns information about the block header.
  • generate: Immediately mines the specified number of blocks to an address in the wallet.

Wallet

  • getwalletinfo: Returns an object containing various information about the wallet's status.
  • listwallets: Returns the list of currently loaded wallets.
  • walletpassphrasechange: Changes the wallet password.

Mempool

  • getmempoolinfo: Returns detailed information about the activity status of the memory pool.
  • getrawmempool: Returns detailed information about all transactions in the memory pool.
  • getmempoolentry: Returns memory pool data for a given transaction.

Transaction

  • getchaintxstats: Calculates statistics about the total number and rate of transactions in the chain.
  • getrawtransaction: Returns raw transaction data.
  • listtransactions: Returns a list of transactions for a given account.

Signature

  • signrawtransaction: Signs the inputs of the raw transaction.
  • signmessage: Signs information with the private key of the address.
  • dumpprivkey: Retrieves the private key.

Network

  • getnetworkinfo: Returns status information about the P2P network.
  • getpeerinfo: Returns data for each connected network node.
  • getconnectioncount: Returns the number of connections to the node.

Mining

  • getmininginfo: Returns an object containing mining-related information.
  • getblocktemplate: Returns the data needed to construct a block.
  • prioritisetransaction: Accepts transactions into the mining block with higher or lower priority.

Conclusion#

The above is an interpretation of some core technologies of Bitcoin, mainly providing an in-depth understanding of its basic principles and data model. Through the study of Bitcoin, one can well understand the design philosophy and operating mechanism of blockchain. Next, we will study and analyze Ethereum, known as blockchain 2.0. Stay tuned!

References#

  1. COMP7408 Distributed Ledger and Blockchain Technology, Professor S.M. Yiu, HKU
  2. Udacity Blockchain Developer Nanodegree, Udacity
  3. Blockchain Technology and Applications, Xiao Zhen, Peking University
  4. Advanced Blockchain Technology and Practice, Cai Liang, Li Qilei, Liang Xiubo, Zhejiang University | QuChain Technology
Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.