Bitcoin Core 0.11.0

Bitcoin Core installation binaries can be downloaded from bitcoincore.org and the source-code is available from the Bitcoin Core source repository.

Bitcoin Core version 0.11.0 is now available from:

https://bitcoincore.org/bin/bitcoin-core-0.11.0/

This is a new major version release, bringing both new features and bug fixes.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading

How to Upgrade

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

Downgrade warning

Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

  • 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. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility. There are no known problems when downgrading from 0.11.x to 0.10.x.

Important information

Transaction flooding

At the time of this release, the P2P network is being flooded with low-fee transactions. This causes a ballooning of the mempool size.

If this growth of the mempool causes problematic memory use on your node, it is possible to change a few configuration options to work around this. The growth of the mempool can be monitored with the RPC command getmempoolinfo.

One is to increase the minimum transaction relay fee minrelaytxfee, which defaults to 0.00001. This will cause transactions with fewer BTC/kB fee to be rejected, and thus fewer transactions entering the mempool.

The other is to restrict the relaying of free transactions with limitfreerelay. This option sets the number of kB/minute at which free transactions (with enough priority) will be accepted. It defaults to 15. Reducing this number reduces the speed at which the mempool can grow due to free transactions.

For example, add the following to bitcoin.conf:

minrelaytxfee=0.00005
limitfreerelay=5

More robust solutions are being worked on for a follow-up release.

Notable changes

Block file pruning

This release supports running a fully validating node without maintaining a copy of the raw block and undo data on disk. To recap, there are four types of data related to the blockchain in the bitcoin system: the raw blocks as received over the network (blk???.dat), the undo data (rev???.dat), the block index and the UTXO set (both LevelDB databases). The databases are built from the raw data.

Block pruning allows Bitcoin Core to delete the raw block and undo data once it’s been validated and used to build the databases. At that point, the raw data is used only to relay blocks to other nodes, to handle reorganizations, to look up old transactions (if -txindex is enabled or via the RPC/REST interfaces), or for rescanning the wallet. The block index continues to hold the metadata about all blocks in the blockchain.

The user specifies how much space to allot for block & undo files. The minimum allowed is 550MB. Note that this is in addition to whatever is required for the block index and UTXO databases. The minimum was chosen so that Bitcoin Core will be able to maintain at least 288 blocks on disk (two days worth of blocks at 10 minutes per block). In rare instances it is possible that the amount of space used will exceed the pruning target in order to keep the required last 288 blocks on disk.

Block pruning works during initial sync in the same way as during steady state, by deleting block files “as you go” whenever disk space is allocated. Thus, if the user specifies 550MB, once that level is reached the program will begin deleting the oldest block and undo files, while continuing to download the blockchain.

For now, block pruning disables block relay. In the future, nodes with block pruning will at a minimum relay “new” blocks, meaning blocks that extend their active chain.

Block pruning is currently incompatible with running a wallet due to the fact that block data is used for rescanning the wallet and importing keys or addresses (which require a rescan.) However, running the wallet with block pruning will be supported in the near future, subject to those limitations.

Block pruning is also incompatible with -txindex and will automatically disable it.

Once you have pruned blocks, going back to unpruned state requires re-downloading the entire blockchain. To do this, re-start the node with -reindex. Note also that any problem that would cause a user to reindex (e.g., disk corruption) will cause a pruned node to redownload the entire blockchain. Finally, note that when a pruned node reindexes, it will delete any blk???.dat and rev???.dat files in the data directory prior to restarting the download.

To enable block pruning on the command line:

  • -prune=N: where N is the number of MB to allot for raw block & undo data.

Modified RPC calls:

  • getblockchaininfo now includes whether we are in pruned mode or not.
  • getblock will check if the block’s data has been pruned and if so, return an error.
  • getrawtransaction will no longer be able to locate a transaction that has a UTXO but where its block file has been pruned.

Pruning is disabled by default.

Big endian support

Experimental support for big-endian CPU architectures was added in this release. All little-endian specific code was replaced with endian-neutral constructs. This has been tested on at least MIPS and PPC hosts. The build system will automatically detect the endianness of the target.

