doc: Update release notes from wiki

doc/release-notes.md

@@ -1,9 +1,9 @@
 (note: this is a temporary file, to be added-to by anybody, and moved to
 release-notes at release time)
 
-Bitcoin Core version *version* is now available from:
+Bitcoin Core version 0.14.0 is now available from:
 
-  <https://bitcoin.org/bin/bitcoin-core-*version*/>
+  <https://bitcoin.org/bin/bitcoin-core-0.14.0/>
 
 This is a new major version release, including new features, various bugfixes
 and performance improvements, as well as updated translations.
@@ -22,9 +22,9 @@ Compatibility
 Bitcoin Core is extensively tested on multiple operating systems using
 the Linux kernel, macOS 10.8+, and Windows Vista and later.
 
-Microsoft ended support for Windows XP on [April 8th, 2014](https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support).
+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.
+can still do so at your own risk but be aware that there are known instabilities and issues.
 Please 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
@@ -33,6 +33,167 @@ frequently tested on them.
 Notable changes
 ===============
 
+Manual Pruning
+--------------
+
+Bitcoin Core has supported automatically pruning the blockchain since 0.11. Pruning
+the blockchain allows for significant storage space savings as the vast majority of
+the downloaded data can be discarded after processing so very little of it remains
+on the disk.
+
+Manual block pruning can now be enabled by setting `-prune=1`. Once that is set,
+the RPC command `pruneblockchain` can be used to prune the blockchain up to the
+specified height or timestamp.
+
+`getinfo` Deprecated
+--------------------
+
+The `getinfo` RPC command has been deprecated. Each field in the RPC call
+has been moved to another command's output with that command also giving
+additional information that `getinfo` did not provide. The following table
+shows where each field has been moved to:
+
+|`getinfo` field   | Moved to                                  |
+|------------------|-------------------------------------------|
+`"version"`	   | `getnetworkinfo()["version"]`
+`"protocolversion"`| `getnetworkinfo()["protocolversion"]`
+`"walletversion"`  | `getwalletinfo()["walletversion"]`
+`"balance"`	   | `getwalletinfo()["balance"]`
+`"blocks"`	   | `getblockchaininfo()["blocks"]`
+`"timeoffset"`	   | `getnetworkinfo()["timeoffset"]`
+`"connections"`	   | `getnetworkinfo()["connections"]`
+`"proxy"`	   | `getnetworkinfo()["networks"][0]["proxy"]`
+`"difficulty"`	   | `getblockchaininfo()["difficulty"]`
+`"testnet"`	   | `getblockchaininfo()["chain"] == "test"`
+`"keypoololdest"`  | `getwalletinfo()["keypoololdest"]`
+`"keypoolsize"`	   | `getwalletinfo()["keypoolsize"]`
+`"unlocked_until"` | `getwalletinfo()["unlocked_until"]`
+`"paytxfee"`	   | `getwalletinfo()["paytxfee"]`
+`"relayfee"`	   | `getnetworkinfo()["relayfee"]`
+`"errors"`	   | `getnetworkinfo()["warnings"]`
+
+ZMQ On Windows
+--------------
+
+Previously the ZeroMQ notification system was unavailable on Windows
+due to various issues with ZMQ. These have been fixed upstream and
+now ZMQ can be used on Windows. Please see [this document](https://github.com/bitcoin/bitcoin/blob/master/doc/zmq.md) for
+help with using ZMQ in general.
+
+Nested RPC Commands in Debug Console
+------------------------------------
+
+The ability to nest RPC commands has been added to the debug console. This
+allows users to have the output of a command become the input to another
+command without running the commands separately.
+
+The nested RPC commands use bracket syntax (i.e. `getwalletinfo()`) and can
+be nested (i.e. `getblock(getblockhash(1))`). Simple queries can be
+done with square brackets where object values are accessed with either an 
+array index or a non-quoted string (i.e. `listunspent()[0][txid]`). Both
+commas and spaces can be used to separate parameters in both the bracket syntax
+and normal RPC command syntax.
+
+Network Activity Toggle
+-----------------------
+
+A RPC command and GUI toggle have been added to enable or disable all p2p
+network activity. The network status icon in the bottom right hand corner 
+is now the GUI toggle. Clicking the icon will either enable or disable all
+p2p network activity. If network activity is disabled, the icon will 
+be grayed out with an X on top of it.
+
+Additionally the `setnetworkactive` RPC command has been added which does
+the same thing as the GUI icon. The command takes one boolean parameter,
+`true` enables networking and `false` disables it.
+
+Out-of-sync Modal Info Layer
+----------------------------
+
+When Bitcoin Core is out-of-sync on startup, a semi-transparent information
+layer will be shown over top of the normal display. This layer contains
+details about the current sync progress and estimates the amount of time
+remaining to finish syncing. This layer can also be hidden and subsequently
+unhidden by clicking on the progress bar at the bottom of the window.
+
+Support for JSON-RPC Named Arguments
+------------------------------------
+
+Commands sent over the JSON-RPC interface and through the `bitcoin-cli` binary
+can now use named arguments. This follows the [JSON-RPC specification](http://www.jsonrpc.org/specification)
+for passing parameters by-name with an object.
+
+`bitcoin-cli` has been updated to support this by parsing `name=value` arguments
+when the `-named` option is given.
+
+Some examples:
+
+    src/bitcoin-cli -named help command="help"
+    src/bitcoin-cli -named getblockhash height=0
+    src/bitcoin-cli -named getblock blockhash=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
+    src/bitcoin-cli -named sendtoaddress address="(snip)" amount="1.0" subtractfeefromamount=true
+
+The order of arguments doesn't matter in this case. Named arguments are also
+useful to leave out arguments that should stay at their default value. The
+rarely-used arguments `comment` and `comment_to` to `sendtoaddress`, for example, can
+be left out. However, this is not yet implemented for many RPC calls, this is
+expected to land in a later release.
+
+The RPC server remains fully backwards compatible with positional arguments.
+
+Opt into RBF When Sending
+-------------------------
+
+A new startup option, `-walletrbf`, has been added to allow users to have all
+transactions sent opt into RBF support. The default value for this option is
+currently `false`, so transactions will not opt into RBF by default.
+
+Sensitive Data Is No Longer Stored In Debug Console History
+-----------------------------------------------------------
+
+The debug console maintains a history of previously entered commands that can be
+accessed by pressing the Up-arrow key so that users can easily reuse previously
+entered commands. Commands which have sensitive information such as passphrases and
+private keys will now have a `(...)` in place of the parameters when accessed through
+the history.
+
+Retaining the Mempool Across Restarts
+-------------------------------------
+
+The mempool will be saved to the data directory prior to shutdown
+to a `mempool.dat` file. This file preserves the mempool so that when the node
+restarts the mempool can be filled with transactions without waiting for new transactions
+to be created. This will also preserve any changes made to a transaction through
+commands such as `prioritisetransaction` so that those changes will not be lost.
+
+Final Alert
+-----------
+
+The Alert System was [disabled and deprecated](https://bitcoin.org/en/alert/2016-11-01-alert-retirement) in Bitcoin Core 0.12.1 and removed in 0.13.0. 
+To Alert System was retired with a maximum sequence final alert which causes any nodes
+supporting the Alert System to display a static hard-coded "Alert Key Compromised" message which also
+prevents any other alerts from overriding it. This final alert is hard-coded into this release
+so that all old nodes receive the final alert.
+
+GUI Changes
+-----------
+
+ - After resetting the options by clicking the `Reset Options` button 
+   in the options dialog or with the `-resetguioptions` startup option, 
+   the user will be prompted to choose the data directory again. This 
+   is to ensure that custom data directories will be kept after the 
+   option reset which clears the custom data directory set via the choose 
+   datadir dialog.
+
+ - Multiple peers can now be selected in the list of peers in the debug 
+   window. This allows for users to ban or disconnect multiple peers 
+   simultaneously instead of banning them one at a time.
+
+ - An indicator has been added to the bottom right hand corner of the main
+   window to indicate whether the wallet being used is a HD wallet. This
+   icon will be grayed out with an X on top of it if the wallet is not a
+   HD wallet.
+
 Low-level RPC changes
 ----------------------
 
@@ -40,11 +201,54 @@ Low-level RPC changes
    an optional third arg, which was always ignored. Make sure to never pass more
    than two arguments.
 
+ - The first boolean argument to `getaddednodeinfo` has been removed. This is 
+   an incompatible change.
+
+ - RPC command "getmininginfo" loses the "testnet" field in favor of the more
+   generic "chain" (which has been present for years).
+
+ - A new RPC command `preciousblock` has been added which marks a block as
+   precious. A precious block will be treated as if it were received earlier
+   than a competing block.
+
+ - A new RPC command `importmulti` has been added which receives an array of 
+   JSON objects representing the intention of importing a public key, a 
+   private key, an address and script/p2sh
+
+ - Use of `getrawtransaction` for retrieving confirmed transactions with unspent
+   outputs has been deprecated. For now this will still work, but in the future
+   it may change to only be able to retrieve information about transactions in
+   the mempool or if `txindex` is enabled.
+
+ - A new RPC command `getmemoryinfo` has been added which will return information
+   about the memory usage of Bitcoin Core. This was added in conjunction with
+   optimizations to memory management. See [Pull #8753](https://github.com/bitcoin/bitcoin/pull/8753)
+   for more information.
+
+HTTP REST Changes
+-----------------
+
+ - 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.
+
+Minimum Fee Rate Policies
+-------------------------
+
+Since the changes in 0.12 to automatically limit the size of the mempool and improve the performance of block creation in mining code it has not been important for relay nodes or miners to set `-minrelaytxfee`. With this release the following concepts that were tied to this option have been separated out:
+- incremental relay fee used for calculating BIP 125 replacement and mempool limiting. (1000 satoshis/kB)
+- calculation of threshold for a dust output. (effectively 3 * 1000 satoshis/kB)
+- minimum fee rate of a package of transactions to be included in a block created by the mining code. If miners wish to set this minimum they can use the new `-blockmintxfee` option.  (defaults to 1000 satoshis/kB)
+
+The `-minrelaytxfee` option continues to exist but is recommended to be left unset.
+
 Fee Estimation Changes
 ----------------------
 
 - 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
+  disabled. The fee slider will no longer be able to choose a target of 1 block.
+  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.
 
@@ -52,7 +256,7 @@ Fee Estimation Changes
   (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
@@ -61,42 +265,20 @@ Removal of Priority Estimation
   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.
+- Support for "priority" (coin age) transaction sorting for mining is
+  considered deprecated in Core and will be removed in the next major version.
+  This is not to be confused with the `prioritisetransaction` RPC which will remain
+  supported by Core for adding fee deltas to transactions.
 
 P2P connection management
 --------------------------
 
-- Peers manually added through the addnode option or addnode RPC now have their own
+- 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
--------------------------------------
+  connection usage and is not subject to the limitation imposed by the `-maxconnections`
+  option.
 
-- 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
+- New connections to manually added peers are performed more quickly.
 
 0.14.0 Change log
 =================
@@ -108,14 +290,6 @@ git merge commit are mentioned.
 
 ### RPC and REST
 
-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.
-
-The first boolean argument to `getaddednodeinfo` has been removed. This is an incompatible change.
-
-Call "getmininginfo" loses the "testnet" field in favor of the more generic "chain" (which has been present for years).
-
 ### Configuration and command-line options
 
 ### Block and transaction handling
@@ -128,16 +302,6 @@ Call "getmininginfo" loses the "testnet" field in favor of the more generic "cha
 
 ### Wallet
 
-0.14.0 Fundrawtransaction change address reuse
-==============================================
-
-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.
-
-Since 0.14, fundrawtransaction does reserve the change-output-key from the keypool by default (optional by setting  `reserveChangeKey`, default = `true`)
-
-Users should also consider using `getrawchangeaddress()` in conjunction with `fundrawtransaction`'s `changeAddress` option.
-
 ### GUI
 
 ### Tests