Bitcoin Core-v0.14.0

Bitcoin Core version 0.14.0 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.14.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

Bitcoin Core is extensively tested on multiple operating systems using the Linux kernel, macOS 10.8+, and Windows Vista and later.

Microsoft ended support for Windows XP on April 8th, 2014, No attempt is made to prevent installing or running the software on Windows XP, you can still do so at your own risk but be aware that there are known instabilities and issues. Please do not report issues about Windows XP to the issue tracker.

Bitcoin Core should also work on most other Unix-like systems but is not frequently tested on them.

Notable changes

Performance Improvements

Validation speed and network propagation performance have been greatly improved, leading to much shorter sync and initial block download times.

  • The script signature cache has been reimplemented as a “cuckoo cache”, allowing for more signatures to be cached and faster lookups.
  • Assumed-valid blocks have been introduced which allows script validation to be skipped for ancestors of known-good blocks, without changing the security model. See below for more details.
  • In some cases, compact blocks are now relayed before being fully validated as per BIP152.
  • P2P networking has been refactored with a focus on concurrency and throughput. Network operations are no longer bottlenecked by validation. As a result, block fetching is several times faster than previous releases in many cases.
  • The UTXO cache now claims unused mempool memory. This speeds up initial block download as UTXO lookups are a major bottleneck there, and there is no use for the mempool at that stage.

Manual Pruning

Bitcoin Core has supported automatically pruning the blockchain since 0.11. Pruning the blockchain allows for significant storage space savings as the vast majority of the downloaded data can be discarded after processing so very little of it remains on the disk.

Manual block pruning can now be enabled by setting -prune=1. Once that is set, the RPC command pruneblockchain can be used to prune the blockchain up to the specified height or timestamp.

getinfo Deprecated

The getinfo RPC command has been deprecated. Each field in the RPC call has been moved to another command’s output with that command also giving additional information that getinfo did not provide. The following table shows where each field has been moved to:

getinfo field Moved to
"version" getnetworkinfo()["version"]
"protocolversion" getnetworkinfo()["protocolversion"]
"walletversion" getwalletinfo()["walletversion"]
"balance" getwalletinfo()["balance"]
"blocks" getblockchaininfo()["blocks"]
"timeoffset" getnetworkinfo()["timeoffset"]
"connections" getnetworkinfo()["connections"]
"proxy" getnetworkinfo()["networks"][0]["proxy"]
"difficulty" getblockchaininfo()["difficulty"]
"testnet" getblockchaininfo()["chain"] == "test"
"keypoololdest" getwalletinfo()["keypoololdest"]
"keypoolsize" getwalletinfo()["keypoolsize"]
"unlocked_until" getwalletinfo()["unlocked_until"]
"paytxfee" getwalletinfo()["paytxfee"]
"relayfee" getnetworkinfo()["relayfee"]
"errors" getnetworkinfo()["warnings"]

ZMQ On Windows

Previously the ZeroMQ notification system was unavailable on Windows due to various issues with ZMQ. These have been fixed upstream and now ZMQ can be used on Windows. Please see this document for help with using ZMQ in general.

Nested RPC Commands in Debug Console

The ability to nest RPC commands has been added to the debug console. This allows users to have the output of a command become the input to another command without running the commands separately.

The nested RPC commands use bracket syntax (i.e. getwalletinfo()) and can be nested (i.e. getblock(getblockhash(1))). Simple queries can be done with square brackets where object values are accessed with either an array index or a non-quoted string (i.e. listunspent()[0][txid]). Both commas and spaces can be used to separate parameters in both the bracket syntax and normal RPC command syntax.

Network Activity Toggle

A RPC command and GUI toggle have been added to enable or disable all p2p network activity. The network status icon in the bottom right hand corner is now the GUI toggle. Clicking the icon will either enable or disable all p2p network activity. If network activity is disabled, the icon will be grayed out with an X on top of it.

Additionally the setnetworkactive RPC command has been added which does the same thing as the GUI icon. The command takes one boolean parameter, true enables networking and false disables it.

Out-of-sync Modal Info Layer

When Bitcoin Core is out-of-sync on startup, a semi-transparent information layer will be shown over top of the normal display. This layer contains details about the current sync progress and estimates the amount of time remaining to finish syncing. This layer can also be hidden and subsequently unhidden by clicking on the progress bar at the bottom of the window.

Support for JSON-RPC Named Arguments

Commands sent over the JSON-RPC interface and through the bitcoin-cli binary can now use named arguments. This follows the JSON-RPC specification for passing parameters by-name with an object.

bitcoin-cli has been updated to support this by parsing name=value arguments when the -named option is given.

Some examples:

src/bitcoin-cli -named help command="help"
src/bitcoin-cli -named getblockhash height=0
src/bitcoin-cli -named getblock blockhash=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
src/bitcoin-cli -named sendtoaddress address="(snip)" amount="1.0" subtractfeefromamount=true

The order of arguments doesn’t matter in this case. Named arguments are also useful to leave out arguments that should stay at their default value. The rarely-used arguments comment and comment_to to sendtoaddress, for example, can be left out. However, this is not yet implemented for many RPC calls, this is expected to land in a later release.

The RPC server remains fully backwards compatible with positional arguments.

Opt into RBF When Sending

A new startup option, -walletrbf, has been added to allow users to have all transactions sent opt into RBF support. The default value for this option is currently false, so transactions will not opt into RBF by default. The new bumpfee RPC can be used to replace transactions that opt into RBF.

Sensitive Data Is No Longer Stored In Debug Console History

The debug console maintains a history of previously entered commands that can be accessed by pressing the Up-arrow key so that users can easily reuse previously entered commands. Commands which have sensitive information such as passphrases and private keys will now have a (...) in place of the parameters when accessed through the history.

Retaining the Mempool Across Restarts

The mempool will be saved to the data directory prior to shutdown to a mempool.dat file. This file preserves the mempool so that when the node restarts the mempool can be filled with transactions without waiting for new transactions to be created. This will also preserve any changes made to a transaction through commands such as prioritisetransaction so that those changes will not be lost.

Final Alert

The Alert System was disabled and deprecated in Bitcoin Core 0.12.1 and removed in 0.13.0. The Alert System was retired with a maximum sequence final alert which causes any nodes supporting the Alert System to display a static hard-coded “Alert Key Compromised” message which also prevents any other alerts from overriding it. This final alert is hard-coded into this release so that all old nodes receive the final alert.

GUI Changes

  • After resetting the options by clicking the Reset Options button in the options dialog or with the -resetguioptionsstartup option, the user will be prompted to choose the data directory again. This is to ensure that custom data directories will be kept after the option reset which clears the custom data directory set via the choose datadir dialog.
  • Multiple peers can now be selected in the list of peers in the debug window. This allows for users to ban or disconnect multiple peers simultaneously instead of banning them one at a time.
  • An indicator has been added to the bottom right hand corner of the main window to indicate whether the wallet being used is a HD wallet. This icon will be grayed out with an X on top of it if the wallet is not a HD wallet.

Low-level RPC changes

  • importprunedfunds only accepts two required arguments. Some versions accept an optional third arg, which was always ignored. Make sure to never pass more than two arguments.
  • The first boolean argument to getaddednodeinfo has been removed. This is an incompatible change.
  • RPC command getmininginfo loses the “testnet” field in favor of the more generic “chain” (which has been present for years).
  • A new RPC command preciousblock has been added which marks a block as precious. A precious block will be treated as if it were received earlier than a competing block.
  • A new RPC command importmulti has been added which receives an array of JSON objects representing the intention of importing a public key, a private key, an address and script/p2sh
  • Use of getrawtransaction for retrieving confirmed transactions with unspent outputs has been deprecated. For now this will still work, but in the future it may change to only be able to retrieve information about transactions in the mempool or if txindex is enabled.
  • A new RPC command getmemoryinfo has been added which will return information about the memory usage of Bitcoin Core. This was added in conjunction with optimizations to memory management. See Pull #8753 for more information.
  • A new RPC command bumpfee has been added which allows replacing an unconfirmed wallet transaction that signaled RBF (see the -walletrbf startup option above) with a new transaction that pays a higher fee, and should be more likely to get confirmed quickly.

HTTP REST Changes

  • UTXO set query (GET /rest/getutxos/<checkmempool>/<txid>-<n>/<txid>-<n> /.../<txid>-<n>.<bin|hex|json>) responses were changed to return status code HTTP_BAD_REQUEST (400) instead of HTTP_INTERNAL_SERVER_ERROR (500) when requests contain invalid parameters.

Minimum Fee Rate Policies

Since the changes in 0.12 to automatically limit the size of the mempool and improve the performance of block creation in mining code it has not been important for relay nodes or miners to set -minrelaytxfee. With this release the following concepts that were tied to this option have been separated out:

  • incremental relay fee used for calculating BIP 125 replacement and mempool limiting. (1000 satoshis/kB)
  • calculation of threshold for a dust output. (effectively 3 * 1000 satoshis/kB)
  • minimum fee rate of a package of transactions to be included in a block created by the mining code. If miners wish to set this minimum they can use the new -blockmintxfee option. (defaults to 1000 satoshis/kB)

The -minrelaytxfee option continues to exist but is recommended to be left unset.

Fee Estimation Changes

  • Since 0.13.2 fee estimation for a confirmation target of 1 block has been disabled. The fee slider will no longer be able to choose a target of 1 block. This is only a minor behavior change as there was often insufficient data for this target anyway. estimatefee 1 will now always return -1 and estimatesmartfee 1 will start searching at a target of 2.
  • The default target for fee estimation is changed to 6 blocks in both the GUI (previously 25) and for RPC calls (previously 2).

Removal of Priority Estimation

  • Estimation of “priority” needed for a transaction to be included within a target number of blocks has been removed. The RPC calls are deprecated and will either return -1 or 1e24 appropriately. The format for fee_estimates.dat has also changed to no longer save these priority estimates. It will automatically be converted to the new format which is not readable by prior versions of the software.
  • Support for “priority” (coin age) transaction sorting for mining is considered deprecated in Core and will be removed in the next major version. This is not to be confused with the prioritisetransaction RPC which will remain supported by Core for adding fee deltas to transactions.

P2P connection management

  • Peers manually added through the -addnode option or addnode RPC now have their own limit of eight connections which does not compete with other inbound or outbound connection usage and is not subject to the limitation imposed by the -maxconnections option.
  • New connections to manually added peers are performed more quickly.

Introduction of assumed-valid blocks

  • A significant portion of the initial block download time is spent verifying scripts/signatures. Although the verification must pass to ensure the security of the system, no other result from this verification is needed: If the node knew the history of a given block were valid it could skip checking scripts for its ancestors.
  • A new configuration option ‘assumevalid’ is provided to express this knowledge to the software. Unlike the ‘checkpoints’ in the past this setting does not force the use of a particular chain: chains that are consistent with it are processed quicker, but other chains are still accepted if they’d otherwise be chosen as best. Also unlike ‘checkpoints’ the user can configure which block history is assumed true, this means that even outdated software can sync more quickly if the setting is updated by the user.
  • Because the validity of a chain history is a simple objective fact it is much easier to review this setting. As a result the software ships with a default value adjusted to match the current chain shortly before release. The use of this default value can be disabled by setting -assumevalid=0

Fundrawtransaction change address reuse

  • Before 0.14, fundrawtransaction was by default wallet stateless. In almost all cases fundrawtransaction does add a change-output to the outputs of the funded transaction. Before 0.14, the used keypool key was never marked as change-address key and directly returned to the keypool (leading to address reuse). Before 0.14, calling getnewaddress directly after fundrawtransaction did generate the same address as the change-output address.
  • Since 0.14, fundrawtransaction does reserve the change-output-key from the keypool by default (optional by settingreserveChangeKey, default = true)
  • Users should also consider using getrawchangeaddress() in conjunction with fundrawtransaction‘s changeAddressoption.

