• TL;DR
• Acknowledgment
• Part 1: What Is Bitcoin Core and How Does It Operate
  • The GitHub Repository
  • A Brief History of Bitcoin Core
  • How Are Proposals Approved by Contributors on GitHub?
  • The Five People Who Can Merge PRs — the Maintainers
  • How a PR Actually Gets Merged
  • From GitHub Draft to Your Computer
  • Why Users Wait: Bugs in Recent Releases
  • Is Bitcoin development Centralized or Decentralized?
  • The Real Check on Bitcoin Core’s Powers: Your Node Is Your Vote
  • Why Should You Care If You Just Hold Bitcoin?
  • What If GitHub Disappears?
  • Who Funds Bitcoin Core?
  • The Questions That Matter
  • Let’s Summarize the Threats and the Mitigation Tactics
  • In Summary
  • The Segue to Part 2: The OP_RETURN Controversy
  • References

§TL;DR

• I research and attempt to describe in plain language how Bitcoin Core operates, and assess how decentralized and resistant to capture it is.

• My motivation is to demystify the technical jargon and translate it into more accessible language that Bitcoin users with no technical background (myself included) can understand.

• The article covers the following topics: GitHub, pull requests, maintainers and other contributors, the reference implementation, version releases, the OP_RETURN controversy, “spam” on Bitcoin, policy changes vs. consensus changes, BIP-110, non-Core Bitcoin implementations (Knots and others), as well as other technical lingo and concepts.

• The article is divided into 3 parts, progressively building on each other: 1. What is Bitcoin Core; 2. The OP_RETURN Controversy; 3. The BIP-110 Potential Fork.

• I found this research very helpful for myself, and I think the article will be helpful to others who might have the same questions as I did:

  What’s Bitcoin Core and is it compromised?

  Can a chain split hurt my interests?

  What is spam on Bitcoin?

  Is there a civil war?

  Are the claims made on social media valid or exaggerated?

  And what the hell are OP_RETURN and BIP-110?

§Acknowledgment

I do my best to verify, perform my due diligence, and “fact-check” the claims made in this article; however, I cannot validate every claim with certainty, as I do not have a technical background or training. Technical details, such as the meaning of every line of code in Bitcoin’s implementation, are beyond my current comprehension.

This article is an open invitation to validate any claim made and to point out any inaccuracies — please post them in your comments. Any valuable contribution that offers a better education to non-technical Bitcoin users is appreciated.

§Part 1: What Is Bitcoin Core and How Does It Operate

§The GitHub Repository

If you have never looked inside an open-source software project, the first thing to understand is GitHub.

It is a website where developers collaborate on code. Think of it as a shared workshop where everyone brings their tools and works on the same project, but each person’s contribution is tracked separately. The code, the discussions, the reviews, and the entire history are visible to anyone with an internet connection.

Bitcoin Core — the software that most people run to connect to the Bitcoin network — currently lives on GitHub at github.com/bitcoin/bitcoin.

There are no locked doors. You can read the code, see every change ever made, and watch the debates in real time.

When a developer wants to change something, they create what is called a Pull Request, or PR for short. A PR is a formal proposal that says: “I have written some new code, and I would like the project to adopt it.”

The PR shows exactly what the developer changed, line by line. Other developers can read it, test it, comment on it, suggest improvements, or object to it.

Every PR goes through a review process. Bitcoin Core is not a website or an app where one developer can quietly slip in a backdoor. The code is reviewed by dozens of people, tested on multiple systems, and debated publicly. A single PR can take weeks, months, or even years before it is ready to be merged.

But GitHub is the workshop, not the store.

The raw code on GitHub is not what you install on your computer (although you can). The finished, tested product is published separately on bitcoincore.org.

This distinction matters. We will see why later in the article.

§A Brief History of Bitcoin Core

Bitcoin Core did not always have its current structure, nor was it always called Bitcoin Core.

In January 2009, Satoshi Nakamoto released the original Bitcoin software — hosted at the time as a downloadable archive on Bitcoin.org — and was the sole developer. Later that year, developer Martti Malmi (known online as “sirius-m”) joined the project as its second maintainer and migrated the code to a proper version control system on SourceForge.

After Satoshi disappeared from public view, the project passed through a small number of trusted hands. Gavin Andresen became the lead maintainer and later handed responsibility to Wladimir van der Laan, who served as a maintainer for many years.

In 2011, development migrated from SourceForge to GitHub, and the SourceForge project was officially shut down on September 13th of that year.

The software was originally called simply “Bitcoin.” It was later known as “Bitcoin-Qt,” reflecting the graphical user interface framework it used. In 2014, starting with version 0.9.0, it was renamed “Bitcoin Core” specifically to distinguish the software from the network itself.

The p2p network connecting thousands of nodes is called Bitcoin.

The Bitcoin Core node software is one implementation of it.

For many years now, it has been the reference implementation. This means it is the most rigorously reviewed by the largest group of developers within Bitcoin circles, and it is the most widely used by end users — the node operators.

