aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorWladimir J. van der Laan <laanwj@gmail.com>2014-12-11 16:03:46 +0100
committerWladimir J. van der Laan <laanwj@gmail.com>2014-12-11 16:03:46 +0100
commitd7492304e9b92b755c0bdafb9805bdca66dae94a (patch)
treefeadc53a3f269e06a0884b957f837ab94112b72a /doc
parent41cced21063a89992ef393dda4fffc44ff60c7c3 (diff)
Now that 0.10 has been branched, master is 0.10.99
Diffstat (limited to 'doc')
-rw-r--r--doc/Doxyfile2
-rw-r--r--doc/README.md2
-rw-r--r--doc/README_windows.txt2
-rw-r--r--doc/release-notes.md123
4 files changed, 3 insertions, 126 deletions
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