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
Low-level RPC changes
----------------------
----------------------
- `importprunedfunds` only accepts two required arguments. Some versions accept
- `importprunedfunds` only accepts two required arguments. Some versions accept
an optional third arg, which was always ignored. Make sure to never pass more
an optional third arg, which was always ignored. Make sure to never pass more
than two arguments.
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
Fee Estimation Changes
----------------------
----------------------
- Since 0.13.2 fee estimation for a confirmation target of 1 block has been
- 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
data for this target anyway. `estimatefee 1` will now always return -1 and
`estimatesmartfee 1` will start searching at a target of 2.
`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).
(previously 25) and for RPC calls (previously 2).
Removal of Priority Estimation
Removal of Priority Estimation
-------------------------------
------------------------------
- Estimation of "priority" needed for a transaction to be included within a target
- 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
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
converted to the new format which is not readable by prior versions of the
software.
software.
- The concept of "priority" (coin age) transactions is planned to be removed in
- Support for "priority" (coin age) transaction sorting for mining is
the next major version. To prepare for this, the default for the rate limit of
considered deprecated in Core and will be removed in the next major version.
priority transactions (`-limitfreerelay`) has been set to `0` kB/minute. This
This is not to be confused with the `prioritisetransaction` RPC which will remain
is not to be confused with the `prioritisetransaction` RPC which will remain
supported by Core for adding fee deltas to transactions.
supported for adding fee deltas to transactions.
P2P connection management
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
limit of eight connections which does not compete with other inbound or outbound
connection usage and is not subject to the maxconnections limitation.
connection usage and is not subject to the limitation imposed by the `-maxconnections`
option.
- 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
- New connections to manually added peers are performed more quickly.
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
0.14.0 Change log
=================
=================
@ -108,14 +290,6 @@ git merge commit are mentioned.
### RPC and REST
### 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
### Configuration and command-line options
### Block and transaction handling
### Block and transaction handling
@ -128,16 +302,6 @@ Call "getmininginfo" loses the "testnet" field in favor of the more generic "cha
### Wallet
### 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.
Wladimir J. van der Laan
8 years ago