We’re very excited to announce the official release of Bitcoin Core v0.12.0. A lot of hard work has gone into this release and it may just be the biggest one yet, with more significant improvements than any other before.
Here are the major improvements you’ll get to benefit from if you upgrade your nodes to version 0.12:
- 7x Faster Signature Validation
- Ability to Limit Upload Traffic
- Crash Prevention via Memory Pool Limits
- Option to Send Transactions That Can Be Fee-Boosted
- Automatic Usage of Tor When it’s Running
- Ability for Apps to Subscribe to Notifications With ZeroMQ
- Massively Reduced Disk Usage for Wallets
- Much Faster Block Assembly for Miners
In addition to these, there are 13 other improvements that didn’t make the top list but are nonetheless quite valuable. You can find a complete list of them at the end of this post.
Now, let’s go and take a deeper dive into each of these improvements.
7x Faster Signature Validation
In Bitcoin Core, OpenSSL was traditionally used to validate ECDSA signatures in Bitcoin transactions. OpenSSL is very comprehensive in its capabilities (doing much more than simply validating ECDSA signatures), but this enormous feature set means that its attack surface is fairly large as a result. Because of the threat this represents to Bitcoin security, it became a priority to de-couple OpenSSL from Bitcoin Core and replace it with a simpler, more focused alternative.
To address this issue, a new ECDSA signature validation library called libsecp256k1 has been developed by members of the Bitcoin Core team and plugged in as a replacement for OpenSSL. It is the result of almost 3 years of complex engineering, and with this integration, the attack surface for signature validation code has been greatly reduced.
Further, libsecp256k1’s signature validation is much faster than that performed by OpenSSL. It is up to 7x faster on 64-bit architecture, and raw reindexing and block validation now takes less than half the time it did before - a major step forward for validating Bitcoin transactions.
Credits: Pieter Wuille, Greg Maxwell, and Cory Fields
Ability to Limit Upload Traffic
Node upload traffic can be burdensome for some users, so the ability to put limitations on such traffic is a much-needed improvement. Node users now have the ability to set soft limits on how much data they upload and serve to their peers. Users can set a parameter that specifies how much data the node should target to be served daily. It will try to stay below the limit, rather than hit it, and if it hits the limit it will only serve blocks requested within the last week.
Credits: Jonas Schnelli
Crash Prevention via Memory Pool Limits
Older versions of Bitcoin Software had no limit on the number of transactions they would allow into their memory pool. Even though nodes will only accept transactions that have a certain specified minimum relay fee, at times the number of transactions that meet those requirements will get arbitrarily large and cause nodes with relatively low RAM to crash. Particularly concerning is that attackers can take advantage of this system by flooding the network with transactions in order to crash a subset of nodes.
With this update, nodes now have default limitations on the size of their memory pools and the operator can configure this to the amount of memory they want to dedicate to the mempool. When the memory limit is reached, new transactions can still be accepted, while transactions with the lowest fees will be dropped from the mempool. This new memory limitation ensures that unexpected crashes will not happen due to the number of cached transactions getting out of hand.
Credits: Matt Corallo and Suhas Daftuar
Option to Send Transactions That Can Be Fee-Boosted
Transactions often get stuck if they have fees that are too low. This can cause problems because unspent transactions outputs (UTXOs) that were used in those transactions can be hard to spend, potentially freezing funds. Appropriate transaction fees are hard to calculate because they are highly dependent on the volume of transactions and their fees at any given time. Thus, one either typically underestimates, resulting in many stuck transactions or overestimates, resulting in a massive overpayment and a steady loss of funds.
A new feature called Opt-in Replace-by-Fee gives transaction senders the option to configure their transactions to be able to be replaced later by other transactions that specify larger fees. Senders can start with a low fee and see if their transaction gets accepted, and if not they can increase their fee until it gets accepted. This allows senders to both minimize the fees they pay and maximize the chance that their transactions will be included in a block.
Credits: Peter Todd and Suhas Daftuar
Automatic Usage of Tor When it’s Running
Nodes will now detect whether Tor is running and if it is they will automatically create Tor hidden services and connect to other nodes through the Tor network. No manual configuration is required.
Credits: Wladimir van der Laan
Ability for Apps to Subscribe to Notifications With ZeroMQ
Up until now, there has been limited support for external services to subscribe to notifications about the arrival of new blocks and incoming transactions. Services now have this ability thanks to an integration with ZeroMQ.
Credits: Johnathan Corgan
Massively Reduced Disk Usage for Wallets
Users of the Bitcoin Core wallet often feel the burden of the high data storage requirements that come with running a full node (which is now up to 60GB and continues to rise). For users who have limitations on storage capacity and still want to use a wallet with a full node, they now have the ability to run their wallet in pruned mode. This means that the node will only focus on keeping track of unspent outputs and will forget previously-processed blocks as well as outputs that have been spent. This in turn means users will be able to run a full node while only storing around 2GB of data, a massive reduction from the previously-required 60GB.
Credits: Jonas Schnelli, Greg Maxwell, and Adam Weiss
Much Faster Block Assembly for Miners
Traditionally, block template creation has been quite expensive for miners, requiring high computation times and quite a bit of memory. The high computation time is a consequence of the fact that historically, miners have had to perform consensus critical calcuations for block validation simultaneously while they assemble a block. The high memory requirements have been due to the fact that historically during block assembly, every transaction in one’s memory pool would need to have its inputs pulled into an in-memory cache for various calculations.
With the 0.12 release, consensus-critical calculations pertaining to individual transactions are no longer performed all at once during block assembly, but are pre-calculated on all transactions as soon as they hit the memory pool and then cached. This means that during block assembly, most of the calculations have already been performed and the block template can be created extremely quickly. Specifically, this represents a time reduction from an interval measured in seconds to one measured in tens of milliseconds.
The pre-calculations that are peformed also mean that the inputs of all the transactions in one’s memory pool no longer have to be pulled into the cache all at once, leading to a sizeable reduction in memory requirements.
Credits: Alex Morcos
Closing Word
The release of Version 0.12 will be a major move forward for the Bitcoin Core client. However, there is still much more to do and we’re always looking for more contributors. For more details see our contributing page and specifically CONTRIBUTING.md. There are many other ways to contribute too - just ask others how you can help out (see community resources below).
Download from https://bitcoin.org/bin/bitcoin-core-0.12.0/.
The Bitcoin Core Development Team
v0.12 Resources
Community Resources
IRC Community:
Join the #bitcoin-dev and #bitcoin-core-dev channels on irc.freenode.net.
Slack Community, sign up at slack.bitcoincore.org.
Twitter: Follow Bitcoin Core updates at @bitcoincoreorg
This blog post was written by Ryan Shea based on the official release notes.