Now that 0.10 has been branched, master is 0.10.99

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