doc/release-notes.md

   1 (note: this is a temporary file, to be added-to by anybody, and moved to
   2 release-notes at release time)
   3
   4 Block file backwards-compatibility warning
   5 ===========================================
   6
   7 Because release 0.10.0 makes use of headers-first synchronization and parallel
   8 block download, the block files and databases are not backwards-compatible
   9 with older versions of Bitcoin Core:
  10
  11 * Blocks will be stored on disk out of order (in the order they are
  12 received, really), which makes it incompatible with some tools or
  13 other programs. Reindexing using earlier versions will also not work
  14 anymore as a result of this.
  15
  16 * The block index database will now hold headers for which no block is
  17 stored on disk, which earlier versions won't support.
  18
  19 If you want to be able to downgrade smoothly, make a backup of your entire data
  20 directory. Without this your node will need start syncing (or importing from
  21 bootstrap.dat) anew afterwards.
  22
  23 This does not affect wallet forward or backward compatibility.
  24
  25 Transaction fee changes
  26 =======================
  27
  28 This release automatically estimates how high a transaction fee (or how
  29 high a priority) transactions require to be confirmed quickly. The default
  30 settings will create transactions that confirm quickly; see the new
  31 'txconfirmtarget' setting to control the tradeoff between fees and
  32 confirmation times.
  33
  34 Prior releases used hard-coded fees (and priorities), and would
  35 sometimes create transactions that took a very long time to confirm.
  36
  37 Statistics used to estimate fees and priorities are saved in the
  38 data directory in the `fee_estimates.dat` file just before
  39 program shutdown, and are read in at startup.
  40
  41 New Command Line Options
  42 ---------------------------
  43
  44 - `-txconfirmtarget=n` : create transactions that have enough fees (or priority)
  45 so they are likely to confirm within n blocks (default: 1). This setting
  46 is over-ridden by the -paytxfee option.
  47
  48 New RPC methods
  49 ----------------
  50
  51 - `estimatefee nblocks` : Returns approximate fee-per-1,000-bytes needed for
  52 a transaction to be confirmed within nblocks. Returns -1 if not enough
  53 transactions have been observed to compute a good estimate.
  54
  55 - `estimatepriority nblocks` : Returns approximate priority needed for
  56 a zero-fee transaction to confirm within nblocks. Returns -1 if not
  57 enough free transactions have been observed to compute a good
  58 estimate.
  59
  60 RPC access control changes
  61 ==========================================
  62
  63 Subnet matching for the purpose of access control is now done
  64 by matching the binary network address, instead of with string wildcard matching.
  65 For the user this means that `-rpcallowip` takes a subnet specification, which can be
  66
  67 - a single IP address (e.g. `1.2.3.4` or `fe80::0012:3456:789a:bcde`)
  68 - a network/CIDR (e.g. `1.2.3.0/24` or `fe80::0000/64`)
  69 - 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`)
  70
  71 An arbitrary number of `-rpcallow` arguments can be given. An incoming connection will be accepted if its origin address
  72 matches one of them.
  73
  74 For example:
  75
  76 | 0.9.x and before                           | 0.10.x                                |
  77 |--------------------------------------------|---------------------------------------|
  78 | `-rpcallowip=192.168.1.1`                  | `-rpcallowip=192.168.1.1` (unchanged) |
  79 | `-rpcallowip=192.168.1.*`                  | `-rpcallowip=192.168.1.0/24`          |
  80 | `-rpcallowip=192.168.*`                    | `-rpcallowip=192.168.0.0/16`          |
  81 | `-rpcallowip=*` (dangerous!)               | `-rpcallowip=::/0`                    |
  82
  83 Using wildcards will result in the rule being rejected with the following error in debug.log:
  84
  85     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).
  86
  87 RPC Server "Warm-Up" Mode
  88 =========================
  89
  90 The RPC server is started earlier now, before most of the expensive
  91 intialisations like loading the block index.  It is available now almost
  92 immediately after starting the process.  However, until all initialisations
  93 are done, it always returns an immediate error with code -28 to all calls.
  94
  95 This new behaviour can be useful for clients to know that a server is already
  96 started and will be available soon (for instance, so that they do not
  97 have to start it themselves).
  98
  99 Improved signing security
 100 =========================
 101
 102 For 0.10 the security of signing against unusual attacks has been
 103 improved by making the signatures constant time and deterministic.
 104
 105 This change is a result of switching signing to use libsecp256k1
 106 instead of OpenSSL. Libsecp256k1 is a cryptographic library
 107 optimized for the curve Bitcoin uses which was created by Bitcoin
 108 Core developer Pieter Wuille.
 109
 110 There exist attacks[1] against most ECC implementations where an
 111 attacker on shared virtual machine hardware could extract a private
 112 key if they could cause a target to sign using the same key hundreds
 113 of times. While using shared hosts and reusing keys are inadvisable
 114 for other reasons, it's a better practice to avoid the exposure.
 115
 116 OpenSSL has code in their source repository for derandomization
 117 and reduction in timing leaks, and we've  eagerly wanted to use
 118 it for a long time but this functionality has still not made its
 119 way into a released version of OpenSSL. Libsecp256k1 achieves
 120 significantly stronger protection: As far as we're aware this is
 121 the only deployed implementation of constant time signing for
 122 the curve Bitcoin uses and we have reason to believe that
 123 libsecp256k1 is better tested and more thoroughly reviewed
 124 than the implementation in OpenSSL.
 125
 126 [1] https://eprint.iacr.org/2014/161.pdf