Bitcoin Development

Bitcoin Core Development: How Bitcoin's Protocol Actually Evolves

Bitcoin Core development is one of the most scrutinised, slowest-moving, and most conservative open-source projects in existence — deliberately so. When the protocol that secures hundreds of billions of dollars in value changes, every line of code matters. Understanding how Bitcoin Core development works explains why Bitcoin is so slow to change, and why that slowness is a feature, not a bug.

The Development Process

Bitcoin Core development happens entirely in the open on GitHub (github.com/bitcoin/bitcoin). The process:

1. Proposal: A developer opens a Pull Request (PR) with code changes
2. Review: Other developers review the code, test it, and leave comments — this process can take months or years
3. ACK / NACK: Reviewers signal approval (ACK) or rejection (NACK) — there's no formal voting, only accumulated consensus
4. Merge: A maintainer merges the PR only when sufficient review and consensus exists
5. Release: Changes are bundled into a new Bitcoin Core release

Who Controls Bitcoin Core?

No one and everyone. There are a small number of "maintainers" with merge access to the repository — but they cannot push anything without community review. And even if they merged something controversial, node operators worldwide would simply not upgrade. The real power in Bitcoin development is not held by developers but by full node operators who choose which software to run.

"Bitcoin Core maintainers are janitors, not kings. They clean up the repository. They don't control the protocol." — Bitcoin development community saying

Want to go deeper?

• Bitcoin development — lopp.net
• Contributing to Bitcoin Core

---

This content is written and approved by Marius, AI-assisted using Claude (Anthropic), with references curated from: Jameson Lopp (lopp.net, PD) · Mastering Bitcoin by A. Antonopoulos & D. Harding (CC BY-SA 4.0) · Blockchain Commons (CC BY 4.0) · developer.bitcoin.org (MIT) · Bitcoin Optech (bitcoinops.org, PD).

Bitcoin Improvement Proposals (BIPs): How Protocol Changes Are Documented

A Bitcoin Improvement Proposal (BIP) is a design document that describes a proposed change to Bitcoin's protocol, process, or standards. BIPs are the formal mechanism through which Bitcoin evolves — not through backroom deals or corporate roadmaps, but through publicly documented, peer-reviewed proposals that anyone can read, comment on, and evaluate.

The BIP Process

1. Author writes a BIP document describing the proposed change, motivation, and technical specification
2. BIP is submitted to the BIPs repository (github.com/bitcoin/bips) for numbering and initial review
3. Community discusses the BIP — developers, researchers, miners, node operators all contribute
4. If accepted, the change is implemented in Bitcoin Core and potentially other software
5. Deployment mechanisms (soft fork activation) are defined — users and miners signal readiness

Famous BIPs

• BIP 32 — Hierarchical Deterministic (HD) wallets: derives all keys from a single seed
• BIP 39 — Mnemonic code (seed phrases): the 12/24-word backup system
• BIP 141 (SegWit) — Segregated Witness: fixed transaction malleability, enabled Lightning
• BIP 340/341/342 (Taproot) — Schnorr signatures, Tapscript: privacy and efficiency improvements
• BIP 174 (PSBT) — Partially Signed Bitcoin Transactions: standard for hardware wallet interoperability

"BIPs are Bitcoin's constitution in practice — proposals that succeed only if the community chooses to adopt them, not because any authority mandated it." — Bitcoin development philosophy

Want to go deeper?

• Bitcoin development — lopp.net
• BIPs repository on GitHub

---

This content is written and approved by Marius, AI-assisted using Claude (Anthropic), with references curated from: Jameson Lopp (lopp.net, PD) · Mastering Bitcoin by A. Antonopoulos & D. Harding (CC BY-SA 4.0) · Blockchain Commons (CC BY 4.0) · developer.bitcoin.org (MIT) · Bitcoin Optech (bitcoinops.org, PD).

Bitcoin Core's C++ Codebase: What's Under the Hood

Bitcoin Core is written primarily in C++ — a language chosen for its performance, control over memory, and long-term stability. The codebase has evolved significantly since Satoshi's original code, but maintains backward-compatible consensus behaviour. Understanding the structure of Bitcoin Core's codebase helps developers navigate, review, and contribute to the project.

Codebase Overview

Bitcoin Core's major components:

• Consensus layer (src/consensus/): The most critical code — defines valid transactions and blocks. Changes here are the most scrutinised.
• Validation (src/validation.cpp): Block and transaction validation logic; interfaces with the UTXO set
• Networking (src/net*.cpp): P2P protocol: how nodes discover peers, relay transactions and blocks
• Wallet (src/wallet/): Key management, UTXO tracking, transaction building
• RPC (src/rpc/): Remote Procedure Call interface for external programs to communicate with Bitcoin Core
• Script (src/script/): Bitcoin Script interpreter

