+Bitcoin Core version 0.13.0 is now available from:
+
+ <https://bitcoin.org/bin/bitcoin-core-0.13.0/>
+
+This is a new major version release, including new features, various bugfixes
+and performance improvements, as well as updated translations.
+
+Please report bugs using the issue tracker at github:
+
+ <https://github.com/bitcoin/bitcoin/issues>
+
+To receive security and update notifications, please subscribe to:
+
+ <https://bitcoincore.org/en/list/announcements/join/>
+
+Compatibility
+==============
+
+Microsoft ended support for Windows XP on [April 8th, 2014](
https://www.microsoft.com/en-us/WindowsForBusiness/end-of-xp-support),
+an OS initially released in 2001. This means that not even critical security
+updates will be released anymore. Without security updates, using a bitcoin
+wallet on a XP machine is irresponsible at least.
+
+In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
+randomly crashing on Windows XP. It is [not clear](
https://github.com/bitcoin/bitcoin/issues/7681#issuecomment-217439891)
+what the source of these crashes is, but it is likely that upstream
+libraries such as Qt are no longer being tested on XP.
+
+We do not have time nor resources to provide support for an OS that is
+end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
+suggested to upgrade to a newer verion of Windows, or install an alternative OS
+that is supported.
+
+No attempt is made to prevent installing or running the software on Windows XP,
+you can still do so at your own risk, but do not expect it to work: do not
+report issues about Windows XP to the issue tracker.
+
+Notable changes+===============
+
+Database cache memory increased
+--------------------------------
+
+As a result of growth of the UTXO set, performance with the prior default
+database cache of 100 MiB has suffered.
+For this reason the default was changed to 300 MiB in this release.
+
+For nodes on low-memory systems, the database cache can be changed back to
+100 MiB (or to another value) by either:
+
+- Adding `dbcache=100` in bitcoin.conf
+- Changing it in the GUI under `Options → Size of database cache`
+
+Note that the database cache setting has the most performance impact
+during initial sync of a node, and when catching up after downtime.
+
+
+bitcoin-cli: arguments privacy
+------------------------------
+
+The RPC command line client gained a new argument, `-stdin`
+to read extra arguments from standard input, one per line until EOF/Ctrl-D.
+For example:
+
+ $ src/bitcoin-cli -stdin walletpassphrase
+ mysecretcode
+ 120
+ ..... press Ctrl-D here to end input
+ $
+
+It is recommended to use this for sensitive information such as wallet
+passphrases, as command-line arguments can usually be read from the process
+table by any user on the system.
+
+
+C++11 and Python 3
+------------------
+
+Various code modernizations have been done. The Bitcoin Core code base has
+started using C++11. This means that a C++11-capable compiler is now needed for
+building. Effectively this means GCC 4.7 or higher, or Clang 3.3 or higher.
+
+When cross-compiling for a target that doesn't have C++11 libraries, configure with
+`./configure --enable-glibc-back-compat ... LDFLAGS=-static-libstdc++`.
+
+For running the functional tests in `qa/rpc-tests`, Python3.4 or higher is now
+required.
+
+
+Linux ARM builds
+----------------
+
+Due to popular request, Linux ARM builds have been added to the uploaded
+executables.
+
+The following extra files can be found in the download directory or torrent:
+
+- `bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz`: Linux binaries for the most
+ common 32-bit ARM architecture.
+- `bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz`: Linux binaries for the most
+ common 64-bit ARM architecture.
+
+ARM builds are still experimental. If you have problems on a certain device or
+Linux distribution combination please report them on the bug tracker, it may be
+possible to resolve them.
+
+Note that Android is not considered ARM Linux in this context. The executables
+are not expected to work out of the box on Android.
+
+
+Compact Block support (BIP 152)
+-------------------------------
+
+Support for block relay using the Compact Blocks protocol has been implemented
+in PR 8068.
+
+The primary goal is reducing the bandwidth spikes at relay time, though in many
+cases it also reduces propagation delay. It is automatically enabled between
+compatible peers.
+[BIP 152](
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki)
+
+As a side-effect, ordinary non-mining nodes will download and upload blocks
+faster if those blocks were produced by miners using similar transaction
+filtering policies. This means that a miner who produces a block with many
+transactions discouraged by your node will be relayed slower than one with
+only transactions already in your memory pool. The overall effect of such
+relay differences on the network may result in blocks which include widely-
+discouraged transactions losing a stale block race, and therefore miners may
+wish to configure their node to take common relay policies into consideration.
+
+
+Hierarchical Deterministic Key Generation
+-----------------------------------------
+Newly created wallets will use hierarchical deterministic key generation
+according to BIP32 (keypath m/0'/0'/k').
+Existing wallets will still use traditional key generation.
+
+Backups of HD wallets, regardless of when they have been created, can
+therefore be used to re-generate all possible private keys, even the
+ones which haven't already been generated during the time of the backup.
+**Attention:** Encrypting the wallet will create a new seed which requires
+a new backup!
+
+Wallet dumps (created using the `dumpwallet` RPC) will contain the deterministic
+seed. This is expected to allow future versions to import the seed and all
+associated funds, but this is not yet implemented.
+
+HD key generation for new wallets can be disabled by `-usehd=0`. Keep in
+mind that this flag only has affect on newly created wallets.
+You can't disable HD key generation once you have created a HD wallet.
+
+There is no distinction between internal (change) and external keys.
+
+HD wallets are incompatible with older versions of Bitcoin Core.
+
+[Pull request](
https://github.com/bitcoin/bitcoin/pull/8035/files), [BIP 32](
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)
+
+
+Segregated Witness
+------------------
+
+The code preparations for Segregated Witness ("segwit"), as described in [BIP
+141](
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki), [BIP
+143](
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki), [BIP
+144](
https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki), and [BIP
+145](
https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki) are
+finished and included in this release. However, BIP 141 does not yet specify
+activation parameters on mainnet, and so this release does not support segwit
+use on mainnet. Testnet use is supported, and after BIP 141 is updated with
+proposed parameters, a future release of Bitcoin Core is expected that
+implements those parameters for mainnet.
+
+Furthermore, because segwit activation is not yet specified for mainnet,
+version 0.13.0 will behave similarly as other pre-segwit releases even after a
+future activation of BIP 141 on the network. Upgrading from 0.13.0 will be
+required in order to utilize segwit-related features on mainnet (such as signal
+BIP 141 activation, mine segwit blocks, fully validate segwit blocks, relay
+segwit blocks to other segwit nodes, and use segwit transactions in the
+wallet, etc).
+
+
+Mining transaction selection ("Child Pays For Parent")
+------------------------------------------------------
+
+The mining transaction selection algorithm has been replaced with an algorithm
+that selects transactions based on their feerate inclusive of unconfirmed
+ancestor transactions. This means that a low-fee transaction can become more
+likely to be selected if a high-fee transaction that spends its outputs is
+relayed.
+
+With this change, the `-blockminsize` command line option has been removed.
+
+The command line option `-blockmaxsize` remains an option to specify the
+maximum number of serialized bytes in a generated block. In addition, the new
+command line option `-blockmaxweight` has been added, which specifies the
+maximum "block weight" of a generated block, as defined by [BIP 141 (Segregated
+Witness)] (
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki).
+
+In preparation for Segregated Witness, the mining algorithm has been modified
+to optimize transaction selection for a given block weight, rather than a given
+number of serialized bytes in a block. In this release, transaction selection
+is unaffected by this distinction (as BIP 141 activation is not supported on
+mainnet in this release, see above), but in future releases and after BIP 141
+activation, these calculations would be expected to differ.
+
+For optimal runtime performance, miners using this release should specify
+`-blockmaxweight` on the command line, and not specify `-blockmaxsize`.
+Additionally (or only) specifying `-blockmaxsize`, or relying on default
+settings for both, may result in performance degradation, as the logic to
+support `-blockmaxsize` performs additional computation to ensure that
+constraint is met. (Note that for mainnet, in this release, the equivalent
+parameter for `-blockmaxweight` would be four times the desired
+`-blockmaxsize`. See [BIP 141]
+(
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) for additional
+details.)
+
+In the future, the `-blockmaxsize` option may be removed, as block creation is
+no longer optimized for this metric. Feedback is requested on whether to
+deprecate or keep this command line option in future releases.
+
+
+Reindexing changes
+------------------
+
+In earlier versions, reindexing did validation while reading through the block
+files on disk. These two have now been split up, so that all blocks are known
+before validation starts. This was necessary to make certain optimizations that
+are available during normal synchronizations also available during reindexing.
+
+The two phases are distinct in the Bitcoin-Qt GUI. During the first one,
+"Reindexing blocks on disk" is shown. During the second (slower) one,
+"Processing blocks on disk" is shown.
+
+It is possible to only redo validation now, without rebuilding the block index,
+using the command line option `-reindex-chainstate` (in addition to
+`-reindex` which does both). This new option is useful when the blocks on disk
+are assumed to be fine, but the chainstate is still corrupted. It is also
+useful for benchmarks.
+
+
+Removal of internal miner
+--------------------------
+
+As CPU mining has been useless for a long time, the internal miner has been
+removed in this release, and replaced with a simpler implementation for the
+test framework.
+
+The overall result of this is that `setgenerate` RPC call has been removed, as
+well as the `-gen` and `-genproclimit` command-line options.
+
+For testing, the `generate` call can still be used to mine a block, and a new
+RPC call `generatetoaddress` has been added to mine to a specific address. This
+works with wallet disabled.
+
+
+New bytespersigop implementation
+--------------------------------
+
+The former implementation of the bytespersigop filter accidentally broke bare
+multisig (which is meant to be controlled by the `permitbaremultisig` option),
+since the consensus protocol always counts these older transaction forms as 20
+sigops for backwards compatibility. Simply fixing this bug by counting more
+accurately would have reintroduced a vulnerability. It has therefore been
+replaced with a new implementation that rather than filter such transactions,
+instead treats them (for fee purposes only) as if they were in fact the size
+of a transaction actually using all 20 sigops.
+
+
+Low-level P2P changes
+----------------------
+
+- The optional new p2p message "feefilter" is implemented and the protocol
+ version is bumped to 70013. Upon receiving a feefilter message from a peer,
+ a node will not send invs for any transactions which do not meet the filter
+ feerate. [BIP 133](
https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki)
+
+- The P2P alert system has been removed in PR #7692 and the `alert` P2P message
+ is no longer supported.
+
+- The transaction relay mechanism used to relay one quarter of all transactions
+ instantly, while queueing up the rest and sending them out in batch. As
+ this resulted in chains of dependent transactions being reordered, it
+ systematically hurt transaction relay. The relay code was redesigned in PRs
+ \#7840 and #8082, and now always batches transactions announcements while also
+ sorting them according to dependency order. This significantly reduces orphan
+ transactions. To compensate for the removal of instant relay, the frequency of
+ batch sending was doubled for outgoing peers.
+
+- Since PR #7840 the BIP35 `mempool` command is also subject to batch processing.
+ Also the `mempool` message is no longer handled for non-whitelisted peers when
+ `NODE_BLOOM` is disabled through `-peerbloomfilters=0`.
+
+- The maximum size of orphan transactions that are kept in memory until their
+ ancestors arrive has been raised in PR #8179 from 5000 to 99999 bytes. They
+ are now also removed from memory when they are included in a block, conflict
+ with a block, and time out after 20 minutes.
+
+- We respond at most once to a getaddr request during the lifetime of a
+ connection since PR #7856.
+
+- Connections to peers who have recently been the first one to give us a valid
+ new block or transaction are protected from disconnections since PR #8084.
+
+
+Low-level RPC changes
+----------------------
+
+- RPC calls have been added to output detailed statistics for individual mempool
+ entries, as well as to calculate the in-mempool ancestors or descendants of a
+ transaction: see `getmempoolentry`, `getmempoolancestors`, `getmempooldescendants`.
+
+- `gettxoutsetinfo` UTXO hash (`hash_serialized`) has changed. There was a divergence between
+ 32-bit and 64-bit platforms, and the txids were missing in the hashed data. This has been
+ fixed, but this means that the output will be different than from previous versions.
+
+- Full UTF-8 support in the RPC API. Non-ASCII characters in, for example,
+ wallet labels have always been malformed because they weren't taken into account
+ properly in JSON RPC processing. This is no longer the case. This also affects
+ the GUI debug console.
+
+- Asm script outputs replacements for OP_NOP2 and OP_NOP3
+
+ - OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by [BIP
+65](
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki)
+
+ - OP_NOP3 has been renamed to OP_CHECKSEQUENCEVERIFY by [BIP
+112](
https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)
+
+ - The following outputs are affected by this change:
+
+ - RPC `getrawtransaction` (in verbose mode)
+ - RPC `decoderawtransaction`
+ - RPC `decodescript`
+ - REST `/rest/tx/` (JSON format)
+ - REST `/rest/block/` (JSON format when including extended tx details)
+ - `bitcoin-tx -json`
+
+- The sorting of the output of the `getrawmempool` output has changed.
+
+- New RPC commands: `generatetoaddress`, `importprunedfunds`, `removeprunedfunds`, `signmessagewithprivkey`,
+ `getmempoolancestors`, `getmempooldescendants`, `getmempoolentry`,
+ `createwitnessaddress`, `addwitnessaddress`.
+
+- Removed RPC commands: `setgenerate`, `getgenerate`.
+
+- New options were added to `fundrawtransaction`: `includeWatching`, `changeAddress`, `changePosition` and `feeRate`.
+
+
+Low-level ZMQ changes
+----------------------
+
+- Each ZMQ notification now contains an up-counting sequence number that allows
+ listeners to detect lost notifications.
+ The sequence number is always the last element in a multi-part ZMQ notification and
+ therefore backward compatible. Each message type has its own counter.
+ PR [#7762](
https://github.com/bitcoin/bitcoin/pull/7762).
+
+