"Don't trust, verify" is one of the most quoted phrases in the Bitcoin world, but what does it actually mean in practice? The honest answer: it means that anyone who really wants to know can read the source code that keeps Bitcoin running themselves. No black box, no bank saying "just trust us," just public code that's been scrutinized by thousands of eyes. That's a bold claim, and this series is our attempt to back it up. We're going to open the hood together and look at what's actually happening underneath. No computer science degree required, but also no oversimplification to the point of meaninglessness.

This first post is the map for the whole series. It explains where the Bitcoin code actually comes from, who wrote it and who develops it today, how big it really is, and it gives you a complete, understandable overview of how Bitcoin works technically, before we dive deep into individual building blocks in the following seven posts.

Where Does the Bitcoin Code Actually Come From?

On October 31, 2008, a person (or group) under the pseudonym Satoshi Nakamoto published a nine-page technical document titled "Bitcoin: A Peer-to-Peer Electronic Cash System" on a cryptography mailing list. This whitepaper describes the idea on a conceptual level: an electronic payment system that works without a bank or any other trusted third party. You can read the original whitepaper here: bitcoin.org/bitcoin.pdf, it's worth reading at least once, if only because almost every later technical decision in Bitcoin ultimately traces back to it.

Three months later, the idea was followed by proof that it worked: on January 3, 2009, Satoshi Nakamoto mined the very first Bitcoin block, the so-called genesis block, using their own, self-written software, version 0.1 of the Bitcoin client software. That's the actual origin of today's code: no corporation "founded" Bitcoin, no startup took investor money and hired a programmer. A single person turned an idea directly into working code and published it themselves.

Satoshi Nakamoto stayed actively involved in development until roughly the end of 2010, then gradually handed over responsibility to other early contributors, most notably the software developer Gavin Andresen, and disappeared completely from public view afterward. To this day, the true identity behind the pseudonym hasn't been conclusively established. That's not a flaw, it's almost logical: a system that depends on no one holding a special position can't really afford to hang on a single, irreplaceable founder figure. After Satoshi stepped back, a growing community of independent developers took over development. In 2014, the original "Bitcoin" software officially became the project we know today as Bitcoin Core: by far the most widely used implementation of the Bitcoin rules, maintained by an open, worldwide community of volunteers and a small number of paid developers (funded partly through foundations and companies from the Bitcoin ecosystem, not by a central company that owns the project).

Where the Code Lives and How It Gets Changed

The complete source code of Bitcoin Core is publicly viewable on GitHub at github.com/bitcoin/bitcoin: downloadable for free by anyone, at any time, under the very permissive MIT license. Concretely, that means anyone can read the code, copy it, modify it, and even publish their own modified version of it. There's no password protection, no "enterprise version," no secrecy.

But how does that turn into the actual running software that millions of users worldwide trust with their money? Through a surprisingly unspectacular but effective process:

  1. Proposal. Anyone, literally anyone with a GitHub account, can propose a change (a "pull request"). This ranges from fixing a typo in the documentation to deep optimizations of the core logic.
  2. Open discussion and code review. Other developers from around the world, often dozens of them for more significant changes, read the proposed code, comment on it, find bugs, and suggest alternatives. These discussions are completely public.
  3. For deep rule changes: the BIP process. Larger, more fundamental proposals are additionally documented formally as a "Bitcoin Improvement Proposal" (BIP) and discussed publicly before any code is even written for them, comparable to a draft law that gets debated before it takes effect.
  4. Merging by maintainers. A small group of experienced, long-standing contributors (currently several people, not a single individual) is allowed to officially merge accepted changes into the main code, but only after sufficient review by others.
  5. The decisive last step: voluntary adoption. And here's the real trick that fundamentally sets Bitcoin apart from any software controlled by a company: even once a change is accepted into the official Bitcoin Core code, at first, nothing happens. Every node operator and every miner worldwide has to voluntarily download and install the new software version themselves before the change takes effect at all. No one can enforce a rule change "from above." That's exactly what the post after next in this series covers in detail: the consensus rules, which are so incorruptible precisely because no one can change them unilaterally.