Unused mempool memory used by coincache

  • Before 0.14, memory reserved for mempool (using the -maxmempool option) went unused during initial block download, or IBD. In 0.14, the UTXO DB cache (controlled with the -dbcache option) borrows memory from the mempool when there is extra memory available. This may result in an increase in memory usage during IBD for those previously relying on only the -dbcache option to limit memory during that time.

0.14.0 Change log

Detailed release notes follow. This overview includes changes that affect behavior, not code moves, minor 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 other APIs

  • #8421 b77bb95 httpserver: drop boost dependency (theuni)
  • #8638 f061415 rest.cpp: change HTTP_INTERNAL_SERVER_ERROR to HTTP_BAD_REQUEST (djpnewton)
  • #8272 91990ee Make the dummy argument to getaddednodeinfo optional (sipa)
  • #8722 bb843ad bitcoin-cli: More detailed error reporting (laanwj)
  • #6996 7f71a3c Add preciousblock RPC (sipa)
  • #8788 97c7f73 Give RPC commands more information about the RPC request (jonasschnelli)
  • #7948 5d2c8e5 Augment getblockchaininfo bip9_softforks data (mruddy)
  • #8980 0e22855 importmulti: Avoid using boost::variant::operator!=, which is only in newer boost versions (luke-jr)
  • #9025 4d8558a Getrawtransaction should take a bool for verbose (jnewbery)
  • #8811 5754e03 Add support for JSON-RPC named arguments (laanwj)
  • #9520 2456a83 Deprecate non-txindex getrawtransaction and better warning (sipa)
  • #9518 a65ced1 Return height of last block pruned by pruneblockchain RPC (ryanofsky)
  • #9222 7cb024e Add ‘subtractFeeFromAmount’ option to ‘fundrawtransaction’ (dooglus)
  • #8456 2ef52d3 Simplified bumpfee command (mrbandrews)
  • #9516 727a798 Bug-fix: listsinceblock: use fork point as reference for blocks in reorg’d chains (kallewoof)
  • #9640 7bfb770 Bumpfee: bugfixes for error handling and feerate calculation (sdaftuar)
  • #9673 8d6447e Set correct metadata on bumpfee wallet transactions (ryanofsky)
  • #9650 40f7e27 Better handle invalid parameters to signrawtransaction (TheBlueMatt)
  • #9682 edc9e63 Require timestamps for importmulti keys (ryanofsky)
  • #9108 d8e8b06 Use importmulti timestamp when importing watch only keys (on top of #9682) (ryanofsky)
  • #9756 7a93af8 Return error when importmulti called with invalid address (ryanofsky)
  • #9778 ad168ef Add two hour buffer to manual pruning (morcos)
  • #9761 9828f9a Use 2 hour grace period for key timestamps in importmulti rescans (ryanofsky)
  • #9474 48d7e0d Mark the minconf parameter to move as ignored (sipa)
  • #9619 861cb0c Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates (luke-jr)
  • #9773 9072395 Return errors from importmulti if complete rescans are not successful (ryanofsky)

Block and transaction handling

  • #8391 37d83bb Consensus: Remove ISM (NicolasDorier)
  • #8365 618c9dd Treat high-sigop transactions as larger rather than rejecting them (sipa)
  • #8814 14b7b3f wallet, policy: ParameterInteraction: Don’t allow 0 fee (MarcoFalke)
  • #8515 9bdf526 A few mempool removal optimizations (sipa)
  • #8448 101c642 Store mempool and prioritization data to disk (sipa)
  • #7730 3c03dc2 Remove priority estimation (morcos)
  • #9111 fb15610 Remove unused variable UNLIKELY_PCT from fees.h (fanquake)
  • #9133 434e683 Unset fImporting for loading mempool (morcos)
  • #9179 b9a87b4 Set DEFAULT_LIMITFREERELAY = 0 kB/minute (MarcoFalke)
  • #9239 3fbf079 Disable fee estimates for 1-block target (morcos)
  • #7562 1eef038 Bump transaction version default to 2 (btcdrak)
  • #9313,#9367 If we don’t allow free txs, always send a fee filter (morcos)
  • #9346 b99a093 Batch construct batches (sipa)
  • #9262 5a70572 Prefer coins that have fewer ancestors, sanity check txn before ATMP (instagibbs)
  • #9288 1ce7ede Fix a bug if the min fee is 0 for FeeFilterRounder (morcos)
  • #9395 0fc1c31 Add test for -walletrejectlongchains (morcos)
  • #9107 7dac1e5 Safer modify new coins (morcos)
  • #9312 a72f76c Increase mempool expiry time to 2 weeks (morcos)
  • #8610 c252685 Share unused mempool memory with coincache (sipa)
  • #9138 f646275 Improve fee estimation (morcos)
  • #9408 46b249e Allow shutdown during LoadMempool, dump only when necessary (jonasschnelli)
  • #9310 8c87f17 Assert FRESH validity in CCoinsViewCache::BatchWrite (ryanofsky)
  • #7871 e2e624d Manual block file pruning (mrbandrews)
  • #9507 0595042 Fix use-after-free in CTxMemPool::removeConflicts() (sdaftuar)
  • #9380 dd98f04 Separate different uses of minimum fees (morcos)
  • #9596 71148b8 bugfix save feeDelta instead of priorityDelta in DumpMempool (morcos)
  • #9371 4a1dc35 Notify on removal (morcos)
  • #9519 9b4d267 Exclude RBF replacement txs from fee estimation (morcos)
  • #8606 e2a1a1e Fix some locks (sipa)
  • #8681 6898213 Performance Regression Fix: Pre-Allocate txChanged vector (JeremyRubin)
  • #8223 744d265 c++11: Use std::unique_ptr for block creation (domob1812)
  • #9125 7490ae8 Make CBlock a vector of shared_ptr of CTransactions (sipa)
  • #8930 93566e0 Move orphan processing to ActivateBestChain (TheBlueMatt)
  • #8580 46904ee Make CTransaction actually immutable (sipa)
  • #9240 a1dcf2e Remove txConflicted (morcos)
  • #8589 e8cfe1e Inline CTxInWitness inside CTxIn (sipa)
  • #9349 2db4cbc Make CScript (and prevector) c++11 movable (sipa)
  • #9252 ce5c1f4 Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling) (sdaftuar)
  • #9283 869781c A few more CTransactionRef optimizations (sipa)
  • #9499 9c9af5a Use recent-rejects, orphans, and recently-replaced txn for compact-block-reconstruction (TheBlueMatt)
  • #9813 3972a8e Read/write mempool.dat as a binary (paveljanik)

P2P protocol and network code

  • #8128 1030fa7 Turn net structures into dumb storage classes (theuni)
  • #8282 026c6ed Feeler connections to increase online addrs in the tried table (EthanHeilman)
  • #8462 53f8f22 Move AdvertiseLocal debug output to net category (Mirobit)
  • #8612 84decb5 Check for compatibility with download in FindNextBlocksToDownload (sipa)
  • #8594 5b2ea29 Do not add random inbound peers to addrman (gmaxwell)
  • #8085 6423116 Begin encapsulation (theuni)
  • #8715 881d7ea only delete CConnman if it’s been created (theuni)
  • #8707 f07424a Fix maxuploadtarget setting (theuni)
  • #8661 d2e4655 Do not set an addr time penalty when a peer advertises itself (gmaxwell)
  • #8822 9bc6a6b Consistent checksum handling (laanwj)
  • #8936 1230890 Report NodeId in misbehaving debug (rebroad)
  • #8968 3cf496d Don’t hold cs_main when calling ProcessNewBlock from a cmpctblock (TheBlueMatt)
  • #9002 e1d1f57 Make connect=0 disable automatic outbound connections (gmaxwell)
  • #9050 fcf61b8 Make a few values immutable, and use deterministic randomness for the localnonce (theuni)
  • #8969 3665483 Decouple peer-processing-logic from block-connection-logic (#2) (TheBlueMatt)
  • #8708 c8c572f have CConnman handle message sending (theuni)
  • #8709 1e50d22 Allow filterclear messages for enabling TX relay only (rebroad)
  • #9045 9f554e0 Hash P2P messages as they are received instead of at process-time (TheBlueMatt)
  • #9026 dc6b940 Fix handling of invalid compact blocks (sdaftuar)
  • #8996 ab914a6 Network activity toggle (luke-jr)
  • #9131 62af164 fNetworkActive is not protected by a lock, use an atomic (jonasschnelli)
  • #8872 0c577f2 Remove block-request logic from INV message processing (TheBlueMatt)
  • #8690 791b58d Do not fully sort all nodes for addr relay (sipa)
  • #9128 76fec09 Decouple CConnman and message serialization (theuni)
  • #9226 3bf06e9 Remove fNetworkNode and pnodeLocalHost (gmaxwell)
  • #9352 a7f7651 Attempt reconstruction from all compact block announcements (sdaftuar)
  • #9319 a55716a Break addnode out from the outbound connection limits (gmaxwell)
  • #9261 2742568 Add unstored orphans with rejected parents to recentRejects (morcos)
  • #9441 8b66bf7 Massive speedup. Net locks overhaul (theuni)
  • #9375 3908fc4 Relay compact block messages prior to full block connection (TheBlueMatt)
  • #9400 8a445c5 Set peers as HB peers upon full block validation (instagibbs)
  • #9561 6696b46 Wake message handling thread when we receive a new block (TheBlueMatt)
  • #9535 82274c0 Split CNode::cs_vSend: message processing and message sending (TheBlueMatt)
  • #9606 3f9f962 Consistently use GetTimeMicros() for inactivity checks (sdaftuar)
  • #9594 fd70211 Send final alert message to older peers after connecting (gmaxwell)
  • #9626 36966a1 Clean up a few CConnman cs_vNodes/CNode things (TheBlueMatt)
  • #9609 4966917 Fix remaining net assertions (theuni)
  • #9671 7821db3 Fix super-unlikely race introduced in 236618061a445d2cb11e72 (TheBlueMatt)
  • #9730 33f3b21 Remove bitseed.xf2.org form the dns seed list (jonasschnelli)
  • #9698 2447c10 Fix socket close race (theuni)
  • #9708 a06ede9 Clean up all known races/platform-specific UB at the time PR was opened (TheBlueMatt)
  • #9715 b08656e Disconnect peers which we do not receive VERACKs from within 60 sec (TheBlueMatt)
  • #9720 e87ce95 Fix banning and disallow sending messages before receiving verack (theuni)
  • #9268 09c4fd1 Fix rounding privacy leak introduced in #9260 (TheBlueMatt)
  • #9075 9346f84 Decouple peer-processing-logic from block-connection-logic (#3) (TheBlueMatt)
  • #8688 047ded0 Move static global randomizer seeds into CConnman (sipa)
  • #9289 d9ae1ce net: drop boost::thread_group (theuni)

Validation

  • #9014 d04aeba Fix block-connection performance regression (TheBlueMatt)
  • #9299 d52ce89 Remove no longer needed check for premature v2 txs (morcos)
  • #9273 b68685a Remove unused CDiskBlockPos* argument from ProcessNewBlock (TheBlueMatt)
  • #8895 b83264d Better SigCache Implementation (JeremyRubin)
  • #9490 e126d0c Replace FindLatestBefore used by importmulti with FindEarliestAtLeast (gmaxwell)
  • #9484 812714f Introduce assumevalid setting to skip validation presumed valid scripts (gmaxwell)
  • #9511 7884956 Don’t overwrite validation state with corruption check (morcos)
  • #9765 1e92e04 Harden against mistakes handling invalid blocks (sdaftuar)
  • #9779 3c02b95 Update nMinimumChainWork and defaultAssumeValid (gmaxwell)
  • #8524 19b0f33 Precompute sighashes (sipa)
  • #9791 1825a03 Avoid VLA in hash.h (sipa)

