The Bitcoin Improvement Proposal (BIP)-110 appeared to stall at the weekend, when the nodes that support the proposal broke away from the main network and produced the chain split people had been warning about — a tiny, stalled one.
The split came Saturday at block 961,632, when the proposal entered its mandatory signaling window. Nodes running BIP-110 software began rejecting any block that failed to signal support through version bit 4. When the first block at that height arrived without the signal, those nodes rejected it and peeled away onto a separate chain.
And it has gone almost nowhere since.
A pseudonymous mining group called Roughnecks produced both BIP-110 blocks — heights 961,632 and 961,633 — using Ocean’s DATUM protocol, then stopped. By Sunday afternoon the enforcing branch remained stuck at 961,633 while Bitcoin’s dominant chain had advanced to 961,744, a gap of 111 blocks and roughly 17 hours without a new block on the fork.
The support was never there. Only 51 of the 2,016 blocks in the preceding difficulty period signaled for the proposal, about 2.53%, against the 55% threshold needed for voluntary lock-in. Since the mandatory window opened, none of the first 113 blocks on the dominant chain have signaled.
Bitcoin’s difficulty adjustment compounds the problem. The fork inherited the main chain’s difficulty but commands a negligible share of hashpower, and cannot make mining easier until it completes a full 2,016-block period. Estimates of how long that would take range from under a year to decades, depending on the hashrate assumed.
BIP-110, formally the Reduced Data Temporary Softfork, would have capped arbitrary data in transactions for roughly a year, targeting Ordinals inscriptions and oversized OP_RETURN payloads.
Michael Saylor and Blockstream’s Adam Back both opposed it publicly, objecting less to the goal than to an activation method they argued invited exactly this outcome. Saylor wrote Sunday that Bitcoin had worked as designed, putting 99.85% of hashpower on the main chain.
Mining company Ocean, whose team supported the proposal, informed clients that some miners using Ocean’s Stratum templates may have believed they were mining on Bitcoin while their hashrate was directed to the new BIP-110 chain.
The company said it would reimburse miners affected with rewards they would have earned on the non-BIP-110 chain during that window.
Author’s note: In my view BIP110 is both useless and harmful, and I do expect it to fail (see scenario 1). Despite this I tried to write this article as factually as I could, entertaining different possible scenarios, as I do hope it may provide some clarity on this soft fork attempt.
The OP_RETURN debate has escalated to the point where Bitcoin Knots implemented BIP110: a consensus protocol change that temporarily limits the size of OP_RETURNs and intends to reduce other types of data on Bitcoin’s blockchain as well.
However BIP110 does not have consensus: not everyone agrees there’s a problem that requires solving in the first place, nor that BIP110 solves it in any meaningful manner, while it restricts Bitcoin in potentially harmful ways. Most obviously, Bitcoin Core — still by far the most-used Bitcoin implementation — has not adopted BIP110, while only some 1-2% of hash power has been signaling support for it in recent weeks.
Nevertheless, BIP110-nodes like Bitcoin Knots will soon — starting from block 961,632, to be mined on or around August 8 — reject blocks that don’t signal support for the upgrade.
Here are the three main scenarios for how that could play out.
Scenario 1: (almost) no miners signal
If current miner signaling is any indication, this is the scenario to expect.
From the perspective of anyone running Bitcoin Core or other non-BIP110 enforcing nodes and wallets (the vast majority of the Bitcoin ecosystem) blocks will be mined as usual, and transactions will be processed like normal too. Anyone who’s not actively tracking these events on social media or elsewhere may not even be aware that anything unusual is going on, and in a practical sense for them there really won’t be; BIP110 does not affect them.
The same is not true for anyone running Bitcoin Knots or other BIP110-enforcing nodes, however. Since their software will reject non-signaling blocks, they basically wouldn’t see any new blocks at all (or perhaps a few per week), and incoming and outgoing transactions won’t confirm (or incredibly slow). In practical terms, these nodes would stall and become unusable.
If this happens, BIP110 proponents will have to decide between waiting to see if things improve for them (see scenario 3), giving up (switching back to non-BIP110 software), or deploying a next protocol change, like hard forking to a different proof-of-work mining algorithm.
Such a hard fork would possibly allow for mining with GPUs again, therefore letting more people mine new blocks to generate a blockchain with the BIP110 rules enforced. However this would also mean that BIP110/hard fork nodes permanently split off from the rest of the Bitcoin ecosystem to essentially create a new cryptocurrency. (More on this below)
Scenario 2: (almost) all miners signal
This is the scenario several prominent BIP110 proponents predict.
In this scenario, when the mandatory signaling window starts, all miners will suddenly signal for BIP110. Or at least, a majority of miners will signal AND reject any non-signaling blocks, so that all blocks that end up in the blockchain include a BIP110 signal.
If this happens, all Bitcoin nodes (Knots and Core alike) remain compatible, and the signals in the blocks indicate that miners plan to start enforcing the BIP110 rules another two weeks later. BIP110-violating transactions should by early September no longer end up in blocks.
In essence, this is the success scenario for BIP110; although only a small faction of developers, miners and users pushed for it, the upgrade goes into effect across the entire network.
…However even in this scenario there is an important caveat.
Blockchain signaling is a useful coordination mechanism for soft fork deployment, but it technically does not guarantee that the new rules will be enforced. Miners can signal support for the upgrade without actually using BIP110 software, which they for example could elect to do simply to ensure their blocks aren’t rejected by Bitcoin Knots nodes during the mandatory signaling window.
Bitcoin’s protocol rules are ultimately enforced by economic nodes however, and nothing currently indicates that most of these will enforce the BIP110 rules even if all blocks include a signal. So if BIP110-violating transactions are later accepted by most miners regardless, these economic nodes would accept blocks that include them, while BIP110 nodes would not. The blockchain would split between nodes that do and do not enforce BIP110 after all.
Scenario 3: a sizable minority of miners signal
This is the scenario that would immediately split the chain.
Currently some two percent of miners signal support for BIP110, which is probably too little to be meaningful (see scenario 1). But let’s imagine this quickly increases tenfold or so. We also have to imagine that this sizable minority itself rejects any non-signaling blocks— else it would still be indistinguishable from scenario 1 where BIP110 nodes stall (since they require ALL blocks to include a signal).
If the sizable minority is both signaling and rejecting non-signaling blocks, they’d start to build their own minority blockchain with only signaling blocks in it. Blocks on this minority chain would confirm significantly slower than usual — maybe just one or two per hour — but BIP110 nodes remain reasonably usable. And after a few months the mining difficulty would adjust, so blocks are found (closer to) six times per hour again. Another couple of weeks later the BIP110 rules would go into effect.
Meanwhile, Bitcoin Core and other non-BIP110 enforcing nodes would still operate fairly normally as well. Their blocks will confirm a little bit slower for a while — maybe about four or five per hour — but after a couple weeks mining difficulty adjusts here too, to also bring this back to six per hour on average. The BIP110 rules would never go into effect on this blockchain.
As a result, a BIP110 blockchain and a blockchain with the original rules would then exist side by side as two different cryptocurrencies, indefinitely.
There is one notable caveat to this scenario as well, however. If the BIP110 chain were to overtake the original chain in length later on (due to miners moving to the BIP110 chain), all nodes — Core and Knots alike — would accept the BIP110 chain as the only chain. The original chain would in this case be discarded, or wiped out.
This one-sided wipe out risk is in fact why BIP110 proponents expect all miners to signal preemptively, preventing a split. Miners won’t want to mine on a blockchain that can later be discarded, they argue, as that would also mean losing all block rewards they earned on it.
In actuality, users and miners that want to prevent that the original chain can get wiped out could do so however: they can manually invalidate any block on the minority BIP110 chain while it still is the minority chain. This way their nodes would reject switching to it even if it becomes longer at any point in the future, making the split permanent also.
So what exactly happens if the chain permanently splits? If and when the Bitcoin blockchain permanently splits, it essentially marks the creation of a new cryptocurrency, or forkcoin. Everyone who owns BTC at the time of the split automatically receives the equivalent amount of coins on the new blockchain, not unlike what happened with Bitcoin and Bitcoin Cash in 2017.
However in reality these things aren’t necessarily as straightforward, and if BIP110 does cause a chain split under any of the scenarios above there will likely be some complications.
For one, there’ll almost certainly be disagreement over which side of the chain represents “Bitcoin” (“BTC”), and which side is the new forkcoin. It seems likely however that the blockchain with the original rules will by most people be considered “Bitcoin”, whereas the blockchain with the BIP110 rules will be called something else; we’ll call it “BIP110 coin” for now.
Accessing the BIP110 coins then, will require BIP110-specific software like, indeed, Bitcoin Knots. The new coins won’t show up on Bitcoin Core nodes or most wallets.
However, BIP110 does not currently include replay protection. This means that transactions on one chain can be copied (“replayed”) on the other chain. Instead of just sending BTC, users could unknowingly also send the equivalent BIP110 coin to an identical address on the BIP110 chain— or vice versa.
It’s difficult to estimate at this point how much the forkcoins will be worth, or even if they will be worth anything at all. The lack of interest in buying BIP110 coins via fork future contracts does suggest there may not be much interest to buy them after a split either. But if you nevertheless want to be sure you’ll receive BIP110 coins if there are any, it’s probably best to self-custody your BTC (have access to your private keys), and don’t send any transactions until the dust settles and there is more clarity on how to proceed.
I scanned the Bitcoin blockchain for images; what I found will shock you. Much has been said online about the arbitrary data and content that can be found on the Bitcoin blockchain. Not only has this possibility spawned a niche art scene, but it has also led to a movement against ‘non-monetary transactions’ on the Bitcoin network. Were you to hear from one of its proponents or detractors, you’d figure the blockchain is basically a wall filled with graffiti.
Well, I decided to put the question to the test: are there actually images on the blockchain? And what does this actually mean for Bitcoiners simply trying to run their own full node and maximize their financial sovereignty?
My methodology was simple: I was to buy a fresh hard drive to store the blockchain on, and then I was going to run classic image recovery software over the data, something used to rescue images from broken hard drives, something designed to find raw image data.
I chose PhotoRec to do the image recovery work, an open source image recovery program that’s been around for over 20 years. The software is designed to find image files in raw data. This can be used to recover images and other file formats from hard drives that have failed or been corrupted. It is actually often used to recover lost wallet.dat files from the early days of Bitcoin wallets, before the proliferation of the seed word format.
Syncing The Full Bitcoin Node
For storage of the full Bitcoin blockchain, I decided to buy a 4-terabyte disk drive for a couple hundred dollars. I then installed the latest version of Bitcoin Core on it and started to sync the chain. The process, which involves downloading and verifying the accounting integrity of all transactions in Bitcoin history, took about 72 hours or three days, automated and running in the background by the Bitcoin Core software.
I did this with an otherwise powerful gaming machine; the main bottleneck in terms of time was the disk drive, which is slow to read and write data as needed when syncing Bitcoin’s blockchain. The slow part of the process involves the unspent transaction output set, or UTXO. When a user syncs the blockchain, every unspent transaction value (output) or positive balance is organized into the UTXO set, and as those values are spent, they are removed from the set, while the new address to which those satoshi were sent is added.
On the disk drive, this UTXO indexing process could have taken three weeks according to some estimates, so to speed it up, my clanker (AI agent) suggested we index the data in RAM instead, then move the data back to the 4-terabyte disk drive. While the whole process took three days, running in the background, an SSD could have done the whole job in about a day. SSD drives are much faster than disk drives; they are more modern, but they are also easily four times the price, or more.
Once the blockchain was fully downloaded and validated, we moved the UTXO index from RAM back to the disk and booted the Bitcoin software; the chain was fully synced and the wallet ready to go. Now it was time for the next step: recovering the images stored on the blockchain.
Image Recovery on the Blockchain with PhotoRec
With the full Bitcoin blockchain on my disk drive, I turned off Bitcoin Core and asked my clanker (Cursor AI agent) to run PhotoRec 7.2 on the drive. The default PhotoRec process looks for jpg, png, gif, tif, bmp, ico, psd, and raw formats. The process ran for over 11 hours on the blockchain data and ultimately found … (drum roll) … nothing.
Over a terabyte of blockchain data and half a day of scanning and no images turned up. The PhotoRec wiki page gives a simple example of how the software works: “PhotoRec identifies a JPEG file when a block begins with: 0xff, 0xd8, 0xff, 0xe0, 0xff, 0xd8, 0xff, 0xe1, or 0xff, 0xd8, 0xff, 0xfe.” In other words, the program looks at the data on the disk for bytes that signal that there’s an image file.
The program is capable of false positives; it saved 8 ICOs and 4 identical PNG files that don’t show any images when opened, as seen in the picture below. So, effectively no meaningful images of any kind were found.
Where Did the Jpegs Go? XOR Magic Tricks
How is this possible? For years, crypto people have been talking about NFTs and how to engrave image data on the Bitcoin blockchain. Millions of dollars have moved in this niche, and a whole culture war is being fought on the matter as we speak. Can there really be no images on the chain?
Turns out the risks involved with arbitrary data have been discussed and planned for in Bitcoin Core development circles for a long time, as early as 2011. XOR, a simple data obfuscation technique, is used to scramble all the blockchain data while it is at rest on a hard drive.
You might have heard that the fundamental language of computers is made up of 0’s and 1’s. Well, in a nutshell, XOR compares two digits or bits and returns 1 if the bits are different or 0 if the bits are the same. In the case of Bitcoin, XOR compares every bit of the blockchain data to a random key generated during initial install, resulting in data at rest that other programs can find no meaning in. However, when the Bitcoin software runs, it has the key to unscramble that data and use it at will. XOR is also very fast, so it does not meaningfully impact performance. Here’s an example of the Bitcoin genesis block before and after an XOR.
XOR is currently applied to both the blockchain data and the UTXO set. XOR was initially discussed in 2014 when anti-virus software started getting tripped up by blockchain data it interpreted as virus code. The anti-virus software would then quarantine a block, corrupting the blockchain data and crashing Bitcoin, making sync impossible. By the end of 2015, XOR had been implemented on the UTXO set data at rest and in 2024 it was implemented on all blockchain data at rest.
Incidentally, the XOR process means that no arbitrary data can be identified or extracted from the blockchain without intentionally bypassing the XOR, a process that is not necessary for monetary use of Bitcoin. Since the Bitcoin Core software keeps a simple database of the location of each scrambled block, it can get its data, unscramble it and use it in a targeted manner easily.
Syncing Bitcoin in an unscrambled way is a custom process that can take as much time as syncing from scratch, since it basically has to re-write the full terabyte of data in a new order, and there’s not much point in that for someone that just wants the normal privacy and security benefits of running a Bitcoin node. So when it comes to the vast majority of copies of the Bitcoin blockchain data, resting on the computers of normal Bitcoiners throughout the world, there’s effectively no arbitrary data or images that can be identified. Shocking, I know. Feel free to run the PhotoRec test yourself on your own node!
Login
