shaolinfry
7 years ago
committed by
Adrian Gallagher
2 changed files with 1041 additions and 0 deletions
@ -0,0 +1,993 @@
@@ -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 @@
@@ -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