Build system

  • #8238 6caf3ee ZeroMQ 4.1.5 && ZMQ on Windows (fanquake)
  • #8520 b40e19c Remove check for openssl/ec.h (laanwj)
  • #8617 de07fdc Include instructions to extract Mac OS X SDK on Linux using 7zip and SleuthKit (luke-jr)
  • #8566 7b98895 Easy to use gitian building script (achow101)
  • #8604 f256843 build,doc: Update for 0.13.0+ and OpenBSD 5.9 (laanwj)
  • #8640 2663e51 depends: Remove Qt46 package (fanquake)
  • #8645 8ea4440 Remove unused Qt 4.6 patch (droark)
  • #8608 7e9ab95 Install manpages via make install, also add some autogenerated manpages (nomnombtc)
  • #8781 ca69ef4 contrib: delete qt_translations.py (MarcoFalke)
  • #8783 64dc645 share: remove qt/protobuf.pri (MarcoFalke)
  • #8423 3166dff depends: expat 2.2.0, ccache 3.3.1, fontconfig 2.12.1 (fanquake)
  • #8791 b694b0d travis: cross-mac: explicitly enable gui (MarcoFalke)
  • #8820 dc64141 depends: Fix Qt compilation with Xcode 8 (fanquake)
  • #8730 489a6ab depends: Add libevent compatibility patch for windows (laanwj)
  • #8819 c841816 depends: Boost 1.61.0 (fanquake)
  • #8826 f560d95 Do not include env_win.cc on non-Windows systems (paveljanik)
  • #8948 e077e00 Reorder Windows gitian build order to match Linux (Michagogo)
  • #8568 078900d new var DIST_CONTRIB adds useful things for packagers from contrib (nomnombtc)
  • #9114 21e6c6b depends: Set OSX_MIN_VERSION to 10.8 (fanquake)
  • #9140 018a4eb Bugfix: Correctly replace generated headers and fail cleanly (luke-jr)
  • #9156 a8b2a82 Add compile and link options echo to configure (jonasschnelli)
  • #9393 03d85f6 Include cuckoocache header in Makefile (MarcoFalke)
  • #9420 bebe369 Fix linker error when configured with –enable-lcov (droark)
  • #9412 53442af Fix ‘make deploy’ for OSX (jonasschnelli)
  • #9475 7014506 Let autoconf detect presence of EVP_MD_CTX_new (luke-jr)
  • #9513 bbf193f Fix qt distdir builds (theuni)
  • #9471 ca615e6 depends: libevent 2.1.7rc (fanquake)
  • #9468 f9117f2 depends: Dependency updates for 0.14.0 (fanquake)
  • #9469 01c4576 depends: Qt 5.7.1 (fanquake)
  • #9574 5ac6687 depends: Fix QT build on OSX (fanquake)
  • #9646 720b579 depends: Fix cross build for qt5.7 (theuni)
  • #9705 6a55515 Add options to override BDB cflags/libs (laanwj)
  • #8249 4e1567a Enable (and check for) 64-bit ASLR on Windows (laanwj)
  • #9758 476cc47 Selectively suppress deprecation warnings (jonasschnelli)
  • #9783 6d61a2b release: bump gitian descriptors for a new 0.14 package cache (theuni)
  • #9789 749fe95 build: add –enable-werror and warn on vla’s (theuni)
  • #9831 99fd85c build: force a c++ standard to be specified (theuni)

GUI

  • #8192 c503863 Remove URLs from About dialog translations (fanquake)
  • #8540 36404ae Fix random segfault when closing “Choose data directory” dialog (laanwj)
  • #8517 2468292 Show wallet HD state in statusbar (jonasschnelli)
  • #8463 62a5a8a Remove Priority from coincontrol dialog (MarcoFalke)
  • #7579 0606f95 Show network/chain errors in the GUI (jonasschnelli)
  • #8583 c19f8a4 Show XTHIN in GUI (rebroad)
  • #7783 4335d5a RPC-Console: support nested commands and simple value queries (jonasschnelli)
  • #8672 6052d50 Show transaction size in transaction details window (Cocosoft)
  • #8777 fec6af7 WalletModel: Expose disablewallet (MarcoFalke)
  • #8371 24f72e9 Add out-of-sync modal info layer (jonasschnelli)
  • #8885 b2fec4e Fix ban from qt console (theuni)
  • #8821 bf8e68a sync-overlay: Don’t block during reindex (MarcoFalke)
  • #8906 088d1f4 sync-overlay: Don’t show progress twice (MarcoFalke)
  • #8918 47ace42 Add “Copy URI” to payment request context menu (luke-jr)
  • #8925 f628d9a Display minimum ping in debug window (rebroad)
  • #8774 3e942a7 Qt refactors to better abstract wallet access (luke-jr)
  • #8985 7b1bfa3 Use pindexBestHeader instead of setBlockIndexCandidates for NotifyHeaderTip() (jonasschnelli)
  • #8989 d2143dc Overhaul smart-fee slider, adjust default confirmation target (jonasschnelli)
  • #9043 273bde3 Return useful error message on ATMP failure (MarcoFalke)
  • #9088 4e57824 Reduce ambiguity of warning message (rebroad)
  • #8874 e984730 Multiple Selection for peer and ban tables (achow101)
  • #9145 924745d Make network disabled icon 50% opaque (MarcoFalke)
  • #9130 ac489b2 Mention the new network toggle functionality in the tooltip (paveljanik)
  • #9218 4d955fc Show progress overlay when clicking spinner icon (laanwj)
  • #9280 e15660c Show ModalOverlay by pressing the progress bar, allow hiding (jonasschnelli)
  • #9296 fde7d99 Fix missed change to WalletTx structure (morcos)
  • #9266 2044e37 Bugfix: Qt/RPCConsole: Put column enum in the right places (luke-jr)
  • #9255 9851a84 layoutAboutToChange signal is called layoutAboutToBeChanged (laanwj)
  • #9330 47e6a19 Console: add security warning (jonasschnelli)
  • #9329 db45ad8 Console: allow empty arguments (jonasschnelli)
  • #8877 6dc4c43 Qt RPC console: history sensitive-data filter, and saving input line when browsing history (luke-jr)
  • #9462 649cf5f Do not translate tilde character (MarcoFalke)
  • #9457 123ea73 Select more files for translation (MarcoFalke)
  • #9413 fd7d8c7 CoinControl: Allow non-wallet owned change addresses (jonasschnelli)
  • #9461 b250686 Improve progress display during headers-sync and peer-finding (jonasschnelli)
  • #9588 5086452 Use nPowTargetSpacing constant (MarcoFalke)
  • #9637 d9e4d1d Fix transaction details output-index to reflect vout index (jonasschnelli)
  • #9718 36f9d3a Qt/Intro: Various fixes (luke-jr)
  • #9735 ec66d06 devtools: Handle Qt formatting characters edge-case in update-translations.py (laanwj)
  • #9755 a441db0 Bugfix: Qt/Options: Restore persistent “restart required” notice (luke-jr)
  • #9817 7d75a5a Fix segfault crash when shutdown the GUI in disablewallet mode (jonasschnelli)

Wallet

  • #8152 b9c1cd8 Remove CWalletDB* parameter from CWallet::AddToWallet (pstratem)
  • #8432 c7e05b3 Make CWallet::fFileBacked private (pstratem)
  • #8445 f916700 Move CWallet::setKeyPool to private section of CWallet (pstratem)
  • #8564 0168019 Remove unused code/conditions in ReadAtCursor (jonasschnelli)
  • #8601 37ac678 Add option to opt into full-RBF when sending funds (rebase, original by petertodd) (laanwj)
  • #8494 a5b20ed init, wallet: ParameterInteraction() iff wallet enabled (MarcoFalke)
  • #8760 02ac669 init: Get rid of some ENABLE_WALLET (MarcoFalke)
  • #8696 a1f8d3e Wallet: Remove last external reference to CWalletDB (pstratem)
  • #8768 886e8c9 init: Get rid of fDisableWallet (MarcoFalke)
  • #8486 ab0b411 Add high transaction fee warnings (MarcoFalke)
  • #8851 940748b Move key derivation logic from GenerateNewKey to DeriveNewChildKey (pstratem)
  • #8287 e10af96 Set fLimitFree = true (MarcoFalke)
  • #8928 c587577 Fix init segfault where InitLoadWallet() calls ATMP before genesis (TheBlueMatt)
  • #7551 f2d7056 Add importmulti RPC call (pedrobranco)
  • #9016 0dcb888 Return useful error message on ATMP failure (instagibbs)
  • #8753 f8723d2 Locked memory manager (laanwj)
  • #8828 a4fd8df Move CWalletDB::ReorderTransactions to CWallet (pstratem)
  • #8977 6a1343f Refactor wallet/init interaction (Reaccept wtx, flush thread) (jonasschnelli)
  • #9036 ed0cc50 Change default confirm target from 2 to 6 (laanwj)
  • #9071 d1871da Declare wallet.h functions inline (sipa)
  • #9132 f54e460 Make strWalletFile const (jonasschnelli)
  • #9141 5ea5e04 Remove unnecessary calls to CheckFinalTx (jonasschnelli)
  • #9165 c01f16a SendMoney: use already-calculated balance (instagibbs)
  • #9311 a336d13 Flush wallet after abandontransaction (morcos)
  • #8717 38e4887 Addition of ImmatureCreditCached to MarkDirty() (spencerlievens)
  • #9446 510c0d9 SetMerkleBranch: remove unused code, remove cs_main lock requirement (jonasschnelli)
  • #8776 2a524b8 Wallet refactoring leading up to multiwallet (luke-jr)
  • #9465 a7d55c9 Do not perform ECDSA signing in the fee calculation inner loop (gmaxwell)
  • #9404 12e3112 Smarter coordination of change and fee in CreateTransaction (morcos)
  • #9377 fb75cd0 fundrawtransaction: Keep change-output keys by default, make it optional (jonasschnelli)
  • #9578 923dc44 Add missing mempool lock for CalculateMemPoolAncestors (TheBlueMatt)
  • #9227 02464da Make nWalletDBUpdated atomic to avoid a potential race (pstratem)
  • #9764 f8af89a Prevent “overrides a member function but is not marked ‘override'” warnings (laanwj)
  • #9771 e43a585 Add missing cs_wallet lock that triggers new lock held assertion (ryanofsky)
  • #9316 3097ea4 Disable free transactions when relay is disabled (MarcoFalke)
  • #9615 d2c9e4d Wallet incremental fee (morcos)
  • #9760 40c754c Remove importmulti always-true check (ryanofsky)

