diff options
Diffstat (limited to 'doc/release-notes.md')
| -rw-r--r-- | doc/release-notes.md | 123 |
1 files changed, 0 insertions, 123 deletions
diff --git a/doc/release-notes.md b/doc/release-notes.md index f804e8c11b..1cb517e5c7 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -1,126 +1,3 @@ (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 |