On August 8th, 2026, Bitcoin block 961632 was mined. This marked the start of the “mandatory signaling” for BIP-110, which meant all blocks not signaling on version bit 4 would be rejected by a node implementing BIP-110. This resulted in a fork, which I livestreamed by showing a modified version of my fork.observer.

While it wasn’t clear if there would be blocks found on the BIP-110 side of the fork, it was expected that the BIP-110-enforcing nodes would consider non-signaling blocks as invalid. Nodes without BIP-110 would continue as normal, while BIP-110-implementing nodes would be stuck.

Monitoring setup

To show this, I connected more than 50 nodes to my fork-observer instance. These included a mix of Bitcoin Core nodes I run, publicly reachable Electrum servers, official and community-run mempool-space instances, a btcd node, a floresta node, as well as a block-dn instance. I connected to a stratum job data feed to show which chain tips mining pools are building on top of.

Getting there took some preparation. In the months before the fork, I worked through a few features that had been on my fork-observer wishlist: support for mempool-space and block-dn backends, the ability to combine multiple fork-observer instances into a single reference instance with good fork coverage, and faster tip notifications from Bitcoin Core nodes.

The fork

The blocks leading up to block 961632 came in fast and the fork happened earlier than anticipated.

• 19:33 UTC: the last shared block, 961631, was found.
• 19:36 UTC: the non-BIP-110-signaling block 961632 was found.
• 20:12 UTC: to the surprise of many, BIP-110 miners found a signaling block 961632. This forked the chain.
• 20:19 UTC: F2Pool found 961633 on the non-signaling chain.
• 20:30 UTC: a non-BIP-110-signaling Ocean miner found 961634. The non-signaling chain was two blocks in the lead.
• 21:49 UTC: the signaling chain found its block 961633. By then, the non-signaling tip had extended to 961638.

As of August 11th, the non-signaling chain leads with more than 400 blocks and the signaling chain hasn’t found another block. The network has rejected BIP-110.

My livestream and fork-observer attracted people from both sides of the fork. The tooling is inherently neutral and just visualizes what’s happening across different node implementations. I saw countless screenshots of fork-observer helping people understand what’s going on and saw it being used in other livestreams too (one, another). I’m happy to see that it’s a useful tool.

Sergi enjoying una buena noche.

@tatumturnup monitoring the situation.

Ocean using the 'trippy-space' fork-observer theme.

@btcbenchmark doesn't know about dark mode.

Alex Waltz watching the stream.

Running out of web server workers

However, I wasn’t prepared for the amount of traffic I was getting. Since each browser tab with a fork-observer page open maintains a Server-Sent Events (SSE) connection to my server, my web server ran out of workers to handle these. This led to new visitors getting a 500 Internal Server Error message. While I was trying to put out fires during the stream, for example by adding caching for some of the static assets, I didn’t manage to find the right fix during the stream. I’ve now spent some time investigating and improving, and think it should handle the next big wave of traffic better. Sorry to everyone who got a 500 Internal Server Error.

I’ve seen some other tools that monitored the fork too. I’m very happy to see competition in monitoring tools and look forward to seeing which of these will stick around. Competition fosters innovation.

Recordings

I livestreamed the fork on X and YouTube. For both, recordings are available.

I also have a faster replay of the BIP-110 fork at height 961632.

With the BIP-110 fork being rejected by the network, I hope this allows us to focus on improving other parts of Bitcoin again. I think monitoring network behavior and forks like these is important, but the whole BIP-110 topic has consumed enough time and energy already.