Tests and QA

  • #8270 6e5e5ab Tests: Use portable #! in python scripts (/usr/bin/env) (ChoHag)
  • #8534,#8504 Remove java comparison tool (laanwj,MarcoFalke)
  • #8482 740cff5 Use single cache dir for chains (MarcoFalke)
  • #8450 21857d2 Replace rpc_wallet_tests.cpp with python RPC unit tests (pstratem)
  • #8671 ddc3080 Minimal fix to slow prevector tests as stopgap measure (JeremyRubin)
  • #8680 666eaf0 Address Travis spurious failures (theuni)
  • #8789 e31a43c pull-tester: Only print output when failed (MarcoFalke)
  • #8810 14e8f99 tests: Add exception error message for JSONRPCException (laanwj)
  • #8830 ef0801b test: Add option to run bitcoin-util-test.py manually (jnewbery)
  • #8881 e66cc1d Add some verbose logging to bitcoin-util-test.py (jnewbery)
  • #8922 0329511 Send segwit-encoded blocktxn messages in p2p-compactblocks (TheBlueMatt)
  • #8873 74dc388 Add microbenchmarks to profile more code paths (ryanofsky)
  • #9032 6a8be7b test: Add format-dependent comparison to bctest (laanwj)
  • #9023 774db92 Add logging to bitcoin-util-test.py (jnewbery)
  • #9065 c9bdf9a Merge doc/unit-tests.md into src/test/README.md (laanwj)
  • #9069 ed64bce Clean up bctest.py and bitcoin-util-test.py (jnewbery)
  • #9095 b8f43e3 test: Fix test_random includes (MarcoFalke)
  • #8894 faec09b Testing: Include fRelay in mininode version messages (jnewbery)
  • #9097 e536499 Rework sync_* and preciousblock.py (MarcoFalke)
  • #9049 71bc39e Remove duplicatable duplicate-input check from CheckTransaction (TheBlueMatt)
  • #9136 b422913 sync_blocks cleanup (ryanofsky)
  • #9151 4333b1c proxy_test: Calculate hardcoded port numbers (MarcoFalke)
  • #9206 e662d28 Make test constant consistent with consensus.h (btcdrak)
  • #9139 0de7fd3 Change sync_blocks to pick smarter maxheight (on top of #9196) (ryanofsky)
  • #9100 97ec6e5 tx_valid: re-order inputs to how they are encoded (dcousens)
  • #9202 e56cf67 bench: Add support for measuring CPU cycles (laanwj)
  • #9223 5412c08 unification of Bloom filter representation (s-matthew-english)
  • #9257 d7ba4a2 Dump debug logs on travis failures (sdaftuar)
  • #9221 9e4bb31 Get rid of duplicate code (MarcoFalke)
  • #9274 919db03 Use cached utxo set to fix performance regression (MarcoFalke)
  • #9276 ea33f19 Some minor testing cleanups (morcos)
  • #9291 8601784 Remove mapOrphanTransactionsByPrev from DoS_tests (sipa)
  • #9309 76fcd9d Wallet needs to stay unlocked for whole test (morcos)
  • #9172 5bc209c Resurrect pstratem’s “Simple fuzzing framework” (laanwj)
  • #9331 c6fd923 Add test for rescan feature of wallet key import RPCs (ryanofsky)
  • #9354 b416095 Make fuzzer actually test CTxOutCompressor (sipa)
  • #9390,#9416 travis: make distdir (MarcoFalke)
  • #9308 0698639 test: Add CCoinsViewCache Access/Modify/Write tests (ryanofsky)
  • #9406 0f921e6 Re-enable a blank v1 Tx JSON test (droark)
  • #9435 dbc8a8c Removed unused variable in test, fixing warning (ryanofsky)
  • #9436 dce853e test: Include tx data in EXTRA_DIST (MarcoFalke)
  • #9525 02e5308 test: Include tx data in EXTRA_DIST (MarcoFalke)
  • #9498 054d664 Basic CCheckQueue Benchmarks (JeremyRubin)
  • #9554 0b96abc test: Avoid potential NULL pointer dereference in addrman_tests.cpp (practicalswift)
  • #9628 f895023 Increase a sync_blocks timeout in pruning.py (sdaftuar)
  • #9638 a7ea2f8 Actually test assertions in pruning.py (MarcoFalke)
  • #9647 e99f0d7 Skip RAII event tests if libevent is built without event_set_mem_functions (luke-jr)
  • #9691 fc67cd2 Init ECC context for test_bitcoin_fuzzy (gmaxwell)
  • #9712 d304fef bench: Fix initialization order in registration (laanwj)
  • #9707 b860915 Fix RPC failure testing (jnewbery)
  • #9269 43e8150 Align struct COrphan definition (sipa)
  • #9820 599c69a Fix pruning test broken by 2 hour manual prune window (ryanofsky)
  • #9824 260c71c qa: Check return code when stopping nodes (MarcoFalke)
  • #9875 50953c2 tests: Fix dangling pwalletMain pointer in wallet tests (laanwj)
  • #9839 eddaa6b [qa] Make import-rescan.py watchonly check reliable (ryanofsky)

Documentation

  • #8332 806b9e7 Clarify witness branches in transaction.h serialization (dcousens)
  • #8935 0306978 Documentation: Building on Windows with WSL (pooleja)
  • #9144 c98f6b3 Correct waitforblockheight example help text (fanquake)
  • #9407 041331e Added missing colons in when running help command (anditto)
  • #9378 870cd2b Add documentation for CWalletTx::fFromMe member (ryanofsky)
  • #9297 0b73807 Various RPC help outputs updated (Mirobit)
  • #9613 07421cf Clarify getbalance help string to explain interaction with bumpfee (ryanofsky)
  • #9663 e30d928 Clarify listunspent amount description (instagibbs)
  • #9396 d65a13b Updated listsinceblock rpc documentation (accraze)
  • #8747 ce43630 rpc: Fix transaction size comments and RPC help text (jnewbery)
  • #8058 bbd9740 Doc: Add issue template (AmirAbrams)
  • #8567 85d4e21 Add default port numbers to REST doc (djpnewton)
  • #8624 89de153 build: Mention curl (MarcoFalke)
  • #8786 9da7366 Mandatory copyright agreement (achow101)
  • #8823 7b05af6 Add privacy recommendation when running hidden service (laanwj)
  • #9433 caa2f10 Update the Windows build notes (droark)
  • #8879 f928050 Rework docs (MarcoFalke)
  • #8887 61d191f Improve GitHub issue template (fanquake)
  • #8787 279bbad Add missing autogen to example builds (AmirAbrams)
  • #8892 d270c30 Add build instructions for FreeBSD (laanwj)
  • #8890 c71a654 Update Doxygen configuration file (fanquake)
  • #9207 fa1f944 Move comments above bash command in build-unix (AmirAbrams)
  • #9219 c4522e7 Improve windows build instructions using Linux subsystem (laanwj)
  • #8954 932d02a contrib: Add README for pgp keys (MarcoFalke)
  • #9093 2fae5b9 release-process: Mention GitHub release and archived release notes (MarcoFalke)
  • #8743 bae178f Remove old manpages from contrib/debian in favour of doc/man (fanquake)
  • #9550 4105cb6 Trim down the XP notice and say more about what we support (gmaxwell)
  • #9246 9851498 Developer docs about existing subtrees (gmaxwell)
  • #9401 c2ea1e6 Make rpcauth help message clearer, add example in example .conf (instagibbs)
  • #9022,#9033 Document dropping OS X 10.7 support (fanquake, MarcoFalke)
  • #8771 bc9e3ab contributing: Mention not to open several pulls (luke-jr)
  • #8852 7b784cc Mention Gitian building script in doc (Laudaa) (laanwj)
  • #8915 03dd707 Add copyright/patent issues to possible NACK reasons (petertodd)
  • #8965 23e03f8 Mention that PPA doesn’t support Debian (anduck)
  • #9115 bfc7aad Mention reporting security issues responsibly (paveljanik)
  • #9840 08e0690 Update sendfrom RPC help to correct coin selection misconception (ryanofsky)
  • #9865 289204f Change bitcoin address in RPC help message (marijnfs)

Miscellaneous

  • #8274 7a2d402 util: Update tinyformat (laanwj)
  • #8291 5cac8b1 util: CopyrightHolders: Check for untranslated substitution (MarcoFalke)
  • #8557 44691f3 contrib: Rework verifybinaries (MarcoFalke)
  • #8621 e8ed6eb contrib: python: Don’t use shell=True (MarcoFalke)
  • #8813 fb24d7e bitcoind: Daemonize using daemon(3) (laanwj)
  • #9004 67728a3 Clarify listenonion (unsystemizer)
  • #8674 bae81b8 tools for analyzing, updating and adding copyright headers in source files (isle2983)
  • #8976 8c6218a libconsensus: Add input validation of flags (laanwj)
  • #9112 46027e8 Avoid ugly exception in log on unknown inv type (laanwj)
  • #8837 2108911 Allow bitcoin-tx to parse partial transactions (jnewbery)
  • #9204 74ced54 Clarify CreateTransaction error messages (instagibbs)
  • #9265 31bcc66 bitcoin-cli: Make error message less confusing (laanwj)
  • #9303 72bf1b3 Update comments in ctaes (sipa)
  • #9417 c4b7d4f Do not evaluate hidden LogPrint arguments (sipa)
  • #9506 593a00c RFC: Improve style for if indentation (sipa)
  • #8883 d5d4ad8 Add all standard TXO types to bitcoin-tx (jnewbery)
  • #9531 23281a4 Release notes for estimation changes (morcos)
  • #9486 f62bc10 Make peer=%d log prints consistent (TheBlueMatt)
  • #9552 41cb05c Add IPv6 support to qos.sh (jamesmacwhite)
  • #9542 e9e7993 Docs: Update CONTRIBUTING.md (jnewbery)
  • #9649 53ab12d Remove unused clang format dev script (MarcoFalke)
  • #9625 77bd8c4 Increase minimum debug.log size to 10MB after shrink (morcos)
  • #9070 7b22e50 Lockedpool fixes (kazcw)
  • #8779 7008e28 contrib: Delete spendfrom (MarcoFalke)
  • #9587,#8793,#9496,#8191,#8109,#8655,#8472,#8677,#8981,#9124 Avoid shadowing of variables (paveljanik)
  • #9063 f2a6e82 Use deprecated MAP_ANON if MAP_ANONYMOUS is not defined (paveljanik)
  • #9060 1107653 Fix bloom filter init to isEmpty = true (robmcl4)
  • #8613 613bda4 LevelDB 1.19 (sipa)
  • #9225 5488514 Fix some benign races (TheBlueMatt)
  • #8736 5fa7b07 base58: Improve DecodeBase58 performance (wjx)
  • #9039 e81df49 Various serialization simplifcations and optimizations (sipa)
  • #9010 a143b88 Split up AppInit2 into multiple phases, daemonize after datadir lock errors (laanwj)
  • #9230 c79e52a Fix some benign races in timestamp logging (TheBlueMatt)
  • #9183,#9260 Mrs Peacock in The Library with The Candlestick (killed main.{h,cpp}) (TheBlueMatt)
  • #9236 7f72568 Fix races for strMiscWarning and fLargeWork*Found, make QT runawayException use GetWarnings (gmaxwell)
  • #9243 7aa7004 Clean up mapArgs and mapMultiArgs Usage (TheBlueMatt)
  • #9387 cfe41d7 RAII of libevent stuff using unique ptrs with deleters (kallewoof)
  • #9472 fac0f30 Disentangle progress estimation from checkpoints and update it (sipa)
  • #9512 6012967 Fix various things -fsanitize complains about (sipa)
  • #9373,#9580 Various linearization script issues (droark)
  • #9674 dd163f5 Lock debugging: Always enforce strict lock ordering (try or not) (TheBlueMatt)
  • #8453,#9334 Update to latest libsecp256k1 (laanwj,sipa)
  • #9656 7c93952 Check verify-commits on pushes to master (TheBlueMatt)
  • #9679 a351162 Access WorkQueue::running only within the cs lock (TheBlueMatt)
  • #9777 8dee822 Handle unusual maxsigcachesize gracefully (jnewbery)
  • #8863,#8807 univalue: Pull subtree (MarcoFalke)
  • #9798 e22c067 Fix Issue #9775 (Check returned value of fopen) (kirit93)
  • #9856 69832aa Terminate immediately when allocation fails (theuni)

 

Index of /bin/bitcoin-core-0.14.0/


