Bitcoin Magazine

Bitcoin’s BIP110 Moment: Three Possible Scenarios

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.

Aaron van Wirdum is the former Editor-in-Chief of Bitcoin Magazine and author of The Genesis Book: The Story of the People and Projects That Inspired Bitcoin. Follow him on Nostr.

This post Bitcoin’s BIP110 Moment: Three Possible Scenarios first appeared on Bitcoin Magazine and is written by Aaron van Wirdum.

Bitcoin Magazine

Corporation’s Approach to the BIP-110 Soft Fork

BIP-110 is approaching its first consequential activation boundary. The proposal enters mandatory signaling at block 961,632, currently projected around August 9, 2026. It locks in no later than block 963,648, roughly in late August, and activates its new transaction rules at block 965,664, currently projected for early September. BIP-110 uses a 55% signaling threshold and would enforce its restrictions for 52,416 blocks, approximately one year.

Bitcoin resolves consensus changes through coordination among miners, users, and nodes (note that anyone can be any combination of these three things). Miners choose which valid chain to extend. Users decide which chain’s coins, deposits, and payments they recognize. Nodes independently choose which rules they enforce. Durable consensus emerges whenever these groups converge on the same chain.

BIP-110 restricts large data pushes, oversized output scripts, undefined witness versions, Taproot annexes, deep Taproot control blocks, OP_SUCCESS opcodes, and certain Tapscript conditionals. It grandfathers UTXOs created before activation, while standard monetary uses remain compatible with its rules.

Most corporations don’t have to do anything 

For most corporations, BIP-110 requires no action. Today, the typical corporate Bitcoin utility is as a store of value, as a long-duration treasury reserve asset. This use case is basically unaffected by the transaction features targeted by BIP-110.

Corporations using Bitcoin for payments also face limited direct impact. Standard on-chain payments remain compatible (see below for specifics), while ordinary Lightning payments occur off-chain. A chain split can still affect Lightning channel monitoring, force-close behavior, and the chain source that a Lightning node treats as authoritative. However, even corporations using Bitcoin for payments normally use a third party provider like Square, so all of this abstracted away to be a non-issue. 

A corporation that runs its own full node has a direct choice. Every user retains the right to run the Bitcoin implementation that matches its needs. A corporation that supports BIP-110 should therefore switch over to running BIP-110. All other node-running corporations can simply do nothing. 

A BIP-110 node enforces tighter rules. During mandatory signaling, it rejects blocks that fail to signal bit 4. After activation, it also rejects blocks containing transactions that violate BIP-110. A non-BIP-110 node accepts BIP-110-compliant blocks as well as blocks that remain valid under the existing rules. Among all chains valid under its own rules, a node follows the branch with the greatest accumulated proof of work.

So the key factor to be aware of is a chain split. When miners build a chain that is not compliant to the BIP, BIP-110 nodes can separate from the broader network. Non-BIP-110 nodes may continue following the higher-work branch, while BIP-110 nodes could remain on a compliant branch with less accumulated work. 

Corporations dealing with chain splits 

Mining companies face the highest immediate economic exposure. Electricity and machine time are sunk costs. A miner should select the branch it expects other miners, nodes, and users to recognize and mine on it. A miner may also stop mining and wait for the chain split to resolve. If BIP-110 and non-BIP-110 chains develop independently, miners must track chainwork, signaling, validity under both rule sets, and their own mining pool’s stance, and the market value assigned to each branch.

Corporations operating exchanges and institutional custody should prepare for settlement uncertainty. During an extended split, the ordinary six-confirmation standard loses much of its value because each branch can show six confirmations independently. Operators should monitor both branches, raise confirmation requirements, pause large deposits or withdrawals when risk rises, and delay final settlement until one branch has decisively accumulated more work or the transaction has sufficient depth on all viable branches. Different validation rules can produce chain splits, false confirmations, and double-spend risk.

Let’s consider a chain split occurring at block height S. 

Suppose a deposit appears on Chain A at S+4 and on Chain B at S+6. Once both chains reach S+12, the deposit has substantial depth on each branch (assuming we are still using six-confirmations). Now, this number of six confirmations should change depending on the work on each branch. And it might be the case that the number of confirmations one would like to see would be different for each branch. The main point is that the operator must wait until both branches reach the requisite confirmations. The operator can at that point be confident that the transaction remains, not matter which branch becomes canonical.

If the transaction appears on only one branch, the operator should wait for that branch to win or apply chain-specific accounting. That would be the only way to ensure no double spending happens. In practice, monetary transactions should always eventually appear on both branches, since the BIP-110 chain does not prohibit monetary transactions.

Conclusion 

The main thing to be aware of is a chain split. If there is no split, then there is nothing that needs to be done differently. Even with a chain split, BIP-110 will not create insurmountable disruptions. 

For corporations that may be impacted by a chain split, the main action to take is to lengthen confirmation times and monitor both branches. For node-running corporations that support the BIP, the main action is to start running it on their nodes, if they haven’t already. 

Miners, as usual, should direct their hashrate based on their view of which branch will end up with the most accumulated proof of work. Exchanges and custodians should lengthen settlement procedures and maintain visibility into both chains, should a chain split occur. For the daily operations of most corporate Bitcoin users, BIP-110 changes very little, if it changes anything at all. 

Disclaimer: This content was prepared on behalf of Bitcoin For Corporations for informational purposes only. It reflects the author’s own analysis and opinion and should not be relied upon as investment advice. Nothing in this article constitutes an offer, invitation, or solicitation to purchase, sell, or subscribe for any security or financial product.

This post Corporation’s Approach to the BIP-110 Soft Fork first appeared on Bitcoin Magazine and is written by Allard Peng.

Bitcoin Magazine

I Scanned the Entire Bitcoin Blockchain for Images. What I Found Will Shock You

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!

This post I Scanned the Entire Bitcoin Blockchain for Images. What I Found Will Shock You first appeared on Bitcoin Magazine and is written by Juan Galt.