On 10 August 2026 the Bitcoin Knots project published an announcement that begins: "The Bitcoin network is under attack, and block production has slowed significantly." It advises users "not to downgrade or switch to software that weakens Bitcoin's consensus protections" (bitcoinknots.org announcements feed).
On 21 August 2026 at 09:39 UTC the chain the large mining pools are building on stood at height 963,417, having produced eight blocks in the preceding forty minutes, credited to SpiderPool, Foundry USA, MARA Pool and others (mempool.space).
Both of those statements can be checked, and neither is a lie. They describe different
chains. From 8 August 2026 a node enforcing BIP-110 and a node not enforcing it stopped
agreeing on which blocks exist: the BIP-110 project's own site gives the hash of its block
961,632 as ending 7c78dbc16
(bitcoinknots.org/learn/2026-rdts), while block
961,632 on the chain those pools extend is
00000000000000000000d1e01392faa65ceeaed307f0a3159144b84146ff24ba
(mempool.space).
This is what Bitcoin's governance actually looks like from the inside: not a decision, but a set of separate parties each holding one lever, none of which is the whole thing. It is worth being precise about which lever is which, because almost every confident sentence written about this subject gets at least one of them wrong.
What nodes decide
A node decides what it will accept as valid, for itself, and nothing else. That is the whole of it, and it is more than it sounds like. Bitcoin Core's contributors wrote the position down in a signed statement on 6 June 2025: "Bitcoin is a network that is defined by its users, who have ultimate freedom in choosing what software they use (fully-validating or not) and implementing whatever policies they desire. Bitcoin Core contributors are not in a position to mandate what those are." The same statement notes their "long-running practice of avoiding auto-updating in the software", so that "no entity can unilaterally push out changes to Bitcoin Core users" (bitcoincore.org, 6 June 2025).
Node counts are the closest thing there is to a measurement of that choice, and they are a
poor one. User agent strings are self-reported, crawlers only see nodes that accept incoming
connections, and a node behind Tor or a firewall is invisible. With that stated: a Bitnodes
crawl timed at 09:26 UTC on 21 August 2026 reported 27,225 reachable nodes, of which 5,075,
or 18.6 percent, advertised a Bitcoin Knots user agent and 21,548 a Satoshi one
(bitnodes.io API, counted from the snapshot at that
timestamp). For direction over the dispute rather than a point in time, Bitfinex's research
blog reported on 5 September 2025 that Knots stood at "4,240 of 23,842 reachable nodes, or
about 17.78 percent", against "only 69 Knots nodes in January 2024"
(Bitfinex, 5 September 2025).
Whatever else that is, it is a lot of people making an explicit choice about software they
previously took as given.
What miners decide
Miners decide which valid chain to extend and which transactions go into their blocks. That is real power, it is exclusively theirs, and no node can override it. What it is not is authority over the rules.
BIP-110 is the cleanest demonstration available, because it tried to convert the first into the second and the machinery is all on the record. The proposal, "Reduced Data Temporary Softfork" by Dathon Ohm, used mandatory signalling: from block 961,632, a node running it would reject any block that did not set version bit 4, and the threshold for activation was 1,109 blocks out of 2,016. In the retarget period that ended at block 961,631, on the chain the pools were building, 51 of those 2,016 blocks set bit 4. That is 2.53 percent, counted from the block version fields returned by Blockstream's Esplora API on 21 August 2026. On 8 August the window opened, blocks arrived without the bit, nodes enforcing BIP-110 rejected them as invalid, and those nodes followed a different chain. The proposal was marked Closed in the BIP repository on 9 August with the changelog line "Mark as Closed, following a chain split with stalled mining" (bip-0110.mediawiki), and we covered the split itself at the time.
The accounts of what followed differ, and both are published. The BIP repository's status is "Closed". The BIP-110 project's own page says "Bitcoin is alive albeit low hash-powered after SHA256d mining pools quit the network" and that "new blocks are mined albeit at a slower rate than usual". The Knots announcement of 10 August describes an attack in progress and adds that "a new proof-of-work algorithm will be chosen on August 11th at 14:00 UTC" in a Discord channel; no further announcement had appeared on that feed as of 21 August 2026. This site is not going to tell you which of those framings is right. It will tell you that they are descriptions of two different block histories, and that nothing about the outcome is settled.
The transferable point is narrow and it cuts both ways. Miners could not make BIP-110 the rule by signalling for it, and they could not stop it either: the nodes that enforced it went on enforcing it against a chain with almost none of the hashrate. What miners determined was how fast each of the two chains would confirm anything, which is a question of usability rather than validity, and under the difficulty rule a minority chain has no quick way to fix it.
What developers decide, and what they do not
The live case is the OP_RETURN relay default.
Bitcoin Core merged pull request #32406 on 9
June 2025, and the change shipped in version 30.0: "-datacarriersize is increased to 100,000
by default, which effectively uncaps the limit (as the maximum transaction size limit will be
hit first). It can be overridden with -datacarriersize=83 to revert to the limit enforced
in previous versions"
(30.0 release notes).
We wrote up the merge and what it changed
separately; the short version is that the limit was always a rule about what a node passes
on, never about what a block may contain, and
the mempool piece has that distinction in full.
So what did the developers decide? They decided what their software does when you run it
without changing anything. That is a smaller thing than "what Bitcoin allows" and a much
larger thing than "nothing", because defaults are what almost everybody runs. They did not
decide what is valid: no consensus rule moved, and a transaction with a large OP_RETURN was
valid in a block before the merge and after it. They cannot push the change to anyone. And
they conspicuously did not decide the argument, which the statement itself says: it "is not
endorsing or condoning non-financial data usage".
The other half of the answer is Bitcoin Knots, which exists precisely because a default is
not a verdict. The project describes itself as "a derivative of Bitcoin Core with a
collection of improvements backported from, proposed for, and sometimes maintained outside of
the master git tree"
(release description, 29.4.knots20260508),
and its site names Luke Dashjr as lead maintainer and describes the software as a "Bitcoin
node and wallet in one" that "ensures bitcoins you receive are both real bitcoins and really
received as yours" (bitcoinknots.org). Its release notes carry a
section headed "New spam filters", and the 29.3.knots20260508 release, published 9 May 2026,
shipped BIP-110 behind an explicit consensusrules=rdts opt-in, describing it as an upgrade
"which fixes critical vulnerabilities in long-standing network design"
(Knots 29.3.knots20260508 release notes).
That is what having two implementations means. One of them changed a default; the other kept it, and then went further. Nobody had to be overruled for either to happen.
The two positions, at their strongest
This is a live disagreement between people who are still arguing, so here is each case as its advocates make it, in their own words.
Relay policy should be restrictive. Luke Dashjr replied to the proposal on the developer mailing list on 26 April 2025: "It should be needless to say, but this idea is utter insanity. Disappointing to see positive responses, and not one sensible reply calling it out yet. The bugs should be fixed, not the abuse embraced. If attackers continue to bypass filters, we can go back to a full whitelist approach. We're now 2+ years into this wave of attacks, and the damage it has already done should be more than enough to prove the hands-off attitude is not viable" (bitcoindev, 26 April 2025). BIP-110 makes the same case at the level of consensus: "in order to protect Bitcoin's intended function as the Internet's native money, the Bitcoin community has historically treated techniques for embedding arbitrary data into Bitcoin transactions with antagonism", and the proposal "aims to set Bitcoin back on the path to becoming the world's money by rejecting the standardization of data storage as a supported use case at the consensus level".
Put in a sentence a critic would have to answer: the costs of data storage land on people who never consented to carry it, every node operator stores and serves it forever, defaults are the network's real policy whatever the documentation says, and a filter that leaks is still a filter that raises the price of the behaviour it is aimed at. "It can be bypassed" is not an argument for removing it, or locks would be pointless.
Relay policy should not pretend to be consensus. Antoine Poinsot opened the thread on 17 April 2025 with the observation that the rule was producing the opposite of its intent: Clementine, a bridge design, "uses unspendable Taproot outputs to store data in its 'WatchtowerChallenge' transaction due to the standardness restrictions on the size of OP_RETURNs", and "we have witnessed in recent years that the nudge is ineffective to deter storing data onchain" (bitcoindev, 17 April 2025). The signed statement puts the systemic version: "knowingly refusing to relay transactions that miners would include in blocks anyway forces users into alternate communication channels", which pushes transaction submission into private arrangements with large miners and undermines both fee estimation and block propagation.
Put in a sentence its critics would have to answer: the filter did not stop the data, it
chose the format, and the format it pushed people into was an unspendable output that sits in
the UTXO set forever rather than an OP_RETURN that a node can discard. If a policy's effect
is to make the externality worse while its supporters point at its intent, intent is not the
thing to measure.
Both of those are serious. This site is not going to pick, and the reason is not diplomacy. It is that the question they disagree about, whether a node's relay defaults should try to shape what people do or try to predict what miners will mine, is genuinely unresolved by any fact currently available.
What exchanges and custodians decide
The most under-described lever. When a chain splits, somebody has to say what the thing in your account is called, and that decision is made by companies, in public, on a deadline.
Kraken's pre-fork notice for the 2018 Bitcoin Cash split, published 10 November 2018, is still the clearest statement of the mechanism: "Initially Kraken will only support Bitcoin ABC", and "After the fork, any BCH balances in your Kraken account will be tokens of the Bitcoin ABC network" (Kraken, 10 November 2018). Eight days later it listed the other chain too, under a separate ticker and a list of stated risks (Kraken, 18 November 2018). That episode is the subject of our piece on the hash war, and the relevant part here is that no miner and no developer made that call.
The same machinery ran again this month. Crypto Finance, writing on 3 August 2026 about BIP-110, framed the custodian problem in operational terms: "A custodian could therefore intend to process a withdrawal on its supported Bitcoin chain while unintentionally transferring the corresponding asset on the other branch", and listed what a split requires of a custodian, including "an assessment of whether replay protection exists" (Crypto Finance, 3 August 2026).
A ticker is not a truth claim, and it is not nothing either. It decides what most people can buy, sell, borrow against and price things in, which over time decides which chain has an economy. That is a form of power, held by parties nobody elected, and it is the part of Bitcoin governance least examined by the people who write about Bitcoin governance.
Where users sit
Not at the end of this list as an afterthought, and not at the top as a slogan either.
A user with coins on an exchange has delegated the whole question. A user running a node has made a choice about consensus rules whether or not they experienced it as one, because that is what installing an implementation is. Start9, which packages node software and shipped a BIP-110 activation task, put the position to its own customers about as squarely as it can be put: "This guide takes no position on which chain you should follow. That is a choice about consensus rules, and it is yours" (Start9, 5 August 2026).
The uncomfortable part is that most people do not want that choice, and there is no honest way to hand it back. The alternative to "you decide which rules your node enforces" is somebody deciding for you, and the entire design exists to prevent that. Knots' own release notes state the corollary bluntly from the other direction: skipping an upgrade "does not reject it", and "to effectively reject this upgrade, you need to run alternative software designed to split away from the upgraded network". Inaction is not neutrality. It is consent to whatever the software you are already running does next.
What is actually unresolved
As of 21 August 2026: OP_RETURN relay is uncapped by default in Bitcoin Core and capped by
default in Bitcoin Knots. Roughly one reachable node in five advertises Knots. BIP-110 is
marked Closed in the BIP repository and is described as active by the project that wrote it.
Two block histories exist above height 961,631 and each has software enforcing it. Nobody has
conceded anything.
Anyone telling you how this ends is guessing. What can be said without guessing is that the mechanism worked exactly as designed the whole way through: people who disagreed about the rules ran different software, and the disagreement became visible as two chains rather than as one side being made to comply. That is not a failure of governance. In a system with no one in charge, it is the only shape a real disagreement can take, and the cost of it is borne by whoever needs to know, this week, which chain their money is on.