../
test.rc1/                                          19-Feb-2017 11:32                   -
test.rc2/                                          25-Feb-2017 16:42                   -
test.rc3/                                          01-Mar-2017 08:48                   -
SHA256SUMS.asc                                     08-Mar-2017 06:26                1957
bitcoin-0.14.0-aarch64-linux-gnu.tar.gz            08-Mar-2017 06:27             9923944
bitcoin-0.14.0-arm-linux-gnueabihf.tar.gz          08-Mar-2017 06:29             9248720
bitcoin-0.14.0-i686-pc-linux-gnu.tar.gz            08-Mar-2017 06:28            24957220
bitcoin-0.14.0-osx.dmg                             08-Mar-2017 06:27            13833934
bitcoin-0.14.0-osx64.tar.gz                        08-Mar-2017 06:27            19553349
bitcoin-0.14.0-win32-setup.exe                     08-Mar-2017 06:29            13236616
bitcoin-0.14.0-win32.zip                           08-Mar-2017 06:29            23491078
bitcoin-0.14.0-win64-setup.exe                     08-Mar-2017 06:27            13841000
bitcoin-0.14.0-win64.zip                           08-Mar-2017 06:27            24938761
bitcoin-0.14.0-x86_64-linux-gnu.tar.gz             08-Mar-2017 06:28            24552895
bitcoin-0.14.0.tar.gz                              08-Mar-2017 06:28             6376903
bitcoin-0.14.0.torrent                             08-Mar-2017 06:36               15165

Bitcoin Core v0.13.2

Compatibility

Microsoft ended support for Windows XP on April 8th, 2014, 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 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 version 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.

From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+, but severe issues with the libc++ version on 10.7.x keep it from running reliably. 0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.

Notable changes

Change to wallet handling of mempool rejection

When a newly created transaction failed to enter the mempool due to the limits on chains of unconfirmed transactions the sending RPC calls would return an error. The transaction would still be queued in the wallet and, once some of the parent transactions were confirmed, broadcast after the software was restarted.

This behavior has been changed to return success and to reattempt mempool insertion at the same time transaction rebroadcast is attempted, avoiding a need for a restart.

Transactions in the wallet which cannot be accepted into the mempool can be abandoned with the previously existing abandontransaction RPC (or in the GUI via a context menu on the transaction).

bitcoin-0.13.2-aarch64-linux-gnu.tar.gz            03-Jan-2017 08:04             9505843
bitcoin-0.13.2-arm-linux-gnueabihf.tar.gz          03-Jan-2017 08:04             8842928
bitcoin-0.13.2-i686-pc-linux-gnu.tar.gz            03-Jan-2017 08:05            24320334
bitcoin-0.13.2-osx.dmg                             03-Jan-2017 08:05            13606103
bitcoin-0.13.2-osx64.tar.gz                        03-Jan-2017 08:05            18940662
bitcoin-0.13.2-win32-setup.exe                     03-Jan-2017 08:05            12590672
bitcoin-0.13.2-win32.zip                           03-Jan-2017 08:05            22480628
bitcoin-0.13.2-win64-setup.exe                     03-Jan-2017 08:06            13144152
bitcoin-0.13.2-win64.zip                           03-Jan-2017 08:06            23832542
bitcoin-0.13.2-x86_64-linux-gnu.tar.gz             03-Jan-2017 08:06            23916428
bitcoin-0.13.2.tar.gz                              03-Jan-2017 08:06             5303321
bitcoin-0.13.2.torrent                             03-Jan-2017 08:10               14605

Bitcoin Core v0.13.2

Bitcoin Core version 0.13.2 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.13.2/

This is a new minor version release, including 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, 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 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 version 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.

From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+, but severe issues with the libc++ version on 10.7.x keep it from running reliably. 0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.

Notable changes

Change to wallet handling of mempool rejection

When a newly created transaction failed to enter the mempool due to the limits on chains of unconfirmed transactions the sending RPC calls would return an error. The transaction would still be queued in the wallet and, once some of the parent transactions were confirmed, broadcast after the software was restarted.

This behavior has been changed to return success and to reattempt mempool insertion at the same time transaction rebroadcast is attempted, avoiding a need for a restart.

Transactions in the wallet which cannot be accepted into the mempool can be abandoned with the previously existing abandontransaction RPC (or in the GUI via a context menu on the transaction).

 

SHA256SUMS.asc                                     03-Jan-2017 08:04                1957
bitcoin-0.13.2-aarch64-linux-gnu.tar.gz            03-Jan-2017 08:04             9505843
bitcoin-0.13.2-arm-linux-gnueabihf.tar.gz          03-Jan-2017 08:04             8842928
bitcoin-0.13.2-i686-pc-linux-gnu.tar.gz            03-Jan-2017 08:05            24320334
bitcoin-0.13.2-osx.dmg                             03-Jan-2017 08:05            13606103
bitcoin-0.13.2-osx64.tar.gz                        03-Jan-2017 08:05            18940662
bitcoin-0.13.2-win32-setup.exe                     03-Jan-2017 08:05            12590672
bitcoin-0.13.2-win32.zip                           03-Jan-2017 08:05            22480628
bitcoin-0.13.2-win64-setup.exe                     03-Jan-2017 08:06            13144152
bitcoin-0.13.2-win64.zip                           03-Jan-2017 08:06            23832542
bitcoin-0.13.2-x86_64-linux-gnu.tar.gz             03-Jan-2017 08:06            23916428
bitcoin-0.13.2.tar.gz                              03-Jan-2017 08:06             5303321
bitcoin-0.13.2.torrent                             03-Jan-2017 08:10               14605

Bitcoin Core v0.13.1

Bitcoin Core version 0.13.1 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.13.1/

This is a new minor version release, including activation parameters for the segwit softfork, 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, 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 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 version 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.

From 0.13.1 onwards OS X 10.7 is no longer supported. 0.13.0 was intended to work on 10.7+, but severe issues with the libc++ version on 10.7.x keep it from running reliably. 0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.

Notable changes

Segregated witness soft fork

Segregated witness (segwit) is a soft fork that, if activated, will allow transaction-producing software to separate (segregate) transaction signatures (witnesses) from the part of the data in a transaction that is covered by the txid. This provides several immediate benefits:

  • Elimination of unwanted transaction malleability: Segregating the witness allows both existing and upgraded software to calculate the transaction identifier (txid) of transactions without referencing the witness, which can sometimes be changed by third-parties (such as miners) or by co-signers in a multisig spend. This solves all known cases of unwanted transaction malleability, which is a problem that makes programming Bitcoin wallet software more difficult and which seriously complicates the design of smart contracts for Bitcoin.
  • Capacity increase: Segwit transactions contain new fields that are not part of the data currently used to calculate the size of a block, which allows a block containing segwit transactions to hold more data than allowed by the current maximum block size. Estimates based on the transactions currently found in blocks indicate that if all wallets switch to using segwit, the network will be able to support about 70% more transactions. The network will also be able to support more of the advanced-style payments (such as multisig) than it can support now because of the different weighting given to different parts of a transaction after segwit activates (see the following section for details).
  • Weighting data based on how it affects node performance: Some parts of each Bitcoin block need to be stored by nodes in order to validate future blocks; other parts of a block can be immediately forgotten (pruned) or used only for helping other nodes sync their copy of the block chain. One large part of the immediately prunable data are transaction signatures (witnesses), and segwit makes it possible to give a different “weight” to segregated witnesses to correspond with the lower demands they place on node resources. Specifically, each byte of a segregated witness is given a weight of 1, each other byte in a block is given a weight of 4, and the maximum allowed weight of a block is 4 million. Weighting the data this way better aligns the most profitable strategy for creating blocks with the long-term costs of block validation.
  • Signature covers value: A simple improvement in the way signatures are generated in segwit simplifies the design of secure signature generators (such as hardware wallets), reduces the amount of data the signature generator needs to download, and allows the signature generator to operate more quickly. This is made possible by having the generator sign the amount of bitcoins they think they are spending, and by having full nodes refuse to accept those signatures unless the amount of bitcoins being spent is exactly the same as was signed. For non-segwit transactions, wallets instead had to download the complete previous transactions being spent for every payment they made, which could be a slow operation on hardware wallets and in other situations where bandwidth or computation speed was constrained.
  • Linear scaling of sighash operations: In 2015 a block was produced that required about 25 seconds to validate on modern hardware because of the way transaction signature hashes are performed. Other similar blocks, or blocks that could take even longer to validate, can still be produced today. The problem that caused this can’t be fixed in a soft fork without unwanted side-effects, but transactions that opt-in to using segwit will now use a different signature method that doesn’t suffer from this problem and doesn’t have any unwanted side-effects.
  • Increased security for multisig: Bitcoin addresses (both P2PKH addresses that start with a ‘1’ and P2SH addresses that start with a ‘3’) use a hash function known as RIPEMD-160. For P2PKH addresses, this provides about 160 bits of security—which is beyond what cryptographers believe can be broken today. But because P2SH is more flexible, only about 80 bits of security is provided per address. Although 80 bits is very strong security, it is within the realm of possibility that it can be broken by a powerful adversary. Segwit allows advanced transactions to use the SHA256 hash function instead, which provides about 128 bits of security (that is 281 trillion times as much security as 80 bits and is equivalent to the maximum bits of security believed to be provided by Bitcoin’s choice of parameters for its Elliptic Curve Digital Security Algorithm [ECDSA].)
  • More efficient almost-full-node security Satoshi Nakamoto’s original Bitcoin paper describes a method for allowing newly-started full nodes to skip downloading and validating some data from historic blocks that are protected by large amounts of proof of work. Unfortunately, Nakamoto’s method can’t guarantee that a newly-started node using this method will produce an accurate copy of Bitcoin’s current ledger (called the UTXO set), making the node vulnerable to falling out of consensus with other nodes. Although the problems with Nakamoto’s method can’t be fixed in a soft fork, Segwit accomplishes something similar to his original proposal: it makes it possible for a node to optionally skip downloading some blockchain data (specifically, the segregated witnesses) while still ensuring that the node can build an accurate copy of the UTXO set for the block chain with the most proof of work. Segwit enables this capability at the consensus layer, but note that Bitcoin Core does not provide an option to use this capability as of this 0.13.1 release.
  • Script versioning: Segwit makes it easy for future soft forks to allow Bitcoin users to individually opt-in to almost any change in the Bitcoin Script language when those users receive new transactions. Features currently being researched by Bitcoin Core contributors that may use this capability include support for Schnorr signatures, which can improve the privacy and efficiency of multisig transactions (or transactions with multiple inputs), and Merklized Abstract Syntax Trees (MAST), which can improve the privacy and efficiency of scripts with two or more conditions. Other Bitcoin community members are studying several other improvements that can be made using script versioning.

Activation for the segwit soft fork is being managed using BIP9 versionbits. Segwit’s version bit is bit 1, and nodes will begin tracking which blocks signal support for segwit at the beginning of the first retarget period after segwit’s start date of 15 November 2016. If 95% of blocks within a 2,016-block retarget period (about two weeks) signal support for segwit, the soft fork will be locked in. After another 2,016 blocks, segwit will activate.

For more information about segwit, please see the segwit FAQ, the segwit wallet developers guide or BIPs 141, 143, 144, and 145. If you’re a miner or mining pool operator, please see the versionbits FAQ for information about signaling support for a soft fork.

Null dummy soft fork

Combined with the segwit soft fork is an additional change that turns a long-existing network relay policy into a consensus rule. The OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY opcodes consume an extra stack element (“dummy element”) after signature validation. The dummy element is not inspected in any manner, and could be replaced by any value without invalidating the script.

Because any value can be used for this dummy element, it’s possible for a third-party to insert data into other people’s transactions, changing the transaction’s txid (called transaction malleability) and possibly causing other problems.

