Bitcoin software gets its biggest upgrade in history

On the evening of February 23rd, Beijing time, version 0.12.0 of the Bitcoin Core software was officially released. This version update may be the most significant improvement to the Bitcoin software to date.

The following are the most important improvements of this version. If you upgrade your node to version 0.12, you will enjoy:

1. Signature verification will be 7 times faster;

2. Ability to limit upload traffic;

3. Collision prevention through memory pool restrictions;

4. When sending a transaction, you can choose to increase the handling fee to speed up the transaction processing;

5. Improved transaction relay rules;

6. It can be used automatically when Tor is running;

7. The ability to subscribe to apps through ZeroMQ notifications;

8. Significantly reduce the disk space occupied by the wallet;

9. Miners can become faster at assembling blocks;

In addition to these, there are 13 other improvements that didn’t make it to this list, but are still very valuable. You can find the full list of them at the end of this post.

Let’s take a closer look at each of these improvements.

Signature verification will be 7 times faster

In Bitcoin Core, OpenSSL was previously used to verify ECDSA signatures of Bitcoin transactions. OpenSSL is very comprehensive in terms of its functionality (it can do more than simply verify ECDSA signatures), but this large feature set also means that its attack surface is very wide. This also threatens the security of Bitcoin, and replacing OpenSSL from Bitcoin Core has become a high-priority improvement and replacing it with a simpler, more focused alternative.

To address this issue, the Bitcoin Core team has developed a new ECDSA signature verification library called libsecp256k1 as a drop-in replacement for OpenSSL. This is the result of nearly three years of complex engineering research by the developers, and after incorporating it into Bitcoin Core, the attack surface of the signature verification code has been greatly reduced.

In addition, libsecp256k1's signature verification is much faster than OpenSSL's execution. In a 64-bit architecture environment, signature verification can be accelerated by up to 7 times, and the original indexing and block verification may now take less than half the time to complete, which is a big step forward for the verification process of Bitcoin transactions.

Credit goes to: Pieter Wuille, Greg Maxwell and Cory Fields

Ability to limit upload traffic

Node upload traffic can be a burden to some users, so the ability to limit traffic is a much-needed improvement for Bitcoin. Node users can now set a soft limit on how much traffic they can upload. Users can set a parameter for how much data a node can send to certain destinations. It will try to stay below the limit, rather than reaching it, and if traffic reaches the limit, it will only serve requested blocks within the last week.

Credit goes to: Jonas Schnelli

Collision prevention through memory pool limits

Older versions of the Bitcoin software did not have a limit on how many transactions could be allowed into a node's memory pool. Even though nodes would only accept transactions with a certain minimum relay fee, sometimes the number of transactions that met these requirements could still be so high that nodes with relatively low RAM would crash. This is especially true considering that attackers could exploit this feature to flood the Bitcoin network with transactions, causing some nodes to crash.

In this new version, nodes can set a size limit for their memory pool, and operators can configure the number of transactions they want to put into the mempool. When this memory limit is reached, new transactions will still be accepted, but the transaction with the lowest transaction fee will be removed from the mempool. This new memory limit ensures that accidental crashes of the memory pool are prevented because the number of transactions that can be carried out is controllable.

Credit goes to: Matt Corallo and Suhas Daftuar

When sending a transaction, you can choose to increase the handling fee to speed up the transaction processing

If users send transactions with too low a fee, these transactions tend to get stuck (not considered for processing by miners), which can cause problems because the unspent outputs (UTXOs) in these transactions may be difficult to spend, potentially resulting in frozen funds. Appropriate transaction fees are difficult to calculate because they are highly dependent on the volume of the transaction and the time given. As a result, users often underestimate transaction fees, causing many transactions to get stuck, or overestimate transaction fees, resulting in a large amount of unnecessary fees being paid.

A new feature called Opt-in Replace-by-Fee allows transaction senders to configure their transactions. Senders can start with a lower fee to see if their transaction will be accepted, and if not, they can increase their fee until it is accepted. This allows senders to minimize their payment fees and maximize the chances of their transaction being included in a block. (Translator's Note: This solution is highly controversial, mainly because it has a great impact on zero confirmation)

Credit goes to: Peter Todd and Suhas Daftuar

Improved transaction relay rules

As of now, a certain amount of relay bandwidth has been reserved for low-fee (or even zero-fee) transactions (also known as free transactions). The problem with this setup is that all other transactions (both medium-fee and high-fee transactions) have to compete for the limited available relay space.

In order to better serve transaction senders, nodes will no longer reserve a certain number of free transactions for relaying.

Credit goes to: Alex Morcos and Suhas Daftuar

When Tor is running, it can automatically use

Nodes can now detect if Tor is running, and if so, they automatically create hidden services for Tor and connect to other nodes over the Tor network. No manual configuration required.

Credit goes to: Wladimir van der Laan

Through ZeroMQ, APP can subscribe to the communication

Until now, there was limited support for external services to subscribe to notifications of new blocks and new transactions, but now with the integration of ZeroMQ, this capability is available.

Credit goes to: Johnathan Corgan

Significantly reduce the disk space occupied by the wallet

Users of the Bitcoin Core wallet often have a headache about one problem. Allowing a full node means a high data storage burden (currently 60GB and will continue to rise). For those who want to run a full node but don't want too high a data storage burden, the new version of Bitcoin Core can implement the ability of pruning mode, which means that the node only needs to track unspent outputs and forget about previously processed blocks and spent outputs. In turn, this means that users only need to store about 2GB of data when running a full node, which is a significant reduction from the previous 60GB.

Credit goes to: Jonas Schnelli, Greg Maxwell and Adam Weiss

Miners can become faster at assembling blocks

Previously, block template creation has been quite expensive for miners, requiring high computation time and considerable memory. The so-called high computation time means that miners need to perform consensus critical calculations for block verification while assembling blocks. The high memory requirement is because when assembling blocks, each transaction in a node's memory pool needs to put its inputs into the in-memory cache for various calculations.

In version 0.12, consensus critical calculation is no longer a one-time execution process during the block assembly process. Instead, once all these transactions are entered into the memory pool, they will be pre-calculated and cached. This means that during the assembly process, most of the calculations have been executed, and the block template can be generated very quickly. Specifically, the assembly time will be shortened from several seconds to tens of milliseconds.

This pre-calculation means that the input of all transactions in a node’s memory pool no longer enters the cache at once, thereby reducing the demand for memory.

Credit goes to: Alex Morcos

Conclusion:

The release of version 0.12 will be a major step forward for the Bitcoin Core client. However, the current development team still has a lot of work to do, and Bitcoin Core is always looking for more contributors. For more details, please refer to the Bitcoin Core contribution page, especially CONTRIBUTING.md. Download version 0.12 at:

Download from https://bitcoin.org/bin/bitcoin-core-0.12.0/.

Original text: https://bitcoincore.org/en/2016/02/23/release-0.12.0/
Author: Bitcoin Core Development Team
Compiled by: Satuoxi
Source (translation): Babbitt Information (http://www.8btc.com/release-0-12-0)