Litecoin Core v0.15.0.1
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
- 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
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
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
estimatefeeRPC is now deprecated in favor of using only
estimatesmartfee(which is the implementation used by the GUI)
estimatesmartfeeRPC interface has been changed (See PR 10707):
nblocksargument has been renamed to
conf_target(to be consistent with other RPC methods).
estimate_modeargument has been added. This argument takes one of the following strings:
UNSET(which defaults to
- The RPC return object now contains an
errorsmember, 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
estimaterawfeeRPC 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-clicommands 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-clicommands 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
litecoin-clicommands should be run with a
-rpcwalletoption, for example
litecoin-cli -rpcwallet=wallet1.dat getbalance.
- A new node-level
listwalletsRPC 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
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
-relaypriorityoptions which controlled relay of free transactions have therefore been removed.
-sendfreetransactionsoption has been removed, since almost all miners do not include transactions which do not attach a transaction fee.
-blockprioritysizeoption has been removed.
estimatesmartpriorityRPCs have been removed.
getrawmempoolRPCs no longer return
prioritisetransactionRPC no longer takes a
priority_deltaargument, which is replaced by a
dummyargument 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
-can now be set to 0. If
minrelaytxfeeis set, then fees smaller than
minrelaytxfee(per kB) are rejected from relaying, mining and transaction creation. This defaults to 1000 satoshi/kB.
-printpriorityoption 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.datfile will not be loaded on startup or saved on shutdown.
New RPC methods
Version 0.15 introduces several new RPC methods:
abortrescanstops current wallet rescan, e.g. when triggered by an
importprivkeycall (See PR 10208).
combinerawtransactionaccepts a JSON array of raw transactions and combines them into a single raw transaction (See PR 10571).
estimaterawfeereturns 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.
getchaintxstatsreturns statistics about the total number and rate of transactions in the chain (See PR 9733).
listwalletslists wallets which are currently loaded. See the Multi-walletsection of these release notes for full details (See Multi-wallet support).
uptimereturns the total runtime of the
litecoindserver 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:
gettxoutRPC no longer has a
versionfield in the response.
hash_serialized, which does not commit to the transaction versions of unspent outputs, but does commit to the height and coinbase information.
getutxosREST path no longer reports the
txversfield in JSON format, and always reports 0 for transaction versions in the binary format
estimatefeeRPC is deprecated. Clients should switch to using the
estimatesmartfeeRPC, which returns better fee estimates. See Fee Estimation Improvements for full details on changes to the fee estimation logic and interface.
gettxoutsetinforesponse now contains
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).
signrawtransactioncan no longer be used to combine multiple transactions into a single transaction. Instead, use the new
combinerawtransactionRPC (See PR 10571).
fundrawtransactionno longer accepts a
reserveChangeKeyoption. 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
getnewaddresscall, which could potentially result in confusing or dangerous behaviour (See PR 10784).
estimatesmartpriorityhave been removed. See Removal of Coin Age Priority.
listunspentRPC now takes a
query_optionsargument (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
getrawmempoolRPCs no longer return
currentpriority. See Removal of Coin Age Priority.
dumpwalletRPC now returns the full absolute path to the dumped wallet. It used to return no value, even if successful (See PR 9740).
- In the
getpeerinfoRPC, the return object for each peer now returns an
addrbindmember, which contains the ip address and port of the connection to the peer. This is in addition to the
addrlocalmember which contains the ip address and port of the local node as reported by the peer (See PR 10478).
disconnectnodeRPC 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
nodeidargument (See PR 10143).
- The second argument in
prioritisetransactionhas been renamed from
dummysince Litecoin Core no longer has a concept of coin age priority. The
dummyargument has no functional effect, but is retained for positional argument compatibility. See Removal of Coin Age Priority.
resendwallettransactionsRPC throws an error if the
-walletbroadcastoption is set to false (See PR 10995).
- The second argument in the
submitblockRPC argument has been renamed from
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
submitblockin order to be compatible with BIP 22.)
getblockhas been renamed to
verbosityand 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
verbosenamed 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):
getblocknow 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.
pruneblockchainnow returns RPC_MISC_ERROR if the blocks cannot be pruned because the node is not in pruned mode. Previously returned RPC_METHOD_NOT_FOUND.
pruneblockchainnow returns RPC_INVALID_PARAMETER if the blocks cannot be pruned because the supplied timestamp is too late. Previously returned RPC_INTERNAL_ERROR.
pruneblockchainnow returns RPC_MISC_ERROR if the blocks cannot be pruned because the blockchain is too short. Previously returned RPC_INTERNAL_ERROR.
setbannow returns RPC_CLIENT_INVALID_IP_OR_SUBNET if the supplied IP address or subnet is invalid. Previously returned RPC_CLIENT_NODE_ALREADY_ADDED.
setbannow 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.
removeprunedfundsnow returns RPC_WALLET_ERROR if
litecoindis unable to remove the transaction. Previously returned RPC_INTERNAL_ERROR.
removeprunedfundsnow returns RPC_INVALID_PARAMETER if the transaction does not exist in the wallet. Previously returned RPC_INTERNAL_ERROR.
fundrawtransactionnow returns RPC_INVALID_ADDRESS_OR_KEY if an invalid change address is provided. Previously returned RPC_INVALID_PARAMETER.
fundrawtransactionnow returns RPC_WALLET_ERROR if
litecoindis unable to create the transaction. The error message provides further details. Previously returned RPC_INTERNAL_ERROR.
bumpfeenow returns RPC_INVALID_PARAMETER if the provided transaction has descendants in the wallet. Previously returned RPC_MISC_ERROR.
bumpfeenow returns RPC_INVALID_PARAMETER if the provided transaction has descendants in the mempool. Previously returned RPC_MISC_ERROR.
bumpfeenow 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.
bumpfeenow returns RPC_WALLET_ERROR if the provided transaction is not BIP 125 replaceable. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
bumpfeenow returns RPC_WALLET_ERROR if the provided transaction has already been bumped by a different transaction. Previously returned RPC_INVALID_REQUEST.
bumpfeenow returns RPC_WALLET_ERROR if the provided transaction contains inputs which don’t belong to this wallet. Previously returned RPC_INVALID_ADDRESS_OR_KEY.
bumpfeenow returns RPC_WALLET_ERROR if the provided transaction has multiple change outputs. Previously returned RPC_MISC_ERROR.
bumpfeenow returns RPC_WALLET_ERROR if the provided transaction has no change output. Previously returned RPC_MISC_ERROR.
bumpfeenow returns RPC_WALLET_ERROR if the fee is too high. Previously returned RPC_MISC_ERROR.
bumpfeenow returns RPC_WALLET_ERROR if the fee is too low. Previously returned RPC_MISC_ERROR.
bumpfeenow 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:
045629d5f394a07b7b87e11642da747f6405a3a803ecb5d30eb442ab807a62ae litecoin-0.15.0.1rc1-osx.dmg 12398ed5bd53ea92e73382a35093582f4f7889e6df29fbbdafbe48177db1c804 litecoin-0.15.0.1rc1-win32-setup.exe 670389642eec09145937277e5e04598a4f3b76a5121bf3c023d90b44d98bad45 litecoin-0.15.0.1rc1-win64-setup.exe 14023c8e79acac1affd3de10e432a5a074d304e5ac8bbd19fb80592ffe735b86 litecoin-0.15.0-aarch64-linux-gnu.tar.gz 8e533096fe361fc380bf90f0e532391952d0d3e057a08dd970b93e0b224d24fa litecoin-0.15.0-arm-linux-gnueabihf.tar.gz 9a930b90ead9fd47039633e5cbaace12b9093624a4f42c408182652428c8cc01 litecoin-0.15.0-i686-pc-linux-gnu.tar.gz 8808d834cde9f9fd3b541564481651746c958582e6a93c7ec22a016ced9f64e7 litecoin-0.15.0-osx64.tar.gz 838a175afb51ec992cf4da8a71192ba1fe41716daf68e532a8c04d5f1f07d704 litecoin-0.15.0-osx-unsigned.dmg 37716adc03f85b714c1b8af1811aea85983ba059930582741ab89f2fdf780343 litecoin-0.15.0.tar.gz 118f2dfb90f12d93ddcf3a06ef693e51eff586d036261523cf6cc0da5b95a0bd litecoin-0.15.0-win32.zip d539661a392684333c5fd33ec3ad3d401b6f7ed96db7a1f28aaa8530462966f5 litecoin-0.15.0-win64.zip b47171844cbd653cea95de5339259c484f94c5ec2ef69575b78207447b3c763f litecoin-0.15.0-x86_64-linux-gnu.tar.gz
Thanks to everyone who directly contributed to this release:
- The Bitcoin Core Developers
- Adrian Gallagher