Since Bitcoin Core 0.10.0, nodes have defaulted to only relaying and mining transactions whose dummy element was a null value (0x00, also called OP_0). The null dummy soft fork turns this relay rule into a consensus rule both for non-segwit transactions and segwit transactions, so that this method of mutating transactions is permanently eliminated from the network.

Signaling for the null dummy soft fork is done by signaling support for segwit, and the null dummy soft fork will activate at the same time as segwit.

For more information, please see BIP147.

Low-level RPC changes

  • importprunedfunds only accepts two required arguments. Some versions accept an optional third arg, which was always ignored. Make sure to never pass more than two arguments.

Linux ARM builds

With the 0.13.0 release, pre-built Linux ARM binaries were added to the set of uploaded executables. Additional detail on the ARM architecture targeted by each is provided below.

The following extra files can be found in the download directory or torrent:

  • bitcoin-${VERSION}-arm-linux-gnueabihf.tar.gz: Linux binaries targeting the 32-bit ARMv7-A architecture.
  • bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz: Linux binaries targeting the 64-bit ARMv8-A 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 the device you use must be (backward) compatible with the architecture targeted by the binary that you use. For example, a Raspberry Pi 2 Model B or Raspberry Pi 3 Model B (in its 32-bit execution state) device, can run the 32-bit ARMv7-A targeted binary. However, no model of Raspberry Pi 1 device can run either binary because they are all ARMv6 architecture devices that are not compatible with ARMv7-A or ARMv8-A.

Note that Android is not considered ARM Linux in this context. The executables are not expected to work out of the box on Android.

 

SHA256SUMS.asc                                     27-Oct-2016 18:09                1957
bitcoin-0.13.1-aarch64-linux-gnu.tar.gz            27-Oct-2016 18:10             9502407
bitcoin-0.13.1-arm-linux-gnueabihf.tar.gz          27-Oct-2016 18:09             8838849
bitcoin-0.13.1-i686-pc-linux-gnu.tar.gz            27-Oct-2016 18:08            24174972
bitcoin-0.13.1-osx.dmg                             27-Oct-2016 18:10            13459408
bitcoin-0.13.1-osx64.tar.gz                        27-Oct-2016 18:10            18783541
bitcoin-0.13.1-win32-setup.exe                     27-Oct-2016 18:08            12505872
bitcoin-0.13.1-win32.zip                           27-Oct-2016 18:09            22337165
bitcoin-0.13.1-win64-setup.exe                     27-Oct-2016 18:10            13062072
bitcoin-0.13.1-win64.zip                           27-Oct-2016 18:08            23680245
bitcoin-0.13.1-x86_64-linux-gnu.tar.gz             27-Oct-2016 18:09            23768981
bitcoin-0.13.1.tar.gz                              27-Oct-2016 18:10             5187256
bitcoin-0.13.1.torrent                             27-Oct-2016 18:12               14505

Bitcoin Core v0.13.0

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, 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 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 targeting the 32-bit ARMv7-A architecture.
  • bitcoin-${VERSION}-aarch64-linux-gnu.tar.gz: Linux binaries targeting the 64-bit ARMv8-A 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 the device you use must be (backward) compatible with the architecture targeted by the binary that you use. For example, a Raspberry Pi 2 Model B or Raspberry Pi 3 Model B (in its 32-bit execution state) device, can run the 32-bit ARMv7-A targeted binary. However, no model of Raspberry Pi 1 device can run either binary because they are all ARMv6 architecture devices that are not compatible with ARMv7-A or ARMv8-A.

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

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, BIP 32

Segregated Witness

The code preparations for Segregated Witness (“segwit”), as described in BIP 141, BIP 143, BIP 144, and BIP 145 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).

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 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
  • 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
    • OP_NOP3 has been renamed to OP_CHECKSEQUENCEVERIFY by BIP 112
    • 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.
SHA256SUMS.asc                                     23-Aug-2016 14:09                1957
bitcoin-0.13.0-aarch64-linux-gnu.tar.gz            23-Aug-2016 14:11             9473252
bitcoin-0.13.0-arm-linux-gnueabihf.tar.gz          23-Aug-2016 14:10             8809096
bitcoin-0.13.0-i686-pc-linux-gnu.tar.gz            23-Aug-2016 14:09            24055918
bitcoin-0.13.0-osx.dmg                             23-Aug-2016 14:11            13363815
bitcoin-0.13.0-osx64.tar.gz                        23-Aug-2016 14:11            18647267
bitcoin-0.13.0-win32-setup.exe                     23-Aug-2016 14:12            12417552
bitcoin-0.13.0-win32.zip                           23-Aug-2016 14:10            22216695
bitcoin-0.13.0-win64-setup.exe                     23-Aug-2016 14:11            12958984
bitcoin-0.13.0-win64.zip                           23-Aug-2016 14:10            23560362
bitcoin-0.13.0-x86_64-linux-gnu.tar.gz             23-Aug-2016 14:10            23652105
bitcoin-0.13.0.tar.gz                              23-Aug-2016 14:11             5073643
bitcoin-0.13.0.torrent                             23-Aug-2016 14:27               14425

Bitcoin Core v0.12.1

Bitcoin Core version 0.12.1 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.12.1/

This is a new minor version release, including the BIP9, BIP68 and BIP112 softfork, various bugfixes and updated translations.

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

Downgrade to a version < 0.12.0

Because release 0.12.0 and later will obfuscate the chainstate on every fresh sync or reindex, the chainstate is not backwards-compatible with pre-0.12 versions of Bitcoin Core or other software.

If you want to downgrade after you have done a reindex with 0.12.0 or later, you will need to reindex when you first start Bitcoin Core version 0.11 or earlier.

Notable changes

First version bits BIP9 softfork deployment

This release includes a soft fork deployment to enforce BIP68, BIP112 and BIP113 using the BIP9 deployment mechanism.

The deployment sets the block version number to 0x20000001 between midnight 1st May 2016 and midnight 1st May 2017 to signal readiness for deployment. The version number consists of 0x20000000 to indicate version bits together with setting bit 0 to indicate support for this combined deployment, shown as “csv” in the getblockchaininfo RPC call.

For more information about the soft forking change, please see https://github.com/bitcoin/bitcoin/pull/7648

This specific backport pull-request can be viewed at https://github.com/bitcoin/bitcoin/pull/7543

BIP68 soft fork to enforce sequence locks for relative locktime

BIP68 introduces relative lock-time consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint.

For more information about the implementation, see https://github.com/bitcoin/bitcoin/pull/7184

BIP112 soft fork to enforce OP_CHECKSEQUENCEVERIFY

BIP112 redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV) for a new opcode in the Bitcoin scripting system that in combination with BIP68 allows execution pathways of a script to be restricted based on the age of the output being spent.

For more information about the implementation, see https://github.com/bitcoin/bitcoin/pull/7524

BIP113 locktime enforcement soft fork

Bitcoin Core 0.11.2 previously introduced mempool-only locktime enforcement using GetMedianTimePast(). This release seeks to consensus enforce the rule.

Bitcoin transactions currently may specify a locktime indicating when they may be added to a valid block. Current consensus rules require that blocks have a block header time greater than the locktime specified in any transaction in that block.

Miners get to choose what time they use for their header time, with the consensus rule being that no node will accept a block whose time is more than two hours in the future. This creates a incentive for miners to set their header times to future values in order to include locktimed transactions which weren’t supposed to be included for up to two more hours.

The consensus rules also specify that valid blocks may have a header time greater than that of the median of the 11 previous blocks. This GetMedianTimePast() time has a key feature we generally associate with time: it can’t go backwards.

BIP113 specifies a soft fork enforced in this release that weakens this perverse incentive for individual miners to use a future time by requiring that valid blocks have a computed GetMedianTimePast() greater than the locktime specified in any transaction in that block.

Mempool inclusion rules currently require transactions to be valid for immediate inclusion in a block in order to be accepted into the mempool. This release begins applying the BIP113 rule to received transactions, so transaction whose time is greater than the GetMedianTimePast() will no longer be accepted into the mempool.

Implication for miners: you will begin rejecting transactions that would not be valid under BIP113, which will prevent you from producing invalid blocks when BIP113 is enforced on the network. Any transactions which are valid under the current rules but not yet valid under the BIP113 rules will either be mined by other miners or delayed until they are valid under BIP113. Note, however, that time-based locktime transactions are more or less unseen on the network currently.

Implication for users: GetMedianTimePast() always trails behind the current time, so a transaction locktime set to the present time will be rejected by nodes running this release until the median time moves forward. To compensate, subtract one hour (3,600 seconds) from your locktimes to allow those transactions to be included in mempools at approximately the expected time.

For more information about the implementation, see https://github.com/bitcoin/bitcoin/pull/6566

Miscellaneous

The p2p alert system is off by default. To turn on, use -alert with startup configuration.

 

SHA256SUMS.asc                                     15-Apr-2016 06:28                1724
bitcoin-0.12.1-linux32.tar.gz                      15-Apr-2016 06:28            24361212
bitcoin-0.12.1-linux64.tar.gz                      15-Apr-2016 06:27            23986357
bitcoin-0.12.1-osx.dmg                             15-Apr-2016 06:29            13412304
bitcoin-0.12.1-osx64.tar.gz                        15-Apr-2016 06:29            18747598
bitcoin-0.12.1-win32-setup.exe                     15-Apr-2016 06:28            13115664
bitcoin-0.12.1-win32.zip                           15-Apr-2016 06:28            23692903
bitcoin-0.12.1-win64-setup.exe                     15-Apr-2016 06:29            13613832
bitcoin-0.12.1-win64.zip                           15-Apr-2016 06:27            24983914
bitcoin-0.12.1.tar.gz                              15-Apr-2016 06:28             5445416
bitcoin-0.12.1.torrent                             15-Apr-2016 06:53               13286

Bitcoin Core v0.12.0

Bitcoin Core version 0.12.0 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.12.0/

This is a new major version release, bringing new features and other improvements.

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

Downgrade to a version < 0.10.0

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.

Downgrade to a version < 0.12.0

Because release 0.12.0 and later will obfuscate the chainstate on every fresh sync or reindex, the chainstate is not backwards-compatible with pre-0.12 versions of Bitcoin Core or other software.

If you want to downgrade after you have done a reindex with 0.12.0 or later, you will need to reindex when you first start Bitcoin Core version 0.11 or earlier.

Notable changes

Signature validation using libsecp256k1

ECDSA signatures inside Bitcoin transactions now use validation using libsecp256k1 instead of OpenSSL.

Depending on the platform, this means a significant speedup for raw signature validation speed. The advantage is largest on x86_64, where validation is over five times faster. In practice, this translates to a raw reindexing and new block validation times that are less than half of what it was before.

Libsecp256k1 has undergone very extensive testing and validation.

A side effect of this change is that libconsensus no longer depends on OpenSSL.

Reduce upload traffic

A major part of the outbound traffic is caused by serving historic blocks to other nodes in initial block download state.

It is now possible to reduce the total upload traffic via the -maxuploadtarget parameter. This is not a hard limit but a threshold to minimize the outbound traffic. When the limit is about to be reached, the uploaded data is cut by not serving historic blocks (blocks older than one week). Moreover, any SPV peer is disconnected when they request a filtered block.

This option can be specified in MiB per day and is turned off by default (-maxuploadtarget=0). The recommended minimum is 144 * MAX_BLOCK_SIZE (currently 144MB) per day.

Whitelisted peers will never be disconnected, although their traffic counts for calculating the target.

A more detailed documentation about keeping traffic low can be found in /doc/reduce-traffic.md.

Direct headers announcement (BIP 130)

