About 10 months ago, I wrote here about the dispute between Bitcoin Core and Knots. Back then, it was mainly an open back-and-forth between many Bitcoiners on X (https://getqu.in/bLMDbe/)
That has changed. The conflict may have first emerged on Block 961,632 . $BTC (-2,82%) . That’s why I thought I’d check in again and give you an update🫡
According to current estimates, depending on the block generation rate, we’ll reach this block height sometime between August 7 and 9—in just over a week.
But what exactly will happen then?
Online, the dispute between the two sides is escalating. One side wants to save Bitcoin; the other says someone is trying to hijack the network... Specifically, it’s about a “Bitcoin Improvement Proposal”—namely BIP-110—that aims to force a temporary soft fork.
What BIP-110 Aims to Do
The policy dispute over OP_RETURN (feel free to reread my old post on the subject) has turned into a proposal for a genuine consensus change. Officially, it’s called the “Reduced Data Temporary Soft Fork", or BIP-110 for short. It initially circulated as BIP-444. It was authored under the pseudonym “Dathon Ohm,” and the original draft is attributed to Luke Dashjr.
At its core are seven additional rules that will be in effect for one year and then automatically expire. I’ll spare you the specifics of the rules. Essentially, the first four rules are intended to cap the amount of data that can be included in various parts of a transaction, and the last three close loopholes that are actually reserved for future Bitcoin upgrades but are currently used primarily for data smuggling.
Normally, soft forks are implemented via a so-called miner signal with a 95% threshold.
Such forks can always become dangerous when there are several camps of nearly equal size. That’s why a 95% threshold has always been used in the past, to ensure that such rule changes are implemented only when the overwhelming majority votes in favor.
BUT BIP-110 takes a different approach. The threshold is only 55%.
And that’s not all. If the 55% threshold is not reached, a cutoff date automatically takes effect: Block 961,632
Miners can set a specific bit (bit 4) in Bitcoin blocks to signal that they support BIP-110 (Every block has a 32-bit version field in its header—essentially 32 switches. A few of these are unused and have been used as voting boxes for years.)
Starting with this block, nodes implementing BIP-110 will reject any block that does not have version bit 4 set.
And that’s exactly where the problem lies. Starting with block 961,632, BIP-110 nodes will reject any block that lacks this checkmark—even if everything else in the block is correct. A block full of perfectly normal transactions is rejected simply because a checkbox wasn’t checked.
The seven rule changes for BIP-110 nodes will then be automatically activated starting with block 965,664.
What’s the current situation?
Modest.
Signaling stands at around 1 to 3%. Virtually all signaling blocks come from Ocean, whose CTO is Luke Dashjr himself and which has been signaling by default since July 15.
Foundry USA, the largest pool with about a quarter of the hashrate, allows its customers to vote on a hashrate-weighted basis. The default position is “No”; non-responses count as “No,” and Foundry would only change its stance if approval reaches 51%. Voting runs through block 961,632. This is the only realistic chance for the situation to still turn around.
Things are getting confusing on the node side. Depending on the measurement method, Knots runs on 8 to 23% of the reachable nodes. But Knots is not the same as BIP-110: Only about 2 to 8% are actually running a version that enforces the soft fork.
What is a soft fork?
A soft fork tightens the rules: Any block that is valid under BIP-110 rules is also valid under the old rules. So old nodes accept the new blocks without issue. A hard fork, on the other hand, would expand the rules, causing old nodes to reject the new blocks.
The punchline here is that, despite the soft fork, a chain split could still occur. So in the end, we might end up with two cryptocurrencies after all: Bitcoin and Luke-Coin… or something like that😅
Core nodes do not reject blocks from the BIP-110 chain because they are completely valid under the old rules. The reverse, however, is true. So it’s not the old side that splits off, but the new one. This means two different data states would develop side by side. If Ocean, for example, continues mining with its 3% hashrate, it will occasionally find a new block after a few hours of idle time. In doing so, it will naturally drift further and further away from the Core data state.
This raises the question, however, of whether—and how many—miners would actually mine BIP-110 blocks. Miners have an incentive to stay with the network that has the most hashrate. The other chain would, in principle, create a different coin that would likely be worthless compared to Bitcoin. And why would miners switch to the network with lower security, where the return is very likely to be many times lower?
It would be funny, though, if Luke and Ocean just went ahead and mined BIP-110 blocks out of the blue, creating a new coin in the process😂
What happens if BIP-110 miraculously reaches 55%?
Miners could continue to mine blocks that are invalid from a BIP-110 perspective. However, the BIP 110 nodes would then reject these blocks, and the BIP 110 miners would continue from the last valid block and, with the majority of the hashrate, inevitably create the longer—and thus valid—chain. This would allow the 55% of BIP 110 miners to impose their will on the other 45%. The 45% would then also have to follow the BIP 110 rules in order to include valid blocks and receive the block reward. Given the current maximum of 3% miner signaling, however, this is absolutely utopian.
Why am I telling you this now, when it’s highly unlikely that anything will actually happen?
Because it’s important to understand how such soft forks unfold and function. To prevent panic from breaking out when such reports surface, it’s important to at least have a basic understanding of the underlying mechanisms.
In my view, Bitcoin already has sufficient spam protection built in:
Transaction fees.
If someone wants to clutter the blockchain with meaningless junk, they have to pay for it—in extreme cases, until they run out of money. OP_RETURN is a separate area that has nothing to do with the UTXO set of transactions. It’s essentially an appendix that isn’t required for the payments themselves. All transactions are valid even without OP_RETURN.
And Peter Todd has shown that you can’t prevent spam one way or another. He actually packed the entire BIP-110 paper into a BIP-110-valid transaction and demonstrated how to circumvent the rules🤷♂️
Have a great evening, everyone!
