We are pleased to announce the release of Bitcoin Core 0.15.0, which provides better fee estimates and more accessible fee bumping, initial support for multiple wallets in a single installation, and a number of significant performance improvements. Many bug fixes, optimizations, and other improvements are also included.
One of the performance optimizations in Bitcoin Core 0.15.0 is an update to the format of the database that tracks spendable bitcoins. The first time you start Bitcoin Core 0.15.0 (or a later version), it will automatically begin this update, which will take from about 5 minutes to 30 minutes depending on the speed of your computer.
Graphical users can monitor the progress of the update on the Bitcoin Core splash screen; bitcoind users can monitor it in the
debug.log file in their data directory.
If you later decide to downgrade to an earlier version of Bitcoin Core, please see the instructions in the release notes.
Better fee estimates
Evidence shows that users who are willing to wait just a few hours for their transactions to confirm can often save 80% or more in transaction fees over users who need rapid confirmation during periods of high demand.
Not only do these patient users save money, but they also help ensure Bitcoin miners always have plenty of fee-paying transactions to include in their blocks, which will be necessary to keep miners working on extending the Bitcoin block chain in the future as Bitcoin gets closer to the upper limit of 21 million bitcoins and transaction fees increasingly make up a greater share of miner income.
To help patient users get the best deal on transaction fees and rushed users get their transactions confirmed as quickly as possible, we’ve made several significant improvements to the built-in fee estimation algorithm and user interface in Bitcoin Core 0.15.0.
40x increase in maximum targets: the fee estimator can now provide reasonable estimates up to 1,008 blocks into the future (about 1 week), up from a previous maximum of 25 blocks (about 4 hours), allowing users making safe transfers between their own wallets and other non-urgent tasks to save as much as possible on transactions fees.
In order to expose this new increased range in the graphical user interface, the previous fee slider has been replaced by a fee dropdown:
More responsive: fee estimates now adjust faster to changing network conditions of higher or lower demand for block space. The algorithm makes multiple extrapolations of the transaction data and selects the best one automatically. For more information about the algorithm used, please see developer Alex Morcos’s description.
Lower fee estimates for RBF users: previously it was difficult to change the fee of unconfirmed transactions after broadcasting them, so Bitcoin Core suggested fees higher than normally needed. As described later in this post, Bitcoin Core now provides tools for increasing the fee of already-sent unconfirmed transactions, so we give lower fee estimates to users of those tools since they can always increase their fee later if necessary.
Programmers and command-line users automatically receive access to the improved fee estimation through their current RPC calls and can also use the new
estimatesmartfee RPC to get access to the advanced features described above. Note that the older
estimatefee RPC continues to work, but is now deprecated and will be removed in a subsequent release. For more information, run
bitcoin-cli help estimatesmartfee and see the release notes.
Graphical fee bumping
Bitcoin Core 0.14.0 introduced expert options to allow users to increase the amount of transaction fee they paid on their unconfirmed transactions, a process often called fee bumping.
This can allow frugal users to pay a very low transaction fee, wait a while to see if the transaction confirms at that fee, and then increase the fee if it hasn’t been included in any of the recent blocks. It also helps ensure that any user who accidentally pays too low a fee can later increase that fee to get the transaction confirmed.
In Bitcoin Core 0.15.0, this option is no longer just for experts. In the the fee options when sending a transaction using the graphical interface, users can now choose to “Request Replace-By-Fee”, allowing them to replace one version of an unconfirmed transaction with a later version that pays a higher fee.
If users enable this feature on a transaction, they can later go to the Transactions tab, right-click on the transaction, and select the “Increase transaction fee” option.
Both the original transaction and the replacement will be shown in the Transaction tab so you can see which one gets confirmed (it isn’t guaranteed that the higher-fee transaction will be confirmed, but it is guaranteed that only one of the transactions can be confirmed). Once one version of the transaction is confirmed, all other versions of the same transaction will be shown as failed.
You can repeat the fee bumping step as many times as you’d like until one version of the transaction confirms, and no matter how many replacements you create, only one version of the transaction will be confirmed.
Users who want to request Replace-By-Fee (RBF) by default can start Bitcoin Core with the
-walletrbf option or add
walletrbf=1 to their configuration file. Note that some services that accept unconfirmed transactions as finalized payments may not accept replace-by-fee transactions as final until they confirm; for more information about opt-in replace by fee, please see the RBF FAQ.
In Bitcoin Core 0.15.0, a single running Bitcoin Core program can now manage multiple wallets with ease. This feature is still new and only accessible to expert users, but we hope to make it available in the graphical user interface in the future.
You can use the new multiwallet mode to,
Use one wallet for your business and one wallet for your personal use in order to simplify your accounting and prevent accidental misuse of funds.
Separate bitcoins that are associated with your identity from bitcoins that can’t be traced back to you in order to help protect your privacy. Each wallet uses completely different private keys and will never automatically mix its bitcoins with bitcoins from another wallet, preventing taint analysis from connecting those two wallets.
Manage a Bitcoin backend for an organization in much the same way that has been historically possible with the now-deprecated Bitcoin Core accounts features. As a simple example, if you handle small bitcoin balances for your less-experienced friends and family, you can now manage each person’s bitcoins in a separate wallet rather than risking mixing them up with your own bitcoins.
These features are currently only available through the RPC interface for programmers and command-line users, and the API for them may change in future versions. Please see the bottom of this post for information about how to contribute to development if you’d like to help improve multiwallet mode and make it available in the graphical interface. For more information about multiwallet mode, please see the release notes.
As part of the continuing effort to make full nodes available to as many users as possible even as the block chain continues to grow in size and complexity, Bitcoin Core 0.15.0 includes several significant performance improvements.
30% to 40% faster block validation and 10% to 20% less memory used on tests of Initial Block Download (IBD), with far fewer writes to disk. This is the result of simplifying the format of the the chainstate database that tracks each spendable group of bitcoins and what information the owner of those bitcoins needs to provide in order to spend them.
40% to 50% faster validation of blocks consisting of previously-seen transactions as the result of repeating fewer validation steps when a previously-verified mempool transaction is later received in a block.
Moderate performance gains on some platforms as the result of using hardware acceleration for some operations, such as support on modern computer processors for the consistency-checking operation used by the chainstate database. This mainly benefits users of 64-bit Intel and AMD processors produced in 2008 or later.
More information on each of these improvements may be found in the release notes.
The future: P2SH-wrapped segwit addresses
As final preparations are being made to release Bitcoin Core 0.15.0, segregated witness has activated on the Bitcoin network and is now ready to use.
Bitcoin Core has supported creating segwit addresses since 0.13.0, but this support was designed for testing has only been available to expert users—we were waiting to see if segwit was adopted before adding segwit support to the regular user interfaces, both graphical and RPC.
The timing of segwit lock in and activation meant that we had to choose between either delaying the planned release of 0.15.0 and all its features described above or shipping 0.15.0 without a user interface defaulting to segwit.
We decided to take the later option, but we’re also not going to wait the normal six months before the next major update. Instead, our next feature release will generate segwit-compatible addresses by default. This will be made available as soon as it has been written and thoroughly tested.
For those of you interested in technical details, our plan is to use P2SH-wrapped segwit addresses that are compatible with nearly all other wallets on the network. We may support sending to Bech32 native segwit addresses generated by other wallets, but the graphical user interface will probably not support generating Bech32 addresses itself until a subsequent release.
If you are interested in contributing to Bitcoin Core, please see our contributing page and the document How to contribute code to Bitcoin Core. If you don’t know where to get started or have any other questions, please stop by our IRC chatroom and we’ll do our best to help you.
Hashes for verification