Between compatible peers, BIP 130 direct headers announcement is used. This means that blocks are advertised by announcing their headers directly, instead of just announcing the hash. In a reorganization, all new headers are sent, instead of just the new tip. This can often prevent an extra roundtrip before the actual block is downloaded.

Memory pool limiting

Previous versions of Bitcoin Core had their mempool limited by checking a transaction’s fees against the node’s minimum relay fee. There was no upper bound on the size of the mempool and attackers could send a large number of transactions paying just slighly more than the default minimum relay fee to crash nodes with relatively low RAM. A temporary workaround for previous versions of Bitcoin Core was to raise the default minimum relay fee.

Bitcoin Core 0.12 will have a strict maximum size on the mempool. The default value is 300 MB and can be configured with the -maxmempool parameter. Whenever a transaction would cause the mempool to exceed its maximum size, the transaction that (along with in-mempool descendants) has the lowest total feerate (as a package) will be evicted and the node’s effective minimum relay feerate will be increased to match this feerate plus the initial minimum relay feerate. The initial minimum relay feerate is set to 1000 satoshis per kB.

Bitcoin Core 0.12 also introduces new default policy limits on the length and size of unconfirmed transaction chains that are allowed in the mempool (generally limiting the length of unconfirmed chains to 25 transactions, with a total size of 101 KB). These limits can be overriden using command line arguments; see the extended help (--help -help-debug) for more information.

Opt-in Replace-by-fee transactions

It is now possible to replace transactions in the transaction memory pool of Bitcoin Core 0.12 nodes. Bitcoin Core will only allow replacement of transactions which have any of their inputs’ nSequence number set to less than 0xffffffff - 1. Moreover, a replacement transaction may only be accepted when it pays sufficient fee, as described in BIP 125.

Transaction replacement can be disabled with a new command line option, -mempoolreplacement=0. Transactions signaling replacement under BIP125 will still be allowed into the mempool in this configuration, but replacements will be rejected. This option is intended for miners who want to continue the transaction selection behavior of previous releases.

The -mempoolreplacement option is not recommended for wallet users seeking to avoid receipt of unconfirmed opt-in transactions, because this option does not prevent transactions which are replaceable under BIP 125 from being accepted (only subsequent replacements, which other nodes on the network that implement BIP 125 are likely to relay and mine). Wallet users wishing to detect whether a transaction is subject to replacement under BIP 125 should instead use the updated RPC calls gettransaction and listtransactions, which now have an additional field in the output indicating if a transaction is replaceable under BIP125 (“bip125-replaceable”).

Note that the wallet in Bitcoin Core 0.12 does not yet have support for creating transactions that would be replaceable under BIP 125.

RPC: Random-cookie RPC authentication

When no -rpcpassword is specified, the daemon now uses a special ‘cookie’ file for authentication. This file is generated with random content when the daemon starts, and deleted when it exits. Its contents are used as authentication token. Read access to this file controls who can access through RPC. By default it is stored in the data directory but its location can be overridden with the option -rpccookiefile.

This is similar to Tor’s CookieAuthentication: see https://www.torproject.org/docs/tor-manual.html.en

This allows running bitcoind without having to do any manual configuration.

Relay: Any sequence of pushdatas in OP_RETURN outputs now allowed

Previously OP_RETURN outputs with a payload were only relayed and mined if they had a single pushdata. This restriction has been lifted to allow any combination of data pushes and numeric constant opcodes (OP_1 to OP_16) after the OP_RETURN. The limit on OP_RETURN output size is now applied to the entire serialized scriptPubKey, 83 bytes by default. (the previous 80 byte default plus three bytes overhead)

Relay: New and only new blocks relayed when pruning

When running in pruned mode, the client will now relay new blocks. When responding to the getblocks message, only hashes of blocks that are on disk and are likely to remain there for some reasonable time window (1 hour) will be returned (previously all relevant hashes were returned).

Relay and Mining: Priority transactions

Bitcoin Core has a heuristic ‘priority’ based on coin value and age. This calculation is used for relaying of transactions which do not pay the minimum relay fee, and can be used as an alternative way of sorting transactions for mined blocks. Bitcoin Core will relay transactions with insufficient fees depending on the setting of -limitfreerelay=<r> (default: r=15 kB per minute) and -blockprioritysize=<s>.

In Bitcoin Core 0.12, when mempool limit has been reached a higher minimum relay fee takes effect to limit memory usage. Transactions which do not meet this higher effective minimum relay fee will not be relayed or mined even if they rank highly according to the priority heuristic.

The mining of transactions based on their priority is also now disabled by default. To re-enable it, simply set -blockprioritysize=<n> where is the size in bytes of your blocks to reserve for these transactions. The old default was 50k, so to retain approximately the same policy, you would set -blockprioritysize=50000.

Additionally, as a result of computational simplifications, the priority value used for transactions received with unconfirmed inputs is lower than in prior versions due to avoiding recomputing the amounts as input transactions confirm.

External miner policy set via the prioritisetransaction RPC to rank transactions already in the mempool continues to work as it has previously. Note, however, that if mining priority transactions is left disabled, the priority delta will be ignored and only the fee metric will be effective.

This internal automatic prioritization handling is being considered for removal entirely in Bitcoin Core 0.13, and it is at this time undecided whether the more accurate priority calculation for chained unconfirmed transactions will be restored. Community direction on this topic is particularly requested to help set project priorities.

Automatically use Tor hidden services

Starting with Tor version 0.2.7.1 it is possible, through Tor’s control socket API, to create and destroy ‘ephemeral’ hidden services programmatically. Bitcoin Core has been updated to make use of this.

This means that if Tor is running (and proper authorization is available), Bitcoin Core automatically creates a hidden service to listen on, without manual configuration. Bitcoin Core will also use Tor automatically to connect to other .onion nodes if the control socket can be successfully opened. This will positively affect the number of available .onion nodes and their usage.

This new feature is enabled by default if Bitcoin Core is listening, and a connection to Tor can be made. It can be configured with the -listenonion, -torcontrol and -torpassword settings. To show verbose debugging information, pass -debug=tor.

Notifications through ZMQ

Bitcoind can now (optionally) asynchronously notify clients through a ZMQ-based PUB socket of the arrival of new transactions and blocks. This feature requires installation of the ZMQ C API library 4.x and configuring its use through the command line or configuration file. Please see docs/zmq.md for details of operation.

Wallet: Transaction fees

Various improvements have been made to how the wallet calculates transaction fees.

Users can decide to pay a predefined fee rate by setting -paytxfee=<n> (or settxfee <n> rpc during runtime). A value of n=0 signals Bitcoin Core to use floating fees. By default, Bitcoin Core will use floating fees.

Based on past transaction data, floating fees approximate the fees required to get into the mth block from now. This is configurable with -txconfirmtarget=<m> (default: 2).

Sometimes, it is not possible to give good estimates, or an estimate at all. Therefore, a fallback value can be set with -fallbackfee=<f> (default: 0.0002 BTC/kB).

At all times, Bitcoin Core will cap fees at -maxtxfee=<x> (default: 0.10) BTC. Furthermore, Bitcoin Core will never create transactions paying less than the current minimum relay fee. Finally, a user can set the minimum fee rate for all transactions with -mintxfee=<i>, which defaults to 1000 satoshis per kB.

Wallet: Negative confirmations and conflict detection

The wallet will now report a negative number for confirmations that indicates how deep in the block chain the conflict is found. For example, if a transaction A has 5 confirmations and spends the same input as a wallet transaction B, B will be reported as having -5 confirmations. If another wallet transaction C spends an output from B, it will also be reported as having -5 confirmations. To detect conflicts with historical transactions in the chain a one-time -rescan may be needed.

Unlike earlier versions, unconfirmed but non-conflicting transactions will never get a negative confirmation count. They are not treated as spendable unless they’re coming from ourself (change) and accepted into our local mempool, however. The new “trusted” field in the listtransactions RPC output indicates whether outputs of an unconfirmed transaction are considered spendable.

Wallet: Merkle branches removed

Previously, every wallet transaction stored a Merkle branch to prove its presence in blocks. This wasn’t being used for more than an expensive sanity check. Since 0.12, these are no longer stored. When loading a 0.12 wallet into an older version, it will automatically rescan to avoid failed checks.

Wallet: Pruning

With 0.12 it is possible to use wallet functionality in pruned mode. This can reduce the disk usage from currently around 60 GB to around 2 GB.

However, rescans as well as the RPCs importwallet, importaddress, importprivkey are disabled.

To enable block pruning set prune=<N> on the command line or in bitcoin.conf, where N is the number of MiB to allot for raw block & undo data.

A value of 0 disables pruning. The minimal value above 0 is 550. Your wallet is as secure with high values as it is with low ones. Higher values merely ensure that your node will not shut down upon blockchain reorganizations of more than 2 days – which are unlikely to happen in practice. In future releases, a higher value may also help the network as a whole: stored blocks could be served to other nodes.

For further information about pruning, you may also consult the release notes of v0.11.0.

NODE_BLOOM service bit

Support for the NODE_BLOOM service bit, as described in BIP 111, has been added to the P2P protocol code.

BIP 111 defines a service bit to allow peers to advertise that they support bloom filters (such as used by SPV clients) explicitly. It also bumps the protocol version to allow peers to identify old nodes which allow bloom filtering of the connection despite lacking the new service bit.

In this version, it is only enforced for peers that send protocol versions >=70011. For the next major version it is planned that this restriction will be removed. It is recommended to update SPV clients to check for the NODE_BLOOM service bit for nodes that report versions newer than 70011.

Option parsing behavior

Command line options are now parsed strictly in the order in which they are specified. It used to be the case that -X -noXends up, unintuitively, with X set, as -X had precedence over -noX. This is no longer the case. Like for other software, the last specified value for an option will hold.

RPC: Low-level API changes

  • Monetary amounts can be provided as strings. This means that for example the argument to sendtoaddress can be “0.0001” instead of 0.0001. This can be an advantage if a JSON library insists on using a lossy floating point type for numbers, which would be dangerous for monetary amounts.
  • The asm property of each scriptSig now contains the decoded signature hash type for each signature that provides a valid defined hash type.
  • OP_NOP2 has been renamed to OP_CHECKLOCKTIMEVERIFY by BIP 65

The following items contain assembly representations of scriptSig signatures and are affected by this change:

  • RPC getrawtransaction
  • RPC decoderawtransaction
  • RPC decodescript
  • REST /rest/tx/ (JSON format)
  • REST /rest/block/ (JSON format when including extended tx details)
  • bitcoin-tx -json

For example, the scriptSig.asm property of a transaction input that previously showed an assembly representation of:

304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c509001 400000 OP_NOP2

now shows as:

304502207fa7a6d1e0ee81132a269ad84e68d695483745cde8b541e3bf630749894e342a022100c1f7ab20e13e22fb95281a870f3dcf38d782e53023ee313d741ad0cfbc0c5090[ALL] 400000 OP_CHECKLOCKTIMEVERIFY

Note that the output of the RPC decodescript did not change because it is configured specifically to process scriptPubKey and not scriptSig scripts.

RPC: SSL support dropped

SSL support for RPC, previously enabled by the option rpcssl has been dropped from both the client and the server. This was done in preparation for removing the dependency on OpenSSL for the daemon completely.

Trying to use rpcssl will result in an error:

Error: SSL mode for RPC (-rpcssl) is no longer supported.

If you are one of the few people that relies on this feature, a flexible migration path is to use stunnel. This is an utility that can tunnel arbitrary TCP connections inside SSL. On e.g. Ubuntu it can be installed with:

sudo apt-get install stunnel4

Then, to tunnel a SSL connection on 28332 to a RPC server bound on localhost on port 18332 do:

