Bitcoin Core
The reference implementation of the Bitcoin protocol, maintained by hundreds of contributors and running on the majority of full nodes.
Key Takeaways
- Bitcoin Core is the reference implementation of the Bitcoin protocol: originally released by Satoshi Nakamoto in 2009, it is now maintained by hundreds of open-source contributors and runs on roughly 75-80% of all full nodes.
- It does not "control" Bitcoin: anyone can fork the code or run alternative implementations, and consensus changes like soft forks require broad agreement from node operators, miners, and users before activation.
- The software provides full block validation, a built-in wallet, an RPC interface, configurable mempool policies, and peer-to-peer networking: everything needed to participate in the Bitcoin network independently.
What Is Bitcoin Core?
Bitcoin Core is the open-source software that defines the Bitcoin protocol in code. When someone asks "what are Bitcoin's rules?" the answer lives in Bitcoin Core's codebase. It validates every block and transaction against consensus rules, maintains a copy of the entire blockchain, relays transactions to peers, and includes a wallet for sending and receiving bitcoin.
Satoshi Nakamoto published the first version (v0.1) on January 9, 2009, under the simple name "Bitcoin." As the ecosystem grew and alternative implementations appeared, the software was renamed to "Bitcoin Core" in version 0.9.0 (March 2014) to distinguish the specific software from the network itself. The project is written in C++, licensed under the MIT license, and hosted on GitHub with over 1,200 all-time contributors.
While other implementations exist (Bitcoin Knots, btcd, Libbitcoin), Bitcoin Core remains the dominant client. Its codebase is the reference that other implementations follow. Changes to Bitcoin's consensus rules typically originate as Bitcoin Improvement Proposals (BIPs) and are first implemented in Bitcoin Core before propagating to the wider ecosystem.
How It Works
When you run Bitcoin Core, the software connects to the peer-to-peer network and begins downloading and validating the entire blockchain from the genesis block forward. This process, called initial block download (IBD), verifies every transaction in Bitcoin's history independently, trusting no external party.
Block Validation
For every block received from peers, Bitcoin Core checks that the proof-of-work meets the current difficulty target, that the block header references the correct previous block, that no transaction spends a UTXO that doesn't exist or has already been spent, that the coinbase transaction doesn't exceed the allowed block subsidy plus fees, and that all scripts evaluate correctly. If any check fails, the entire block is rejected regardless of how much hash power produced it.
Mempool Management
Bitcoin Core maintains a mempool: a pool of unconfirmed transactions waiting to be included in a block. The software applies relay policies to filter transactions before accepting them into the mempool. These policies include minimum fee rates, standardness rules, and size limits.
As of version 31.0 (April 2026), Bitcoin Core uses a cluster mempool architecture that organizes transactions into groups of related transactions (clusters of up to 64 transactions or 101 kB). This redesign improves fee estimation and makes replace-by-fee (RBF) more predictable. Bitcoin Core also supports full RBF, allowing any unconfirmed transaction to be replaced by a higher-fee version.
RPC Interface
Bitcoin Core exposes a JSON-RPC interface that lets applications interact with the node programmatically. Developers can query blockchain data, manage wallets, broadcast transactions, and monitor network state through hundreds of commands:
# Query blockchain info
bitcoin-cli getblockchaininfo
# Get mempool statistics
bitcoin-cli getmempoolinfo
# Create and send a transaction
bitcoin-cli sendtoaddress "bc1q..." 0.001
# Estimate fee for confirmation within 6 blocks
bitcoin-cli estimatesmartfee 6This RPC layer is how most Bitcoin applications, from block explorers to Lightning nodes like LND and Core Lightning, interact with the base layer.
Networking
Bitcoin Core connects to other nodes using a peer-to-peer protocol. Since version 27.0, it defaults to BIP 324 encrypted transport (v2), which encrypts all peer communication to resist BGP hijacking and network-level surveillance. The software supports IPv4, IPv6, Tor, I2P, and CJDNS networks.
Development Process
Bitcoin Core follows one of the most conservative development processes in open-source software. Given that bugs in consensus-critical code could allow counterfeiting, chain splits, or loss of funds, the project prioritizes correctness and security above all else.
Contribution Model
Anyone can propose changes by opening a pull request on the GitHub repository. Every change undergoes extensive peer review, where other developers test the code, examine edge cases, and debate design tradeoffs. Discussion happens publicly on GitHub, the Bitcoin Development Mailing List, and IRC channels. In 2025 alone, over 135 developers contributed code changes.
Maintainers and Merging
As of 2026, six maintainers hold merge access: Michael Ford (fanquake), Ava Chow (achow101), Gloria Zhao (glozow), Ryan Ofsky (ryanofsky), Hennadii Stepanov (hebasto), and TheCharlatan (added January 2026). The role of lead maintainer was deliberately left vacant after Wladimir van der Laan stepped back in August 2022, reflecting the project's push toward decentralized governance.
Maintainers do not have unilateral power to change consensus rules. Their role is to verify that pull requests meet quality standards, have sufficient review, and align with the project's principles. They sign releases with their PGP keys so users can verify authenticity.
Release Cycle
New major versions ship approximately every six months. The project maintains the last three major versions with security and bug fixes. Recent major releases include:
| Version | Release Date | Notable Changes |
|---|---|---|
| v31.0 | April 2026 | Cluster mempool, MuSig2 signing (BIP 327) |
| v30.0 | October 2025 | Increased OP_RETURN limits, TRUC transactions |
| v29.0 | April 2025 | CMake build system migration |
| v28.0 | October 2024 | Full RBF default, testnet4 |
Major Protocol Upgrades
Several landmark consensus changes have been implemented and activated through Bitcoin Core:
- P2SH (Pay-to-Script-Hash): introduced in v0.6.0 (2012), enabling more complex spending conditions by hashing scripts into shorter addresses
- SegWit (Segregated Witness): activated in August 2017 via BIPs 141, 143, and 144, fixing transaction malleability and increasing effective block capacity
- Taproot: activated in November 2021 at block 709,632, introducing Schnorr signatures (BIP 340) and improving privacy and smart contract flexibility
- CLTV and CSV timelocks: enabling time-locked spending conditions that underpin Lightning Network channels
Each of these upgrades was implemented as a soft fork: backward-compatible changes that old nodes can still validate, even if they don't understand the new rules. This approach ensures the network doesn't split during upgrades.
Use Cases
Running a Full Node
The primary use case for Bitcoin Core is running a full node that independently validates the entire blockchain. This is the foundation of Bitcoin's trustless model: rather than relying on third parties to tell you which transactions are valid, your node verifies everything itself. Users who run Bitcoin Core contribute to the network's decentralization and gain the strongest possible security guarantees for their own transactions.
Backend for Lightning Nodes
Lightning Network implementations typically require a Bitcoin Core node as their backend. LND, Core Lightning, and Eclair all connect to Bitcoin Core via its RPC interface to monitor the blockchain for channel opens, closes, and justice transactions. Bitcoin Core's reliability directly impacts Lightning node operation.
Mining
Miners and mining pools rely on Bitcoin Core to construct valid block templates. The software's mempool determines which transactions are available for inclusion, and its validation engine ensures blocks will be accepted by the network. Version 30.0 introduced an experimental IPC Mining Interface for Stratum v2 integration.
Development and Testing
Bitcoin Core includes support for regtest, signet, and testnet networks, allowing developers to build and test applications without risking real funds. These testing environments reproduce the behavior of the main network while providing tools like instant block generation. For a deeper comparison of node implementations, see the Bitcoin node implementation comparison.
Common Misconceptions
Does Bitcoin Core Control Bitcoin?
No. This is perhaps the most persistent misconception in the Bitcoin ecosystem. Bitcoin Core developers write and maintain the most widely used implementation, but they have no mechanism to force changes on the network. Node operators must voluntarily download and run new versions. There is no auto-update feature.
If Bitcoin Core shipped a version with rules that the network disagreed with, node operators would simply refuse to upgrade (or switch to a fork like Bitcoin Knots). The SegWit activation debate (2015-2017) demonstrated this dynamic: even with broad developer support, the upgrade required years of negotiation with miners and users before activation.
Is Bitcoin Core the Only Option?
No. Alternative full-node implementations include Bitcoin Knots (a conservative fork currently running on roughly 19% of reachable nodes), btcd (written in Go), and Libbitcoin. However, running consensus-critical code with bugs can cause chain splits, so alternative implementations carry additional risk. Most users and businesses choose Bitcoin Core because it has the most extensive testing and review.
Risks and Considerations
Monoculture Risk
Bitcoin Core running on 75-80% of nodes creates a software monoculture. A critical bug in Bitcoin Core could affect the vast majority of the network simultaneously. This happened on a small scale in March 2013, when the transition from Berkeley DB to LevelDB in version 0.8 caused a temporary chain split between upgraded and non-upgraded nodes.
Resource Requirements
Running a full Bitcoin Core node requires significant storage (the blockchain exceeds 600 GB), bandwidth, and processing power for initial sync. While pruned mode reduces storage needs and AssumeUTXO speeds up initial sync, these requirements still exceed what many users can provide. Lighter alternatives like SPV clients trade security for convenience.
Development Centralization
Although Bitcoin Core is open-source with hundreds of contributors, the merge authority is concentrated among six maintainers. Funding for full-time developers comes from a small number of organizations (Brink, Chaincode Labs, Spiral, Blockstream). This concentration is a practical tradeoff: review-heavy development requires dedicated expertise, but the funding structure introduces subtle influence vectors. The project mitigates this through radical transparency: all review happens in public, and any contributor can flag concerns.
Layer 2 protocols like the Lightning Network and Spark build on top of the foundation that Bitcoin Core provides. Understanding how Bitcoin Core works helps developers and users appreciate the security model that underpins everything built above it.
This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.