On 10 August 2026 at 21:05 UTC, a small change was merged into a GitHub repository called bitcoin/bips. Pull request #2245, opened the day before by Jon Atack, one of the five people listed as BIP editors, changed one word in the header of BIP 110: its status became “Closed”. Two days earlier, a soft fork described by that document had split off a handful of nodes onto a chain that stalled almost at once. The pull request did not stop anyone from running those rules. It only recorded, in the archive of every Bitcoin Improvement Proposal, that the attempt was over.
Even that one word drew 32 comments. Editors and reviewers argued over whether a failed soft fork had to pass through the status “Deployed”, since software enforcing it had shipped, before it could be closed. Greg Maxwell, a long-time Bitcoin developer, objected to the whole debate: “BIPs repo is emphatically not the governance of bitcoin,” he wrote in the thread. Two days after the merge, Greg Tonoski, a BIP-110 supporter, objected that the rules had activated at the height written in the specification and that the nodes still enforcing them were free to do so.
Bitcoin has no board, no chief executive and no vote, yet its rules have changed, most visibly with SegWit in 2017 and Taproot in 2021. Each change passed through the same layers: a public document, code that a few maintainers merge, a method for switching the rules on, and thousands of operators who decide what to run. When the layers disagree, the result is a fight.
This lesson follows our lesson on Bitcoin layer 2s and sidechains, which showed how much can be built without touching Bitcoin’s base rules. One reminder before going further: a soft fork only tightens the rules, so non-upgraded nodes keep following the chain as long as most hash power enforces the new rules, while a hard fork loosens or changes them and leaves non-upgraded nodes behind. Our guide to soft forks, hard forks and chain splits explains both, shows how miners signal and tells the BIP-110 split of 8 August 2026 block by block. This lesson is about who decided, and how.
Who controls Bitcoin: four powers and no owner
A useful way to read Bitcoin governance is to separate four powers that are often lumped together. Developers propose changes and write code. Full nodes, run by anyone, check every block against the rules in the software their owners chose to install. Miners order transactions into blocks and, during a soft fork, signal whether they are ready to enforce new rules. Economic users (exchanges, custodians, merchants, holders) decide which chain they call bitcoin and accept as payment. In practice no group has managed to impose a change on the other three, and changes come slowly.
Our lesson on what a node does and why it matters covers the enforcement side. The short version: a rule exists only when the software people actually run enforces it. Code that nobody installs changes nothing, and a block that nodes reject is worthless to the miner who made it.
People inside the project describe this balance in different words. The README of the BIP repository says that “ultimately acceptance and adoption rests with the Bitcoin users”, and links to a page on the “economic majority”. A statement signed in June 2025 by 31 Bitcoin Core contributors says the network is defined by its users and that “Bitcoin Core contributors are not in a position to mandate what those are”, meaning the policies users run. Supporters of BIP-110 put more weight on node operators: Tonoski, in the BIP 110 pull request, said an estimated 18,000 fully validating nodes did not reject the soft fork, a figure he gave without a source. Others point to hash power, which in August 2026 decided in practice which chain kept growing. None of these views is an official doctrine, because there is no office to issue one.
Compare this with token-based governance in decentralised finance, where holders of a governance token vote and a smart contract executes the result. Bitcoin has no such token and no on-chain vote. Its “votes” are software choices made one machine at a time.
What a Bitcoin Improvement Proposal is, and how one lives and dies
A Bitcoin Improvement Proposal, or BIP, is a design document. It describes a change to the protocol, to the way software around Bitcoin works, or to the process itself, in a fixed format with a header, a motivation, a specification and a section on backward compatibility. Some numbers are familiar to people who never read one: BIP 39 is the standard that turns a wallet’s secret into the 12 or 24 words of a seed phrase, and BIP 141 is the main SegWit document. BIP 39, by far the best known to wallet users, is one proposal among more than 200 in the repository’s list.
A public repository where publication is not approval
BIPs live in the bitcoin/bips repository on GitHub. Its README sets the order of things: an author first describes the idea on the bitcoindev mailing list, gathers feedback, and opens a pull request only once the draft has made substantial progress. Authors do not pick their own number. A BIP editor assigns one when the proposal meets the editorial criteria, and publishes it by merging the pull request.
The README is explicit about what publication means. Having a BIP in the repository “does not indicate that it is a good idea, has community consensus, or that it is about to be adopted”, it says, and editors are expected to publish liberally and stay out of decisions made on behalf of the community. When editors cannot agree whether a controversial proposal should be published, the conservative option applies and the proposal is closed. The five editors listed in BIP 3 as of 9 November 2026 are Bryan Bishop, Jon Atack, Mark “Murch” Erhardt, Olaoluwa Osuntokun and Ruben Somsen.
Draft, Complete, Deployed, Closed: the BIP 3 life cycle
The process itself is described by a BIP. For almost nine years that was BIP 2, written by Luke Dashjr and assigned in February 2016, with statuses such as Proposed, Final, Rejected, Withdrawn and Replaced. Its successor, BIP 3, “Updated BIP Process”, written by Murch and assigned on 9 January 2025, now has the status Deployed, while BIP 2 is marked Closed. The old labels still appear in older articles and should be read as history.
BIP 3 keeps four statuses. A Draft is a proposal under work; if it stalls for a year or leaves feedback unaddressed, anyone may propose closing it, and it is closed unless the authors say within four weeks that they will continue. Complete means the authors consider the specification solid and recommend adoption; a specification BIP needs a working reference implementation and test vectors to get there, and Complete is the final status of most successful informational BIPs. Deployed is reserved for a BIP that is settled and shown to be in active use, and “Once Deployed, the BIP is considered final”. Closed covers what is of historical interest only. Nothing is deleted: a closed BIP stays in the archive with a changelog line explaining why.
The Deployed rule is what the BIP 110 pull request argued about. BIP 3 accepts as evidence of active use “an established project having deployed support for the BIP in mainnet software releases”, and Knots, a node program, had shipped the rules; it also accepts a soft fork’s activation criteria being met on the network, which had not happened on the main chain. Murch, who first accepted moving through Deployed, changed his position on 10 August and wrote that treating a failed activation attempt as a deployment “seems a bit weird”. The pull request was rewritten to go straight to Closed and merged that evening. The BIP’s changelog now reads, under version 1.0.1 dated 9 August 2026, “Mark as Closed, following a chain split with stalled mining”.
Not every BIP touches the rules
Only a minority of BIPs change consensus, such as BIP 141 for SegWit or BIP 340 and 341 for Schnorr signatures and Taproot, all Deployed. Others are standards that wallets follow without any fork, such as BIP 39 and BIP 32 for hierarchical deterministic wallets. BIP 3 sorts documents into three types: Specification, Informational (where the activation methods BIP 9 and BIP 8 are filed) and Process, such as BIP 3 itself. The repository’s table gives each proposal a layer, a type and a status, and is the fastest way to see where it stands.
Who writes the code: Bitcoin Core, its maintainers and the other clients
Most reachable nodes run Bitcoin Core, the software descended from Satoshi Nakamoto’s original client. Changing Bitcoin in practice usually means changing Bitcoin Core, so its rules for accepting code matter almost as much as the BIP process.
How a change gets into Bitcoin Core
The project’s CONTRIBUTING file starts by saying there is “no particular concept of ‘Bitcoin Core developers’ in the sense of privileged people”. Anyone may open a pull request; anyone may review one. Reviewers use a short vocabulary: a Concept ACK supports the idea, an Approach ACK supports the idea and the way it is done, and a NACK opposes it. A NACK must come with a rationale, and the file says NACKs without reasons may be disregarded.
Merging is a different matter. The same file says that whether a pull request is merged “rests with the project merge maintainers”, who weigh whether it fits the project’s principles, meets its standards and reflects “the general consensus of contributors”. For consensus changes the bar is higher: such patches must be preceded by extensive mailing list discussion, come with a numbered BIP and have a widely perceived technical consensus behind them. The BIP is a precondition, not a ticket: a numbered proposal can sit unmerged for years.
A handful of merge maintainers, and no automatic updates
The project has a small group of maintainers who hold keys that can merge into the main repository. Protos reported in January 2026 that six people held such trusted keys, but public accounts of who holds them have changed more than once during 2026, and the list is best checked on the project’s own pages rather than in press reports. What does not change is the limit of their power. Merging code into Bitcoin Core does not install it anywhere.
The June 2025 contributors’ statement makes that point directly: the project avoids auto-updating, so “no entity can unilaterally push out changes to Bitcoin Core users”. Each operator decides when to upgrade, whether to upgrade, or whether to switch to other software. That is why old versions stay in use for years.
Bitcoin Core vs Knots, btcd and libbitcoin
Bitcoin Core is not the only full node. Bitcoin Knots, whose lead maintainer is Luke Dashjr, is built on Bitcoin Core’s code with extra options, many of them about which transactions a node relays, such as -datacarriercost. In May 2026 Knots published two builds side by side: 29.3.knots20260507, whose release notes say it “does not support the upcoming BIP110 (RDTS) network upgrade”, and 29.3.knots20260508, which included BIP-110 (called RDTS by Knots) and asked server users to add consensusrules=rdts to their configuration. Later releases kept those rules. The notes of 29.5.knots20260508, the latest version listed on the Knots site on 9 November 2026, also describe a “long coinbase maturity softfork” that delays when newly mined coins can be spent; Bitcoin Core has no such rule.
btcd is an independent full-node implementation written in Go, and libbitcoin is a separate set of C++ libraries with its own node. Both are far less common on the network.
How many nodes run each one can only be estimated, because a node announces its own “user agent” string, which can be changed, and nodes that accept no inbound connections or sit behind Tor are often missed. The table below is a count of user-agent strings in one snapshot of the Bitnodes crawler (btcnodes.io), not a census.
| Software (user-agent string) | Nodes | Share |
|---|---|---|
| Strings containing “Knots” | 2,066 | 9.9% |
| Other “/Satoshi:” strings (Bitcoin Core) | 18,701 | 89.8% |
| Other clients (btcd and others) | 65 | 0.3% |
| Total reachable nodes | 20,832 | 100% |
| Most common single string: /Satoshi:32.1.0/ | 4,323 | 20.8% |
| Most common Knots string: /Satoshi:29.3.0/Knots:20260507/ | 1,387 | 6.7% |
Source: Bitnodes API snapshot of 9 November 2026, 08:56 UTC, counted by Coindaro. User agents are self-reported.
The strings say something about the BIP-110 episode too. In the same snapshot, 1,413 Knots strings carried the 20260507 tag, the build that left BIP-110 out, against 4 carrying the 20260508 tag of the builds that included it. A string is self-declared and does not prove which rules a node enforces, but it suggests most reachable Knots nodes stayed on the version without the soft fork.
Other crawls give other numbers. A snapshot of 18 October 2026 from the Karlsruhe Institute of Technology, used in our report on outdated Bitcoin Core nodes, counted 1,096 Knots strings among 9,691 peers, about 11%. Trackers use different methods and reach different nodes, so a difference between two of them is not a trend.
Who pays the developers
There is no Bitcoin company paying Bitcoin’s developers. Contributors are funded by a patchwork of non-profits, companies and grants. OpenSats, a US 501(c)(3) public charity with a nine-person board, says on its site that it has allocated $21,646,000 to free and open-source projects and sent about 24.6 billion sats to 252 grantees in 40 countries, figures shown without a date and read on 9 November 2026; Bitcoin Core is among the projects it lists. Brink, founded in 2020 with financial support from John Pfeffer and Wences Casares, says it is 100% funded by donations and runs a fellowship programme for new contributors and grants for established protocol engineers.
Other contributors work for companies. Chaincode Labs describes its purpose in one line: it “exists to support Bitcoin”. Spiral, called Square Crypto until its renaming on 1 December 2021, presents itself as a Block initiative for the public good and wrote at its renaming that it is supposed to be independent of its corporate benefactor. Companies also give through these organisations: on 16 October 2026 OpenSats announced the first donation under Strive’s recurring support for its Red Team Fund. No public, authoritative count of funded Bitcoin Core developers exists.
Where proposals are argued: the mailing list, a forum and GitHub
Most of the arguing happens in three places. The bitcoindev mailing list is the oldest. After earlier homes that included SourceForge and the Linux Foundation, it moved to Google Groups, a migration announced by moderator Bryan Bishop in an email dated 9 February 2024; its archive is mirrored outside Google, at gnusha.org and mirror.b10c.me, so it can be read without an account. The Discourse forum at delvingbitcoin.org has the tagline “A place to dig deep into Bitcoin”, with categories for protocol design, implementation and economics, and many design threads now start there. GitHub hosts the code review itself, in the bitcoin/bitcoin repository for Core and bitcoin/bips for the documents.
Following a proposal in practice takes a few steps, none of which needs any permission:
- Find the BIP number and its status in the table of the bitcoin/bips README, and read the document’s header and changelog.
- Search the bitcoindev archive and delvingbitcoin.org for its name to read the arguments for and against, with the authors’ replies.
- Look for an implementation pull request in Bitcoin Core or another client, and note whether it includes activation parameters for mainnet or only test networks.
- Read the weekly Bitcoin Optech newsletter and its topic pages, such as the one on soft fork activation, which summarise the threads with links.
- Check which version of your own node software you run, since that decides which rules your node enforces.
How a soft fork is switched on: activation methods compared
Agreeing on a change is half the problem. The other half is switching it on without splitting the chain. Bitcoin’s soft forks have usually been activated by counting miner signals in the version field of blocks, the mechanism our forks guide walks through. What changed after each fight was who could stop the count: the miners, or the node operators.
BIP 9, by Pieter Wuille, assigned in October 2015, is the base design: 29 usable version bits, a window with a start and a timeout, and failure if the timeout passes first. In 2017 it showed that a minority of hash power could hold a change back by not signalling. BIP 8, by Shaolin Fry and Luke Dashjr, counts in block heights and adds an option called lockinontimeout, or LOT: with LOT set to true, miners must signal in the final period, so the change locks in by the deadline whatever they want. BIP 8 has the status Complete; a deployment of Taproot with LOT=true, BIP 343, is now Closed, its changelog citing “the absence of known deployments”.
| Method | Threshold | Clock | Can miners block it? | Used for |
|---|---|---|---|---|
| BIP 9 version bits | 95% (1,916 of 2,016 blocks) | Timestamps, with timeout | Yes: it fails at timeout | SegWit deployment of 2016-2017 |
| BIP 148 user-activated soft fork | None: nodes reject non-signalling blocks from 1 Aug 2017 | Fixed date | No, if enough nodes and buyers follow | Forcing SegWit signalling, 2017 |
| BIP 91 reduced-threshold activation | 80% (269 of 336 blocks) | Timestamps | Yes, below 80% | Locking in SegWit, July 2017 |
| BIP 8 with LOT=true | Configurable | Block heights | No: mandatory signalling at the end | Never deployed on mainnet |
| Speedy Trial (BIP 9 variant) | 90% (1,815 of 2,016) | 24 Apr to 11 Aug 2021, minimum activation height | Yes, within a short window | Taproot, 2021 |
| BIP-110 (modified BIP 9) | 55% (1,109 of 2,016), then mandatory signalling | Block heights from 961,632 | Only by the chain splitting | BIP-110, August 2026: failed |
Sources: BIP 8, 9, 91, 110, 148, 341 and 343 in the bitcoin/bips repository, read on 9 November 2026.
Two patterns stand out. Methods that let miners block a change (BIP 9, Speedy Trial) have never split the chain when they failed: the change simply did not happen. Methods that force it (BIP 148, BIP 8 with LOT=true, BIP-110’s mandatory signalling) only work if most of the economy and the hash power follow, and split the chain if they do not. How SegWit and Taproot then changed transactions is covered in our lesson on SegWit and Taproot; here only the route to activation counts.
Three fights over Bitcoin’s rules, dated
| Date | Event |
|---|---|
| 22 Jun 2015 | BIP 101 (8 MB blocks, 75% miner threshold) assigned; shipped in Bitcoin XT in August |
| 12-13 Sep 2015 | Scaling Bitcoin workshop, Montreal |
| 6-7 Dec 2015 | Scaling Bitcoin, Hong Kong: Pieter Wuille presents Segregated Witness |
| 23 May 2017 | New York Agreement published: SegWit at 80% on bit 4, a 2 MB hard fork within six months |
| 21-23 Jul 2017 | BIP 91 locks in (block 476,784) and activates (block 477,120) |
| 1 Aug 2017 | BIP 148 start date; Bitcoin Cash splits off |
| 9 Aug 2017 | SegWit locked in (period starting at block 479,808) |
| 24 Aug 2017 | SegWit active, block 481,824, 01:57 UTC |
| 8 Nov 2017 | SegWit2x hard fork suspended |
| 13 Jun 2021 | Taproot locked in (period ending at block 687,455, 20:06 UTC) |
| 14 Nov 2021 | Taproot active, block 709,632, 05:15 UTC |
| 27 Apr 2025 | Pull request #32359 to remove Bitcoin Core’s OP_RETURN limits opened (closed unmerged on 12 May) |
| 6 Jun 2025 | Statement of 31 Bitcoin Core contributors on relay policy |
| 9 Jun 2025 | Pull request #32406 “policy: uncap datacarrier by default” merged |
| 10 Oct 2025 | Bitcoin Core 30.0 released with the new default |
| 3 Dec 2025 | BIP 110 number assigned |
| 8 Aug 2026 | BIP-110 mandatory signalling at block 961,632; minority chain stalls |
| 10 Aug 2026 | BIP 110 marked Closed (pull request #2245 merged) |
Sources: BIP texts, scalingbitcoin.org, press reports of May and November 2017, Bitcoin Core release notes and GitHub, block times from mempool.space, read on 9 November 2026.
2015-2017: the block size war and SegWit
The first fight was about capacity. Bitcoin blocks were capped at 1 MB, and one camp wanted to raise the cap with a hard fork. BIP 101, by Gavin Andresen, assigned on 22 June 2015, proposed 8 MB blocks from January 2016, doubling every two years, activated when 750 of 1,000 blocks signalled. Its text explains the 75% threshold as a way to stop one large mining pool from having an effective veto. Bitcoin XT, an alternative client, shipped it in August 2015. It never came close to activating, and BIP 101 is now Closed.
Two Scaling Bitcoin workshops followed, in Montreal in September 2015 and in Hong Kong in December, where Pieter Wuille presented Segregated Witness, a soft fork that moved signature data out of the part of the block counted by the old limit. SegWit was deployed with BIP 9 in Bitcoin Core in 2016, but miner signalling stayed far below 95% for months while many large miners backed bigger blocks.
Two pressures broke the deadlock in 2017. Node operators and some businesses rallied around BIP 148, the user-activated soft fork described in our forks guide. On 23 May 2017, after a meeting held around the Consensus conference in New York, a group of companies and miners published the New York Agreement, pairing SegWit activation at 80% on bit 4 with a 2 MB hard fork within six months. BIP 91, by James Hilliard, implemented the first half with an 80% threshold over 336 blocks and was active from 23 July. Bitcoin Optech’s summary of the period notes that how much each pressure mattered is still argued over.
SegWit locked in on 9 August and became active on 24 August 2017; the big-block side had already launched Bitcoin Cash on 1 August. The second half of the agreement, the 2 MB hard fork known as SegWit2x, was suspended on 8 November 2017 in an email from BitGo chief executive Mike Belshe, co-signed by five other backers, who wrote that they had “not built sufficient consensus for a clean blocksize upgrade at this time”. The companies and miners who signed in May had no means to make nodes run the second half.
2021: Taproot and the “Speedy Trial” compromise
Taproot, the upgrade that added Schnorr signatures and a new output type, had little technical opposition. The fight was about the method. One camp wanted BIP 8 with LOT=true, so miners could not delay it; another wanted LOT=false, so a failed activation could not split the chain. BIP 343 records that the compromise, nicknamed Speedy Trial, was proposed by Russell O’Connor and outlined on the mailing list by David Harding: a short window, a 90% threshold and a minimum activation height, so that the economy had months to upgrade after lock-in.
Version 0.21.1 of Bitcoin Core shipped it, miners crossed the threshold in mid-June 2021 and Taproot became active in November without a split. Taproot later made the inscriptions of Ordinals, Runes and BRC-20 cheaper to write, which set up the third fight.
2025-2026: OP_RETURN, Bitcoin Core v30 and BIP-110
The third fight began over a node setting, not a consensus rule. Bitcoin Core used to relay transactions carrying at most 83 bytes in an OP_RETURN output, a policy limit, not a validity rule: miners could include larger ones, and some did. On 27 April 2025, Peter Todd opened pull request #32359 to remove those limits; it was closed without being merged on 12 May. A second one, #32406, “policy: uncap datacarrier by default”, opened on 2 May and merged on 9 June 2025, is the one the Bitcoin Core 30.0 release notes credit.
Bitcoin Core 30.0, released on 10 October 2025, raised the default -datacarriersize to 100,000 bytes, which in practice removes the cap since the maximum transaction size is reached first, and allowed several OP_RETURN outputs per transaction. Operators can still set -datacarriersize=83 to restore the old limit. Before the release, 31 contributors explained their reasoning in a statement dated 6 June 2025: relay policy should predict what miners will mine rather than try to block transactions with sustained demand. They added: “This is not endorsing or condoning non-financial data usage”.
Critics, many of them Knots users, said the change invited more non-financial data into blocks, and some operators switched node software. Some then took the dispute from policy to consensus. BIP 110, “Reduced Data Temporary Softfork”, by the pseudonymous Dathon Ohm, was assigned a number on 3 December 2025. It proposed turning limits on data into consensus rules for about a year, with a 55% threshold and mandatory signalling from block 961,632. Knots shipped it in a separate build; Bitcoin Core did not.
Miners did not follow. On 8 August 2026 the enforcing nodes split onto a chain that stalled, as the forks guide tells block by block. By 12 August, Murch counted four blocks on the minority tip against 533 on the main chain, and wrote in the BIP 110 pull request that the deployment “was decisively rejected by the Bitcoin network”. Tonoski and other supporters kept their view that the soft fork had activated as specified.
Bitcoin soft fork proposals on the table in November 2026
Several soft forks are being discussed, and the repository shows where each stands. None of them has activation parameters for mainnet in a released Bitcoin Core version as of 9 November 2026, and none is scheduled.
| BIP | What it would do | Status in the repository |
|---|---|---|
| BIP 54, Consensus Cleanup (Antoine Poinsot, Matt Corallo) | Fixes the timewarp bug, caps worst-case block validation time, makes 64-byte transactions invalid, prevents duplicate transactions | Complete |
| BIP 119, CHECKTEMPLATEVERIFY (Jeremy Rubin) | New opcode committing in advance to the outputs of the transaction that spends a coin | Draft |
| BIP 348, CHECKSIGFROMSTACK (Brandon Black, Jeremy Rubin) | Opcode in tapscript that checks a signature on arbitrary data | Draft |
| BIP 347, OP_CAT in tapscript (Ethan Heilman, Armin Sabouri) | Brings back concatenation of stack items in tapscript, with a 520-byte limit | Complete (since 1 March 2026) |
| BIP 360, Pay-to-Merkle-Root (P2MR) | New output type like Taproot but without the key path, as a defence against future quantum attacks | Draft |
| BIP 361, Post Quantum Migration and Legacy Signature Sunset (Jameson Lopp and others) | Phased end of sending to, then spending from, quantum-vulnerable outputs | Draft (Informational) |
Source: headers of each BIP in the bitcoin/bips repository, read on 9 November 2026.
BIP 54 has gone furthest. Its authors say bundling several fixes amortises the fixed cost of deploying a soft fork, and the 2,500-signature-operation limit that Bitcoin Core 30.0 added to its relay policy was, according to the release notes, done to prepare for a possible BIP 54 deployment. A pull request implementing BIP 54 “without mainnet activation” was opened in Bitcoin Core on 24 July 2026 and was still open on 9 November 2026. Activation timing is a matter of personal estimates, not of any plan.
The quantum proposals are the most contested. BIP 361 does not stand alone: it would follow the adoption of a post-quantum output type, which is not yet specified, and its first phase would forbid sending funds to quantum-vulnerable addresses. Frederic Fosco, a co-founder of OP_NET, told Decrypt in April 2026 that a protocol-enforced freeze “is confiscation, full stop”; Lopp, quoted in the same article, said of the proposal: “I wrote it because I like the alternative even less.” CTV and CHECKSIGFROMSTACK are often discussed together as a covenant package, with supporters and opponents on the mailing list and delvingbitcoin.org. Each proposal would also need its own activation method.
Security fixes do not need a soft fork
Not every change goes through this machinery. Bug fixes that do not alter consensus are released like any software update, and operators install them or not. On 22 October 2026, Bitcoin Core merged pull request #1281 on its website, adding an “easily discoverable” class of bugs to its security policy: bugs that can be found with minimal effort, such as a simple prompt to an AI model, are fixed in all maintained versions and disclosed at once, without the embargo of the Low, Medium, High and Critical tiers. Our report on the new disclosure policy gives the details.
Bitcoin Core 32.0 followed on 27 October 2026, and the project’s lifecycle page gives the same date as the end of life of 29.x, so the maintained lines are now 32.x, 31.x and 30.x. Since Bitcoin Core never updates itself, old versions stay in use: in the 18 October crawl studied in our report on outdated nodes, about four in ten reachable Bitcoin Core nodes ran lines the project no longer patched. Unsupported does not mean compromised, but fixes no longer reach those machines.
What Bitcoin governance means for holders and node runners
For a holder who keeps coins on an exchange or in a wallet without a node, most of this happens out of sight. Your custodian or wallet provider decides which software it runs and, in a contested split, which chain it credits. Soft forks such as SegWit and Taproot required no action from holders: old addresses kept working, and new features were optional.
For a node runner, the software you choose is your position on policy, and in a contested soft fork it can decide which chain you follow. Running Bitcoin Core or Knots, setting -datacarriersize or leaving the default, are legitimate choices, and our step-by-step guide to running a Bitcoin node covers the setup. Before installing a release that enforces new consensus rules, read which rules it adds, from which block, and what happens if most miners do not follow: the BIP-110 nodes of August 2026 ended up on a chain almost nobody else used. Keeping software on a maintained line is the other habit that matters.
Splits also raise tax questions, which the forks guide covers for the United States (IRS Revenue Ruling 2019-24) and the United Kingdom. The BIP-110 episode left a few blocks on a stalled chain and no known traded coin. Our guide to crypto taxes in the United States covers the general rules.
The next date to watch is not a block height. It is the moment a Bitcoin Core release, or another client, ships mainnet activation parameters for one of the proposals above. Until then, they remain documents and pull requests.
