diff options
| -rw-r--r-- | configure.ac | 2 | ||||
| -rw-r--r-- | doc/Doxyfile | 2 | ||||
| -rw-r--r-- | doc/README.md | 2 | ||||
| -rw-r--r-- | doc/README_windows.txt | 2 | ||||
| -rw-r--r-- | doc/release-notes.md | 123 | ||||
| -rw-r--r-- | src/clientversion.h | 2 |
6 files changed, 5 insertions, 128 deletions
diff --git a/configure.ac b/configure.ac index c4c21eaf4f..efb4c00319 100644 --- a/configure.ac +++ b/configure.ac @@ -1,7 +1,7 @@ dnl require autoconf 2.60 (AS_ECHO/AS_ECHO_N) AC_PREREQ([2.60]) define(_CLIENT_VERSION_MAJOR, 0) -define(_CLIENT_VERSION_MINOR, 9) +define(_CLIENT_VERSION_MINOR, 10) define(_CLIENT_VERSION_REVISION, 99) define(_CLIENT_VERSION_BUILD, 0) define(_CLIENT_VERSION_IS_RELEASE, false) diff --git a/doc/Doxyfile b/doc/Doxyfile index e0339e652e..8a11d1e8d0 100644 --- a/doc/Doxyfile +++ b/doc/Doxyfile @@ -34,7 +34,7 @@ PROJECT_NAME = Bitcoin # This could be handy for archiving the generated documentation or # if some version control system is used. -PROJECT_NUMBER = 0.9.99 +PROJECT_NUMBER = 0.10.99 # Using the PROJECT_BRIEF tag one can provide an optional one line description # for a project that appears at the top of each page and should give viewer diff --git a/doc/README.md b/doc/README.md index d5d61738e8..3ec5f11df2 100644 --- a/doc/README.md +++ b/doc/README.md @@ -1,4 +1,4 @@ -Bitcoin 0.9.99 BETA +Bitcoin 0.10.99 BETA ===================== Copyright (c) 2009-2014 Bitcoin Developers diff --git a/doc/README_windows.txt b/doc/README_windows.txt index 368f2b45e1..9780a2cb13 100644 --- a/doc/README_windows.txt +++ b/doc/README_windows.txt @@ -1,4 +1,4 @@ -Bitcoin 0.9.99 BETA
+Bitcoin 0.10.99 BETA
Copyright (c) 2009-2014 Bitcoin Core Developers
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 diff --git a/src/clientversion.h b/src/clientversion.h index 0a36eb8012..32deaa0f1e 100644 --- a/src/clientversion.h +++ b/src/clientversion.h @@ -15,7 +15,7 @@ //! These need to be macros, as clientversion.cpp's and bitcoin*-res.rc's voodoo requires it #define CLIENT_VERSION_MAJOR 0 -#define CLIENT_VERSION_MINOR 9 +#define CLIENT_VERSION_MINOR 10 #define CLIENT_VERSION_REVISION 99 #define CLIENT_VERSION_BUILD 0 |