af82884ab7
Start the RPC server before doing all the (expensive) startup initialisations like loading the block index. Until the node is ready, return all calls immediately with a new error signalling "in warmup" with an appropriate status message (similar to the init message). This is useful for RPC clients to know that the server is there (e. g., they don't have to start it) but not yet available. It is used in Namecoin and Huntercoin already for some time, and there exists a UI hooked onto the RPC interface that actively uses this to its advantage.
98 lines
4.3 KiB
Markdown
98 lines
4.3 KiB
Markdown
(note: this is a temporary file, to be added-to by anybody, and moved to
|
|
release-notes at release time)
|
|
|
|
Block file backwards-compatibility warning
|
|
===========================================
|
|
|
|
Because release 0.10.0 makes use of headers-first synchronization and parallel
|
|
block download, the block files and databases are not backwards-compatible
|
|
with older versions of Bitcoin Core:
|
|
|
|
* Blocks will be stored on disk out of order (in the order they are
|
|
received, really), which makes it incompatible with some tools or
|
|
other programs. Reindexing using earlier versions will also not work
|
|
anymore as a result of this.
|
|
|
|
* The block index database will now hold headers for which no block is
|
|
stored on disk, which earlier versions won't support.
|
|
|
|
If you want to be able to downgrade smoothly, make a backup of your entire data
|
|
directory. Without this your node will need start syncing (or importing from
|
|
bootstrap.dat) anew afterwards.
|
|
|
|
This does not affect wallet forward or backward compatibility.
|
|
|
|
Transaction fee changes
|
|
=======================
|
|
|
|
This release automatically estimates how high a transaction fee (or how
|
|
high a priority) transactions require to be confirmed quickly. The default
|
|
settings will create transactions that confirm quickly; see the new
|
|
'txconfirmtarget' setting to control the tradeoff between fees and
|
|
confirmation times.
|
|
|
|
Prior releases used hard-coded fees (and priorities), and would
|
|
sometimes create transactions that took a very long time to confirm.
|
|
|
|
Statistics used to estimate fees and priorities are saved in the
|
|
data directory in the `fee_estimates.dat` file just before
|
|
program shutdown, and are read in at startup.
|
|
|
|
New Command Line Options
|
|
---------------------------
|
|
|
|
- `-txconfirmtarget=n` : create transactions that have enough fees (or priority)
|
|
so they are likely to confirm within n blocks (default: 1). This setting
|
|
is over-ridden by the -paytxfee option.
|
|
|
|
New RPC methods
|
|
----------------
|
|
|
|
- `estimatefee nblocks` : Returns approximate fee-per-1,000-bytes needed for
|
|
a transaction to be confirmed within nblocks. Returns -1 if not enough
|
|
transactions have been observed to compute a good estimate.
|
|
|
|
- `estimatepriority nblocks` : Returns approximate priority needed for
|
|
a zero-fee transaction to confirm within nblocks. Returns -1 if not
|
|
enough free transactions have been observed to compute a good
|
|
estimate.
|
|
|
|
RPC access control changes
|
|
==========================================
|
|
|
|
Subnet matching for the purpose of access control is now done
|
|
by matching the binary network address, instead of with string wildcard matching.
|
|
For the user this means that `-rpcallowip` takes a subnet specification, which can be
|
|
|
|
- a single IP address (e.g. `1.2.3.4` or `fe80::0012:3456:789a:bcde`)
|
|
- a network/CIDR (e.g. `1.2.3.0/24` or `fe80::0000/64`)
|
|
- a network/netmask (e.g. `1.2.3.4/255.255.255.0` or `fe80::0012:3456:789a:bcde/ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff`)
|
|
|
|
An arbitrary number of `-rpcallow` arguments can be given. An incoming connection will be accepted if its origin address
|
|
matches one of them.
|
|
|
|
For example:
|
|
|
|
| 0.9.x and before | 0.10.x |
|
|
|--------------------------------------------|---------------------------------------|
|
|
| `-rpcallowip=192.168.1.1` | `-rpcallowip=192.168.1.1` (unchanged) |
|
|
| `-rpcallowip=192.168.1.*` | `-rpcallowip=192.168.1.0/24` |
|
|
| `-rpcallowip=192.168.*` | `-rpcallowip=192.168.0.0/16` |
|
|
| `-rpcallowip=*` (dangerous!) | `-rpcallowip=::/0` |
|
|
|
|
Using wildcards will result in the rule being rejected with the following error in debug.log:
|
|
|
|
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).
|
|
|
|
RPC Server "Warm-Up" Mode
|
|
=========================
|
|
|
|
The RPC server is started earlier now, before most of the expensive
|
|
intialisations like loading the block index. It is available now almost
|
|
immediately after starting the process. However, until all initialisations
|
|
are done, it always returns an immediate error with code -28 to all calls.
|
|
|
|
This new behaviour can be useful for clients to know that a server is already
|
|
started and will be available soon (for instance, so that they do not
|
|
have to start it themselves).
|