If one were to ask what the most up-to-date version of Bitcoin node software is, Bitcoin Core would be the answer. That is what “reference implementation” essentially means.

Over the years, the project grew from one person to a distributed team of hundreds of contributors and several maintainers.

The maintainers’ role is not granted by election or corporate appointment. It is, as the project itself states, “by agreement of project contributors.”

Anyone who contributes code, review, testing, translation, or documentation is considered a contributor.

The Bitcoin Core project now has approximately 1,050 total contributors who have participated since its inception. (This should not be confused with the wider Bitcoin ecosystem, where the number of developers working on other implementations, wallets, Layer 2 solutions, services, and businesses built on top of Bitcoin is likely to be in the tens of thousands.)

§How Are Proposals Approved by Contributors on GitHub?

When reviewers examine a PR submitted by any contributor, they use technical terms that have evolved from open-source software culture (not specific to Bitcoin Core) to describe their reviews.

Here are a few such terms:

• ACK stands for Acknowledge (from telecommunications and network protocol terminology). In Bitcoin Core, it means: “I have reviewed this code and tested it, and I believe it is correct and safe.” This is a green light for the merge.

• NACK stands for Negative Acknowledge. It means: “I object to this change. Do not merge it.” A NACK from a respected developer is taken seriously. If a trusted reviewer NACKs a change, maintainers usually will not merge it unless the objections are thoroughly addressed.

• Concept ACK means: “I like the idea, but I have not reviewed the actual code in detail.”

• tACK means: “I tested this code and it works, but I may not have reviewed every line.”

• utACK means: “I reviewed the code but did not run it myself.”

These abbreviations were borrowed from early computing and network communications, where ACK and NACK were standard signals for confirming or rejecting data transmission. They were adopted into the Linux kernel development culture and then into Bitcoin Core as the review process matured.

A PR with multiple ACKs from trusted reviewers with established reputations is much more likely to be merged.

A PR with a NACK from a respected developer often stalls until the concerns are resolved.

This is not a vote. It is a conversation conducted in a transparent manner on a publicly available platform, where technical credibility matters more than loudness.

§The Five People Who Can Merge PRs — the Maintainers

After a PR has been reviewed, tested, and discussed by contributors to the Bitcoin open-source project, someone must decide whether to add it to the official software. This decision is made by the maintainers — a small group who hold merge keys.

A merge key is a cryptographic signature. It proves that a specific person personally reviewed a change and authorized it to become part of the master branch of the code. Without a merge key signature, a change cannot enter the official master copy on GitHub.

The maintainers act as gatekeepers, deciding when a proposal has been sufficiently reviewed and tested.

As of July 2026, there are five active maintainers with merge keys:

• Michael Ford

• Ryan Ofsky

• Hennadii Stepanov

• Ava Chow

• TheCharlatan (pseudonymous, added in January 2026)

There were previously six, but Gloria Zhao stepped down as a maintainer in February 2026 and revoked her signing key. This is a standard security practice in open-source projects: when someone leaves, they remove their key so it cannot be misused.

TheCharlatan was added in January 2026 as the first new maintainer since May 2023, partly in response to concerns about maintaining a healthy distribution of merge authority.

It is important to distinguish between maintainers and reviewers. Reviewers are the broader community — roughly 135 active contributors who write, test, and comment on code.

Reviewers have no power to merge. They can only offer their judgment.

Maintainers are the ones who hold the keys and can merge PRs.

§How a PR Actually Gets Merged

Does it take a vote of all five maintainers to merge a PR?

No.

According to the project’s own documentation: “Whether a pull request is merged into Bitcoin Core rests with the project merge maintainers.”

Any single maintainer can merge a PR if they believe it is in line with the project’s principles, meets minimum standards, and has achieved general consensus among contributors.

This means a single maintainer can — and often does — merge a change after judging that reasonable objections have been addressed.

There is no formal requirement for a majority vote or a unanimous decision among the five maintainers. This is not a board of directors. It is a trust-based system where each maintainer is expected to use their judgment responsibly.

Why does it work this way?

Because requiring all five maintainers to agree on every change would create a bottleneck. The project processes hundreds of PRs per year. From the project’s inception until July 2026, there have been almost 36,000 PRs and Issues registered on GitHub. If every merge required a committee vote, development would grind to a halt.

Instead, the system relies on a principle used in various open-source projects known as “lazy consensus” — a change is accepted not when everyone votes yes, but when no one raises a technically sound objection.

If a maintainer merges something controversial, the other maintainers can object, and the community can discuss it. But the day-to-day work requires individual judgment.

This is a critical point: maintainers merge approved changes into the master branch on GitHub, which is the active development line. This is not a finished product. It is a draft.

The master branch is continuously updated with reviewed and merged PRs over weeks and months before the public release of an updated Bitcoin Core version.

It is not until these changes are bundled, tested, and signed that they become a release you can download.

§From GitHub Draft to Your Computer

The process works like this:

