5fdbe67ad9
I dropped mention of libgmp that I had in my first draft because it looks like we'll be able to get that out prior to release.
126 lines
5.6 KiB
Markdown
126 lines
5.6 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).
|
|
|
|
Improved signing security
|
|
=========================
|
|
|
|
For 0.10 the security of signing against unusual attacks has been
|
|
improved by making the signatures constant time and deterministic.
|
|
|
|
This change is a result of switching signing to use libsecp256k1
|
|
instead of OpenSSL. Libsecp256k1 is a cryptographic library
|
|
optimized for the curve Bitcoin uses which was created by Bitcoin
|
|
Core developer Pieter Wuille.
|
|
|
|
There exist attacks[1] against most ECC implementations where an
|
|
attacker on shared virtual machine hardware could extract a private
|
|
key if they could cause a target to sign using the same key hundreds
|
|
of times. While using shared hosts and reusing keys are inadvisable
|
|
for other reasons, it's a better practice to avoid the exposure.
|
|
|
|
OpenSSL has code in their source repository for derandomization
|
|
and reduction in timing leaks, and we've eagerly wanted to use
|
|
it for a long time but this functionality has still not made its
|
|
way into a released version of OpenSSL. Libsecp256k1 achieves
|
|
significantly stronger protection: As far as we're aware this is
|
|
the only deployed implementation of constant time signing for
|
|
the curve Bitcoin uses and we have reason to believe that
|
|
libsecp256k1 is better tested and more thoroughly reviewed
|
|
than the implementation in OpenSSL.
|
|
|
|
[1] https://eprint.iacr.org/2014/161.pdf
|