@ -10,7 +10,7 @@ Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
https://github.com/bitcoin/bitcoin/issues
Upgrading and downgrading
Upgrading and downgrading
==========================
=========================
How to Upgrade
How to Upgrade
--------------
--------------
@ -28,8 +28,8 @@ Downgrading warning
---------------------
---------------------
Because release 0.10.0 makes use of headers-first synchronization and parallel
Because release 0.10.0 makes use of headers-first synchronization and parallel
block download, the block files and databases are not backwards-compatible
block download (see further), the block files and databases are not
with older versions of Bitcoin Core:
backwards-compatible with older versions of Bitcoin Core:
* Blocks will be stored on disk out of order (in the order they are
* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
received, really), which makes it incompatible with some tools or
@ -45,8 +45,37 @@ bootstrap.dat) anew afterwards.
This does not affect wallet forward or backward compatibility.
This does not affect wallet forward or backward compatibility.
Notable changes
===============
Faster synchronization
----------------------
Bitcoin Core now uses 'headers-first synchronization'. This means that we first
ask peers for block headers (a total of 27 megabytes, as of December 2014) and
validate those. In a second stage, when the headers have been discovered, we
download the blocks. However, as we already know about the whole chain in
advance, the blocks can be downloaded in parallel from all available peers.
In practice, this means a much faster and more robust synchronization. On
recent hardware with a decent network link, it can be as little as 3 hours
for an initial full synchronization. You may notice a slower progress in the
very first few minutes, when headers are still being fetched and verified, but
it should gain speed afterwards.
A few RPCs were added/updated as a result of this:
- `getblockchaininfo` now returns the number of validated headers in addition to
the number of validated blocks.
- `getpeerinfo` lists both the number of blocks and headers we know we have in
common with each peer. While synchronizing, the heights of the blocks that we
have requested from peers (but haven't received yet) are also listed as
'inflight'.
- A new RPC `getchaintips` lists all known branches of the block chain,
including those we only have headers for.
Transaction fee changes
Transaction fee changes
=======================
-----------------------
This release automatically estimates how high a transaction fee (or how
This release automatically estimates how high a transaction fee (or how
high a priority) transactions require to be confirmed quickly. The default
high a priority) transactions require to be confirmed quickly. The default
@ -61,27 +90,22 @@ Statistics used to estimate fees and priorities are saved in the
data directory in the `fee_estimates.dat` file just before
data directory in the `fee_estimates.dat` file just before
program shutdown, and are read in at startup.
program shutdown, and are read in at startup.
New Command Line Options
New command line options for fee estimation:
---------------------------
- `-txconfirmtarget=n` : create transactions that have enough fees (or priority)
- `-txconfirmtarget=n` : create transactions that have enough fees (or priority)
so they are likely to confirm within n blocks (default: 1). This setting
so they are likely to confirm within n blocks (default: 1). This setting
is over-ridden by the -paytxfee option.
is over-ridden by the -paytxfee option.
New RPC methods
New RPC commands for fee estimation:
----------------
- `estimatefee nblocks` : Returns approximate fee-per-1,000-bytes needed for
- `estimatefee nblocks` : Returns approximate fee-per-1,000-bytes needed for
a transaction to be confirmed within nblocks. Returns -1 if not enough
a transaction to be confirmed within nblocks. Returns -1 if not enough
transactions have been observed to compute a good estimate.
transactions have been observed to compute a good estimate.
- `estimatepriority nblocks` : Returns approximate priority needed for
- `estimatepriority nblocks` : Returns approximate priority needed for
a zero-fee transaction to confirm within nblocks. Returns -1 if not
a zero-fee transaction to confirm within nblocks. Returns -1 if not
enough free transactions have been observed to compute a good
enough free transactions have been observed to compute a good
estimate.
estimate.
RPC access control changes
RPC access control changes
==========================================
--------------------------
Subnet matching for the purpose of access control is now done
Subnet matching for the purpose of access control is now done
by matching the binary network address, instead of with string wildcard matching.
by matching the binary network address, instead of with string wildcard matching.
@ -107,8 +131,27 @@ Using wildcards will result in the rule being rejected with the following error
Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24).
Error: Invalid -rpcallowip subnet specification: *. Valid are a single IP (e.g. 1.2.3.4), a network/netmask (e.g. 1.2.3.4/255.255.255.0) or a network/CIDR (e.g. 1.2.3.4/24).
REST interface
--------------
A new HTTP API is exposed when running with the `-rest` flag, which allows
unauthenticated access to public node data.
It is served on the same port as RPC, but does not need a password, and uses
plain HTTP instead of JSON-RPC.
Assuming a local RPC server running on port 8332, it is possible to request:
Pieter Wuille
10 years ago
committed by