mirror of https://github.com/bitcoin/bitcoin
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
87 lines
3.8 KiB
87 lines
3.8 KiB
(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).
|
|
|