Inside Bitcoin
Opening the selected file…
Opening the selected file…
The code behind the network, with room to understand it.
Release published 2026-10-28 · Snapshot fetched 2026-11-01. Latest stable release at fetch time; development branches and Git history are excluded. Only the selected code window and visible folders load here.
1Bitcoin Core version 0.11.2 is now available from:3<https://bitcoin.org/bin/bitcoin-core-0.11.2/>5This is a new minor version release, bringing bug fixes, the BIP656(CLTV) consensus change, and relay policy preparation for BIP113. It is7recommended to upgrade to this version as soon as possible.9Please report bugs using the issue tracker at github:11<https://github.com/bitcoin/bitcoin/issues>13Upgrading and downgrading14=========================16How to Upgrade17--------------19If you are running an older version, shut it down. Wait until it has completely20shut down (which might take a few minutes for older versions), then run the21installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or22bitcoind/bitcoin-qt (on Linux).24Downgrade warning25------------------27Because release 0.10.0 and later makes use of headers-first synchronization and28parallel block download (see further), the block files and databases are not29backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:31* Blocks will be stored on disk out of order (in the order they are32received, really), which makes it incompatible with some tools or33other programs. Reindexing using earlier versions will also not work34anymore as a result of this.36* The block index database will now hold headers for which no block is37stored on disk, which earlier versions won't support.39If you want to be able to downgrade smoothly, make a backup of your entire data40directory. Without this your node will need start syncing (or importing from41bootstrap.dat) anew afterwards. It is possible that the data from a completely42synchronised 0.10 node may be usable in older versions as-is, but this is not43supported and may break as soon as the older version attempts to reindex.45This does not affect wallet forward or backward compatibility. There are no46known problems when downgrading from 0.11.x to 0.10.x.48Notable changes since 0.11.149============================51BIP65 soft fork to enforce OP_CHECKLOCKTIMEVERIFY opcode52--------------------------------------------------------54This release includes several changes related to the [BIP65][] soft fork55which redefines the existing OP_NOP2 opcode as OP_CHECKLOCKTIMEVERIFY56(CLTV) so that a transaction output can be made unspendable until a57specified point in the future.591. This release will only relay and mine transactions spending a CLTV60output if they comply with the BIP65 rules as provided in code.622. This release will produce version 4 blocks by default. Please see the63*notice to miners* below.653. Once 951 out of a sequence of 1,001 blocks on the local node's best block66chain contain version 4 (or higher) blocks, this release will no67longer accept new version 3 blocks and it will only accept version 468blocks if they comply with the BIP65 rules for CLTV.70For more information about the soft-forking change, please see71<https://github.com/bitcoin/bitcoin/pull/6351>73Graphs showing the progress towards block version 4 adoption may be74found at the URLs below:76- Block versions over the last 50,000 blocks as progress towards BIP6577consensus enforcement: <http://bitcoin.sipa.be/ver-50k.png>79- Block versions over the last 2,000 blocks showing the days to the80earliest possible BIP65 consensus-enforced block: <http://bitcoin.sipa.be/ver-2k.png>82**Notice to miners:** Bitcoin Core’s block templates are now for83version 4 blocks only, and any mining software relying on its84getblocktemplate must be updated in parallel to use libblkmaker either85version 0.4.3 or any version from 0.5.2 onward.87- If you are solo mining, this will affect you the moment you upgrade88Bitcoin Core, which must be done prior to BIP65 achieving its 951/100189status.91- If you are mining with the stratum mining protocol: this does not92affect you.94- If you are mining with the getblocktemplate protocol to a pool: this95will affect you at the pool operator’s discretion, which must be no96later than BIP65 achieving its 951/1001 status.98[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki100BIP113 mempool-only locktime enforcement using GetMedianTimePast()101----------------------------------------------------------------103Bitcoin transactions currently may specify a locktime indicating when104they may be added to a valid block. Current consensus rules require105that blocks have a block header time greater than the locktime specified106in any transaction in that block.108Miners get to choose what time they use for their header time, with the109consensus rule being that no node will accept a block whose time is more110than two hours in the future. This creates a incentive for miners to111set their header times to future values in order to include locktimed112transactions which weren't supposed to be included for up to two more113hours.115The consensus rules also specify that valid blocks may have a header116time greater than that of the median of the 11 previous blocks. This117GetMedianTimePast() time has a key feature we generally associate with118time: it can't go backwards.120[BIP113][] specifies a soft fork (**not enforced in this release**) that121weakens this perverse incentive for individual miners to use a future122time by requiring that valid blocks have a computed GetMedianTimePast()123greater than the locktime specified in any transaction in that block.125Mempool inclusion rules currently require transactions to be valid for126immediate inclusion in a block in order to be accepted into the mempool.127This release begins applying the BIP113 rule to received transactions,128so transaction whose time is greater than the GetMedianTimePast() will129no longer be accepted into the mempool.131**Implication for miners:** you will begin rejecting transactions that132would not be valid under BIP113, which will prevent you from producing133invalid blocks if/when BIP113 is enforced on the network. Any134transactions which are valid under the current rules but not yet valid135under the BIP113 rules will either be mined by other miners or delayed136until they are valid under BIP113. Note, however, that time-based137locktime transactions are more or less unseen on the network currently.139**Implication for users:** GetMedianTimePast() always trails behind the140current time, so a transaction locktime set to the present time will be141rejected by nodes running this release until the median time moves142forward. To compensate, subtract one hour (3,600 seconds) from your143locktimes to allow those transactions to be included in mempools at144approximately the expected time.146[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki148Windows bug fix for corrupted UTXO database on unclean shutdowns149----------------------------------------------------------------151Several Windows users reported that they often need to reindex the152entire blockchain after an unclean shutdown of Bitcoin Core on Windows153(or an unclean shutdown of Windows itself). Although unclean shutdowns154remain unsafe, this release no longer relies on memory-mapped files for155the UTXO database, which significantly reduced the frequency of unclean156shutdowns leading to required reindexes during testing.158For more information, see: <https://github.com/bitcoin/bitcoin/pull/6917>160Other fixes for database corruption on Windows are expected in the161next major release.1630.11.2 Change log164=================166Detailed release notes follow. This overview includes changes that affect167behavior, not code moves, refactors and string updates. For convenience in locating168the code changes and accompanying discussion, both the pull request and169git merge commit are mentioned.171- #6124 `684636b` Make CScriptNum() take nMaxNumSize as an argument172- #6124 `4fa7a04` Replace NOP2 with CHECKLOCKTIMEVERIFY (BIP65)173- #6124 `6ea5ca4` Enable CHECKLOCKTIMEVERIFY as a standard script verify flag174- #6351 `5e82e1c` Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic175- #6353 `ba1da90` Show softfork status in getblockchaininfo176- #6351 `6af25b0` Add BIP65 to getblockchaininfo softforks list177- #6688 `01878c9` Fix locking in GetTransaction178- #6653 `b3eaa30` [Qt] Raise debug window when requested179- #6600 `1e672ae` Debian/Ubuntu: Include bitcoin-tx binary180- #6600 `2394f4d` Debian/Ubuntu: Split bitcoin-tx into its own package181- #5987 `33d6825` Bugfix: Allow mining on top of old tip blocks for testnet182- #6852 `21e58b8` build: make sure OpenSSL heeds noexecstack183- #6846 `af6edac` alias `-h` for `--help`184- #6867 `95a5039` Set TCP_NODELAY on P2P sockets.185- #6856 `dfe55bd` Do not allow blockfile pruning during reindex.186- #6566 `a1d3c6f` Add rules--presently disabled--for using GetMedianTimePast as end point for lock-time calculations187- #6566 `f720c5f` Enable policy enforcing GetMedianTimePast as the end point of lock-time constraints188- #6917 `0af5b8e` leveldb: Win32WritableFile without memory mapping189- #6948 `4e895b0` Always flush block and undo when switching to new file191Credits192=======194Thanks to everyone who directly contributed to this release:196- Alex Morcos197- ฿tcDrak198- Chris Kleeschulte199- Daniel Cousens200- Diego Viola201- Eric Lombrozo202- Esteban Ordano203- Gregory Maxwell204- Luke Dashjr205- Marco Falke206- Mark Friedenbach207- Matt Corallo208- Micha209- Mitchell Cash210- Peter Todd211- Pieter Wuille212- Wladimir J. van der Laan213- Zak Wilcox215And those who contributed additional code review and/or security research.217As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).
Independent explanations by MyBitcoinExplorer. Not affiliated with or endorsed by Bitcoin Core. Guides are educational and do not replace the source or its tests.
Bitcoin Core source © its contributors, distributed under the MIT license. Original notices and bundled third-party licenses are retained in the source tree.