stunnel -d 28332 -r 127.0.0.1:18332 -p stunnel.pem -P ''

It can also be set up system-wide in inetd style.

Another way to re-attain SSL would be to setup a httpd reverse proxy. This solution would allow the use of different authentication, loadbalancing, on-the-fly compression and caching. A sample config for apache2 could look like:

Listen 443

NameVirtualHost *:443
<VirtualHost *:443>

SSLEngine On
SSLCertificateFile /etc/apache2/ssl/server.crt
SSLCertificateKeyFile /etc/apache2/ssl/server.key

<Location /bitcoinrpc>
    ProxyPass http://127.0.0.1:8332/
    ProxyPassReverse http://127.0.0.1:8332/
    # optional enable digest auth
    # AuthType Digest
    # ...

    # optional bypass bitcoind rpc basic auth
    # RequestHeader set Authorization "Basic <hash>"
    # get the <hash> from the shell with: base64 <<< bitcoinrpc:<password>
</Location>

# Or, balance the load:
# ProxyPass / balancer://balancer_cluster_name

</VirtualHost>

Mining Code Changes

The mining code in 0.12 has been optimized to be significantly faster and use less memory. As part of these changes, consensus critical calculations are cached on a transaction’s acceptance into the mempool and the mining code now relies on the consistency of the mempool to assemble blocks. However all blocks are still tested for validity after assembly.

Other P2P Changes

The list of banned peers is now stored on disk rather than in memory. Restarting bitcoind will no longer clear out the list of banned peers; instead a new RPC call (clearbanned) can be used to manually clear the list. The new setban RPC call can also be used to manually ban or unban a peer.

 

SHA256SUMS.asc                                     23-Feb-2016 10:27                1724
bitcoin-0.12.0-linux32.tar.gz                      23-Feb-2016 10:28            36511522
bitcoin-0.12.0-linux64.tar.gz                      23-Feb-2016 10:28            35974648
bitcoin-0.12.0-osx.dmg                             23-Feb-2016 10:29            13353418
bitcoin-0.12.0-osx64.tar.gz                        23-Feb-2016 10:29            26576551
bitcoin-0.12.0-win32-setup.exe                     23-Feb-2016 10:29            13070288
bitcoin-0.12.0-win32.zip                           23-Feb-2016 10:30            33537119
bitcoin-0.12.0-win64-setup.exe                     23-Feb-2016 10:30            13567200
bitcoin-0.12.0-win64.zip                           23-Feb-2016 10:30            35390688
bitcoin-0.12.0.tar.gz                              23-Feb-2016 10:31             5399067
bitcoin-0.12.0.torrent                             23-Feb-2016 10:42               17246

Bitcoin Core v0.11.2 Released

Bitcoin Core version 0.11.2 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.11.2/

This is a new minor version release, bringing bug fixes, the BIP65 (CLTV) consensus change, and relay policy preparation for BIP113. It is recommended to upgrade to this version as soon as possible.

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.

Notable changes since 0.11.1

BIP65 soft fork to enforce OP_CHECKLOCKTIMEVERIFY opcode

This release includes several changes related to the BIP65 soft fork which redefines the existing OP_NOP2 opcode as OP_CHECKLOCKTIMEVERIFY (CLTV) so that a transaction output can be made unspendable until a specified point in the future.

  1. This release will only relay and mine transactions spending a CLTV output if they comply with the BIP65 rules as provided in code.
  2. This release will produce version 4 blocks by default. Please see the notice to miners below.
  3. Once 951 out of a sequence of 1,001 blocks on the local node’s best block chain contain version 4 (or higher) blocks, this release will no longer accept new version 3 blocks and it will only accept version 4 blocks if they comply with the BIP65 rules for CLTV.

For more information about the soft-forking change, please see https://github.com/bitcoin/bitcoin/pull/6351

Graphs showing the progress towards block version 4 adoption may be found at the URLs below:

Notice to miners: Bitcoin Core’s block templates are now for version 4 blocks only, and any mining software relying on its getblocktemplate must be updated in parallel to use libblkmaker either version 0.4.3 or any version from 0.5.2 onward.

  • If you are solo mining, this will affect you the moment you upgrade Bitcoin Core, which must be done prior to BIP65 achieving its 951/1001 status.
  • If you are mining with the stratum mining protocol: this does not affect you.
  • If you are mining with the getblocktemplate protocol to a pool: this will affect you at the pool operator’s discretion, which must be no later than BIP65 achieving its 951/1001 status.

BIP113 mempool-only locktime enforcement using GetMedianTimePast()

Bitcoin transactions currently may specify a locktime indicating when they may be added to a valid block. Current consensus rules require that blocks have a block header time greater than the locktime specified in any transaction in that block.

Miners get to choose what time they use for their header time, with the consensus rule being that no node will accept a block whose time is more than two hours in the future. This creates a incentive for miners to set their header times to future values in order to include locktimed transactions which weren’t supposed to be included for up to two more hours.

The consensus rules also specify that valid blocks may have a header time greater than that of the median of the 11 previous blocks. This GetMedianTimePast() time has a key feature we generally associate with time: it can’t go backwards.

BIP113 specifies a soft fork (not enforced in this release) that weakens this perverse incentive for individual miners to use a future time by requiring that valid blocks have a computed GetMedianTimePast() greater than the locktime specified in any transaction in that block.

Mempool inclusion rules currently require transactions to be valid for immediate inclusion in a block in order to be accepted into the mempool. This release begins applying the BIP113 rule to received transactions, so transaction whose time is greater than the GetMedianTimePast() will no longer be accepted into the mempool.

Implication for miners: you will begin rejecting transactions that would not be valid under BIP113, which will prevent you from producing invalid blocks if/when BIP113 is enforced on the network. Any transactions which are valid under the current rules but not yet valid under the BIP113 rules will either be mined by other miners or delayed until they are valid under BIP113. Note, however, that time-based locktime transactions are more or less unseen on the network currently.

Implication for users: GetMedianTimePast() always trails behind the current time, so a transaction locktime set to the present time will be rejected by nodes running this release until the median time moves forward. To compensate, subtract one hour (3,600 seconds) from your locktimes to allow those transactions to be included in mempools at approximately the expected time.

Windows bug fix for corrupted UTXO database on unclean shutdowns

Several Windows users reported that they often need to reindex the entire blockchain after an unclean shutdown of Bitcoin Core on Windows (or an unclean shutdown of Windows itself). Although unclean shutdowns remain unsafe, this release no longer relies on memory-mapped files for the UTXO database, which significantly reduced the frequency of unclean shutdowns leading to required reindexes during testing.

For more information, see: https://github.com/bitcoin/bitcoin/pull/6917

Other fixes for database corruption on Windows are expected in the next major release.

0.11.2 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.

  • #6124 684636b Make CScriptNum() take nMaxNumSize as an argument
  • #6124 4fa7a04 Replace NOP2 with CHECKLOCKTIMEVERIFY (BIP65)
  • #6124 6ea5ca4 Enable CHECKLOCKTIMEVERIFY as a standard script verify flag
  • #6351 5e82e1c Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic
  • #6353 ba1da90 Show softfork status in getblockchaininfo
  • #6351 6af25b0 Add BIP65 to getblockchaininfo softforks list
  • #6688 01878c9 Fix locking in GetTransaction
  • #6653 b3eaa30 [Qt] Raise debug window when requested
  • #6600 1e672ae Debian/Ubuntu: Include bitcoin-tx binary
  • #6600 2394f4d Debian/Ubuntu: Split bitcoin-tx into its own package
  • #5987 33d6825 Bugfix: Allow mining on top of old tip blocks for testnet
  • #6852 21e58b8 build: make sure OpenSSL heeds noexecstack
  • #6846 af6edac alias -h for --help
  • #6867 95a5039 Set TCP_NODELAY on P2P sockets.
  • #6856 dfe55bd Do not allow blockfile pruning during reindex.
  • #6566 a1d3c6f Add rules–presently disabled–for using GetMedianTimePast as end point for lock-time calculations
  • #6566 f720c5f Enable policy enforcing GetMedianTimePast as the end point of lock-time constraints
  • #6917 0af5b8e leveldb: Win32WritableFile without memory mapping
  • #6948 4e895b0 Always flush block and undo when switching to new file
SHA256SUMS.asc                                     13-Nov-2015 11:50                1724
bitcoin-0.11.2-linux32.tar.gz                      13-Nov-2015 11:51            35337433
bitcoin-0.11.2-linux64.tar.gz                      13-Nov-2015 11:50            34886816
bitcoin-0.11.2-osx.dmg                             13-Nov-2015 11:49            12903697
bitcoin-0.11.2-osx64.tar.gz                        13-Nov-2015 11:50            26325321
bitcoin-0.11.2-win32-setup.exe                     13-Nov-2015 11:51            12590000
bitcoin-0.11.2-win32.zip                           13-Nov-2015 11:48            32303759
bitcoin-0.11.2-win64-setup.exe                     13-Nov-2015 11:51            13011240
bitcoin-0.11.2-win64.zip                           13-Nov-2015 11:49            33863031
bitcoin-0.11.2.tar.gz                              13-Nov-2015 11:51             4758492
bitcoin-0.11.2.torrent                             13-Nov-2015 11:53               16673

Electrum Bitcoin Wallet 2.7.18 Released

# Release 2.7.18
* enforce https on exchange rate APIs
* use hardcoded list of exchanges
* move ‘Freeze’ menu to Coins (utxo) tab
* various bugfixes

Electrum – Lightweight Bitcoin client

Licence: MIT Licence
Author: Thomas Voegtlin
Language: Python
Homepage: https://electrum.org/

Build Status

Getting started

Electrum is a pure python application. However, if you want to use the Qt interface, then you need to install the Qt dependencies:

sudo apt-get install python-qt4

If you downloaded the official package (tar.gz), then you can run Electrum from its root directory, without installing it on your system; all the python dependencies are included in the ‘packages’ directory. To run Electrum from its root directory, just do:

./electrum

You can also install Electrum on your system, by running this command:

python setup.py install

This will download and install the Python dependencies used by Electrum, instead of using the ‘packages’ directory.

If you cloned the git repository, then you need to compile extra files before you can run Electrum. Read the next section, “Development Version”.

Development version

Check out the code from Github:

git clone git://github.com/spesmilo/electrum.git
cd electrum

Run install (this should install dependencies):

python setup.py install

Compile the icons file for Qt:

sudo apt-get install pyqt4-dev-tools
pyrcc4 icons.qrc -o gui/qt/icons_rc.py

Compile the protobuf description file:

sudo apt-get install protobuf-compiler
protoc --proto_path=lib/ --python_out=lib/ lib/paymentrequest.proto

Create translations (optional):

sudo apt-get install python-pycurl gettext
./contrib/make_locale

Creating Binaries

In order to create binaries, you must create the ‘packages’ directory:

./contrib/make_packages

This directory contains the python dependencies used by Electrum.

Mac OS X

# On MacPorts installs:
sudo python setup-release.py py2app

# On Homebrew installs:
ARCHFLAGS="-arch i386 -arch x86_64" sudo python setup-release.py py2app --includes sip

sudo hdiutil create -fs HFS+ -volname "Electrum" -srcfolder dist/Electrum.app dist/electrum-VERSION-macosx.dmg

Windows

See contrib/build-wine/README file.

Android

See gui/kivy/Readme.txt file.

Easy installation

Linux Install dependencies:
sudo apt-get install python-qt4 python-pip
Install Electrum:
sudo pip install https://download.electrum.org/2.7.18/Electrum-2.7.18.tar.gz
Windows
Note: The QR code scanner is not supported in Windows binaries
OSX
Note: The QR code scanner is not supported in OSX binaries
Android Google Play
APK (signature)