![shaolinfry@protonmail.ch](/assets/img/avatar_default.png)
![Adrian Gallagher](/assets/img/avatar_default.png)
2 changed files with 1041 additions and 0 deletions
@ -0,0 +1,993 @@ |
|||||||
|
Litecoin Core version 0.13.2 is now available from: |
||||||
|
|
||||||
|
<https://download.litecoin.org/litecoin-0.13.2.1/> |
||||||
|
|
||||||
|
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: |
||||||
|
|
||||||
|
<https://github.com/litecoin-project/litecoin/issues> |
||||||
|
|
||||||
|
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=<r>` (default: |
||||||
|
`r=15` kB per minute) and `-blockprioritysize=<s>`. |
||||||
|
|
||||||
|
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=<n>` 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=<n>` |
||||||
|
(or `settxfee <n>` 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=<m>` (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=<f>` |
||||||
|
(default: `0.0002` LTC/kB). |
||||||
|
|
||||||
|
At all times, Litecoin Core will cap fees at `-maxtxfee=<x>` (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=<i>`, 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=<N>` 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 |
||||||
|
<VirtualHost *:443> |
||||||
|
|
||||||
|
SSLEngine On |
||||||
|
SSLCertificateFile /etc/apache2/ssl/server.crt |
||||||
|
SSLCertificateKeyFile /etc/apache2/ssl/server.key |
||||||
|
|
||||||
|
<Location /litecoinrpc> |
||||||
|
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 <hash>" |
||||||
|
# get the <hash> from the shell with: base64 <<< litecoinrpc:<password> |
||||||
|
</Location> |
||||||
|
|
||||||
|
# Or, balance the load: |
||||||
|
# ProxyPass / balancer://balancer_cluster_name |
||||||
|
|
||||||
|
</VirtualHost> |
||||||
|
|
||||||
|
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 |
||||||
|
<https://github.com/bitcoin/bitcoin/pull/7184> |
||||||
|
|
||||||
|
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 |
||||||
|
<https://github.com/bitcoin/bitcoin/pull/7524> |
||||||
|
|
||||||
|
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 |
||||||
|
<https://github.com/bitcoin/bitcoin/pull/6566> |
||||||
|
|
||||||
|
|
||||||
|
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 |
@ -0,0 +1,48 @@ |
|||||||
|
Litecoin Core version 0.14.0 is now available from: |
||||||
|
|
||||||
|
<https://download.litecoin.org/litecoin-0.14.0/> |
||||||
|
|
||||||
|
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: |
||||||
|
|
||||||
|
<https://github.com/litecoin-project/litecoin/issues> |
||||||
|
|
||||||
|
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 |
||||||
|
=============== |
||||||
|
|
||||||
|
Credits |
||||||
|
======= |
||||||
|
|
||||||
|
Thanks to everyone who directly contributed to this release: |
||||||
|
|
||||||
|
- [The Bitcoin Core Developers](/doc/release-notes) |
||||||
|
- Adrian Gallagher |
||||||
|
- shaolinfry |
Loading…
Reference in new issue