1. Developers submit PRs to GitHub and debate them for months.

2. Maintainers merge approved PRs into the master branch.

3. Every few months, the maintainers bundle hundreds of merged PRs into a new release.

4. This release is tested as a complete package for weeks by contributors.

5. The final, tested version is cryptographically signed and published on bitcoincore.org with a version number.

Bitcoin Core has had over 30 major releases since the project began. There is a major release approximately every 6 months. You are not downloading a draft from GitHub. You are downloading a finished release that has been through multiple rounds of review, testing, and bundling.

Does a new release break your old version?

No.

Bitcoin Core is designed to be backward compatible. You can upgrade from a very old version directly to the newest version. Your wallet, your transaction history, and your settings will migrate.

Conversely, you are not forced to upgrade. If you are happy with version 28.0 and do not need the new features in version 31.0, you can keep running 28.0. Your node will continue to validate blocks and participate in the network.

There is a practical reason why many users do not rush to upgrade on release day.

§Why Users Wait: Bugs in Recent Releases

Despite rigorous testing, Bitcoin Core has had bugs in recent releases that caused real problems. This is why many users — especially those running businesses or holding significant funds — wait for a new release to be “tested by the market” before upgrading.

Here are two verified examples from recent years.

§Example 1: The Wallet Migration Bug in 30.0 and 30.1**

A wallet migration bug present in Bitcoin Core 30.0 and 30.1 could, under specific conditions, delete all files in the wallet directory. This had the potential to result in a permanent loss of funds. A fix was released on January 13, 2026 in Bitcoin Core v30.2, and as a precaution, the binaries for versions 30.0 and 30.1 were removed from the official download website.

Key facts:

• Who is affected: Only users who actively attempt to migrate a legacy (BDB) wallet to the modern descriptor format. Users who do not trigger the migration feature are completely unaffected and can use versions 30.0 and 30.1 normally.

• The specific trigger: The bug occurs when migrating an unnamed default “wallet.dat” file — typically an old wallet file that was never renamed — especially when the user has set a custom wallet directory or has pruning enabled. This combination is relatively rare.

• What actually happens: When the migration attempt fails, the software incorrectly deletes the entire wallet directory, not just the file being migrated. All wallet files in that directory are permanently removed.

• What is the damage: If you have no backups, your wallet files are gone. Your private keys are gone. Your funds are unrecoverable. This is not a hack where someone steals your coins. This is deletion — your coins still exist on the blockchain, but you no longer have the keys to access them.

• What was the mitigation before the patch: Bitcoin Core explicitly advised users to avoid all wallet migration attempts using the graphical interface or the command line until v30.2 was released. The official advice was: if you have a legacy wallet, leave it as-is until the fix arrives.

• How to protect yourself: The only protection is having backups. If your wallet files are backed up securely — on an external drive, in cold storage, or through your own copy of the seed phrase — you can restore them even if the migration deletes them. Without backups, the loss is permanent.

This example illustrates an important point: even with hundreds of reviewers and thousands of tests, complex software can harbor bugs in rarely-used features. The Bitcoin Core development team is careful, but caution is not perfection. Users who wait a few weeks after a release are not being paranoid. They are observing the experience of the wider network before committing their own node to new code.

Can a bug like this affect hardware wallets?

No. Hardware wallets like Ledger or Trezor are not affected because they do not store their keys in Bitcoin Core’s wallet files. They maintain keys on their own secure hardware. This bug only affects users who store Bitcoin directly in Bitcoin Core’s built-in software wallet, particularly older “legacy” wallets.

§Example 2: CVE-2024-52911 — The Script Interpreter Remote Crash**

(CVE means*** *Common Vulnerabilities and Exposures; 2024 - year when the vulnerability was discovered or reported; 52911 **- a serial number of the vulnerability)

A bug in the script interpreter, present in Bitcoin Core versions from 0.14.0 through 28.x, meant that a specially crafted block could be used to remotely crash a Bitcoin Core node. This was a serious vulnerability: a miner with sufficient proof-of-work could theoretically produce a block that would crash nodes running the affected software. The bug was privately reported in November 2024, fixed through a covert patch in an unrelated pull request, and included in Bitcoin Core 29.0 released in April 2025. The vulnerability was publicly disclosed in May 2026, after the last vulnerable version (28.x) went end-of-life on April 19, 2026.

Key facts:

• How easy is it to exploit? Not easy. The attacker must be a miner — someone with sufficient hash power to produce a valid-looking block with specially crafted invalid transactions. Mining a block requires real electricity, real hardware, and real costs. The block must pass initial validation but trigger the bug during script verification. This is not something a casual hacker can do from a laptop.

• Was it ever executed by anyone? Bitcoin Core has not confirmed any instances of exploitation. The bug was discovered through responsible disclosure by researcher Cory Fields and was patched covertly before the public knew it existed.

