From 59c37ae55a476d3cf84c9bafbc083904472fe4db Mon Sep 17 00:00:00 2001 From: Karl-Johan Alm Date: Fri, 16 Dec 2016 16:52:35 +0900 Subject: [PATCH 1/3] Uses built-in byte swap if available (Apple) and if bswap_XX is undefined. Defers to pre-defined version if found (e.g. protobuf). For protobuf case, the definitions are identical and thus include order should not affect results. Github-Pull: #9366 Rebased-From: 815f4148b2eff6c64c764e910e79677d5a67adc7 --- src/Makefile.qttest.include | 6 +++++- src/Makefile.test.include | 1 + src/compat/byteswap.h | 19 +++++++++++++++++++ src/qt/test/compattests.cpp | 23 +++++++++++++++++++++++ src/qt/test/compattests.h | 19 +++++++++++++++++++ src/qt/test/test_main.cpp | 4 ++++ src/test/bswap_tests.cpp | 26 ++++++++++++++++++++++++++ 7 files changed, 97 insertions(+), 1 deletion(-) create mode 100644 src/qt/test/compattests.cpp create mode 100644 src/qt/test/compattests.h create mode 100644 src/test/bswap_tests.cpp diff --git a/src/Makefile.qttest.include b/src/Makefile.qttest.include index a071fe136..22c5f6a0b 100644 --- a/src/Makefile.qttest.include +++ b/src/Makefile.qttest.include @@ -5,13 +5,16 @@ bin_PROGRAMS += qt/test/test_bitcoin-qt TESTS += qt/test/test_bitcoin-qt -TEST_QT_MOC_CPP = qt/test/moc_uritests.cpp +TEST_QT_MOC_CPP = \ + qt/test/moc_compattests.cpp \ + qt/test/moc_uritests.cpp if ENABLE_WALLET TEST_QT_MOC_CPP += qt/test/moc_paymentservertests.cpp endif TEST_QT_H = \ + qt/test/compattests.h \ qt/test/uritests.h \ qt/test/paymentrequestdata.h \ qt/test/paymentservertests.h @@ -20,6 +23,7 @@ qt_test_test_bitcoin_qt_CPPFLAGS = $(AM_CPPFLAGS) $(BITCOIN_INCLUDES) $(BITCOIN_ $(QT_INCLUDES) $(QT_TEST_INCLUDES) $(PROTOBUF_CFLAGS) qt_test_test_bitcoin_qt_SOURCES = \ + qt/test/compattests.cpp \ qt/test/test_main.cpp \ qt/test/uritests.cpp \ $(TEST_QT_H) diff --git a/src/Makefile.test.include b/src/Makefile.test.include index 0878d8234..256563332 100644 --- a/src/Makefile.test.include +++ b/src/Makefile.test.include @@ -50,6 +50,7 @@ BITCOIN_TESTS =\ test/bip32_tests.cpp \ test/blockencodings_tests.cpp \ test/bloom_tests.cpp \ + test/bswap_tests.cpp \ test/coins_tests.cpp \ test/compress_tests.cpp \ test/crypto_tests.cpp \ diff --git a/src/compat/byteswap.h b/src/compat/byteswap.h index 899220bdc..5c86499d7 100644 --- a/src/compat/byteswap.h +++ b/src/compat/byteswap.h @@ -15,6 +15,23 @@ #include #endif +#if defined(__APPLE__) + +#if !defined(bswap_16) + +// Mac OS X / Darwin features; we include a check for bswap_16 because if it is already defined, protobuf has +// defined these macros for us already; if it isn't, we do it ourselves. In either case, we get the exact same +// result regardless which path was taken +#include +#define bswap_16(x) OSSwapInt16(x) +#define bswap_32(x) OSSwapInt32(x) +#define bswap_64(x) OSSwapInt64(x) + +#endif // !defined(bswap_16) + +#else +// Non-Mac OS X / non-Darwin + #if HAVE_DECL_BSWAP_16 == 0 inline uint16_t bswap_16(uint16_t x) { @@ -44,4 +61,6 @@ inline uint64_t bswap_64(uint64_t x) } #endif // HAVE_DECL_BSWAP64 +#endif // defined(__APPLE__) + #endif // BITCOIN_COMPAT_BYTESWAP_H diff --git a/src/qt/test/compattests.cpp b/src/qt/test/compattests.cpp new file mode 100644 index 000000000..2a7284b5b --- /dev/null +++ b/src/qt/test/compattests.cpp @@ -0,0 +1,23 @@ +// Copyright (c) 2016 The Bitcoin Core developers +// Distributed under the MIT software license, see the accompanying +// file COPYING or http://www.opensource.org/licenses/mit-license.php. + +#include "paymentrequestplus.h" // this includes protobuf's port.h which defines its own bswap macos + +#include "compattests.h" + +#include "compat/byteswap.h" + +void CompatTests::bswapTests() +{ + // Sibling in bitcoin/src/test/bswap_tests.cpp + uint16_t u1 = 0x1234; + uint32_t u2 = 0x56789abc; + uint64_t u3 = 0xdef0123456789abc; + uint16_t e1 = 0x3412; + uint32_t e2 = 0xbc9a7856; + uint64_t e3 = 0xbc9a78563412f0de; + QVERIFY(bswap_16(u1) == e1); + QVERIFY(bswap_32(u2) == e2); + QVERIFY(bswap_64(u3) == e3); +} diff --git a/src/qt/test/compattests.h b/src/qt/test/compattests.h new file mode 100644 index 000000000..35dede774 --- /dev/null +++ b/src/qt/test/compattests.h @@ -0,0 +1,19 @@ +// Copyright (c) 2009-2015 The Bitcoin Core developers +// Distributed under the MIT software license, see the accompanying +// file COPYING or http://www.opensource.org/licenses/mit-license.php. + +#ifndef BITCOIN_QT_TEST_COMPATTESTS_H +#define BITCOIN_QT_TEST_COMPATTESTS_H + +#include +#include + +class CompatTests : public QObject +{ + Q_OBJECT + +private Q_SLOTS: + void bswapTests(); +}; + +#endif // BITCOIN_QT_TEST_COMPATTESTS_H diff --git a/src/qt/test/test_main.cpp b/src/qt/test/test_main.cpp index db193420b..02650320b 100644 --- a/src/qt/test/test_main.cpp +++ b/src/qt/test/test_main.cpp @@ -8,6 +8,7 @@ #include "util.h" #include "uritests.h" +#include "compattests.h" #ifdef ENABLE_WALLET #include "paymentservertests.h" @@ -48,6 +49,9 @@ int main(int argc, char *argv[]) if (QTest::qExec(&test2) != 0) fInvalid = true; #endif + CompatTests test4; + if (QTest::qExec(&test4) != 0) + fInvalid = true; return fInvalid; } diff --git a/src/test/bswap_tests.cpp b/src/test/bswap_tests.cpp new file mode 100644 index 000000000..7b3134d32 --- /dev/null +++ b/src/test/bswap_tests.cpp @@ -0,0 +1,26 @@ +// Copyright (c) 2016 The Bitcoin Core developers +// Distributed under the MIT software license, see the accompanying +// file COPYING or http://www.opensource.org/licenses/mit-license.php. + +#include "compat/byteswap.h" +#include "test/test_bitcoin.h" + +#include + +BOOST_FIXTURE_TEST_SUITE(bswap_tests, BasicTestingSetup) + +BOOST_AUTO_TEST_CASE(bswap_tests) +{ + // Sibling in bitcoin/src/qt/test/compattests.cpp + uint16_t u1 = 0x1234; + uint32_t u2 = 0x56789abc; + uint64_t u3 = 0xdef0123456789abc; + uint16_t e1 = 0x3412; + uint32_t e2 = 0xbc9a7856; + uint64_t e3 = 0xbc9a78563412f0de; + BOOST_CHECK(bswap_16(u1) == e1); + BOOST_CHECK(bswap_32(u2) == e2); + BOOST_CHECK(bswap_64(u3) == e3); +} + +BOOST_AUTO_TEST_SUITE_END() From d8092506cbfac9f52d1b81e040d8463e13f2fe96 Mon Sep 17 00:00:00 2001 From: shaolinfry Date: Mon, 13 Feb 2017 22:34:17 +0000 Subject: [PATCH 2/3] Bump version number 0.13.3 --- src/clientversion.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/clientversion.h b/src/clientversion.h index 898b3a8ca..e0d043ad2 100644 --- a/src/clientversion.h +++ b/src/clientversion.h @@ -16,8 +16,8 @@ //! These need to be macros, as clientversion.cpp's and bitcoin*-res.rc's voodoo requires it #define CLIENT_VERSION_MAJOR 0 #define CLIENT_VERSION_MINOR 13 -#define CLIENT_VERSION_REVISION 2 -#define CLIENT_VERSION_BUILD 1 +#define CLIENT_VERSION_REVISION 3 +#define CLIENT_VERSION_BUILD 0 //! Set to true for release, false for prerelease or test build #define CLIENT_VERSION_IS_RELEASE true From b58a89f87eb184f566f4fcb890e904540ebd7323 Mon Sep 17 00:00:00 2001 From: shaolinfry Date: Mon, 13 Feb 2017 22:48:09 +0000 Subject: [PATCH 3/3] Start release notes for 0.13.3 --- .../release-notes-0.13.2.md | 993 ++++++++++++++++++ doc/release-notes-litecoin.md | 951 +---------------- 2 files changed, 1003 insertions(+), 941 deletions(-) create mode 100644 doc/litecoin-release-notes/release-notes-0.13.2.md diff --git a/doc/litecoin-release-notes/release-notes-0.13.2.md b/doc/litecoin-release-notes/release-notes-0.13.2.md new file mode 100644 index 000000000..619183a3a --- /dev/null +++ b/doc/litecoin-release-notes/release-notes-0.13.2.md @@ -0,0 +1,993 @@ +Litecoin Core version 0.13.2 is now available from: + + + +This is a new major version release, including new features, various bugfixes and performance improvements, as well as updated translations. +It is recommended to upgrade to this version. + +Please report bugs using the issue tracker at github: + + + +Compatibility +============== + +Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support), +an OS initially released in 2001. This means that not even critical security +updates will be released anymore. Without security updates, using a litecoin +wallet on a XP machine is irresponsible at least. + +In addition to that, with 0.12.x there have been varied reports of Bitcoin Core +randomly crashing on Windows XP. It is [not clear](https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891) +what the source of these crashes is, but it is likely that upstream +libraries such as Qt are no longer being tested on XP. + +We do not have time nor resources to provide support for an OS that is +end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are +suggested to upgrade to a newer version of Windows, or install an alternative OS +that is supported. + +No attempt is made to prevent installing or running the software on Windows XP, +you can still do so at your own risk, but do not expect it to work: do not +report issues about Windows XP to the issue tracker. + +From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+, +but severe issues with the libc++ version on 10.7.x keep it from running reliably. +0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly. + +Notable changes +=============== + +Signature validation using libsecp256k1 +--------------------------------------- + +ECDSA signatures inside Litecoin transactions now use validation using +[libsecp256k1](https://github.com/bitcoin-core/secp256k1) instead of OpenSSL. + +Depending on the platform, this means a significant speedup for raw signature +validation speed. The advantage is largest on x86_64, where validation is over +five times faster. In practice, this translates to a raw reindexing and new +block validation times that are less than half of what it was before. + +Libsecp256k1 has undergone very extensive testing and validation. + +A side effect of this change is that libconsensus no longer depends on OpenSSL. + +Reduce upload traffic +--------------------- + +A major part of the outbound traffic is caused by serving historic blocks to +other nodes in initial block download state. + +It is now possible to reduce the total upload traffic via the `-maxuploadtarget` +parameter. This is *not* a hard limit but a threshold to minimize the outbound +traffic. When the limit is about to be reached, the uploaded data is cut by not +serving historic blocks (blocks older than one week). +Moreover, any SPV peer is disconnected when they request a filtered block. + +This option can be specified in MiB per day and is turned off by default +(`-maxuploadtarget=0`). +The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day. + +Whitelisted peers will never be disconnected, although their traffic counts for +calculating the target. + +A more detailed documentation about keeping traffic low can be found in +[/doc/reduce-traffic.md](/doc/reduce-traffic.md). + +Direct headers announcement (BIP 130) +------------------------------------- + +Between compatible peers, [BIP 130] +(https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) +direct headers announcement is used. This means that blocks are advertised by +announcing their headers directly, instead of just announcing the hash. In a +reorganization, all new headers are sent, instead of just the new tip. This +can often prevent an extra roundtrip before the actual block is downloaded. + +Memory pool limiting +-------------------- + +Previous versions of Litecoin Core had their mempool limited by checking +a transaction's fees against the node's minimum relay fee. There was no +upper bound on the size of the mempool and attackers could send a large +number of transactions paying just slighly more than the default minimum +relay fee to crash nodes with relatively low RAM. A temporary workaround +for previous versions of Litecoin Core was to raise the default minimum +relay fee. + +Litecoin Core 0.13.2 will have a strict maximum size on the mempool. The +default value is 300 MB and can be configured with the `-maxmempool` +parameter. Whenever a transaction would cause the mempool to exceed +its maximum size, the transaction that (along with in-mempool descendants) has +the lowest total feerate (as a package) will be evicted and the node's effective +minimum relay feerate will be increased to match this feerate plus the initial +minimum relay feerate. The initial minimum relay feerate is set to +1000 satoshis per kB. + +Litecoin Core 0.13.2 also introduces new default policy limits on the length and +size of unconfirmed transaction chains that are allowed in the mempool +(generally limiting the length of unconfirmed chains to 25 transactions, with a +total size of 101 KB). These limits can be overriden using command line +arguments; see the extended help (`--help -help-debug`) for more information. + +RPC: Random-cookie RPC authentication +------------------------------------- + +When no `-rpcpassword` is specified, the daemon now uses a special 'cookie' +file for authentication. This file is generated with random content when the +daemon starts, and deleted when it exits. Its contents are used as +authentication token. Read access to this file controls who can access through +RPC. By default it is stored in the data directory but its location can be +overridden with the option `-rpccookiefile`. + +This is similar to Tor's CookieAuthentication: see +https://www.torproject.org/docs/tor-manual.html.en + +This allows running litecoind without having to do any manual configuration. + +Relay: Any sequence of pushdatas in OP_RETURN outputs now allowed +----------------------------------------------------------------- + +Previously OP_RETURN outputs with a payload were only relayed and mined if they +had a single pushdata. This restriction has been lifted to allow any +combination of data pushes and numeric constant opcodes (OP_1 to OP_16) after +the OP_RETURN. The limit on OP_RETURN output size is now applied to the entire +serialized scriptPubKey, 83 bytes by default. (the previous 80 byte default plus +three bytes overhead) + +Relay: New and only new blocks relayed when pruning +--------------------------------------------------- + +When running in pruned mode, the client will now relay new blocks. When +responding to the `getblocks` message, only hashes of blocks that are on disk +and are likely to remain there for some reasonable time window (1 hour) will be +returned (previously all relevant hashes were returned). + +Relay and Mining: Priority transactions +--------------------------------------- + +Litecoin Core has a heuristic 'priority' based on coin value and age. This +calculation is used for relaying of transactions which do not pay the +minimum relay fee, and can be used as an alternative way of sorting +transactions for mined blocks. Litecoin Core will relay transactions with +insufficient fees depending on the setting of `-limitfreerelay=` (default: +`r=15` kB per minute) and `-blockprioritysize=`. + +In Bitcoin Core 0.12, when mempool limit has been reached a higher minimum +relay fee takes effect to limit memory usage. Transactions which do not meet +this higher effective minimum relay fee will not be relayed or mined even if +they rank highly according to the priority heuristic. + +The mining of transactions based on their priority is also now disabled by +default. To re-enable it, simply set `-blockprioritysize=` where is the size +in bytes of your blocks to reserve for these transactions. The old default was +50k, so to retain approximately the same policy, you would set +`-blockprioritysize=50000`. + +Additionally, as a result of computational simplifications, the priority value +used for transactions received with unconfirmed inputs is lower than in prior +versions due to avoiding recomputing the amounts as input transactions confirm. + +External miner policy set via the `prioritisetransaction` RPC to rank +transactions already in the mempool continues to work as it has previously. +Note, however, that if mining priority transactions is left disabled, the +priority delta will be ignored and only the fee metric will be effective. + +This internal automatic prioritization handling is being considered for removal +entirely in Litecoin Core 0.13, and it is at this time undecided whether the +more accurate priority calculation for chained unconfirmed transactions will be +restored. Community direction on this topic is particularly requested to help +set project priorities. + +Automatically use Tor hidden services +------------------------------------- + +Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket +API, to create and destroy 'ephemeral' hidden services programmatically. +Litecoin Core has been updated to make use of this. + +This means that if Tor is running (and proper authorization is available), +Litecoin Core automatically creates a hidden service to listen on, without +manual configuration. Litecoin Core will also use Tor automatically to connect +to other .onion nodes if the control socket can be successfully opened. This +will positively affect the number of available .onion nodes and their usage. + +This new feature is enabled by default if Litecoin Core is listening, and +a connection to Tor can be made. It can be configured with the `-listenonion`, +`-torcontrol` and `-torpassword` settings. To show verbose debugging +information, pass `-debug=tor`. + +Notifications through ZMQ +------------------------- + +Litecoind can now (optionally) asynchronously notify clients through a +ZMQ-based PUB socket of the arrival of new transactions and blocks. +This feature requires installation of the ZMQ C API library 4.x and +configuring its use through the command line or configuration file. +Please see [docs/zmq.md](/doc/zmq.md) for details of operation. + +Wallet: Transaction fees +------------------------ + +Various improvements have been made to how the wallet calculates +transaction fees. + +Users can decide to pay a predefined fee rate by setting `-paytxfee=` +(or `settxfee ` rpc during runtime). A value of `n=0` signals Litecoin +Core to use floating fees. By default, Litecoin Core will use floating +fees. + +Based on past transaction data, floating fees approximate the fees +required to get into the `m`th block from now. This is configurable +with `-txconfirmtarget=` (default: `2`). + +Sometimes, it is not possible to give good estimates, or an estimate +at all. Therefore, a fallback value can be set with `-fallbackfee=` +(default: `0.0002` LTC/kB). + +At all times, Litecoin Core will cap fees at `-maxtxfee=` (default: +0.10) LTC. +Furthermore, Litecoin Core will never create transactions paying less than +the current minimum relay fee. +Finally, a user can set the minimum fee rate for all transactions with +`-mintxfee=`, which defaults to 1000 satoshis per kB. + +Wallet: Negative confirmations and conflict detection +----------------------------------------------------- + +The wallet will now report a negative number for confirmations that indicates +how deep in the block chain the conflict is found. For example, if a transaction +A has 5 confirmations and spends the same input as a wallet transaction B, B +will be reported as having -5 confirmations. If another wallet transaction C +spends an output from B, it will also be reported as having -5 confirmations. +To detect conflicts with historical transactions in the chain a one-time +`-rescan` may be needed. + +Unlike earlier versions, unconfirmed but non-conflicting transactions will never +get a negative confirmation count. They are not treated as spendable unless +they're coming from ourself (change) and accepted into our local mempool, +however. The new "trusted" field in the `listtransactions` RPC output +indicates whether outputs of an unconfirmed transaction are considered +spendable. + +Wallet: Merkle branches removed +------------------------------- + +Previously, every wallet transaction stored a Merkle branch to prove its +presence in blocks. This wasn't being used for more than an expensive +sanity check. Since 0.13.2, these are no longer stored. When loading a +0.13.2 wallet into an older version, it will automatically rescan to avoid +failed checks. + +Wallet: Pruning +--------------- + +With 0.13.2 it is possible to use wallet functionality in pruned mode. +This can reduce the disk usage from currently around 6 GB to +around 0.2 GB. + +However, rescans as well as the RPCs `importwallet`, `importaddress`, +`importprivkey` are disabled. + +To enable block pruning set `prune=` on the command line or in +`litecoin.conf`, where `N` is the number of MiB to allot for +raw block & undo data. + +A value of 0 disables pruning. The minimal value above 0 is 550. Your +wallet is as secure with high values as it is with low ones. Higher +values merely ensure that your node will not shut down upon blockchain +reorganizations of more than 2 days - which are unlikely to happen in +practice. In future releases, a higher value may also help the network +as a whole: stored blocks could be served to other nodes. + +For further information about pruning, you may also consult the [release +notes of Bitcoin Core v0.11.0](https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning). + +`NODE_BLOOM` service bit +------------------------ + +Support for the `NODE_BLOOM` service bit, as described in [BIP +111](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki), has been +added to the P2P protocol code. + +BIP 111 defines a service bit to allow peers to advertise that they support +bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol +version to allow peers to identify old nodes which allow bloom filtering of the +connection despite lacking the new service bit. + +In this version, it is only enforced for peers that send protocol versions +`>=70011`. For the next major version it is planned that this restriction will be +removed. It is recommended to update SPV clients to check for the `NODE_BLOOM` +service bit for nodes that report versions newer than 70011. + +Option parsing behavior +----------------------- + +Command line options are now parsed strictly in the order in which they are +specified. It used to be the case that `-X -noX` ends up, unintuitively, with X +set, as `-X` had precedence over `-noX`. This is no longer the case. Like for +other software, the last specified value for an option will hold. + +RPC: Low-level API changes +-------------------------- + +- Monetary amounts can be provided as strings. This means that for example the + argument to sendtoaddress can be "0.0001" instead of 0.0001. This can be an + advantage if a JSON library insists on using a lossy floating point type for + numbers, which would be dangerous for monetary amounts. + +* The `asm` property of each scriptSig now contains the decoded signature hash + type for each signature that provides a valid defined hash type. + +* OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) + +The following items contain assembly representations of scriptSig signatures +and are affected by this change: + +- RPC `getrawtransaction` +- RPC `decoderawtransaction` +- RPC `decodescript` +- REST `/rest/tx/` (JSON format) +- REST `/rest/block/` (JSON format when including extended tx details) +- `litecoin-tx -json` + +For example, the `scriptSig.asm` property of a transaction input that +previously showed an assembly representation of: + + 304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001 400000 OP_NOP2 + +now shows as: + + 304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL] 400000 OP_CHECKLOCKTIMEVERIFY + +Note that the output of the RPC `decodescript` did not change because it is +configured specifically to process scriptPubKey and not scriptSig scripts. + +RPC: SSL support dropped +------------------------ + +SSL support for RPC, previously enabled by the option `rpcssl` has been dropped +from both the client and the server. This was done in preparation for removing +the dependency on OpenSSL for the daemon completely. + +Trying to use `rpcssl` will result in an error: + + Error: SSL mode for RPC (-rpcssl) is no longer supported. + +If you are one of the few people that relies on this feature, a flexible +migration path is to use `stunnel`. This is an utility that can tunnel +arbitrary TCP connections inside SSL. On e.g. Ubuntu it can be installed with: + + sudo apt-get install stunnel4 + +Then, to tunnel a SSL connection on 29332 to a RPC server bound on localhost on port 19334 do: + + stunnel -d 29332 -r 127.0.0.1:19334 -p stunnel.pem -P '' + +It can also be set up system-wide in inetd style. + +Another way to re-attain SSL would be to setup a httpd reverse proxy. This solution +would allow the use of different authentication, loadbalancing, on-the-fly compression and +caching. A sample config for apache2 could look like: + + Listen 443 + + NameVirtualHost *:443 + + + SSLEngine On + SSLCertificateFile /etc/apache2/ssl/server.crt + SSLCertificateKeyFile /etc/apache2/ssl/server.key + + + ProxyPass http://127.0.0.1:9332/ + ProxyPassReverse http://127.0.0.1:9332/ + # optional enable digest auth + # AuthType Digest + # ... + + # optional bypass litecoind rpc basic auth + # RequestHeader set Authorization "Basic " + # get the from the shell with: base64 <<< litecoinrpc: + + + # Or, balance the load: + # ProxyPass / balancer://balancer_cluster_name + + + +Other P2P Changes +----------------- + +The list of banned peers is now stored on disk rather than in memory. +Restarting litecoind will no longer clear out the list of banned peers; instead +a new RPC call (`clearbanned`) can be used to manually clear the list. The new +`setban` RPC call can also be used to manually ban or unban a peer. + +Database cache memory increased +-------------------------------- + +As a result of growth of the UTXO set, performance with the prior default +database cache of 100 MiB has suffered. +For this reason the default was changed to 300 MiB in this release. + +For nodes on low-memory systems, the database cache can be changed back to +100 MiB (or to another value) by either: + +- Adding `dbcache=100` in litecoin.conf +- Changing it in the GUI under `Options → Size of database cache` + +Note that the database cache setting has the most performance impact +during initial sync of a node, and when catching up after downtime. + + +litecoin-cli: arguments privacy +------------------------------ + +The RPC command line client gained a new argument, `-stdin` +to read extra arguments from standard input, one per line until EOF/Ctrl-D. +For example: + + $ src/litecoin-cli -stdin walletpassphrase + mysecretcode + 120 + ..... press Ctrl-D here to end input + $ + +It is recommended to use this for sensitive information such as wallet +passphrases, as command-line arguments can usually be read from the process +table by any user on the system. + + +C++11 and Python 3 +------------------ + +Various code modernizations have been done. The Litecoin Core code base has +started using C++11. This means that a C++11-capable compiler is now needed for +building. Effectively this means GCC 4.7 or higher, or Clang 3.3 or higher. + +When cross-compiling for a target that doesn't have C++11 libraries, configure with +`./configure --enable-glibc-back-compat ... LDFLAGS=-static-libstdc++`. + +For running the functional tests in `qa/rpc-tests`, Python3.4 or higher is now +required. + + +Linux ARM builds +---------------- + +Due to popular request, Linux ARM builds have been added to the uploaded +executables. + +The following extra files can be found in the download directory or torrent: + +- `litecoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries for the most + common 32-bit ARM architecture. +- `litecoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries for the most + common 64-bit ARM architecture. + +ARM builds are still experimental. If you have problems on a certain device or +Linux distribution combination please report them on the bug tracker, it may be +possible to resolve them. + +Note that Android is not considered ARM Linux in this context. The executables +are not expected to work out of the box on Android. + +BIP68 soft fork to enforce sequence locks for relative locktime +--------------------------------------------------------------- + +[BIP68][] introduces relative lock-time consensus-enforced semantics of +the sequence number field to enable a signed transaction input to remain +invalid for a defined period of time after confirmation of its corresponding +outpoint. + +For more information about the implementation, see + + +BIP112 soft fork to enforce OP_CHECKSEQUENCEVERIFY +-------------------------------------------------- + +[BIP112][] redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV) +for a new opcode in the Litecoin scripting system that in combination with +[BIP68][] allows execution pathways of a script to be restricted based +on the age of the output being spent. + +For more information about the implementation, see + + +BIP113 locktime enforcement soft fork +------------------------------------- + +This release seeks to make mempool-only locktime enforcement using GetMedianTimePast() +a consensus rule. + +Litecoin transactions currently may specify a locktime indicating when +they may be added to a valid block. Current consensus rules require +that blocks have a block header time greater than the locktime specified +in any transaction in that block. + +Miners get to choose what time they use for their header time, with the +consensus rule being that no node will accept a block whose time is more +than two hours in the future. This creates a incentive for miners to +set their header times to future values in order to include locktimed +transactions which weren't supposed to be included for up to two more +hours. + +The consensus rules also specify that valid blocks may have a header +time greater than that of the median of the 11 previous blocks. This +GetMedianTimePast() time has a key feature we generally associate with +time: it can't go backwards. + +[BIP113][] specifies a soft fork enforced in this release that +weakens this perverse incentive for individual miners to use a future +time by requiring that valid blocks have a computed GetMedianTimePast() +greater than the locktime specified in any transaction in that block. + +Mempool inclusion rules currently require transactions to be valid for +immediate inclusion in a block in order to be accepted into the mempool. +This release begins applying the BIP113 rule to received transactions, +so transaction whose time is greater than the GetMedianTimePast() will +no longer be accepted into the mempool. + +**Implication for miners:** you will begin rejecting transactions that +would not be valid under BIP113, which will prevent you from producing +invalid blocks when BIP113 is enforced on the network. Any +transactions which are valid under the current rules but not yet valid +under the BIP113 rules will either be mined by other miners or delayed +until they are valid under BIP113. Note, however, that time-based +locktime transactions are more or less unseen on the network currently. + +**Implication for users:** GetMedianTimePast() always trails behind the +current time, so a transaction locktime set to the present time will be +rejected by nodes running this release until the median time moves +forward. To compensate, subtract one hour (3,600 seconds) from your +locktimes to allow those transactions to be included in mempools at +approximately the expected time. + +For more information about the implementation, see + + + +Compact Block support (BIP 152) +------------------------------- + +Support for block relay using the Compact Blocks protocol has been implemented +in PR 8068. + +The primary goal is reducing the bandwidth spikes at relay time, though in many +cases it also reduces propagation delay. It is automatically enabled between +compatible peers. +[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) + +As a side-effect, ordinary non-mining nodes will download and upload blocks +faster if those blocks were produced by miners using similar transaction +filtering policies. This means that a miner who produces a block with many +transactions discouraged by your node will be relayed slower than one with +only transactions already in your memory pool. The overall effect of such +relay differences on the network may result in blocks which include widely- +discouraged transactions losing a stale block race, and therefore miners may +wish to configure their node to take common relay policies into consideration. + + +Hierarchical Deterministic Key Generation +----------------------------------------- +Newly created wallets will use hierarchical deterministic key generation +according to BIP32 (keypath m/0'/0'/k'). +Existing wallets will still use traditional key generation. + +Backups of HD wallets, regardless of when they have been created, can +therefore be used to re-generate all possible private keys, even the +ones which haven't already been generated during the time of the backup. +**Attention:** Encrypting the wallet will create a new seed which requires +a new backup! + +Wallet dumps (created using the `dumpwallet` RPC) will contain the deterministic +seed. This is expected to allow future versions to import the seed and all +associated funds, but this is not yet implemented. + +HD key generation for new wallets can be disabled by `-usehd=0`. Keep in +mind that this flag only has affect on newly created wallets. +You can't disable HD key generation once you have created a HD wallet. + +There is no distinction between internal (change) and external keys. + +HD wallets are incompatible with older versions of Litecoin Core. + +[Pull request](https://github.com/bitcoin/bitcoin/pull/8035/files), [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) + + +Mining transaction selection ("Child Pays For Parent") +------------------------------------------------------ + +The mining transaction selection algorithm has been replaced with an algorithm +that selects transactions based on their feerate inclusive of unconfirmed +ancestor transactions. This means that a low-fee transaction can become more +likely to be selected if a high-fee transaction that spends its outputs is +relayed. + +With this change, the `-blockminsize` command line option has been removed. + +The command line option `-blockmaxsize` remains an option to specify the +maximum number of serialized bytes in a generated block. In addition, the new +command line option `-blockmaxweight` has been added, which specifies the +maximum "block weight" of a generated block, as defined by [BIP 141 (Segregated +Witness)] (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki). + +In preparation for Segregated Witness, the mining algorithm has been modified +to optimize transaction selection for a given block weight, rather than a given +number of serialized bytes in a block. In this release, transaction selection +is unaffected by this distinction (as BIP 141 activation is not supported on +mainnet in this release, see above), but in future releases and after BIP 141 +activation, these calculations would be expected to differ. + +For optimal runtime performance, miners using this release should specify +`-blockmaxweight` on the command line, and not specify `-blockmaxsize`. +Additionally (or only) specifying `-blockmaxsize`, or relying on default +settings for both, may result in performance degradation, as the logic to +support `-blockmaxsize` performs additional computation to ensure that +constraint is met. (Note that for mainnet, in this release, the equivalent +parameter for `-blockmaxweight` would be four times the desired +`-blockmaxsize`. See [BIP 141] +(https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) for additional +details.) + +In the future, the `-blockmaxsize` option may be removed, as block creation is +no longer optimized for this metric. Feedback is requested on whether to +deprecate or keep this command line option in future releases. + + +Reindexing changes +------------------ + +In earlier versions, reindexing did validation while reading through the block +files on disk. These two have now been split up, so that all blocks are known +before validation starts. This was necessary to make certain optimizations that +are available during normal synchronizations also available during reindexing. + +The two phases are distinct in the Litecoin-Qt GUI. During the first one, +"Reindexing blocks on disk" is shown. During the second (slower) one, +"Processing blocks on disk" is shown. + +It is possible to only redo validation now, without rebuilding the block index, +using the command line option `-reindex-chainstate` (in addition to +`-reindex` which does both). This new option is useful when the blocks on disk +are assumed to be fine, but the chainstate is still corrupted. It is also +useful for benchmarks. + + +Removal of internal miner +-------------------------- + +As CPU mining has been useless for a long time, the internal miner has been +removed in this release, and replaced with a simpler implementation for the +test framework. + +The overall result of this is that `setgenerate` RPC call has been removed, as +well as the `-gen` and `-genproclimit` command-line options. + +For testing, the `generate` call can still be used to mine a block, and a new +RPC call `generatetoaddress` has been added to mine to a specific address. This +works with wallet disabled. + + +New bytespersigop implementation +-------------------------------- + +The former implementation of the bytespersigop filter accidentally broke bare +multisig (which is meant to be controlled by the `permitbaremultisig` option), +since the consensus protocol always counts these older transaction forms as 20 +sigops for backwards compatibility. Simply fixing this bug by counting more +accurately would have reintroduced a vulnerability. It has therefore been +replaced with a new implementation that rather than filter such transactions, +instead treats them (for fee purposes only) as if they were in fact the size +of a transaction actually using all 20 sigops. + + +Low-level P2P changes +---------------------- + +- The optional new p2p message "feefilter" is implemented and the protocol + version is bumped to 70013. Upon receiving a feefilter message from a peer, + a node will not send invs for any transactions which do not meet the filter + feerate. [BIP 133](https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki) + +- The P2P alert system has been removed in PR #7692 and the `alert` P2P message + is no longer supported. + +- The transaction relay mechanism used to relay one quarter of all transactions + instantly, while queueing up the rest and sending them out in batch. As + this resulted in chains of dependent transactions being reordered, it + systematically hurt transaction relay. The relay code was redesigned in PRs + \#7840 and #8082, and now always batches transactions announcements while also + sorting them according to dependency order. This significantly reduces orphan + transactions. To compensate for the removal of instant relay, the frequency of + batch sending was doubled for outgoing peers. + +- Since PR #7840 the BIP35 `mempool` command is also subject to batch processing. + Also the `mempool` message is no longer handled for non-whitelisted peers when + `NODE_BLOOM` is disabled through `-peerbloomfilters=0`. + +- The maximum size of orphan transactions that are kept in memory until their + ancestors arrive has been raised in PR #8179 from 5000 to 99999 bytes. They + are now also removed from memory when they are included in a block, conflict + with a block, and time out after 20 minutes. + +- We respond at most once to a getaddr request during the lifetime of a + connection since PR #7856. + +- Connections to peers who have recently been the first one to give us a valid + new block or transaction are protected from disconnections since PR #8084. + + +Low-level RPC changes +---------------------- + +- RPC calls have been added to output detailed statistics for individual mempool + entries, as well as to calculate the in-mempool ancestors or descendants of a + transaction: see `getmempoolentry`, `getmempoolancestors`, `getmempooldescendants`. + +- `gettxoutsetinfo` UTXO hash (`hash_serialized`) has changed. There was a divergence between + 32-bit and 64-bit platforms, and the txids were missing in the hashed data. This has been + fixed, but this means that the output will be different than from previous versions. + +- Full UTF-8 support in the RPC API. Non-ASCII characters in, for example, + wallet labels have always been malformed because they weren't taken into account + properly in JSON RPC processing. This is no longer the case. This also affects + the GUI debug console. + +- Asm script outputs replacements for OP_NOP2 and OP_NOP3 + + - OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP +65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) + + - OP_NOP3 has been renamed to OP_CHECKSEQUENCEVERIFY by [BIP +112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) + + - The following outputs are affected by this change: + + - RPC `getrawtransaction` (in verbose mode) + - RPC `decoderawtransaction` + - RPC `decodescript` + - REST `/rest/tx/` (JSON format) + - REST `/rest/block/` (JSON format when including extended tx details) + - `litecoin-tx -json` + +- The sorting of the output of the `getrawmempool` output has changed. + +- New RPC commands: `generatetoaddress`, `importprunedfunds`, `removeprunedfunds`, `signmessagewithprivkey`, + `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry`, + `createwitnessaddress`, `addwitnessaddress`. + +- Removed RPC commands: `setgenerate`, `getgenerate`. + +- New options were added to `fundrawtransaction`: `includeWatching`, `changeAddress`, `changePosition` and `feeRate`. + + +Low-level ZMQ changes +---------------------- + +- Each ZMQ notification now contains an up-counting sequence number that allows + listeners to detect lost notifications. + The sequence number is always the last element in a multi-part ZMQ notification and + therefore backward compatible. Each message type has its own counter. + PR [#7762](https://github.com/bitcoin/bitcoin/pull/7762). + +Segregated witness soft fork +---------------------------- + +Segregated witness (segwit) is a soft fork that, if activated, will +allow transaction-producing software to separate (segregate) transaction +signatures (witnesses) from the part of the data in a transaction that is +covered by the txid. This provides several immediate benefits: + +- **Elimination of unwanted transaction malleability:** Segregating the witness + allows both existing and upgraded software to calculate the transaction + identifier (txid) of transactions without referencing the witness, which can + sometimes be changed by third-parties (such as miners) or by co-signers in a + multisig spend. This solves all known cases of unwanted transaction + malleability, which is a problem that makes programming Litecoin wallet + software more difficult and which seriously complicates the design of smart + contracts for Litecoin. + +- **Capacity increase:** Segwit transactions contain new fields that are not + part of the data currently used to calculate the size of a block, which + allows a block containing segwit transactions to hold more data than allowed + by the current maximum block size. Estimates based on the transactions + currently found in blocks indicate that if all wallets switch to using + segwit, the network will be able to support about 70% more transactions. The + network will also be able to support more of the advanced-style payments + (such as multisig) than it can support now because of the different weighting + given to different parts of a transaction after segwit activates (see the + following section for details). + +- **Weighting data based on how it affects node performance:** Some parts of + each Litecoin block need to be stored by nodes in order to validate future + blocks; other parts of a block can be immediately forgotten (pruned) or used + only for helping other nodes sync their copy of the block chain. One large + part of the immediately prunable data are transaction signatures (witnesses), + and segwit makes it possible to give a different "weight" to segregated + witnesses to correspond with the lower demands they place on node resources. + Specifically, each byte of a segregated witness is given a weight of 1, each + other byte in a block is given a weight of 4, and the maximum allowed weight + of a block is 4 million. Weighting the data this way better aligns the most + profitable strategy for creating blocks with the long-term costs of block + validation. + +- **Signature covers value:** A simple improvement in the way signatures are + generated in segwit simplifies the design of secure signature generators + (such as hardware wallets), reduces the amount of data the signature + generator needs to download, and allows the signature generator to operate + more quickly. This is made possible by having the generator sign the amount + of litecoins they think they are spending, and by having full nodes refuse to + accept those signatures unless the amount of litecoins being spent is exactly + the same as was signed. For non-segwit transactions, wallets instead had to + download the complete previous transactions being spent for every payment + they made, which could be a slow operation on hardware wallets and in other + situations where bandwidth or computation speed was constrained. + +- **Linear scaling of sighash operations:** In 2015 a block was produced that + required about 25 seconds to validate on modern hardware because of the way + transaction signature hashes are performed. Other similar blocks, or blocks + that could take even longer to validate, can still be produced today. The + problem that caused this can't be fixed in a soft fork without unwanted + side-effects, but transactions that opt-in to using segwit will now use a + different signature method that doesn't suffer from this problem and doesn't + have any unwanted side-effects. + +- **Increased security for multisig:** Litecoin addresses (both P2PKH addresses + that start with a '1' and P2SH addresses that start with a '3' or 'M') use a hash + function known as RIPEMD-160. For P2PKH addresses, this provides about 160 + bits of security---which is beyond what cryptographers believe can be broken + today. But because P2SH is more flexible, only about 80 bits of security is + provided per address. Although 80 bits is very strong security, it is within + the realm of possibility that it can be broken by a powerful adversary. + Segwit allows advanced transactions to use the SHA256 hash function instead, + which provides about 128 bits of security (that is 281 trillion times as + much security as 80 bits and is equivalent to the maximum bits of security + believed to be provided by Litecoin's choice of parameters for its Elliptic + Curve Digital Security Algorithm [ECDSA].) + +- **More efficient almost-full-node security** Satoshi Nakamoto's original + Bitcoin paper describes a method for allowing newly-started full nodes to + skip downloading and validating some data from historic blocks that are + protected by large amounts of proof of work. Unfortunately, Nakamoto's + method can't guarantee that a newly-started node using this method will + produce an accurate copy of Litecoin's current ledger (called the UTXO set), + making the node vulnerable to falling out of consensus with other nodes. + Although the problems with Nakamoto's method can't be fixed in a soft fork, + Segwit accomplishes something similar to his original proposal: it makes it + possible for a node to optionally skip downloading some blockchain data + (specifically, the segregated witnesses) while still ensuring that the node + can build an accurate copy of the UTXO set for the block chain with the most + proof of work. Segwit enables this capability at the consensus layer, but + note that Litecoin Core does not provide an option to use this capability as + of this 0.13.2 release. + +- **Script versioning:** Segwit makes it easy for future soft forks to allow + Litecoin users to individually opt-in to almost any change in the Litecoin + Script language when those users receive new transactions. Features + currently being researched by Bitcoin and Litecoin Core contributors that may + use this capability include support for Schnorr signatures, which can improve + the privacy and efficiency of multisig transactions (or transactions with + multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can + improve the privacy and efficiency of scripts with two or more conditions. + Other Bitcoin community members are studying several other improvements + that can be made using script versioning. + +Activation for the segwit soft fork is being managed using +BIP9. At the beginning of the first retarget period after +segwit's start date of 1 January 2017 miners can update the Litecoin +client to Litecoin Core 0.13.2 to signal for segwit support. When a +super-majority of 75% is reached segwit is activated by optional, and +if 75% of blocks within a 8,064-block retarget period (about 3.5 days) +signal support for segwit, after another 8,064 blocks, segwit will +be required. + +For more information about segwit, please see the [segwit FAQ][], the +[segwit wallet developers guide][] or BIPs [141][BIP141], [143][BIP143], +[144][BIP144], and [145][BIP145]. + +[Segwit FAQ]: https://bitcoincore.org/en/2016/01/26/segwit-benefits/ +[segwit wallet developers guide]: https://bitcoincore.org/en/segwit_wallet_dev/ +[BIP141]: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki +[BIP143]: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki +[BIP144]: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki +[BIP145]: https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki + + +Null dummy soft fork +------------------- + +Combined with the segwit soft fork is an additional change that turns a +long-existing network relay policy into a consensus rule. The +`OP_CHECKMULTISIG` and `OP_CHECKMULTISIGVERIFY` opcodes consume an extra +stack element ("dummy element") after signature validation. The dummy +element is not inspected in any manner, and could be replaced by any +value without invalidating the script. + +Because any value can be used for this dummy element, it's possible for +a third-party to insert data into other people's transactions, changing +the transaction's txid (called transaction malleability) and possibly +causing other problems. + +Since Litecoin Core 0.10.0, nodes have defaulted to only relaying and +mining transactions whose dummy element was a null value (0x00, also +called OP_0). The null dummy soft fork turns this relay rule into a +consensus rule both for non-segwit transactions and segwit transactions, +so that this method of mutating transactions is permanently eliminated +from the network. + +Signaling for the null dummy soft fork is done by signaling support +for segwit, and the null dummy soft fork will activate at the same time +as segwit. + +For more information, please see [BIP147][]. + +[BIP147]: https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki + +Low-level RPC changes +--------------------- + +- `importprunedfunds` only accepts two required arguments. Some versions accept + an optional third arg, which was always ignored. Make sure to never pass more + than two arguments. + + +Linux ARM builds +---------------- + +Pre-built Linux ARM binaries have been added to the set of uploaded executables. +Additional detail on the ARM architecture targeted by each is provided below. + +The following extra files can be found in the download directory or torrent: + +- `litecoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries targeting + the 32-bit ARMv7-A architecture. +- `litecoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries targeting + the 64-bit ARMv8-A architecture. + +ARM builds are still experimental. If you have problems on a certain device or +Linux distribution combination please report them on the bug tracker, it may be +possible to resolve them. Note that the device you use must be (backward) +compatible with the architecture targeted by the binary that you use. +For example, a Raspberry Pi 2 Model B or Raspberry Pi 3 Model B (in its 32-bit +execution state) device, can run the 32-bit ARMv7-A targeted binary. However, +no model of Raspberry Pi 1 device can run either binary because they are all +ARMv6 architecture devices that are not compatible with ARMv7-A or ARMv8-A. + +Note that Android is not considered ARM Linux in this context. The executables +are not expected to work out of the box on Android. + + +Change to wallet handling of mempool rejection +----------------------------------------------- + +When a newly created transaction failed to enter the mempool due to +the limits on chains of unconfirmed transactions the sending RPC +calls would return an error. The transaction would still be queued +in the wallet and, once some of the parent transactions were +confirmed, broadcast after the software was restarted. + +This behavior has been changed to return success and to reattempt +mempool insertion at the same time transaction rebroadcast is +attempted, avoiding a need for a restart. + +Transactions in the wallet which cannot be accepted into the mempool +can be abandoned with the previously existing abandontransaction RPC +(or in the GUI via a context menu on the transaction). + +Credits +======= + +Thanks to everyone who directly contributed to this release: + +- [The Bitcoin Core Developers](/doc/release-notes) +- Charles Lee +- Adrian Gallagher +- shaolinfry +- Xinxi Wang +- Xinrong Guo +- Fan Yang +- Peng Sun +- Loshan T diff --git a/doc/release-notes-litecoin.md b/doc/release-notes-litecoin.md index 619183a3a..ed1ad3f3d 100644 --- a/doc/release-notes-litecoin.md +++ b/doc/release-notes-litecoin.md @@ -1,6 +1,6 @@ -Litecoin Core version 0.13.2 is now available from: +Litecoin Core version 0.13.3 is now available from: - + This is a new major version release, including new features, various bugfixes and performance improvements, as well as updated translations. It is recommended to upgrade to this version. @@ -38,944 +38,18 @@ but severe issues with the libc++ version on 10.7.x keep it from running reliabl Notable changes =============== -Signature validation using libsecp256k1 ---------------------------------------- +New Multisig Address Prefix +--------------------------- -ECDSA signatures inside Litecoin transactions now use validation using -[libsecp256k1](https://github.com/bitcoin-core/secp256k1) instead of OpenSSL. +Litecoin Core now supports P2SH addresses beginning with M on mainnet and Q on testnet. +P2SH addresses beginning with 3 on mainnet and m or n on testnet will continue to be valid. +Old and new addresses can be used interchangeably. -Depending on the platform, this means a significant speedup for raw signature -validation speed. The advantage is largest on x86_64, where validation is over -five times faster. In practice, this translates to a raw reindexing and new -block validation times that are less than half of what it was before. +Reset Testnet +------------- -Libsecp256k1 has undergone very extensive testing and validation. +Testnet3 has been deprecated and replace with Testnet4. -A side effect of this change is that libconsensus no longer depends on OpenSSL. - -Reduce upload traffic ---------------------- - -A major part of the outbound traffic is caused by serving historic blocks to -other nodes in initial block download state. - -It is now possible to reduce the total upload traffic via the `-maxuploadtarget` -parameter. This is *not* a hard limit but a threshold to minimize the outbound -traffic. When the limit is about to be reached, the uploaded data is cut by not -serving historic blocks (blocks older than one week). -Moreover, any SPV peer is disconnected when they request a filtered block. - -This option can be specified in MiB per day and is turned off by default -(`-maxuploadtarget=0`). -The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day. - -Whitelisted peers will never be disconnected, although their traffic counts for -calculating the target. - -A more detailed documentation about keeping traffic low can be found in -[/doc/reduce-traffic.md](/doc/reduce-traffic.md). - -Direct headers announcement (BIP 130) -------------------------------------- - -Between compatible peers, [BIP 130] -(https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) -direct headers announcement is used. This means that blocks are advertised by -announcing their headers directly, instead of just announcing the hash. In a -reorganization, all new headers are sent, instead of just the new tip. This -can often prevent an extra roundtrip before the actual block is downloaded. - -Memory pool limiting --------------------- - -Previous versions of Litecoin Core had their mempool limited by checking -a transaction's fees against the node's minimum relay fee. There was no -upper bound on the size of the mempool and attackers could send a large -number of transactions paying just slighly more than the default minimum -relay fee to crash nodes with relatively low RAM. A temporary workaround -for previous versions of Litecoin Core was to raise the default minimum -relay fee. - -Litecoin Core 0.13.2 will have a strict maximum size on the mempool. The -default value is 300 MB and can be configured with the `-maxmempool` -parameter. Whenever a transaction would cause the mempool to exceed -its maximum size, the transaction that (along with in-mempool descendants) has -the lowest total feerate (as a package) will be evicted and the node's effective -minimum relay feerate will be increased to match this feerate plus the initial -minimum relay feerate. The initial minimum relay feerate is set to -1000 satoshis per kB. - -Litecoin Core 0.13.2 also introduces new default policy limits on the length and -size of unconfirmed transaction chains that are allowed in the mempool -(generally limiting the length of unconfirmed chains to 25 transactions, with a -total size of 101 KB). These limits can be overriden using command line -arguments; see the extended help (`--help -help-debug`) for more information. - -RPC: Random-cookie RPC authentication -------------------------------------- - -When no `-rpcpassword` is specified, the daemon now uses a special 'cookie' -file for authentication. This file is generated with random content when the -daemon starts, and deleted when it exits. Its contents are used as -authentication token. Read access to this file controls who can access through -RPC. By default it is stored in the data directory but its location can be -overridden with the option `-rpccookiefile`. - -This is similar to Tor's CookieAuthentication: see -https://www.torproject.org/docs/tor-manual.html.en - -This allows running litecoind without having to do any manual configuration. - -Relay: Any sequence of pushdatas in OP_RETURN outputs now allowed ------------------------------------------------------------------ - -Previously OP_RETURN outputs with a payload were only relayed and mined if they -had a single pushdata. This restriction has been lifted to allow any -combination of data pushes and numeric constant opcodes (OP_1 to OP_16) after -the OP_RETURN. The limit on OP_RETURN output size is now applied to the entire -serialized scriptPubKey, 83 bytes by default. (the previous 80 byte default plus -three bytes overhead) - -Relay: New and only new blocks relayed when pruning ---------------------------------------------------- - -When running in pruned mode, the client will now relay new blocks. When -responding to the `getblocks` message, only hashes of blocks that are on disk -and are likely to remain there for some reasonable time window (1 hour) will be -returned (previously all relevant hashes were returned). - -Relay and Mining: Priority transactions ---------------------------------------- - -Litecoin Core has a heuristic 'priority' based on coin value and age. This -calculation is used for relaying of transactions which do not pay the -minimum relay fee, and can be used as an alternative way of sorting -transactions for mined blocks. Litecoin Core will relay transactions with -insufficient fees depending on the setting of `-limitfreerelay=` (default: -`r=15` kB per minute) and `-blockprioritysize=`. - -In Bitcoin Core 0.12, when mempool limit has been reached a higher minimum -relay fee takes effect to limit memory usage. Transactions which do not meet -this higher effective minimum relay fee will not be relayed or mined even if -they rank highly according to the priority heuristic. - -The mining of transactions based on their priority is also now disabled by -default. To re-enable it, simply set `-blockprioritysize=` where is the size -in bytes of your blocks to reserve for these transactions. The old default was -50k, so to retain approximately the same policy, you would set -`-blockprioritysize=50000`. - -Additionally, as a result of computational simplifications, the priority value -used for transactions received with unconfirmed inputs is lower than in prior -versions due to avoiding recomputing the amounts as input transactions confirm. - -External miner policy set via the `prioritisetransaction` RPC to rank -transactions already in the mempool continues to work as it has previously. -Note, however, that if mining priority transactions is left disabled, the -priority delta will be ignored and only the fee metric will be effective. - -This internal automatic prioritization handling is being considered for removal -entirely in Litecoin Core 0.13, and it is at this time undecided whether the -more accurate priority calculation for chained unconfirmed transactions will be -restored. Community direction on this topic is particularly requested to help -set project priorities. - -Automatically use Tor hidden services -------------------------------------- - -Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket -API, to create and destroy 'ephemeral' hidden services programmatically. -Litecoin Core has been updated to make use of this. - -This means that if Tor is running (and proper authorization is available), -Litecoin Core automatically creates a hidden service to listen on, without -manual configuration. Litecoin Core will also use Tor automatically to connect -to other .onion nodes if the control socket can be successfully opened. This -will positively affect the number of available .onion nodes and their usage. - -This new feature is enabled by default if Litecoin Core is listening, and -a connection to Tor can be made. It can be configured with the `-listenonion`, -`-torcontrol` and `-torpassword` settings. To show verbose debugging -information, pass `-debug=tor`. - -Notifications through ZMQ -------------------------- - -Litecoind can now (optionally) asynchronously notify clients through a -ZMQ-based PUB socket of the arrival of new transactions and blocks. -This feature requires installation of the ZMQ C API library 4.x and -configuring its use through the command line or configuration file. -Please see [docs/zmq.md](/doc/zmq.md) for details of operation. - -Wallet: Transaction fees ------------------------- - -Various improvements have been made to how the wallet calculates -transaction fees. - -Users can decide to pay a predefined fee rate by setting `-paytxfee=` -(or `settxfee ` rpc during runtime). A value of `n=0` signals Litecoin -Core to use floating fees. By default, Litecoin Core will use floating -fees. - -Based on past transaction data, floating fees approximate the fees -required to get into the `m`th block from now. This is configurable -with `-txconfirmtarget=` (default: `2`). - -Sometimes, it is not possible to give good estimates, or an estimate -at all. Therefore, a fallback value can be set with `-fallbackfee=` -(default: `0.0002` LTC/kB). - -At all times, Litecoin Core will cap fees at `-maxtxfee=` (default: -0.10) LTC. -Furthermore, Litecoin Core will never create transactions paying less than -the current minimum relay fee. -Finally, a user can set the minimum fee rate for all transactions with -`-mintxfee=`, which defaults to 1000 satoshis per kB. - -Wallet: Negative confirmations and conflict detection ------------------------------------------------------ - -The wallet will now report a negative number for confirmations that indicates -how deep in the block chain the conflict is found. For example, if a transaction -A has 5 confirmations and spends the same input as a wallet transaction B, B -will be reported as having -5 confirmations. If another wallet transaction C -spends an output from B, it will also be reported as having -5 confirmations. -To detect conflicts with historical transactions in the chain a one-time -`-rescan` may be needed. - -Unlike earlier versions, unconfirmed but non-conflicting transactions will never -get a negative confirmation count. They are not treated as spendable unless -they're coming from ourself (change) and accepted into our local mempool, -however. The new "trusted" field in the `listtransactions` RPC output -indicates whether outputs of an unconfirmed transaction are considered -spendable. - -Wallet: Merkle branches removed -------------------------------- - -Previously, every wallet transaction stored a Merkle branch to prove its -presence in blocks. This wasn't being used for more than an expensive -sanity check. Since 0.13.2, these are no longer stored. When loading a -0.13.2 wallet into an older version, it will automatically rescan to avoid -failed checks. - -Wallet: Pruning ---------------- - -With 0.13.2 it is possible to use wallet functionality in pruned mode. -This can reduce the disk usage from currently around 6 GB to -around 0.2 GB. - -However, rescans as well as the RPCs `importwallet`, `importaddress`, -`importprivkey` are disabled. - -To enable block pruning set `prune=` on the command line or in -`litecoin.conf`, where `N` is the number of MiB to allot for -raw block & undo data. - -A value of 0 disables pruning. The minimal value above 0 is 550. Your -wallet is as secure with high values as it is with low ones. Higher -values merely ensure that your node will not shut down upon blockchain -reorganizations of more than 2 days - which are unlikely to happen in -practice. In future releases, a higher value may also help the network -as a whole: stored blocks could be served to other nodes. - -For further information about pruning, you may also consult the [release -notes of Bitcoin Core v0.11.0](https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning). - -`NODE_BLOOM` service bit ------------------------- - -Support for the `NODE_BLOOM` service bit, as described in [BIP -111](https://github.com/bitcoin/bips/blob/master/bip-0111.mediawiki), has been -added to the P2P protocol code. - -BIP 111 defines a service bit to allow peers to advertise that they support -bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol -version to allow peers to identify old nodes which allow bloom filtering of the -connection despite lacking the new service bit. - -In this version, it is only enforced for peers that send protocol versions -`>=70011`. For the next major version it is planned that this restriction will be -removed. It is recommended to update SPV clients to check for the `NODE_BLOOM` -service bit for nodes that report versions newer than 70011. - -Option parsing behavior ------------------------ - -Command line options are now parsed strictly in the order in which they are -specified. It used to be the case that `-X -noX` ends up, unintuitively, with X -set, as `-X` had precedence over `-noX`. This is no longer the case. Like for -other software, the last specified value for an option will hold. - -RPC: Low-level API changes --------------------------- - -- Monetary amounts can be provided as strings. This means that for example the - argument to sendtoaddress can be "0.0001" instead of 0.0001. This can be an - advantage if a JSON library insists on using a lossy floating point type for - numbers, which would be dangerous for monetary amounts. - -* The `asm` property of each scriptSig now contains the decoded signature hash - type for each signature that provides a valid defined hash type. - -* OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP 65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) - -The following items contain assembly representations of scriptSig signatures -and are affected by this change: - -- RPC `getrawtransaction` -- RPC `decoderawtransaction` -- RPC `decodescript` -- REST `/rest/tx/` (JSON format) -- REST `/rest/block/` (JSON format when including extended tx details) -- `litecoin-tx -json` - -For example, the `scriptSig.asm` property of a transaction input that -previously showed an assembly representation of: - - 304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001 400000 OP_NOP2 - -now shows as: - - 304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL] 400000 OP_CHECKLOCKTIMEVERIFY - -Note that the output of the RPC `decodescript` did not change because it is -configured specifically to process scriptPubKey and not scriptSig scripts. - -RPC: SSL support dropped ------------------------- - -SSL support for RPC, previously enabled by the option `rpcssl` has been dropped -from both the client and the server. This was done in preparation for removing -the dependency on OpenSSL for the daemon completely. - -Trying to use `rpcssl` will result in an error: - - Error: SSL mode for RPC (-rpcssl) is no longer supported. - -If you are one of the few people that relies on this feature, a flexible -migration path is to use `stunnel`. This is an utility that can tunnel -arbitrary TCP connections inside SSL. On e.g. Ubuntu it can be installed with: - - sudo apt-get install stunnel4 - -Then, to tunnel a SSL connection on 29332 to a RPC server bound on localhost on port 19334 do: - - stunnel -d 29332 -r 127.0.0.1:19334 -p stunnel.pem -P '' - -It can also be set up system-wide in inetd style. - -Another way to re-attain SSL would be to setup a httpd reverse proxy. This solution -would allow the use of different authentication, loadbalancing, on-the-fly compression and -caching. A sample config for apache2 could look like: - - Listen 443 - - NameVirtualHost *:443 - - - SSLEngine On - SSLCertificateFile /etc/apache2/ssl/server.crt - SSLCertificateKeyFile /etc/apache2/ssl/server.key - - - ProxyPass http://127.0.0.1:9332/ - ProxyPassReverse http://127.0.0.1:9332/ - # optional enable digest auth - # AuthType Digest - # ... - - # optional bypass litecoind rpc basic auth - # RequestHeader set Authorization "Basic " - # get the from the shell with: base64 <<< litecoinrpc: - - - # Or, balance the load: - # ProxyPass / balancer://balancer_cluster_name - - - -Other P2P Changes ------------------ - -The list of banned peers is now stored on disk rather than in memory. -Restarting litecoind will no longer clear out the list of banned peers; instead -a new RPC call (`clearbanned`) can be used to manually clear the list. The new -`setban` RPC call can also be used to manually ban or unban a peer. - -Database cache memory increased --------------------------------- - -As a result of growth of the UTXO set, performance with the prior default -database cache of 100 MiB has suffered. -For this reason the default was changed to 300 MiB in this release. - -For nodes on low-memory systems, the database cache can be changed back to -100 MiB (or to another value) by either: - -- Adding `dbcache=100` in litecoin.conf -- Changing it in the GUI under `Options → Size of database cache` - -Note that the database cache setting has the most performance impact -during initial sync of a node, and when catching up after downtime. - - -litecoin-cli: arguments privacy ------------------------------- - -The RPC command line client gained a new argument, `-stdin` -to read extra arguments from standard input, one per line until EOF/Ctrl-D. -For example: - - $ src/litecoin-cli -stdin walletpassphrase - mysecretcode - 120 - ..... press Ctrl-D here to end input - $ - -It is recommended to use this for sensitive information such as wallet -passphrases, as command-line arguments can usually be read from the process -table by any user on the system. - - -C++11 and Python 3 ------------------- - -Various code modernizations have been done. The Litecoin Core code base has -started using C++11. This means that a C++11-capable compiler is now needed for -building. Effectively this means GCC 4.7 or higher, or Clang 3.3 or higher. - -When cross-compiling for a target that doesn't have C++11 libraries, configure with -`./configure --enable-glibc-back-compat ... LDFLAGS=-static-libstdc++`. - -For running the functional tests in `qa/rpc-tests`, Python3.4 or higher is now -required. - - -Linux ARM builds ----------------- - -Due to popular request, Linux ARM builds have been added to the uploaded -executables. - -The following extra files can be found in the download directory or torrent: - -- `litecoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries for the most - common 32-bit ARM architecture. -- `litecoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries for the most - common 64-bit ARM architecture. - -ARM builds are still experimental. If you have problems on a certain device or -Linux distribution combination please report them on the bug tracker, it may be -possible to resolve them. - -Note that Android is not considered ARM Linux in this context. The executables -are not expected to work out of the box on Android. - -BIP68 soft fork to enforce sequence locks for relative locktime ---------------------------------------------------------------- - -[BIP68][] introduces relative lock-time consensus-enforced semantics of -the sequence number field to enable a signed transaction input to remain -invalid for a defined period of time after confirmation of its corresponding -outpoint. - -For more information about the implementation, see - - -BIP112 soft fork to enforce OP_CHECKSEQUENCEVERIFY --------------------------------------------------- - -[BIP112][] redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV) -for a new opcode in the Litecoin scripting system that in combination with -[BIP68][] allows execution pathways of a script to be restricted based -on the age of the output being spent. - -For more information about the implementation, see - - -BIP113 locktime enforcement soft fork -------------------------------------- - -This release seeks to make mempool-only locktime enforcement using GetMedianTimePast() -a consensus rule. - -Litecoin transactions currently may specify a locktime indicating when -they may be added to a valid block. Current consensus rules require -that blocks have a block header time greater than the locktime specified -in any transaction in that block. - -Miners get to choose what time they use for their header time, with the -consensus rule being that no node will accept a block whose time is more -than two hours in the future. This creates a incentive for miners to -set their header times to future values in order to include locktimed -transactions which weren't supposed to be included for up to two more -hours. - -The consensus rules also specify that valid blocks may have a header -time greater than that of the median of the 11 previous blocks. This -GetMedianTimePast() time has a key feature we generally associate with -time: it can't go backwards. - -[BIP113][] specifies a soft fork enforced in this release that -weakens this perverse incentive for individual miners to use a future -time by requiring that valid blocks have a computed GetMedianTimePast() -greater than the locktime specified in any transaction in that block. - -Mempool inclusion rules currently require transactions to be valid for -immediate inclusion in a block in order to be accepted into the mempool. -This release begins applying the BIP113 rule to received transactions, -so transaction whose time is greater than the GetMedianTimePast() will -no longer be accepted into the mempool. - -**Implication for miners:** you will begin rejecting transactions that -would not be valid under BIP113, which will prevent you from producing -invalid blocks when BIP113 is enforced on the network. Any -transactions which are valid under the current rules but not yet valid -under the BIP113 rules will either be mined by other miners or delayed -until they are valid under BIP113. Note, however, that time-based -locktime transactions are more or less unseen on the network currently. - -**Implication for users:** GetMedianTimePast() always trails behind the -current time, so a transaction locktime set to the present time will be -rejected by nodes running this release until the median time moves -forward. To compensate, subtract one hour (3,600 seconds) from your -locktimes to allow those transactions to be included in mempools at -approximately the expected time. - -For more information about the implementation, see - - - -Compact Block support (BIP 152) -------------------------------- - -Support for block relay using the Compact Blocks protocol has been implemented -in PR 8068. - -The primary goal is reducing the bandwidth spikes at relay time, though in many -cases it also reduces propagation delay. It is automatically enabled between -compatible peers. -[BIP 152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) - -As a side-effect, ordinary non-mining nodes will download and upload blocks -faster if those blocks were produced by miners using similar transaction -filtering policies. This means that a miner who produces a block with many -transactions discouraged by your node will be relayed slower than one with -only transactions already in your memory pool. The overall effect of such -relay differences on the network may result in blocks which include widely- -discouraged transactions losing a stale block race, and therefore miners may -wish to configure their node to take common relay policies into consideration. - - -Hierarchical Deterministic Key Generation ------------------------------------------ -Newly created wallets will use hierarchical deterministic key generation -according to BIP32 (keypath m/0'/0'/k'). -Existing wallets will still use traditional key generation. - -Backups of HD wallets, regardless of when they have been created, can -therefore be used to re-generate all possible private keys, even the -ones which haven't already been generated during the time of the backup. -**Attention:** Encrypting the wallet will create a new seed which requires -a new backup! - -Wallet dumps (created using the `dumpwallet` RPC) will contain the deterministic -seed. This is expected to allow future versions to import the seed and all -associated funds, but this is not yet implemented. - -HD key generation for new wallets can be disabled by `-usehd=0`. Keep in -mind that this flag only has affect on newly created wallets. -You can't disable HD key generation once you have created a HD wallet. - -There is no distinction between internal (change) and external keys. - -HD wallets are incompatible with older versions of Litecoin Core. - -[Pull request](https://github.com/bitcoin/bitcoin/pull/8035/files), [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) - - -Mining transaction selection ("Child Pays For Parent") ------------------------------------------------------- - -The mining transaction selection algorithm has been replaced with an algorithm -that selects transactions based on their feerate inclusive of unconfirmed -ancestor transactions. This means that a low-fee transaction can become more -likely to be selected if a high-fee transaction that spends its outputs is -relayed. - -With this change, the `-blockminsize` command line option has been removed. - -The command line option `-blockmaxsize` remains an option to specify the -maximum number of serialized bytes in a generated block. In addition, the new -command line option `-blockmaxweight` has been added, which specifies the -maximum "block weight" of a generated block, as defined by [BIP 141 (Segregated -Witness)] (https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki). - -In preparation for Segregated Witness, the mining algorithm has been modified -to optimize transaction selection for a given block weight, rather than a given -number of serialized bytes in a block. In this release, transaction selection -is unaffected by this distinction (as BIP 141 activation is not supported on -mainnet in this release, see above), but in future releases and after BIP 141 -activation, these calculations would be expected to differ. - -For optimal runtime performance, miners using this release should specify -`-blockmaxweight` on the command line, and not specify `-blockmaxsize`. -Additionally (or only) specifying `-blockmaxsize`, or relying on default -settings for both, may result in performance degradation, as the logic to -support `-blockmaxsize` performs additional computation to ensure that -constraint is met. (Note that for mainnet, in this release, the equivalent -parameter for `-blockmaxweight` would be four times the desired -`-blockmaxsize`. See [BIP 141] -(https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) for additional -details.) - -In the future, the `-blockmaxsize` option may be removed, as block creation is -no longer optimized for this metric. Feedback is requested on whether to -deprecate or keep this command line option in future releases. - - -Reindexing changes ------------------- - -In earlier versions, reindexing did validation while reading through the block -files on disk. These two have now been split up, so that all blocks are known -before validation starts. This was necessary to make certain optimizations that -are available during normal synchronizations also available during reindexing. - -The two phases are distinct in the Litecoin-Qt GUI. During the first one, -"Reindexing blocks on disk" is shown. During the second (slower) one, -"Processing blocks on disk" is shown. - -It is possible to only redo validation now, without rebuilding the block index, -using the command line option `-reindex-chainstate` (in addition to -`-reindex` which does both). This new option is useful when the blocks on disk -are assumed to be fine, but the chainstate is still corrupted. It is also -useful for benchmarks. - - -Removal of internal miner --------------------------- - -As CPU mining has been useless for a long time, the internal miner has been -removed in this release, and replaced with a simpler implementation for the -test framework. - -The overall result of this is that `setgenerate` RPC call has been removed, as -well as the `-gen` and `-genproclimit` command-line options. - -For testing, the `generate` call can still be used to mine a block, and a new -RPC call `generatetoaddress` has been added to mine to a specific address. This -works with wallet disabled. - - -New bytespersigop implementation --------------------------------- - -The former implementation of the bytespersigop filter accidentally broke bare -multisig (which is meant to be controlled by the `permitbaremultisig` option), -since the consensus protocol always counts these older transaction forms as 20 -sigops for backwards compatibility. Simply fixing this bug by counting more -accurately would have reintroduced a vulnerability. It has therefore been -replaced with a new implementation that rather than filter such transactions, -instead treats them (for fee purposes only) as if they were in fact the size -of a transaction actually using all 20 sigops. - - -Low-level P2P changes ----------------------- - -- The optional new p2p message "feefilter" is implemented and the protocol - version is bumped to 70013. Upon receiving a feefilter message from a peer, - a node will not send invs for any transactions which do not meet the filter - feerate. [BIP 133](https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki) - -- The P2P alert system has been removed in PR #7692 and the `alert` P2P message - is no longer supported. - -- The transaction relay mechanism used to relay one quarter of all transactions - instantly, while queueing up the rest and sending them out in batch. As - this resulted in chains of dependent transactions being reordered, it - systematically hurt transaction relay. The relay code was redesigned in PRs - \#7840 and #8082, and now always batches transactions announcements while also - sorting them according to dependency order. This significantly reduces orphan - transactions. To compensate for the removal of instant relay, the frequency of - batch sending was doubled for outgoing peers. - -- Since PR #7840 the BIP35 `mempool` command is also subject to batch processing. - Also the `mempool` message is no longer handled for non-whitelisted peers when - `NODE_BLOOM` is disabled through `-peerbloomfilters=0`. - -- The maximum size of orphan transactions that are kept in memory until their - ancestors arrive has been raised in PR #8179 from 5000 to 99999 bytes. They - are now also removed from memory when they are included in a block, conflict - with a block, and time out after 20 minutes. - -- We respond at most once to a getaddr request during the lifetime of a - connection since PR #7856. - -- Connections to peers who have recently been the first one to give us a valid - new block or transaction are protected from disconnections since PR #8084. - - -Low-level RPC changes ----------------------- - -- RPC calls have been added to output detailed statistics for individual mempool - entries, as well as to calculate the in-mempool ancestors or descendants of a - transaction: see `getmempoolentry`, `getmempoolancestors`, `getmempooldescendants`. - -- `gettxoutsetinfo` UTXO hash (`hash_serialized`) has changed. There was a divergence between - 32-bit and 64-bit platforms, and the txids were missing in the hashed data. This has been - fixed, but this means that the output will be different than from previous versions. - -- Full UTF-8 support in the RPC API. Non-ASCII characters in, for example, - wallet labels have always been malformed because they weren't taken into account - properly in JSON RPC processing. This is no longer the case. This also affects - the GUI debug console. - -- Asm script outputs replacements for OP_NOP2 and OP_NOP3 - - - OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP -65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) - - - OP_NOP3 has been renamed to OP_CHECKSEQUENCEVERIFY by [BIP -112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki) - - - The following outputs are affected by this change: - - - RPC `getrawtransaction` (in verbose mode) - - RPC `decoderawtransaction` - - RPC `decodescript` - - REST `/rest/tx/` (JSON format) - - REST `/rest/block/` (JSON format when including extended tx details) - - `litecoin-tx -json` - -- The sorting of the output of the `getrawmempool` output has changed. - -- New RPC commands: `generatetoaddress`, `importprunedfunds`, `removeprunedfunds`, `signmessagewithprivkey`, - `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry`, - `createwitnessaddress`, `addwitnessaddress`. - -- Removed RPC commands: `setgenerate`, `getgenerate`. - -- New options were added to `fundrawtransaction`: `includeWatching`, `changeAddress`, `changePosition` and `feeRate`. - - -Low-level ZMQ changes ----------------------- - -- Each ZMQ notification now contains an up-counting sequence number that allows - listeners to detect lost notifications. - The sequence number is always the last element in a multi-part ZMQ notification and - therefore backward compatible. Each message type has its own counter. - PR [#7762](https://github.com/bitcoin/bitcoin/pull/7762). - -Segregated witness soft fork ----------------------------- - -Segregated witness (segwit) is a soft fork that, if activated, will -allow transaction-producing software to separate (segregate) transaction -signatures (witnesses) from the part of the data in a transaction that is -covered by the txid. This provides several immediate benefits: - -- **Elimination of unwanted transaction malleability:** Segregating the witness - allows both existing and upgraded software to calculate the transaction - identifier (txid) of transactions without referencing the witness, which can - sometimes be changed by third-parties (such as miners) or by co-signers in a - multisig spend. This solves all known cases of unwanted transaction - malleability, which is a problem that makes programming Litecoin wallet - software more difficult and which seriously complicates the design of smart - contracts for Litecoin. - -- **Capacity increase:** Segwit transactions contain new fields that are not - part of the data currently used to calculate the size of a block, which - allows a block containing segwit transactions to hold more data than allowed - by the current maximum block size. Estimates based on the transactions - currently found in blocks indicate that if all wallets switch to using - segwit, the network will be able to support about 70% more transactions. The - network will also be able to support more of the advanced-style payments - (such as multisig) than it can support now because of the different weighting - given to different parts of a transaction after segwit activates (see the - following section for details). - -- **Weighting data based on how it affects node performance:** Some parts of - each Litecoin block need to be stored by nodes in order to validate future - blocks; other parts of a block can be immediately forgotten (pruned) or used - only for helping other nodes sync their copy of the block chain. One large - part of the immediately prunable data are transaction signatures (witnesses), - and segwit makes it possible to give a different "weight" to segregated - witnesses to correspond with the lower demands they place on node resources. - Specifically, each byte of a segregated witness is given a weight of 1, each - other byte in a block is given a weight of 4, and the maximum allowed weight - of a block is 4 million. Weighting the data this way better aligns the most - profitable strategy for creating blocks with the long-term costs of block - validation. - -- **Signature covers value:** A simple improvement in the way signatures are - generated in segwit simplifies the design of secure signature generators - (such as hardware wallets), reduces the amount of data the signature - generator needs to download, and allows the signature generator to operate - more quickly. This is made possible by having the generator sign the amount - of litecoins they think they are spending, and by having full nodes refuse to - accept those signatures unless the amount of litecoins being spent is exactly - the same as was signed. For non-segwit transactions, wallets instead had to - download the complete previous transactions being spent for every payment - they made, which could be a slow operation on hardware wallets and in other - situations where bandwidth or computation speed was constrained. - -- **Linear scaling of sighash operations:** In 2015 a block was produced that - required about 25 seconds to validate on modern hardware because of the way - transaction signature hashes are performed. Other similar blocks, or blocks - that could take even longer to validate, can still be produced today. The - problem that caused this can't be fixed in a soft fork without unwanted - side-effects, but transactions that opt-in to using segwit will now use a - different signature method that doesn't suffer from this problem and doesn't - have any unwanted side-effects. - -- **Increased security for multisig:** Litecoin addresses (both P2PKH addresses - that start with a '1' and P2SH addresses that start with a '3' or 'M') use a hash - function known as RIPEMD-160. For P2PKH addresses, this provides about 160 - bits of security---which is beyond what cryptographers believe can be broken - today. But because P2SH is more flexible, only about 80 bits of security is - provided per address. Although 80 bits is very strong security, it is within - the realm of possibility that it can be broken by a powerful adversary. - Segwit allows advanced transactions to use the SHA256 hash function instead, - which provides about 128 bits of security (that is 281 trillion times as - much security as 80 bits and is equivalent to the maximum bits of security - believed to be provided by Litecoin's choice of parameters for its Elliptic - Curve Digital Security Algorithm [ECDSA].) - -- **More efficient almost-full-node security** Satoshi Nakamoto's original - Bitcoin paper describes a method for allowing newly-started full nodes to - skip downloading and validating some data from historic blocks that are - protected by large amounts of proof of work. Unfortunately, Nakamoto's - method can't guarantee that a newly-started node using this method will - produce an accurate copy of Litecoin's current ledger (called the UTXO set), - making the node vulnerable to falling out of consensus with other nodes. - Although the problems with Nakamoto's method can't be fixed in a soft fork, - Segwit accomplishes something similar to his original proposal: it makes it - possible for a node to optionally skip downloading some blockchain data - (specifically, the segregated witnesses) while still ensuring that the node - can build an accurate copy of the UTXO set for the block chain with the most - proof of work. Segwit enables this capability at the consensus layer, but - note that Litecoin Core does not provide an option to use this capability as - of this 0.13.2 release. - -- **Script versioning:** Segwit makes it easy for future soft forks to allow - Litecoin users to individually opt-in to almost any change in the Litecoin - Script language when those users receive new transactions. Features - currently being researched by Bitcoin and Litecoin Core contributors that may - use this capability include support for Schnorr signatures, which can improve - the privacy and efficiency of multisig transactions (or transactions with - multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can - improve the privacy and efficiency of scripts with two or more conditions. - Other Bitcoin community members are studying several other improvements - that can be made using script versioning. - -Activation for the segwit soft fork is being managed using -BIP9. At the beginning of the first retarget period after -segwit's start date of 1 January 2017 miners can update the Litecoin -client to Litecoin Core 0.13.2 to signal for segwit support. When a -super-majority of 75% is reached segwit is activated by optional, and -if 75% of blocks within a 8,064-block retarget period (about 3.5 days) -signal support for segwit, after another 8,064 blocks, segwit will -be required. - -For more information about segwit, please see the [segwit FAQ][], the -[segwit wallet developers guide][] or BIPs [141][BIP141], [143][BIP143], -[144][BIP144], and [145][BIP145]. - -[Segwit FAQ]: https://bitcoincore.org/en/2016/01/26/segwit-benefits/ -[segwit wallet developers guide]: https://bitcoincore.org/en/segwit_wallet_dev/ -[BIP141]: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki -[BIP143]: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki -[BIP144]: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki -[BIP145]: https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki - - -Null dummy soft fork -------------------- - -Combined with the segwit soft fork is an additional change that turns a -long-existing network relay policy into a consensus rule. The -`OP_CHECKMULTISIG` and `OP_CHECKMULTISIGVERIFY` opcodes consume an extra -stack element ("dummy element") after signature validation. The dummy -element is not inspected in any manner, and could be replaced by any -value without invalidating the script. - -Because any value can be used for this dummy element, it's possible for -a third-party to insert data into other people's transactions, changing -the transaction's txid (called transaction malleability) and possibly -causing other problems. - -Since Litecoin Core 0.10.0, nodes have defaulted to only relaying and -mining transactions whose dummy element was a null value (0x00, also -called OP_0). The null dummy soft fork turns this relay rule into a -consensus rule both for non-segwit transactions and segwit transactions, -so that this method of mutating transactions is permanently eliminated -from the network. - -Signaling for the null dummy soft fork is done by signaling support -for segwit, and the null dummy soft fork will activate at the same time -as segwit. - -For more information, please see [BIP147][]. - -[BIP147]: https://github.com/bitcoin/bips/blob/master/bip-0147.mediawiki - -Low-level RPC changes ---------------------- - -- `importprunedfunds` only accepts two required arguments. Some versions accept - an optional third arg, which was always ignored. Make sure to never pass more - than two arguments. - - -Linux ARM builds ----------------- - -Pre-built Linux ARM binaries have been added to the set of uploaded executables. -Additional detail on the ARM architecture targeted by each is provided below. - -The following extra files can be found in the download directory or torrent: - -- `litecoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries targeting - the 32-bit ARMv7-A architecture. -- `litecoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries targeting - the 64-bit ARMv8-A architecture. - -ARM builds are still experimental. If you have problems on a certain device or -Linux distribution combination please report them on the bug tracker, it may be -possible to resolve them. Note that the device you use must be (backward) -compatible with the architecture targeted by the binary that you use. -For example, a Raspberry Pi 2 Model B or Raspberry Pi 3 Model B (in its 32-bit -execution state) device, can run the 32-bit ARMv7-A targeted binary. However, -no model of Raspberry Pi 1 device can run either binary because they are all -ARMv6 architecture devices that are not compatible with ARMv7-A or ARMv8-A. - -Note that Android is not considered ARM Linux in this context. The executables -are not expected to work out of the box on Android. - - -Change to wallet handling of mempool rejection ------------------------------------------------ - -When a newly created transaction failed to enter the mempool due to -the limits on chains of unconfirmed transactions the sending RPC -calls would return an error. The transaction would still be queued -in the wallet and, once some of the parent transactions were -confirmed, broadcast after the software was restarted. - -This behavior has been changed to return success and to reattempt -mempool insertion at the same time transaction rebroadcast is -attempted, avoiding a need for a restart. - -Transactions in the wallet which cannot be accepted into the mempool -can be abandoned with the previously existing abandontransaction RPC -(or in the GUI via a context menu on the transaction). Credits ======= @@ -983,11 +57,6 @@ Credits Thanks to everyone who directly contributed to this release: - [The Bitcoin Core Developers](/doc/release-notes) -- Charles Lee - Adrian Gallagher - shaolinfry - Xinxi Wang -- Xinrong Guo -- Fan Yang -- Peng Sun -- Loshan T