This structure is the actual core of the trust this series is about: you don't have to personally trust anyone, not Satoshi Nakamoto, not today's maintainers, because every claim about how it works can ultimately be verified in the openly available code, and because no one can force through a change that the majority of network participants don't support.

The Code in Numbers: Qualitative and Quantitative

How big is this project actually? For this series, we downloaded the official code ourselves (version 31.1, as of September 2026) and counted it, rather than just repeating claims:

Core logic (C++)
≈ 224,000
Lines of code
Automated tests
≈ 174,000
Lines (unit + functional tests)
Files in the project
≈ 2,900
Source code, docs, build scripts

Perhaps the most revealing number here isn't the size of the core logic itself (around 224,000 lines of C++, the language that's been the standard for performance-critical system software like operating systems, or indeed financial infrastructure, for decades), but the ratio to the tests: there are almost as many lines of automated test code as actual program code, roughly 92,000 lines of classic unit and performance tests (in the same language, C++), plus another roughly 81,000 lines of so-called functional tests, written in Python, which check how multiple complete, simulated Bitcoin nodes interact with each other. In other words: for every line that actually does something with real money, there's an almost equally long line whose only job is to prove that the first line behaves correctly. For software that has no backup team, no customer service, and no way to reverse a faulty transaction after the fact, that's not a luxury, it's the basic precondition for anyone to trust it with their money at all.

Every new version is published publicly through GitHub as well as through bitcoincore.org, together with digital signatures from multiple independent developers, which anyone can use to verify that the downloaded file actually matches the reviewed, public source code unchanged.

How Bitcoin Actually Works: The Big Picture

Before we dive deep into individual building blocks over the next seven posts, here's the whole picture in one pass: the journey a single Bitcoin payment technically goes through.

  1. You create a transaction. Your wallet software selects suitable, unspent Bitcoin amounts that belong to you (technically: UTXOs, "Unspent Transaction Outputs") and digitally signs that you want to send them to a specific address.
  2. Your wallet sends the transaction into the network. Over the peer-to-peer network, with no central server, it gets passed on to neighboring nodes, which in turn forward it to their own neighbors, until practically every active node worldwide knows about it.
  3. Every node checks it independently. Before a transaction is even accepted and forwarded, every single node independently checks: are the signatures valid? Have the amounts used not already been spent elsewhere? Does the transaction follow all the fixed rules? Only then does it land in each node's "waiting room," the so-called mempool.
  4. Miners bundle waiting transactions into a block. Miners distributed around the world select transactions from the mempool (usually the ones with the highest fees first) and try to find an extremely rare digital "proof" for a new block, called proof of work, which requires enormous computing power but can be verified by anyone else in a fraction of a second.
  5. The new block is distributed across the network and checked by everyone again. Once a miner finds this proof, they broadcast the finished block, and again, every single node independently checks whether all the rules it contains were really followed before the block is accepted.
  6. The chain with the most proven work wins. Should two competing versions of the blockchain briefly exist (for example, because two miners found a valid block at almost the same time), the network automatically settles on the version that has the most demonstrable computational work behind it overall.
  7. Your wallet recognizes the confirmation and updates your balance. Once your transaction is part of an accepted block, it counts as confirmed. With every additional block built on top of it, reversing it becomes practically more and more impossible.

Each of these seven steps has its own fascinating technical story, and that's exactly where this series will take you.

What to Expect in This Series

The common thread running through all eight posts stays the same: you don't have to take any of this on faith from anyone. Every rule described here is written, word for word, in the public source code that anyone can read for themselves. We'll link to the exact spot in the code for every technical detail. That's the difference between a payment system you're supposed to trust and one you can verify yourself.

Next up, Part 2: The Incorruptible Rules, Bitcoin's Consensus Mechanism Explained.