• What does “crash a node” mean? It means the Bitcoin Core software on your computer stops running unexpectedly. Your node goes offline. It stops validating blocks, relaying transactions, and maintaining its connection to the network. When you restart it, your node must catch up on any blocks it missed while it was down. The crash does not corrupt your wallet or delete your coins. It is a denial of service — your node is temporarily knocked out.

• Could this crash all vulnerable nodes at once? In theory, a coordinated miner could craft a block that crashes any node running the affected software that attempts to validate it. However, the block must be mined with real proof-of-work, and the vulnerability is triggered only when the block is actively validated. Not every node validates every block in the exact same way simultaneously. The risk is real but not absolute.

• Could funds be lost? No. This is a crash vulnerability, not a theft vulnerability. Your coins do not disappear because your node restarts. The risk is that your node goes offline, leaving you temporarily unable to verify the state of the network or send transactions. The deeper theoretical risk is that if enough nodes crash, the network could become temporarily more centralized among the nodes that remain online.

• Why was disclosure delayed until May 2026? Bitcoin Core follows a practice called responsible disclosure. The bug was fixed covertly in late 2024, shipped in version 29.0 in April 2025, and then kept secret for an additional year to give the entire network time to upgrade. The public announcement was deliberately timed for after the last vulnerable version (28.x) reached its end-of-life. Once a version goes end-of-life, it receives no more security patches. By waiting until end-of-life, the developers ensured that anyone still running the vulnerable version was already on unsupported software.

• How many nodes were still vulnerable? Approximately 43% of active nodes were still running software versions prior to 29.0 when the disclosure was made in May 2026. This is why the delay was controversial — a large portion of the network was still exposed.

So NOT updating to the latest release also carries risk. If you are running version 28.x today, you are running end-of-life software that will receive no future security patches. CVE-2024-52911 is fixed in version 29.0 and all later versions. The bug was present for nearly a decade, hidden in the code since 2017. It was discovered only because a security researcher actively hunted for it. There may be other vulnerabilities in older versions that have not yet been found.

Should I upgrade immediately or wait?

There is no universal answer. If you are running a business, holding significant funds, or operating a publicly accessible node, the risks of running end-of-life software are real and growing. If you are a casual user with no urgent need for new features, waiting a few weeks after a release to see if others report issues is a reasonable practice. The key is to not fall so far behind that you are running unsupported software with known vulnerabilities.

§Is Bitcoin development Centralized or Decentralized?

Here is the paradox:

The key features of Bitcoin are extraordinarily hard to change. This is precisely why people value Bitcoin so much. The 21 million supply cap, the difficulty adjustment, the proof-of-work consensus, the physically distributed network of nodes — these are designed to resist tampering. The various versions of software that maintain these features are already developed and operational. The nodes running the already released software, forming the Bitcoin network are what Bitcoin essentially is.

Yet, some parts of software must constantly change and adapt to the current technological landscape. Long-discussed features must be added. Bugs must be patched. Security vulnerabilities must be fixed. Performance must be improved. Adaptation to new operating systems must be done.

Bitcoin Core project is therefore structured to make every change as transparent, backward-compatible, and difficult to implement without rigorous debate and review as possible. It’s decentralized enough to have input from hundreds of contributors. It’s centralized enough to implement specific, agreed-upon changes.

Is it perfect?

No.

It is a naturally evolving software system governed and maintained by humans.

Does it try to be perfect?

Also no.

It only attempts to be better than its competitors.

So let us compare Bitcoin Core to the alternatives.

Bitcoin Core: Five maintainers with merge keys. No elections. No term limits. No formal structure. Hundreds of active contributors debating changes, reviewing proposals. Decisions are made through “lazy consensus” and individual maintainer judgment. But the maintainers cannot change the rules of Bitcoin itself without the network’s acceptance. Contributors can propose changes, however they cannot impose them on the users.

A Central Bank: A board of governors appointed by government officials, with formal legal mandates, public hearings, and the power to change monetary policy by majority vote. The Federal Reserve can raise interest rates, expand the money supply, or create lending facilities. It does not need your permission or supervision. You cannot opt out of the dollar. You cannot stick to the previous policy version if you don’t like the new one. You cannot run an alternative Federal Reserve on your laptop.

Other Crypto Projects: Often governed by a single foundation, a single company, or a charismatic founder. The Ethereum Foundation plays a significant role in guiding Ethereum’s development roadmap. Solana’s development is heavily influenced by Solana Labs and the Solana Foundation. In many cases, core developers are employees of a single organization. The project has a marketing team, a treasury, and a strategy directed by a small group. If the foundation decides to change direction, the community follows or the project fractures.

Bitcoin Core is different from both. It is more decentralized than a foundation-led project because no single company owns it. It is less formally accountable than a central bank because there are no elections and no legal obligation to explain decisions.

But unlike a central bank, you can refuse to run the software. Unlike a foundation-led project, no single organization controls the treasury or the roadmap of the project.

Bitcoin Core is a focal point of Bitcoin development. By definition, focal points are centralizing. However, the development process within this focal point is as decentralized as it can be at any given moment. More contributors means more decentralization. The level of decentralization also varies over time, as the project is a living collaboration between contributors who come and go.

