diff options
Diffstat (limited to 'doc/release-notes.md')
| -rw-r--r-- | doc/release-notes.md | 230 |
1 files changed, 88 insertions, 142 deletions
diff --git a/doc/release-notes.md b/doc/release-notes.md index 3d2baaaaea..0ea9e1949e 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -19,103 +19,86 @@ To receive security and update notifications, please subscribe to: 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 bitcoin -wallet on a XP machine is irresponsible at least. +Bitcoin Core is extensively tested on multiple operating systems using +the Linux kernel, macOS 10.8+, and Windows Vista and later. -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. +Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support). +No attempt is made to prevent installing or running the software on Windows XP, you +can still do so at your own risk but be aware that there are known instabilities. +Please do not report issues about Windows XP to the issue tracker. -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 verion 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. +Bitcoin Core should also work on most other Unix-like systems but is not +frequently tested on them. Notable changes =============== -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 bitcoin.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. - -bitcoin-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: - - $ echo -e "mysecretcode\n120" | src/bitcoin-cli -stdin walletpassphrase - -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. - -RPC low-level changes +Low-level RPC changes ---------------------- -- `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. - -C++11 and Python 3 -------------------- - -Various code modernizations have been done. The Bitcoin 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. +- `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. -The following extra files can be found in the download directory or torrent: - -- `bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries for the most - common 32-bit ARM architecture. -- `bitcoin-${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. +Fee Estimation Changes +---------------------- -0.13.0 Change log +- Since 0.13.2 fee estimation for a confirmation target of 1 block has been + disabled. This is only a minor behavior change as there was often insufficient + data for this target anyway. `estimatefee 1` will now always return -1 and + `estimatesmartfee 1` will start searching at a target of 2. + +- The default target for fee estimation is changed to 6 blocks in both the GUI + (previously 25) and for RPC calls (previously 2). + +Removal of Priority Estimation +------------------------------- + +- Estimation of "priority" needed for a transaction to be included within a target + number of blocks has been removed. The rpc calls are deprecated and will either + return -1 or 1e24 appropriately. The format for `fee_estimates.dat` has also + changed to no longer save these priority estimates. It will automatically be + converted to the new format which is not readable by prior versions of the + software. + +- The concept of "priority" (coin age) transactions is planned to be removed in + the next major version. To prepare for this, the default for the rate limit of + priority transactions (`-limitfreerelay`) has been set to `0` kB/minute. This + is not to be confused with the `prioritisetransaction` RPC which will remain + supported for adding fee deltas to transactions. + +P2P connection management +-------------------------- + +- Peers manually added through the addnode option or addnode RPC now have their own + limit of eight connections which does not compete with other inbound or outbound + connection usage and is not subject to the maxconnections limitation. + +- New connections to manually added peers are much faster. + +Introduction of assumed-valid blocks +------------------------------------- + +- A significant portion of the initial block download time is spent verifying + scripts/signatures. Although the verification must pass to ensure the security + of the system, no other result from this verification is needed: If the node + knew the history of a given block were valid it could skip checking scripts + for its ancestors. + +- A new configuration option 'assumevalid' is provided to express this knowledge + to the software. Unlike the 'checkpoints' in the past this setting does not + force the use of a particular chain: chains that are consistent with it are + processed quicker, but other chains are still accepted if they'd otherwise + be chosen as best. Also unlike 'checkpoints' the user can configure which + block history is assumed true, this means that even outdated software can + sync more quickly if the setting is updated by the user. + +- Because the validity of a chain history is a simple objective fact it is much + easier to review this setting. As a result the software ships with a default + value adjusted to match the current chain shortly before release. The use + of this default value can be disabled by setting -assumevalid=0 + +0.14.0 Change log ================= Detailed release notes follow. This overview includes changes that affect @@ -125,38 +108,13 @@ git merge commit are mentioned. ### RPC and REST -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) -- `bitcoin-tx -json` - -New mempool information RPC calls ---------------------------------- - -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`. +UTXO set query (`GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n>/.../<txid>-<n>.<bin|hex|json>`) responses +were changed to return status code HTTP_BAD_REQUEST (400) instead of HTTP_INTERNAL_SERVER_ERROR (500) when requests +contain invalid parameters. -### ZMQ +The first boolean argument to `getaddednodeinfo` has been removed. This is an incompatible change. -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. -(https://github.com/bitcoin/bitcoin/pull/7762) +Call "getmininginfo" loses the "testnet" field in favor of the more generic "chain" (which has been present for years). ### Configuration and command-line options @@ -164,40 +122,21 @@ Each message type has its own counter. ### P2P protocol and network code -The p2p alert system has been removed in #7692 and the 'alert' message is no longer supported. - - -Fee filtering of invs (BIP 133) ------------------------------------- - -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) - ### Validation ### Build system ### Wallet -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. +0.14.0 Fundrawtransaction change address reuse +============================================== -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. +Before 0.14, `fundrawtransaction` was by default wallet stateless. In almost all cases `fundrawtransaction` does add a change-output to the outputs of the funded transaction. Before 0.14, the used keypool key was never marked as change-address key and directly returned to the keypool (leading to address reuse). +Before 0.14, calling `getnewaddress` directly after `fundrawtransaction` did generate the same address as the change-output address. -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. +Since 0.14, fundrawtransaction does reserve the change-output-key from the keypool by default (optional by setting `reserveChangeKey`, default = `true`) -There is no distinction between internal (change) and external keys. - -[Pull request](https://github.com/bitcoin/bitcoin/pull/8035/files), [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) +Users should also consider using `getrawchangeaddress()` in conjunction with `fundrawtransaction`'s `changeAddress` option. ### GUI @@ -205,3 +144,10 @@ There is no distinction between internal (change) and external keys. ### Miscellaneous +Credits +======= + +Thanks to everyone who directly contributed to this release: + + +As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/). |