We are pleased to release Litecoin Core 0.15.0.1 release candidate. This is a new major version release, including new features, various bugfixes and performance improvements, as well as updated translations.
It is recommended for power users to upgrade to this version. After sufficient testing, Litecoin Core v0.15.0.1 final will be released and is recommended for all users to upgrade.
Version 0.15 contains a number of significant performance improvements, which make Initial Block Download, startup, transaction and block validation much faster:
- The chainstate database (which is used for tracking UTXOs) has been changed from a per-transaction model to a per-output model (See PR 10195). Advantages of this model are that it:
- avoids the CPU overhead of deserializing and serializing the unused outputs;
- has more predictable memory usage;
- uses simpler code;
- is adaptable to various future cache flushing strategies.
- As a result, validating the blockchain during Initial Block Download (IBD) and reindex is ~30–40% faster, uses 10–20% less memory, and flushes to disk far less frequently. The only downside is that the on-disk database is 15% larger. During the conversion from the previous format a few extra gigabytes may be used.
- Earlier versions experienced a spike in memory usage while flushing UTXO updates to disk. As a result, only half of the available memory was actually used as cache, and the other half was reserved to accommodate flushing. This is no longer the case (See PR 10148), and the entirety of the available cache (see -dbcache) is now actually used as cache. This reduces the flushing frequency by a factor 2 or more.
- In previous versions, signature validation for transactions has been cached when the transaction is accepted to the mempool. Version 0.15 extends this to cache the entire script validity (See PR 10192). This means that if a transaction in a block has already been accepted to the mempool, the scriptSig does not need to be re-evaluated. Empirical tests show that this results in new block validation being 40–50% faster.
- LevelDB has been upgraded to version 1.20 (See PR 10544). This version contains hardware acceleration for CRC on architectures supporting SSE 4.2. As a result, synchronization and block validation are now faster.
- SHA256 hashing has been optimized for architectures supporting SSE 4 (See PR 10821). SHA256 is around 50% faster on supported hardware, which results in around 5% faster IBD and block validation. In version 0.15, SHA256 hardware optimization is disabled in release builds by default, but can be enabled by using –enable-experimental-asm when building.
- Refill of the keypool no longer flushes the wallet between each key which resulted in a ~20x speedup in creating a new wallet. Part of this speedup was used to increase the default keypool to 1000 keys to make recovery more robust. (See PR 10831).
- Scrypt hashing has been optimized for architectures supporting SSE 2 (See PR 362). This boosts scrypt hashing performance by a factor of 2. In version 0.15, scrypt hardware optimization is disabled in release builds by default, but can be enabled by using –enable-sse2 when building.
Fee Estimation Improvements
Fee estimation has been significantly improved in version 0.15, with more accurate fee estimates used by the wallet and a wider range of options for advanced users of the estimatesmartfee and estimaterawfee RPCs (See PR 10199).
Changes to internal logic and wallet behavior
- Internally, estimates are now tracked on 3 different time horizons. This allows for longer targets and means estimates adjust more quickly to changes in conditions.
- Estimates can now be conservative or economical. Conservative estimates use longer time horizons to produce an estimate which is less susceptible to rapid changes in fee conditions. Economical estimates use shorter time horizons and will be more affected by short-term changes in fee conditions. Economical estimates may be considerably lower during periods of low transaction activity (for example over weekends), but may result in transactions being unconfirmed if prevailing fees increase rapidly.
- By default, the wallet will use conservative fee estimates to increase the reliability of transactions being confirmed within the desired target. For transactions that are marked as replaceable, the wallet will use an economical estimate by default, since the fee can be ‘bumped’ if the fee conditions change rapidly (See PR 10589).
- Estimates can now be made for confirmation targets up to 1008 blocks (one week).
- More data on historical fee rates is stored, leading to more precise fee estimates.
- Transactions which leave the mempool due to eviction or other non-confirmed reasons are now taken into account by the fee estimation logic, leading to more accurate fee estimates.
- The fee estimation logic will make sure enough data has been gathered to return a meaningful estimate. If there is insufficient data, a fallback default fee is used.
Changes to fee estimate RPCs
- The estimatefee RPC is now deprecated in favor of using only estimatesmartfee (which is the implementation used by the GUI)
- The estimatesmartfee RPC interface has been changed (See PR 10707):
- The nblocks argument has been renamed to conf_target (to be consistent with other RPC methods).
- An estimate_mode argument has been added. This argument takes one of the following strings: CONSERVATIVE, ECONOMICAL or UNSET (which defaults to CONSERVATIVE).
- The RPC return object now contains an errors member, which returns errors encountered during processing.
- If Litecoin Core has not been running for long enough and has not seen enough blocks or transactions to produce an accurate fee estimation, an error will be returned (previously a value of -1 was used to indicate an error, which could be confused for a feerate).
- A new estimaterawfee RPC is added to provide raw fee data. External clients can query and use this data in their own fee estimation logic.
Opt into RBF When Sending
A new startup option, -walletrbf, has been added to allow users to have all transactions sent opt into RBF support. The default value for this option is currently false, so transactions will not opt into RBF by default. The new bumpfee RPC can be used to replace transactions that opt into RBF.
Replace-by-fee control in the GUI
In version 0.15, creating an opt-in RBF transaction and replacing the unconfirmed transaction with a higher-fee transaction are both supported in the GUI (See PR 9592).
Multi-wallet is enabled by using more than one -wallet argument when starting Litecoin, either on the command line or in the Litecoin config file.
In Litecoin-Qt, only the first wallet will be displayed and accessible for creating and signing transactions. GUI selectable multiple wallets will be supported in a future version. However, even in 0.15 other loaded wallets will remain synchronized to the node’s current tip in the background. This can be useful if running a pruned node, since loading a wallet where the most recent sync is beyond the pruned height results in having to download and revalidate the whole blockchain. Continuing to synchronize all wallets in the background avoids this problem.
Litecoin Core 0.15.0 contains the following changes to the RPC interface and litecoin-cli for multi-wallet:
- When running Litecoin Core with a single wallet, there are no changes to the RPC interface or litecoin-cli. All RPC calls and litecoin-cli commands continue to work as before.
- When running Litecoin Core with multi-wallet, all node-level RPC methods continue to work as before. HTTP RPC requests should be send to the normal <RPC IP address>:<RPC port>/ endpoint, and litecoin-cli commands should be run as before. A node-level RPC method is any method which does not require access to the wallet.
- When running Litecoin Core with multi-wallet, wallet-level RPC methods must specify the wallet for which they’re intended in every request. HTTP RPC requests should be send to the <RPC IP address>:<RPC port>/wallet/<wallet name>/ endpoint, for example 127.0.0.1:9332/wallet/wallet1.dat/. litecoin-cli commands should be run with a -rpcwallet option, for example litecoin-cli -rpcwallet=wallet1.dat getbalance.
- A new node-level listwallets RPC method is added to display which wallets are currently loaded. The names returned by this method are the same as those used in the HTTP endpoint and for the rpcwallet argument.
Note that while multi-wallet is now fully supported, the RPC multi-wallet interface should be considered unstable for version 0.15.0, and there may backwards-incompatible changes in future versions.
Removal of Coin Age Priority
In previous versions of Litecoin Core, a portion of each block could be reserved for transactions based on the age and value of UTXOs they spent. This concept (Coin Age Priority) is a policy choice by miners, and there are no consensus rules around the inclusion of Coin Age Priority transactions in blocks. In practice, only a few miners continue to use Coin Age Priority for transaction selection in blocks. Litecoin Core 0.15 removes all remaining support for Coin Age Priority (See PR 9602). This has the following implications:
- The concept of free transactions has been removed. High Coin Age Priority transactions would previously be allowed to be relayed even if they didn’t attach a miner fee. This is no longer possible since there is no concept of Coin Age Priority. The -limitfreerelay and -relaypriority options which controlled relay of free transactions have therefore been removed.
- The -sendfreetransactions option has been removed, since almost all miners do not include transactions which do not attach a transaction fee.
- The -blockprioritysize option has been removed.
- The estimatepriority and estimatesmartpriority RPCs have been removed.
- The getmempoolancestors, getmempooldescendants, getmempoolentry and getrawmempool RPCs no longer return startingpriority and currentpriority.
- The prioritisetransaction RPC no longer takes a priority_delta argument, which is replaced by a dummy argument for backwards compatibility with clients using positional arguments. The RPC is still used to change the apparent fee-rate of the transaction by using the fee_delta argument.
- – can now be set to 0. If minrelaytxfee is set, then fees smaller than minrelaytxfee (per kB) are rejected from relaying, mining and transaction creation. This defaults to 1000 satoshi/kB.
- The -printpriority option has been updated to only output the fee rate and hash of transactions included in a block by the mining code.
Mempool Persistence Across Restarts
Version 0.14 introduced mempool persistence across restarts (the mempool is saved to a mempool.dat file in the data directory prior to shutdown and restores the mempool when the node is restarted). Version 0.15 allows this feature to be switched on or off using the -persistmempool command-line option (See PR 9966). By default, the option is set to true, and the mempool is saved on shutdown and reloaded on startup. If set to false, the mempool.dat file will not be loaded on startup or saved on shutdown.
New RPC methods
Version 0.15 introduces several new RPC methods:
- abortrescan stops current wallet rescan, e.g. when triggered by an importprivkey call (See PR 10208).
- combinerawtransaction accepts a JSON array of raw transactions and combines them into a single raw transaction (See PR 10571).
- estimaterawfee returns raw fee data so that customized logic can be implemented to analyze the data and calculate estimates. See Fee Estimation Improvements for full details on changes to the fee estimation logic and interface.
- getchaintxstats returns statistics about the total number and rate of transactions in the chain (See PR 9733).
- listwallets lists wallets which are currently loaded. See the Multi-wallet section of these release notes for full details (See Multi-wallet support).
- uptime returns the total runtime of the bitcoind server since its last start (See PR 10400).
Low-level RPC changes
- When using Litecoin Core in multi-wallet mode, RPC requests for wallet methods must specify the wallet that they’re intended for. See Multi-wallet support for full details.
- The new database model no longer stores information about transaction versions of unspent outputs (See Performance improvements). This means that:
- The gettxout RPC no longer has a version field in the response.
- The gettxoutsetinfo RPC reports hash_serialized_2 instead of hash_serialized, which does not commit to the transaction versions of unspent outputs, but does commit to the height and coinbase information.
- The getutxos REST path no longer reports the txvers field in JSON format, and always reports 0 for transaction versions in the binary format
- The estimatefee RPC is deprecated. Clients should switch to using the estimatesmartfee RPC, which returns better fee estimates. See Fee Estimation Improvements for full details on changes to the fee estimation logic and interface.
- The gettxoutsetinfo response now contains disk_size and bogosize instead of bytes_serialized. The first is a more accurate estimate of actual disk usage, but is not deterministic. The second is unrelated to disk usage, but is a database-independent metric of UTXO set size: it counts every UTXO entry as 50 + the length of its scriptPubKey (See PR 10426).
- signrawtransaction can no longer be used to combine multiple transactions into a single transaction. Instead, use the new combinerawtransaction RPC (See PR 10571).
- fundrawtransaction no longer accepts a reserveChangeKey option. This option used to allow RPC users to fund a raw transaction using an key from the keypool for the change address without removing it from the available keys in the keypool. The key could then be re-used for a getnewaddress call, which could potentially result in confusing or dangerous behaviour (See PR 10784).
- estimatepriority and estimatesmartpriority have been removed. See Removal of Coin Age Priority.
- The listunspent RPC now takes a query_options argument (see PR 8952), which is a JSON object containing one or more of the following members:
- minimumAmount – a number specifying the minimum value of each UTXO
- maximumAmount – a number specifying the maximum value of each UTXO
- maximumCount – a number specifying the minimum number of UTXOs
- minimumSumAmount – a number specifying the minimum sum value of all UTXOs
- The getmempoolancestors, getmempooldescendants, getmempoolentry and getrawmempool RPCs no longer return startingpriority and currentpriority. See Removal of Coin Age Priority.
- The dumpwallet RPC now returns the full absolute path to the dumped wallet. It used to return no value, even if successful (See PR 9740).
- In the getpeerinfo RPC, the return object for each peer now returns an addrbind member, which contains the ip address and port of the connection to the peer. This is in addition to the addrlocal member which contains the ip address and port of the local node as reported by the peer (See PR 10478).
- The disconnectnode RPC can now disconnect a node specified by node ID (as well as by IP address/port). To disconnect a node based on node ID, call the RPC with the new nodeid argument (See PR 10143).
- The second argument in prioritisetransaction has been renamed from priority_delta to dummy since Bitcoin Core no longer has a concept of coin age priority. The dummy argument has no functional effect, but is retained for positional argument compatibility. See Removal of Coin Age Priority.
- The resendwallettransactions RPC throws an error if the -walletbroadcast option is set to false (See PR 10995).
- The second argument in the submitblock RPC argument has been renamed from parameters to dummy. This argument never had any effect, and the renaming is simply to communicate this fact to the user (See PR 10191) (Clients should, however, use positional arguments for submitblock in order to be compatible with BIP 22.)
- The verbose argument of getblock has been renamed to verbosity and now takes an integer from 0 to 2. Verbose level 0 is equivalent to verbose=false. Verbose level 1 is equivalent to verbose=true. Verbose level 2 will give the full transaction details of each transaction in the output as given by getrawtransaction. The old behavior of using the verbose named argument and a boolean value is still maintained for compatibility.
- Error codes have been updated to be more accurate for the following error cases (See PR 9853):
- getblock now returns RPC_MISC_ERROR if the block can’t be found on disk (for example if the block has been pruned). Previously returned RPC_INTERNAL_ERROR.
- pruneblockchain now returns RPC_MISC_ERROR if the blocks cannot be pruned because the node is not in pruned mode. Previously returned RPC_METHOD_NOT_FOUND.
- pruneblockchain now returns RPC_INVALID_PARAMETER if the blocks cannot be pruned because the supplied timestamp is too late. Previously returned RPC_INTERNAL_ERROR.
- pruneblockchain now returns RPC_MISC_ERROR if the blocks cannot be pruned because the blockchain is too short. Previously returned RPC_INTERNAL_ERROR.
- setban now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the supplied IP address or subnet is invalid. Previously returned RPC_CLIENT_NODE_ALREADY_ADDED.
- setban now returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the user tries to unban a node that has not previously been banned. Previously returned RPC_MISC_ERROR.
- removeprunedfunds now returns RPC_WALLET_ERROR if bitcoind is unable to remove the transaction. Previously returned RPC_INTERNAL_ERROR.
- removeprunedfunds now returns RPC_INVALID_PARAMETER if the transaction does not exist in the wallet. Previously returned RPC_INTERNAL_ERROR.
- fundrawtransaction now returns RPC_INVALID_ADDRESS_OR_KEY if an invalid change address is provided. Previously returned RPC_INVALID_PARAMETER.
- fundrawtransaction now returns RPC_WALLET_ERROR if bitcoind is unable to create the transaction. The error message provides further details. Previously returned RPC_INTERNAL_ERROR.
- bumpfee now returns RPC_INVALID_PARAMETER if the provided transaction has descendants in the wallet. Previously returned RPC_MISC_ERROR.
- bumpfee now returns RPC_INVALID_PARAMETER if the provided transaction has descendants in the mempool. Previously returned RPC_MISC_ERROR.
- bumpfee now returns RPC_WALLET_ERROR if the provided transaction has has been mined or conflicts with a mined transaction. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
- bumpfee now returns RPC_WALLET_ERROR if the provided transaction is not BIP 125 replaceable. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
- bumpfee now returns RPC_WALLET_ERROR if the provided transaction has already been bumped by a different transaction. Previously returned RPC_INVALID_REQUEST.
- bumpfee now returns RPC_WALLET_ERROR if the provided transaction contains inputs which don’t belong to this wallet. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
- bumpfee now returns RPC_WALLET_ERROR if the provided transaction has multiple change outputs. Previously returned RPC_MISC_ERROR.
- bumpfee now returns RPC_WALLET_ERROR if the provided transaction has no change output. Previously returned RPC_MISC_ERROR.
- bumpfee now returns RPC_WALLET_ERROR if the fee is too high. Previously returned RPC_MISC_ERROR.
- bumpfee now returns RPC_WALLET_ERROR if the fee is too low. Previously returned RPC_MISC_ERROR.
- bumpfee now returns RPC_WALLET_ERROR if the change output is too small to bump the fee. Previously returned RPC_MISC_ERROR.
Please use GPG to verify the integrity of the release binaries. This ensures that the binary you have downloaded has not been tampered with. Linux, MacOS and Win32 cygwin command line GPG instructions are available here. Please also note that we GPG sign the binaries as a convenience to you, the ultimate way to verify the integrity of the builds is to build them yourself using Gitian. Instructions on how to perform these builds, can be found here.
For this release, the binaries have been signed with key identifier FE3348877809386C (thrasher’s key).
Despite this version being heavily tested, this version may still contain bugs. Always backup your wallet.dat file before upgrading. If you encounter any issues, please let us know by posting to the bug reporting section below.
Source code & Build instructions
The master branch contains the latest commits to the next stable releases of Litecoin Core.
Build instructions for Linux can be found here.
Build instructions for OSX can be found here.
Submit any issues you encounter here and one of the Litecoin developers will assist you.
Sign up for announcements only or development discussion.
Hashes for verification
These are the SHA-256 hashes of the released files:
Thanks to everyone who directly contributed to this release:
- The Bitcoin Core Developers
- Adrian Gallagher