§The Real Check on Bitcoin Core’s Powers: Your Node Is Your Vote

The five maintainers can propose. They cannot impose. If they tried to change Bitcoin’s most fundamental rules — for example, increasing the 21 million coin supply — the network would reject it. Every node running Bitcoin validates every block against the rules it knows. A block that violates the 21 million cap would be rejected by every honest node, regardless of what the GitHub maintainers merged.

The same is true for policy changes. If the maintainers raise the default limit on how much data can be attached to transactions in OP_RETURN, you can simply run a version that keeps the old limit. You can run an alternative implementation like Bitcoin Knots. You can run an older version of Core. Your node will still validate the same blocks as everyone else, because the change was not a consensus rule. It was a policy preference.

We will examine the controversial OP_RETURN policy change in depth in the second part of this article.

§Why Should You Care If You Just Hold Bitcoin?

If you hold Bitcoin on an exchange, the exchange runs a node. Not you. The exchange chooses the software, the rules, and the version. Major exchanges like Coinbase, Kraken, Binance, and Bybit operate their own node infrastructure, but their choice of node version is typically not public. In the case of contentious forks, their decisions are internal and may be influenced by regulatory compliance considerations. During the 2017 Bitcoin Cash and SegWit2x disputes, exchanges coordinated informally on which chain to support — a process that played out behind closed doors.

If you hold Bitcoin in a hardware wallet or a software wallet on your phone, the situation is similar but less obvious. A hardware wallet — such as a Ledger or Trezor — stores your private keys securely, but it does not independently validate the blockchain. By default, these wallets connect to servers and nodes run by their manufacturers (Ledger Live, Trezor Suite). Software wallets, like Sparrow or Electrum, connect by default to Electrum servers run by volunteers.

When you check your balance or send a transaction, your wallet connects to a node somewhere. If you have not configured it to connect to your own node, it connects to a node run by the wallet provider, a volunteer, or a third-party service. It is not your node. It is someone else’s node. They are choosing the rules for you.

Some software wallets, like Sparrow or Electrum, allow you to connect to your own node. Many hardware wallets also offer this option. If you do this, you are validating the rules yourself. If you do not, you are trusting someone else to validate them for you.

The fact that the developers must convince the exchanges, the miners, and the users to run their software is what makes Bitcoin resistant to capture. It is a distributed social consensus, not a command structure.

But if you do not run a node, you are not participating in that consensus. You are outsourcing your vote to whoever runs the node you connect to.

In the event of a contentious fork, users who do not run their own nodes are at the mercy of the node runners — a topic explored deeper in the third part of this article. That said, your seed phrase remains the key to your coins, and typically you would retain access to your funds on both chains regardless of which node your wallet is connected to.

§What If GitHub Disappears?

Bitcoin Core lives on GitHub today. But what if GitHub were compromised, censored, or shut down?

The project has multiple safeguards. First, because Git is a distributed version control system, every developer who has cloned the repository has a complete copy of the entire code history. If GitHub vanished tomorrow, the community could move the repository to another host and continue working.

Second, there are explicit mirrors and backups. The source code is mirrored on other platforms. There is a SourceForge mirror that describes itself as an exact mirror of the project. Independent developers have created GitLab mirrors and metadata backups to preserve not just the code, but the issues, pull requests, and review history. One developer, b10c, maintains a public read-only mirror and has documented how others can set up their own backup servers.

The source code is also available directly from bitcoincore.org, which is independent of GitHub. The releases are cryptographically signed by multiple contributors. Even if GitHub were compromised, the existing release signatures could be verified against the developers’ known public keys.

So while GitHub is the current workshop, Bitcoin Core does not depend on GitHub’s continued existence. The project could migrate to another platform with minimal disruption.

The worst-case scenario, then, is not a collapse of Bitcoin itself, but a temporary pause in building the next version of the Bitcoin software. If GitHub were compromised or shut down overnight, the active development of the next release would be delayed. Contributors would need to coordinate on a new platform, set up fresh mirrors of the repository, and redirect the testing infrastructure. Until the new workshop is fully operational, the merging of new pull requests and the bundling of the next version would slow down or pause. This is an interruption in development, not an interruption in the network.

Crucially, the Bitcoin network itself does not know that GitHub exists. Every node running already released versions continues to validate blocks, broadcast transactions, and enforce the rules exactly as it did before. The software already installed on thousands of computers does not phone home to GitHub to ask permission. It validates blocks against the code it already contains. The Bitcoin network would continue operating without a single missed block. The workshop might have to move, but the network keeps running.

§Who Funds Bitcoin Core?

Bitcoin Core has no treasury. There is no foundation with a budget. There is no built-in mechanism in the protocol that automatically sends coins to developers. The 21 million supply cap does not include a developer tax. No block reward is diverted to a foundation. This is by design, but it creates a practical problem: the people who maintain a trillion-dollar network must eat, pay rent, and buy coffee just like everyone else.

