Three major updates in Bitcoin Core 0.13.0

Since Satoshi Nakamoto released the first Bitcoin client 8 years ago, Bitcoin Core 0.13.0 has become the 13th generation product. Bitcoin Core 0.13.0 has been officially released.

Nearly 100 people participated in the development of Bitcoin Core 0.13.0, which took more than 5 months. The focus of this client update is naturally Segregated Witness (SegWit), but its code will not be activated in the current version, and it is likely to be activated in 0.13.1. Nevertheless, compared with version 0.12.0, Bitcoin Core 0.13.0 still brings some important changes.

Here are the most important changes.

Alleviate block congestion

The number of transactions in the Bitcoin network has been steadily increasing over time. This has ultimately led to more and more block congestion, as miners prioritize transactions based on the fees they pay. If users can't provide enough fees, transactions take longer to confirm, or may not be confirmed at all. The increase in transaction volume and the delays in many transactions have pushed the network into a "stress test" phase, which is a big problem.

Individual users can encourage miners to prioritize their transactions by increasing transaction fees, so that the problem can be properly solved. Even if the transaction has been sent, users can change the fee through the optional fee replacement method (RBF); however, most wallets do not have this function. In addition, RBF is only effective for the initiator of the transaction. So far, the recipient has not been able to speed up the confirmation time by increasing the fee.

There is a new feature in Bitcoin Core 0.13.0 called "Children Pay for Parents" (CPFP). CPFP is a policy for miners to choose the priority of transaction processing. With this CPFP policy, miners no longer need to prioritize large transactions. Instead, they will prioritize transactions that are beneficial to them. In other words: if a transaction has a low fee, but the subsequent transaction makes appropriate compensation for the previous transaction in terms of fee, then the miner will prioritize this transaction and package both transactions at the same time.

If CPFP is brought into actual transactions, it will be like this: the recipient of a low-fee transaction can "add" an additional high-fee transaction and send it to himself. In this way, miners will be attracted by this new high-fee transaction and start to package two transactions. Therefore, the recipient no longer has to wait for confirmation time, and miners can also increase their income.

Compact Block Support

Currently, Bitcoin's P2P protocol is somewhat inefficient. Usually, transaction data nodes are sent twice: the first time when the transaction is sent to the network, and the second time after the transaction is confirmed.

There are some disadvantages to this approach. First, sending the transaction data twice requires more bandwidth, which increases the cost of running Bitcoin Core. Second and most importantly, sending multiple new blocks to nodes at the same time will cause bandwidth congestion, which will hinder the normal use of the network when each new block is generated, which is too annoying for users. In addition, this model will slow down the propagation of blocks throughout the network. Slowing down the propagation of blocks is exactly what large mining pools want, because it can bring them more benefits and create a centralized mining environment.

Compact blocks (BIP152) were developed by Bitcoin Core and Blockstream developer Matt Corallo to reduce the over-transmission of data. When a new block is generated, the node only needs to receive a simple hash of the transaction data, and the receiving node will try to use the received information and the transactions in its memory pool to reconstruct the entire block.

But this doesn’t always work perfectly. If a node hasn’t received the original transaction before receiving the hash, then the node cannot select the transaction. However, this rarely happens: when the wrong transaction is hashed in the correct hash, the node will mistakenly think it received the correct transaction and will not discover the problem until the block reconstruction stage.
From the above two failures, we can see that the nodes only need the specific transaction data. As long as some nodes receive the complete data, the propagation speed of compact blocks will be faster and less bandwidth will be required.

HD Key Generation

Bitcoin Core generates random public and private keys for each new Bitcoin address. While this is done for security and privacy reasons, it is still burdensome for users. To ensure the security of the keys, they must back them up frequently.

Hierarchical Deterministic (HD) Key Generation (BIP32) was developed by Bitcoin Core developers Gregory Maxwell, Dr. Pieter Wuille, and Bitcoin wallet developer Alan Reiner between 2012 and 2013. With HD key generation, Bitcoin Core created a new key combination that consists of 12 single characters. As long as the user remembers these 12 characters, they can regenerate the key and successfully access funds.

HD key generation is not a new invention in the Bitcoin world. Many wallet providers have already used this feature, but Bitcoin clients have not yet used it.

Performance and security

Bitcoin Core 0.13.0 also includes a number of performance and security upgrades that are far too numerous to mention in this article. Here is just a small sampling of them (for more details, please refer to the official 0.13.0 information).

The database cache speed has been improved, which can accelerate the transaction verification and other functions of the node; users can interactively input sensitive information on the command line, and this information will not be stored, which improves security to a certain extent; the software will use the latest versions of programming languages ​​​​after the update, including C++11 and Python 3, which will help develop more and more powerful functions; 0.13.0 also developed ARM (special microprocessor architecture) binaries for Linux, so users do not need to compile manually; transaction data in the memory pool can be interoperable (implemented by CPFP), and can also be connected to external programs; network nodes can request to set handling fees to prevent DoS attacks; finally, this update also involves P2P protocols, remote calls, and information systems (ZMQ) protocols.

Note: Thanks to Bitcoin Core Lead Maintainer Wladimir van der Laan and Bitcoin Core Developer and Ciphrex CEO Eric Lombrozo for providing information and feedback.