Dependencies and Build System

Bitcoin Core uses CMake (switching from autotools in recent versions) for its build system. Key dependencies include: libsecp256k1 (Bitcoin's optimised elliptic curve library, also maintained by Bitcoin Core contributors), Boost, Berkeley DB (for legacy wallet), SQLite (for new descriptor wallets), and various cryptographic libraries.

"The Bitcoin Core codebase rewards patience. It is dense, well-commented in critical areas, and changes extremely carefully. That's by design." — Bitcoin developer observation

Want to go deeper?

• Bitcoin development — lopp.net
• Bitcoin Core source code on GitHub

---

This content is written and approved by Marius, AI-assisted using Claude (Anthropic), with references curated from: Jameson Lopp (lopp.net, PD) · Mastering Bitcoin by A. Antonopoulos & D. Harding (CC BY-SA 4.0) · Blockchain Commons (CC BY 4.0) · developer.bitcoin.org (MIT) · Bitcoin Optech (bitcoinops.org, PD).

Bitcoin's Consensus Rules: The Inviolable Laws of the Protocol

Bitcoin's consensus rules are the specific, exactly-defined criteria that every valid transaction and block must meet. Every full node on the network enforces these rules independently. No transaction or block that violates them can be part of the valid chain — regardless of who produced it, how much hash power backs it, or what any company or government wants. Understanding these rules is understanding Bitcoin at its deepest level.

Key Consensus Rules

• Block reward: Coinbase transaction cannot claim more than the subsidy + fees; violating this = invalid block
• 21 million supply: Enforced via the halving schedule in block reward rules
• Script validation: Every input script must satisfy the output script it's spending
• No double-spending: Each UTXO can only be spent once per valid chain
• Block size limits: 1MB base block size (4 million weight units with SegWit)
• Proof of Work: Block hash must be below the current target
• Timestamp rules: Blocks cannot be too far in the past or future

Consensus vs. Policy

Consensus rules are absolute. Policy rules (like default minimum fee rates for transaction relay) can vary between nodes and can be changed without a hard fork. Understanding this distinction explains why some "Bitcoin changes" are simply miner/node policy choices that don't require consensus, while others require network-wide coordination.

"Consensus rules are the constitution of Bitcoin. They define what Bitcoin is. Change them incorrectly and you have a different coin." — Bitcoin developer culture

Want to go deeper?

• Bitcoin development — lopp.net
• Bitcoin Whitepaper — protocol rules

---

This content is written and approved by Marius, AI-assisted using Claude (Anthropic), with references curated from: Jameson Lopp (lopp.net, PD) · Mastering Bitcoin by A. Antonopoulos & D. Harding (CC BY-SA 4.0) · Blockchain Commons (CC BY 4.0) · developer.bitcoin.org (MIT) · Bitcoin Optech (bitcoinops.org, PD).

Contributing to Bitcoin Core: How to Get Involved

Bitcoin Core is an open-source project that welcomes contributions from developers worldwide. But contributing to the most security-critical financial infrastructure ever built is different from contributing to most open-source projects. The bar is high, the review process is thorough, and patience is required. Here's what you need to know.

Types of Contributions

• Code review — The most valuable contribution. Review open PRs, test them, leave thoughtful feedback. Consistent reviewers are highly valued.
• Bug reports — Detailed, reproducible bug reports are genuinely useful. Non-security bugs go to GitHub Issues; security bugs go to security@bitcoincore.org privately.
• Documentation — Improving developer documentation, RPC documentation, or the Bitcoin Core wiki helps onboard new contributors.
• Testing — Manual and automated testing of new releases, particularly Release Candidates, helps catch regressions.
• Code contributions — New features and bug fixes, following the contribution guidelines.

Getting Started as a New Developer

Recommended path for new Bitcoin Core contributors:

1. Build Bitcoin Core from source — understand the codebase structure
2. Run the test suite (unit tests, functional tests)
3. Review existing PRs — start with small, self-contained changes
4. Fix small bugs from the "good first issue" label
5. Engage respectfully in code review discussions

"The best contribution to Bitcoin Core you can make right now is reviewing open PRs. There are always more PRs than reviewers." — Bitcoin Core contributor advice

Want to go deeper?

• Bitcoin development — lopp.net
• CONTRIBUTING.md — Bitcoin Core

---

This content is written and approved by Marius, AI-assisted using Claude (Anthropic), with references curated from: Jameson Lopp (lopp.net, PD) · Mastering Bitcoin by A. Antonopoulos & D. Harding (CC BY-SA 4.0) · Blockchain Commons (CC BY 4.0) · developer.bitcoin.org (MIT) · Bitcoin Optech (bitcoinops.org, PD).