So where does the money come from?

§The Short Answer: Other People’s Money

Bitcoin Core development is funded entirely by external, voluntary contributions. A small number of nonprofit organizations, academic institutions, and companies pay the salaries and stipends of the most active contributors. The rest are unpaid volunteers, hobbyists, or people whose employers let them contribute on company time.

According to the nonprofit funding platform OpenSats, the combined annual budget across all Bitcoin Core development organizations is approximately $8 million.

To put this in perspective, the Federal Reserve System operates on an annual budget of roughly $7.4 billion and employs over 24,000 staff.

Bitcoin Core sustains the reference implementation for a global monetary network on approximately $8 million per year — a fraction of a fraction of the FED’s budget.

The money does not come from Bitcoin itself. It comes from:

• Nonprofit grant organizations (OpenSats, Brink, Human Rights Foundation)

• Academic research labs (MIT Digital Currency Initiative)

• Private developer labs (Chaincode Labs in New York)

• Corporate sponsors (Blockstream, Spiral — formerly Square Crypto, OKX, BitMEX, Coinbase)

• Individual donations (often through platforms like OpenSats or the Hardcore Fund)

An extensive research report published by 1A1z identified thirteen major sponsoring organizations that have directly funded or employed Bitcoin Core developers over a sustained period. These include Blockstream, Chaincode Labs, MIT, Spiral (Block), OKX, Human Rights Foundation, and Brink, among others.

Interestingly enough, the Federal Reserve is also funded by other people’s money. The only difference is that it’s not voluntary. The Fed creates money to buy Treasury securities, and the interest on those securities funds its operations. The money creation itself dilutes the purchasing power of every existing dollar — so every dollar holder involuntarily pays for the Fed’s existence through inflation, while the Fed collects the interest. It is, in effect, a hidden tax — one that funds the very organization that competes with Bitcoin.

§Who Pays the Five Maintainers?

This is where it gets more opaque. The five active maintainers with merge keys are not employees of Bitcoin Core — there is no such employer. Each maintainer is funded by a different organization, or in some cases, may have multiple funding sources over time.

According to one analysis posted directly to the Bitcoin Core GitHub repository, Bitcoin Core has five maintainers funded by four organizations. The exact identities of these four funders are not formally disclosed in a single public registry, but they can be pieced together from public announcements:

• Marco Falke has received grants from OKCoin and Paradigm

• Chaincode Labs has historically been the most prolific financial supporter of Bitcoin Core development, employing or funding multiple core contributors including developers who later became maintainers 

• MIT DCI has funded long-term contributors like Wladimir van der Laan and Cory Fields

• OpenSats funds multiple current contributors through its Long-Term Support (LTS) program, including some who have taken on maintainer-like responsibilities

§Is This Information Required to Be Public?

No. There is no rule, no policy, and no enforcement mechanism that requires a Bitcoin Core maintainer or contributor to disclose who pays their salary. Some developers are transparent about their funding sources. Others are not. The project itself does not collect this information.

This is a structural feature of Bitcoin’s decentralization, not a bug. Because there is no foundation, no corporation, and no formal employment relationship with the project, there is also no HR department, no payroll ledger, and no mandatory disclosure forms. A developer can show up, review code, submit pull requests, and eventually be granted a merge key — all while their rent is paid by an organization the community may or may not know about.

This opacity worries some observers. If a maintainer is secretly funded by an entity with a financial interest in Bitcoin’s direction, could that influence their judgment? The counterargument is that the code is public, the reviews are public, and a maintainer cannot merge malicious code without hundreds of reviewers noticing. Funding influence is a subtle threat, but it is mitigated by the transparency of the work itself.

§Where Does the Money Actually Go?

Here is the most surprising fact: most of the budget does not go to new features. It goes to maintenance.

OpenSats estimates that more than 70% of all project activity is maintenance work: bug fixes, test coverage, continuous integration (CI) upkeep, build system improvements, release engineering, and handling the edge cases that users report.

This is not glamorous work. It does not produce headlines. It does not generate new tokens or exciting product launches. It is the digital equivalent of cleaning the boiler room: fixing memory leaks, updating dependencies, making sure the software compiles on new operating systems, and verifying that a change on one part of the codebase does not silently break another.

The $8 million annual budget pays for human time. Some of it goes to server infrastructure for testing and CI. Most of it goes to salaries, stipends, and grants that allow roughly 50 regular contributors to work on the software that secures a trillion-dollar network.

§The Funding Is Not Guaranteed

This is the critical point for understanding Bitcoin Core’s governance: no funding is guaranteed to continue. The code is owned by everyone. The development capacity is owned by no one.

As the GitHub analysis noted: “Brink, Chaincode Labs, Spiral, and OpenSats could cease funding, which would shrink the already-thin maintainer pool.” If these organizations stopped paying tomorrow, the maintainers would need to find other income, reduce their hours, or stop contributing entirely. The code would not disappear. The repository would remain. But the pace of maintenance, security patches, and release engineering would slow down.

