21Relay
Advanced curriculum
Lesson 1320 minReviewed July 2026

Bitcoin's Development Process

Understand how Bitcoin improvements move from an idea through public review, implementation, testing and voluntary adoption without a central product owner.

Learning outcomes

By the end of this lesson, you should be able to

  • Bitcoin Core does not own or govern the Bitcoin network.
  • A BIP number documents a proposal; it does not mean approval.
  • Review, testing, release and consensus activation are distinct stages.
  • Node operators choose the software and rules they run.
1

No one organisation controls Bitcoin

Bitcoin is a protocol implemented by independently chosen software. Developers can propose and publish code, but they cannot force node operators, miners, wallets or businesses to run it.

Bitcoin Core is a widely used implementation, not a company that owns the network. Other compatible implementations can participate when they enforce the same consensus rules.

2

BIPs organise proposals

A Bitcoin Improvement Proposal, or BIP, is a design document for a feature, process or information relevant to Bitcoin. BIP editors check formatting and scope; a BIP number does not mean the proposal is approved or activated.

Discussion can happen on public mailing lists, repositories and review forums before, during and after a BIP is written. Technical quality, compatibility and review matter more than the identity of the author.

3

Code review is deliberately conservative

A change to Bitcoin Core normally arrives as a focused pull request. Reviewers inspect the design, reproduce tests and consider security, privacy, performance and compatibility. Maintainers merge changes after sufficient review; they do not decide which network rules users must adopt.

Consensus-sensitive changes receive exceptional scrutiny because incompatible validation behavior can split the network. Many useful changes affect wallet, relay or interface behavior without changing consensus.

4

Releases and activation are separate

A merged change may appear in a later software release, but users still choose whether and when to install that release. A consensus change may also require a defined activation mechanism before new rules are enforced.

Miner signaling can communicate readiness under some mechanisms, but it is not a vote that overrides node validation. The outcome depends on software rules and the choices of participants running them.

5

Read proposals by status and evidence

When evaluating a claimed Bitcoin upgrade, find the actual BIP or code, check its status, review open concerns and distinguish an implemented feature from an activated consensus rule.

Avoid treating social-media support, a BIP number or a merged pull request as proof that the network has adopted a change. Bitcoin development is observable, but its stages must be interpreted carefully.

Visual recap

From proposal to voluntary adoption

Public documentation and review inform each stage; no single stage grants control over the network.

01

Identify problem

02

Draft and discuss

03

Specify BIP

04

Implement and test

05

Release software

06

Users choose

Key takeaways

  • Bitcoin Core does not own or govern the Bitcoin network.
  • A BIP number documents a proposal; it does not mean approval.
  • Review, testing, release and consensus activation are distinct stages.
  • Node operators choose the software and rules they run.
  • Claims about upgrades should be checked against primary repositories and deployment status.

Lesson recap

Check what you learned

Reveal each model answer, then honestly mark whether you understood it or need another review.

1 of 3

Recall

Does assigning a proposal a BIP number mean Bitcoin has adopted it?

References

Further reading

Lesson progress

Loading progress...

Rate this lesson

Was this lesson helpful?

No name or financial information is collected.

Found inaccurate or outdated information? Report a correction