How Bitcoin Gets Built

From SourceForge to GitHub

Bitcoin's early code lived on SourceForge, a popular open-source hosting platform of the era. As the project grew, it moved to GitHub, where it has remained ever since. GitHub made collaboration easier — developers could submit pull requests, leave comments on specific lines of code, and track issues across thousands of contributors spread across dozens of countries. Today, the main repository for Bitcoin Core has hundreds of contributors who have made at least one commit, and the review process for any significant change can take months or even years.

Bitcoin Core

Bitcoin Core is the reference implementation of the Bitcoin protocol. It is the software that the majority of the network relies on to validate transactions, maintain copies of the blockchain, and relay data between peers. It is not the only Bitcoin software, but it sets the standard — when Core changes, the whole network takes notice.

Running a full node — a copy of Bitcoin Core synced to the entire transaction history — means independently verifying every block and transaction without trusting anyone else. Every node rejects invalid data regardless of its source. The more nodes running worldwide, the more resistant the network becomes to censorship or manipulation. Anyone can run one, and many thousands of people do.

Code Review and Bitcoin Improvement Proposals

Bitcoin's development culture is defined by extreme caution and thorough peer review. A proposed change to Bitcoin Core must be read, tested, and challenged by multiple contributors before it can be merged. Because Bitcoin handles real money at scale, even small bugs can have serious consequences. This creates a slow-moving but robust process — one where conservative voices carry real weight.

Formal proposals go through a system called Bitcoin Improvement Proposals, or BIPs. A BIP is a structured document that describes a proposed change, the reasoning behind it, and its technical specifications. BIPs give the community a shared language for debating upgrades. Some are purely informational. Others define new standards that wallets and exchanges need to implement. A few have reshaped Bitcoin's architecture entirely.

Consensus Rather Than Authority

There is no board of directors that approves changes to Bitcoin. Instead, development follows what is often called rough consensus — a principle borrowed from early internet governance. If a change attracts sustained, broad support from developers, businesses, and node operators over time, it moves forward. If it creates significant opposition, it stalls. No single person can force a change through, and no single person can block one forever. Full nodes are ultimately the ones that enforce this: they accept or reject software upgrades by choosing which rules to follow, giving ordinary users genuine power in the governance process.

The People Behind the Code

Gavin Andresen was one of the first developers Nakamoto trusted with commit access to the original codebase. After Nakamoto's disappearance, Andresen became the de facto lead of Bitcoin development and coordinated much of the early infrastructure that made Bitcoin usable by ordinary people. He later stepped back from a central role, consistent with Bitcoin's preference for distributed leadership.

Pieter Wuille is among the most prolific contributors in Bitcoin's history. He has authored or co-authored dozens of BIPs, contributed improvements to Bitcoin's cryptographic foundations, and worked on scripting systems that make Bitcoin's transaction logic more flexible and efficient. His work on Segregated Witness and Taproot shaped the network's most important recent upgrades.

Gregory Maxwell brought deep cryptographic thinking to Bitcoin's development. He proposed confidential transactions — a method for hiding transaction amounts while still allowing verification — and contributed heavily to relay protocol design and signature optimization. Maxwell is also known for pushing back hard on proposals he considered premature or risky, a role that proved invaluable during heated debates about the network's future.

Wladimir J. van der Laan served as Bitcoin Core's lead maintainer for nearly a decade. That role involves merging approved changes, managing release schedules, and ensuring the codebase remains stable. It is a position of significant responsibility with no formal authority — van der Laan could not unilaterally approve changes, only steward the process. His consistent, meticulous approach helped Bitcoin Core maintain its reputation for reliability through a turbulent period.

These are not the only significant contributors. Bitcoin's development history includes hundreds of engineers who have submitted patches, caught security bugs, written documentation, or built the testing infrastructure that keeps everything running. Many of them are barely known outside developer circles.

Engineering Beyond the Headlines

Matt Corallo focused on how blocks move across the network. Slow or unreliable block propagation can create security problems and unfair advantages for large miners. Corallo developed solutions to make block relay faster and more equitable — work that most Bitcoin users never see but that shapes the network's fairness at a structural level.

Peter Todd is a Bitcoin Core developer and applied cryptography researcher known for his work on transaction malleability, replace-by-fee policies, and Open Timestamps — a protocol for anchoring arbitrary data to the Bitcoin blockchain as a trustless timestamp. His work on wallet design and transaction security highlighted edge cases that others missed, and his willingness to challenge proposals publicly kept development honest.

Andrew Poelstra works at the intersection of academic cryptography and Bitcoin engineering. He contributed to research on Schnorr signatures, scriptless scripts, and sidechains — technologies that extend what Bitcoin can do without compromising its base-layer security. His work is often theoretical but consistently points toward practical improvements.

Christian Decker, a researcher at Blockstream, became one of the leading technical minds behind the Lightning Network — specifically the formalization of payment channel design. His academic work helped establish the theoretical framework that Lightning's engineers built on, bridging research and production code.

Two Bugs That Could Have Ended Everything

The most consequential work of the unsung builders is often invisible precisely because it succeeds. On August 15, 2010, block 74,638 contained a transaction that exploited an integer-overflow flaw (later catalogued as CVE-2010-5139), conjuring 184,467,440,737 bitcoins out of nothing. Satoshi Nakamoto and Gavin Andresen released a patched client within about five hours, adding a consensus rule that rejected overflow outputs, and the network abandoned the defective chain. The phantom coins were erased rather than redistributed.

Eight years later, in September 2018, a pseudonymous developer known as "awemany" privately reported what looked like a simple denial-of-service bug in Bitcoin Core (CVE-2018-17144). Within hours, reviewers including Matt Corallo, Pieter Wuille, Gregory Maxwell, and Wladimir van der Laan realized it was far worse: the same flaw could let a miner inflate the money supply. The team patched and disclosed the lesser problem publicly while quietly urging miners and exchanges to upgrade. The bug was never exploited on the main network.

These are the real meaning of "decentralized security": no authority ordered the fix. Independent developers, miners, and businesses acted in concert to protect a system none of them owned.