This is Bitcoin’s immune system at work, and also its vulnerability. The network does not depend on any single donor. But the development of the reference implementation does depend on a small pool of donors continuing to show up. Everyone benefits from the software, but only a few individuals and organizations pay to maintain it.

§Why Does This Matter for Your Node?

If you run your own Bitcoin Core node, you are running software that was built on a patchwork of grants, donations, and volunteer labor. The people who merged the code you are running were not elected, not appointed by a foundation, and not required to tell you who paid their rent.

This is both a strength and a weakness. The strength is that no single donor controls the project. The weakness is that the project could be captured, starved, or skewed by the donors who do exist.

The only real protection is the same protection we have discussed throughout this article: the code is public, the reviews are public, and you can run whatever version you choose. If the funded developers go in a direction you do not like, you can keep running the old version. If the funding dries up, the code remains. The network keeps running.

But the next version? The security patch next year? The compatibility fix for the operating system you will upgrade to in 2028? That depends on whether someone is still willing to pay for the boiler room.

§The Questions That Matter

§Are five maintainers too few?

The number sounds small, but the maintainers’ role in Bitcoin Core is largely janitorial. They are not executives who decide the future of Bitcoin by decree, nor are they architects who redesign the protocol alone. Their job is to merge pull requests that have already been reviewed, tested, and debated by dozens or even hundreds of contributors. When a maintainer signs a merge, they are not imposing their vision. They are certifying that the community has done its homework and that the technical criteria have been met.

But the critical point is that no maintainer can change the rules of Bitcoin alone. They can only change the next version of the software that interprets those rules. If the rules they implement diverge from what the network accepts, the network ignores them.

§What if the maintainers are corrupted or captured?

There are two layers of protection. First, the code is public. Every change is visible. If a maintainer tried to merge malicious code, hundreds of reviewers would see it instantly. Second, if the maintainers collectively went rogue, the community could fork the software. The code is open-source. Anyone can copy it, remove the bad maintainers, and publish a new version. This is not theoretical. It is how open-source projects work. In the second and third parts of this article, we will explore the rise in popularity of Knots implementation that followed a disagreement on the OP_RETURN policy change.

§How does this compare to a company that issues a software update?

When Apple releases an iOS update, you have two practical choices: install it or stop using your phone. The App Store stops working. Your apps stop updating. You are forced into the ecosystem. With Bitcoin, you can keep running an old version indefinitely. The network does not kick you out. The developers cannot remotely disable your node. This is the difference between a service and a protocol.

§If I just hold Bitcoin on an exchange, why should I care?

Because the exchange is running a node, not you. The exchange chooses the software, the rules, and the version. If the developers changed a consensus rule, the exchange would upgrade and your coins would follow the new rules. But the fact that the developers must convince the exchanges, the miners, and the users to run their software is what makes Bitcoin resistant to capture. It is a distributed social consensus, not a command structure.

§If I use a hardware wallet, do I run a node?

No. Your hardware wallet stores your keys securely, but it does not validate the blockchain. It connects to someone else’s node. If you have not configured your wallet to connect to your own node, you are trusting the wallet provider to tell you the truth about your balance and the validity of your transactions.

§Let’s Summarize the Threats and the Mitigation Tactics

• Threat: Five maintainers hold centralized merge power.

  Mitigation: The code is fully open-source. Every change is publicly reviewed by hundreds of contributors before it reaches a maintainer. If maintainers are captured, the community can fork the code and continue without them. No single maintainer can change the rules of Bitcoin without the network’s acceptance.

• Threat: New releases may contain bugs that cause fund loss or node crashes.

  Mitigation: Users can wait for a new release to be “tested by the market” before upgrading. The project publishes detailed release notes and advisories. Keeping secure backups of wallet files and seed phrases protects against data-loss bugs.

• Threat: Running outdated, end-of-life software exposes you to known vulnerabilities.

  Mitigation: Do not fall so far behind that you are running unsupported versions. Bitcoin Core fixes vulnerabilities in new releases and eventually discloses them once old versions go end-of-life. Upgrade to a supported version before the old one loses security patches.

• Threat: GitHub could be compromised, censored, or shut down.

  Mitigation: The project maintains mirrors on SourceForge, GitLab, and other platforms. Releases are cryptographically signed and distributed independently via bitcoincore.org. The Bitcoin network itself does not depend on GitHub and would continue operating normally.

• Threat: If you do not run your own node, someone else chooses the rules for you.

  Mitigation: Run your own Bitcoin Core (or alternative) node. Connect your software wallet or hardware wallet to your own node. This ensures you validate every transaction and block yourself, rather than trusting an exchange or wallet provider to do it for you.

§In Summary

Bitcoin Core is a collaborative software development initiative that releases new versions of Bitcoin node software.

The Bitcoin network consists of nodes running previously released and tested software.

