Today marks the official release of Bitcoin Core 0.14.0, the fourteenth generation of Bitcoin’s original software client launched by Satoshi Nakamoto eight years ago. Overseen by Bitcoin Core lead maintainer Wladimir van der Laan, this latest major release was developed by nearly 100 contributors over a six-month period.
Bitcoin Core 0.14.0 features a significant list of improvements. Compared to some previous releases, however, most of these concern “internals” of the software: performance improvements that take place under the hood but may not be very noticeable for everyday users.
That said, here are some of the more notable changes.
“Assumevalid” Blocks
Whenever a new node bootstraps on the network, it syncs the entire blockchain. It downloads and verifies all blocks that were ever mined, and verifies all transactions in all of these blocks. Unfortunately, this can take quite some time. Even new, high-end laptops often require more than a full day to catch up. For older or lower-grade machines, it takes even longer.
“Assumevalid” significantly speeds up this process. In essence, Bitcoin Core 0.14.0 nodes assume that all transactions up to a certain block are valid. While a syncing node still verifies the proof of work for all blocks, and records the entire transaction history, it no longer checks signatures and similar data for each individual transaction.
The assumption as to which block is valid is configurable. By default, it’s block 453354 for Bitcoin Core 0.14.0. But users who do want to fully verify every single transaction, even those dating years back, still can.
It’s also worth noting that, as opposed to a checkpointing system that establishes that a specific block must be part of the blockchain, the assumed valid block is not necessarily binding. A Bitcoin Core 0.14.0 node will readily switch to an alternative blockchain without the assumed valid block, if that alternative blockchain is longer.
Improved Fee Estimation
As Bitcoin blocks have been filling up, particularly over the last year, not all transactions sent over the network fit into the very next block. As a result, miners usually prioritize transactions that include the most fees. Transactions that include more fees have a higher chance of being included in the very next block or shortly thereafter. Transactions that include lower fees are outbid and take longer to confirm.
Of course, not everyone needs their transactions to confirm as quickly. Users who send bitcoins to an exchange because of rapid price movements may be in a rush to have their transactions confirmed. Meanwhile, users who move bitcoins between their own wallets may be more patient.
Since Bitcoin Core 0.10.0, users have been able to adjust their fees accordingly. They can manually include higher fees if they are in more of a rush, and lower fees if they are not. Bitcoin Core 0.11.0 and 0.12.0 both refined the fee estimation software, and Bitcoin 0.14.0 now includes another set of improvements, which in particular makes the algorithm more robust in edge case situations.
Additionally, the default confirmation target was decreased from 25 blocks to 6 blocks; most transactions made from Bitcoin Core should confirm within an hour even if the user doesn’t touch the fee settings.
Opt-In Replace-by-Fee for Sending
In addition to the improved fee estimation, Bitcoin Core 0.14.0 users have another option to speed up their transactions.
First introduced a year ago with the release of Bitcoin Core 0.12.0, Bitcoin transactions can be marked with a “replace-by-fee” flag. Senders of a transaction can replace their initial transaction with a newer transaction that includes a higher fee. This allows them to “skip the line” and have their transaction confirmed faster.
Up until this point, Bitcoin Core only included opt-in replace-by-fee in the node behavior: it accepted and forwarded transactions with replace-by-fee flags (instead of rejecting them as double-spends). But Bitcoin Core users could not utilize opt-in replace-by-fee to bump their own fees; so far only users of wallets like Electrum or GreenAddress could.
Now, opt-in replace-by-fee has been added as a remote procedure call (RPC) option in Bitcoin Core 0.14.0. This means that users working from the command line, or on applications built on Bitcoin Core, can utilize replace-by-fee, too.
Manual Pruning
Bitcoin’s blockchain is over 100 gigabytes in size and at its current rate is growing about 50 gigabytes each year. All that data needs to be stored, which can present a significant burden for users running a full node.
That’s why Bitcoin Core 0.11.0 introduced blockchain pruning. Users can get rid of older blocks once they are verified, so running a full node doesn’t require as much disk space.
But up till now, users could only prune starting from a fixed number of blocks. With pruning set at 1000 blocks, for example, Bitcoin Core kept exactly the latest 1000 blocks. Whenever a new block was added, the oldest block was discarded, to keep the total at 1000.
Unfortunately, this meant that certain applications relying on Bitcoin Core couldn’t really utilize pruning. For example, a payment processing application — for merchants that want to accept bitcoin but prefer not to rely on external services like BitPay or Coinbase — may in some cases need to figure out whether a valid payment was made in an older block. If that block is already pruned, the application can’t do its job.
Bitcoin Core 0.14.0 therefore allows for more specific pruning. Instead of keeping a set number of blocks, users can prune the blockchain starting from a specific point in time, a specific block height, and keep all blocks that were created since.
Combined with another new feature called “importmulti,” Bitcoin Core 0.14.0 can import and timestamp addresses, for example, from the aforementioned payment processing application. Using the timestamps to establish when a specific address was created, Bitcoin Core knows from which point in time blocks are relevant for the application and won’t prune these blocks.
Block Relay Improvements
Whenever a new block is mined, it is transmitted over Bitcoin’s peer-to-peer network, until each node received it. Unfortunately, latency on this network can benefit pooled mining as well as geographic clusters of miners, incentivizing a more centralized mining topology.
Increasing block propagation speed has therefore been a central point of focus for the Bitcoin Core development team for some years now, and Bitcoin Core 0.14.0 includes another batch of improvements.
Perhaps most important, Bitcoin Core 0.14.0 nodes forward blocks to their peers sooner. Where nodes would previously verify a block in its entirety before sending it to connected nodes, Bitcoin Core 0.14.0 starts the forwarding process as soon as the proof of work checks out.
While many miners today do use alternative relay networks as well, increasing speed on Bitcoin’s peer-to-peer network reduces the reliance on these networks and even benefits these relay networks where they connect to the peer-to-peer network.
And …
As mentioned, the improvements listed above are really only the tip of the iceberg. Bitcoin Core 0.14.0 includes a list of additional performance improvements, varying from low-level RPC changes, to changes in the graphical user interface (GUI), and anything in between. For a full overview of all improvements, see the Bitcoin Core 0.14.0 release notes.
You can download Bitcoin Core 0.14.0 from bitcoincore.org or bitcoin.org.