Memory usage optimization

There have been many changes in this release to reduce the default memory usage of a node, among which:

  • Accurate UTXO cache size accounting (#6102); this makes the option -dbcache precise where this grossly underestimated memory usage before
  • Reduce size of per-peer data structure (#6064 and others); this increases the number of connections that can be supported with the same amount of memory
  • Reduce the number of threads (#5964, #5679); lowers the amount of (esp. virtual) memory needed

Fee estimation changes

This release improves the algorithm used for fee estimation. Previously, -1 was returned when there was insufficient data to give an estimate. Now, -1 will also be returned when there is no fee or priority high enough for the desired confirmation target. In those cases, it can help to ask for an estimate for a higher target number of blocks. It is not uncommon for there to be no fee or priority high enough to be reliably (85%) included in the next block and for this reason, the default for -txconfirmtarget=n has changed from 1 to 2.

Privacy: Disable wallet transaction broadcast

This release adds an option -walletbroadcast=0 to prevent automatic transaction broadcast and rebroadcast (#5951). This option allows separating transaction submission from the node functionality.

Making use of this, third-party scripts can be written to take care of transaction (re)broadcast:

  • Send the transaction as normal, either through RPC or the GUI
  • Retrieve the transaction data through RPC using gettransaction (NOT getrawtransaction). The hex field of the result will contain the raw hexadecimal representation of the transaction
  • The transaction can then be broadcasted through arbitrary mechanisms supported by the script

One such application is selective Tor usage, where the node runs on the normal internet but transactions are broadcasted over Tor.

For an example script see bitcoin-submittx.

Privacy: Stream isolation for Tor

This release adds functionality to create a new circuit for every peer connection, when the software is used with Tor. The new option, -proxyrandomize, is on by default.

When enabled, every outgoing connection will (potentially) go through a different exit node. That significantly reduces the chance to get unlucky and pick a single exit node that is either malicious, or widely banned from the P2P network. This improves connection reliability as well as privacy, especially for the initial connections.

Important note: If a non-Tor SOCKS5 proxy is configured that supports authentication, but doesn’t require it, this change may cause that proxy to reject connections. A user and password is sent where they weren’t before. This setup is exceedingly rare, but in this case -proxyrandomize=0 can be passed to disable the behavior.

0.11.0 Change log

Detailed release notes follow. This overview includes changes that affect behavior, not code moves, refactors and string updates. For convenience in locating the code changes and accompanying discussion, both the pull request and git merge commit are mentioned.

RPC and REST

Configuration and command-line options

  • #5636 a353ad4 Add option -allowselfsignedrootcertificate to allow self signed root certs (for testing payment requests)
  • #5900 3e8a1f2 Add a consistency check -checkblockindex for the block chain data structures
  • #5951 7efc9cf Make it possible to disable wallet transaction broadcast (using -walletbroadcast=0)
  • #5911 b6ea3bc privacy: Stream isolation for Tor (on by default, use -proxyrandomize=0 to disable)
  • #5863 c271304 Add autoprune functionality (-prune=<size>)
  • #6153 0bcf04f Parameter interaction: disable upnp if -proxy set
  • #6274 4d9c7fe Add option -alerts to opt out of alert system

Block and transaction handling

  • #5367 dcc1304 Do all block index writes in a batch
  • #5253 203632d Check against MANDATORY flags prior to accepting to mempool
  • #5459 4406c3e Reject headers that build on an invalid parent
  • #5481 055f3ae Apply AreSane() checks to the fees from the network
  • #5580 40d65eb Preemptively catch a few potential bugs
  • #5349 f55c5e9 Implement test for merkle tree malleability in CPartialMerkleTree
  • #5564 a89b837 clarify obscure uses of EvalScript()
  • #5521 8e4578a Reject non-final txs even in testnet/regtest
  • #5707 6af674e Change hardcoded character constants to descriptive named constants for db keys
  • #5286 fcf646c Change the default maximum OP_RETURN size to 80 bytes
  • #5710 175d86e Add more information to errors in ReadBlockFromDisk
  • #5948 b36f1ce Use GetAncestor to compute new target
  • #5959 a0bfc69 Add additional block index consistency checks
  • #6058 7e0e7f8 autoprune minor post-merge improvements
  • #5159 2cc1372 New fee estimation code
  • #6102 6fb90d8 Implement accurate UTXO cache size accounting
  • #6129 2a82298 Bug fix for clearing fCheckForPruning
  • #5947 e9af4e6 Alert if it is very likely we are getting a bad chain
  • #6203 c00ae64 Remove P2SH coinbase flag, no longer interesting
  • #5985 37b4e42 Fix removing of orphan transactions
  • #6221 6cb70ca Prune: Support noncontiguous block files
  • #6256 fce474c Use best header chain timestamps to detect partitioning
  • #6233 a587606 Advance pindexLastCommonBlock for blocks in chainActive

P2P protocol and network code

  • #5507 844ace9 Prevent DOS attacks on in-flight data structures
  • #5770 32a8b6a Sanitize command strings before logging them
  • #5859 dd4ffce Add correct bool combiner for net signals
  • #5876 8e4fd0c Add a NODE_GETUTXO service bit and document NODE_NETWORK
  • #6028 b9311fb Move nLastTry from CAddress to CAddrInfo
  • #5662 5048465 Change download logic to allow calling getdata on inbound peers
  • #5971 18d2832 replace absolute sleep with conditional wait
  • #5918 7bf5d5e Use equivalent PoW for non-main-chain requests
  • #6059 f026ab6 chainparams: use SeedSpec6’s rather than CAddress’s for fixed seeds
  • #6080 31c0bf1 Add jonasschnellis dns seeder
  • #5976 9f7809f Reduce download timeouts as blocks arrive
  • #6172 b4bbad1 Ignore getheaders requests when not synced
  • #5875 304892f Be stricter in processing unrequested blocks
  • #6333 41bbc85 Hardcoded seeds update June 2015

Validation

Build system

Wallet

GUI

Tests

Miscellaneous

Credits

Thanks to everyone who directly contributed to this release:

  • 21E14
  • Adam Weiss
  • Alex Morcos
  • ayeowch
  • azeteki
  • Ben Holden-Crowther
  • bikinibabe
  • BitcoinPRReadingGroup
  • Blake Jakopovic
  • BtcDrak
  • charlescharles
  • Chris Arnesen
  • Ciemon
  • CohibAA
  • Corinne Dashjr
  • Cory Fields
  • Cozz Lovan
  • Daira Hopwood
  • Daniel Kraft
  • Dave Collins
  • David A. Harding
  • dexX7
  • Earlz
  • Eric Lombrozo
  • Eric R. Schulz
  • Everett Forth
  • Flavien Charlon
  • fsb4000
  • Gavin Andresen
  • Gregory Maxwell
  • Heath
  • Ivan Pustogarov
  • Jacob Welsh
  • Jameson Lopp
  • Jason Lewicki
  • Jeff Garzik
  • Jonas Schnelli
  • Jonathan Brown
  • Jorge Timón
  • joshr
  • jtimon
  • Julian Yap
  • Luca Venturini
  • Luke Dashjr
  • Manuel Araoz
  • MarcoFalke
  • Matt Bogosian
  • Matt Corallo
  • Micha
  • Michael Ford
  • Mike Hearn
  • mrbandrews
  • Nicolas Benoit
  • paveljanik
  • Pavel Janík
  • Pavel Vasin
  • Peter Todd
  • Philip Kaufmann
  • Pieter Wuille
  • pstratem
  • randy-waterhouse
  • rion
  • Rob Van Mieghem
  • Ross Nicoll
  • Ruben de Vries
  • sandakersmann
  • Shaul Kfir
  • Shawn Wilkinson
  • sinetek
  • Suhas Daftuar
  • svost
  • Thomas Zander
  • Tom Harding
  • UdjinM6
  • Vitalii Demianets
  • Wladimir J. van der Laan

And all those who contributed additional code review and/or security research:

  • Sergio Demian Lerner

As well as everyone that helped translating on Transifex.