Historically, every new release of Bitcoin Core has been gradually adopted by node operators; however, this adoption takes time.

No single Bitcoin Core version holds a majority share among all reachable nodes. As of July 2026, the latest release, version 31.0.0, is used by approximately 12.5% of all reachable nodes.

The exact number is unknown, as there are various ways to crawl node data and compile statistics, and the number of active but unreachable nodes can only be estimated (see the Reference section).

From a technical standpoint, Bitcoin Core is sufficiently decentralized to implement changes to the new releases of Bitcoin software while taking into account the views and the technical expertise of the largest pool of developers.

It is also sufficiently centralized to turn long and rigorous discussions into merged PRs that, eventually, result in newer versions of Bitcoin software.

On the surface it looks like it is reasonably secure against social manipulation attacks.

Or is it?

§The Segue to Part 2: The OP_RETURN Controversy

Now that we more or less understand what Bitcoin Core is and how it operates, the next question is: what happens when a simple policy change — a preference in the software, not a rule of the network itself — causes a mass exodus of users to alternative software such as Bitcoin Knots?

That is where the story of Bitcoin’s continuous development gets another layer of complexity — the social layer where people disagree on the meaning of words.

Part 2 will be published soon. Follow to get notified.

§References

1. Bitcoin Core GitHub Repository — github.com/bitcoin/bitcoin

2. Bitcoin Core Official Releases — bitcoincore.org

3. Bitcoin Core - Bitcoin Wiki — en.bitcoin.it/wiki/Bitcoin_Core

4. Who Controls Bitcoin Core? - Cypherpunk Cogitations — blog.lopp.net/who-controls-bitcoin-core/

5. The Core Issue: The Role And History of Bitcoin Core Maintainers — bitcoinmagazine.com/print/the-core-issue-the-role-and-history-of-bitcoin-core-maintainers

6. Bitcoin Core Security Advisory: CVE-2024-52911 — bitcoincore.org/en/2026/05/05/disclose-cve-2024-52911
   Source for the timeline, severity, affected versions (0.14.0 through 28.x), and disclosure timing of the script interpreter crash bug.

7. Bitcoin Core Wallet Migration Bug Advisory — bitcoincore.org/en/2026/01/05/wallet-migration-bug
   Source for the claim that Bitcoin Core 30.0 and 30.1 could delete wallet files during migration, and the official advice to avoid migration until v30.2.

8. Bitcoin Core 30.2 Release Notes — bitcoincore.org/en/2026/01/10/release-30.2
   Source for the release date of the wallet migration fix and removal of affected binaries.

9. Protos: Bitcoin Core Adds Sixth Trusted Key Maintainer (TheCharlatan) — protos.com/bitcoin-core-promotes-first-trusted-keys-maintainer-in-three-years
   Source for the claim that TheCharlatan was added as a sixth maintainer on January 8, 2026, and the names of the five other keyholders at that time.

10. DLNews: Gloria Zhao Steps Down dlnews.com/articles/people-culture/gloria-zhao-steps-down-as-bitcoin-core-maintainer/
    Source for the claim that Gloria Zhao stepped down as a maintainer in early 2026.

11. Bitcoin Core Security Advisories Index — bitcoincore.org/en/security-advisories
    Source for the claim that Bitcoin Core follows responsible disclosure practices and maintains a public advisory archive.

12. Bitcoin Optech Newsletter #405: CVE-2024-52911 Disclosure — bitcoinops.org/en/newsletters/2026/05/15
    Source for the claim that the vulnerability disclosure was coordinated through the Bitcoin-Dev mailing list.

13. Bitref: Bitcoin Node Statistics and Client Distribution — bitref.com/nodes
    Source for the claim that no single version holds majority share, and for live node distribution by client and version (e.g., Bitcoin Core vs. Bitcoin Knots).

14. Coin Dance: Bitcoin Nodes Summary — coin.dance/nodes
    Source for node counts by implementation, version breakdown tables, and historical trends of Bitcoin Core vs. alternative implementations.

15. BTC Nodes: Network Snapshot and Crawler — btcnodes.io
    Source for the claim that multiple independent crawlers exist, and for the distinction between reachable, live, and pending node counts.

16. Delving Bitcoin: GitLab Backups Discussion — delvingbitcoin.org/t/gitlab-backups-for-bitcoin-core-repository/624
    Source for the claim that the community actively discusses and maintains backup infrastructure for the GitHub repository.

17. Bitcoin Core — OpenSats Funding Overview — opensats.org/projects/bitcoin-core

18. BitMEX Research: Who Funds Bitcoin Development? — bitmex.com/blog/who-funds-bitcoin-development

19. Who Funds Bitcoin Development? (Public Tracker) — whofundsbitcoin.com

20. 41 Developers Power a $1.7 Trillion Empire (The Block Beats/1A1z Report) — m.theblockbeats.info/en/news/60470

21. Federal Reserve System Budgets (2024–2025) — federalreserve.gov/publications/2024-ar-federal-reserve-system-budgets.htm