Now that 0.10 has been branched, master is 0.10.99
This commit is contained in:
Wladimir J. van der Laan
parent
41cced2106
commit
d7492304e9
6 changed files with 5 additions and 128 deletions
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Bitcoin 0.9.99 BETA
|
||||
Bitcoin 0.10.99 BETA
|
||||
=====================
|
||||
|
||||
Copyright (c) 2009-2014 Bitcoin Developers
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Bitcoin 0.9.99 BETA
|
||||
Bitcoin 0.10.99 BETA
|
||||
|
||||
Copyright (c) 2009-2014 Bitcoin Core Developers
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue