While not mentioned in the BIP proposal, BIP-110 nodes' networking code heavily prefers to connect to BIP-110 nodes exclusively:

  // BIP-110: Allow up to 2 non-BIP110 outbound peers.
        if (pfrom.ExpectServicesFromConn() && !(nServices & NODE_REDUCED_DATA)) {
            if (m_num_non_bip110_outbound >= 2) {
                LogDebug(BCLog::NET, "peer lacks NODE_REDUCED_DATA and already have 2 non-BIP110 outbound peers, %s\n",
                         pfrom.DisconnectMsg(fLogIPs));
                pfrom.fDisconnect = true;
                return;
            }
            ++m_num_non_bip110_outbound;
            pfrom.m_is_non_bip110_outbound = true;
            LogDebug(BCLog::NET, "connected to non-BIP110 outbound peer (%d/2), %s\n",
                     m_num_non_bip110_outbound.load(), pfrom.ConnectionTypeAsString());
        }

....

// Count the number of BIP110 full-relay peers we have (excludes non-BIP110 peers).
int GetBIP110FullOutboundConnCount() const;


....

// Non-BIP110 outbound peers are "additional" - don't count toward limits
if (pnode->IsFullOutboundConn() && !pnode->m_is_non_bip110_outbound) nOutboundFullRelay++;

BIP-110 nodes aggressively attempt to connect to 8 outbound BIP-110 nodes using normal Core rules, and only connect to 0-2 non-BIP-110 nodes as an optional "sidecar".

The net result is that BIP-110 nodes barely participate in the wider network; from the beginning they formed their own network that is sparsely connected to Core nodes.

The original networking code was even more aggressive; the outbound sidecar was added only after BIP-110 nodes were having trouble being connected at all, and inbound connections could not sustain them.

There's only one reason to do this: if you assume you're going to be the minority in a partition. This helps defend against eclipse attacks and stranded nodes in the event that a split/partition happens, and you are on the losing side.

This is actively harmful if you expect to be the winner though: partitioning off your nodes into a big ball doesn't do anything to pressure Core if you have majority support. And it's pointless before flag day.

The BIP-110 networking code gives away the author's true beliefs: BIP-110 would fail to attain a majority in hash or nodes, and would fork off.

When Satoshi published the original implementation of Bitcoin in 2009, it did use block height (count of blocks from genesis to tip) to determine which chain was the main chain. The whitepaper mentioned the "longest" chain.

However, within about a year and a half people realized that this could be exploited to quickly create a new longer chain, but with a small fraction of the compute it took to generate the current main chain. So in July 2010 "accumulated chainwork" became the new consensus standard for determining which chain was the main chain.

Exploiting Block Height

Before I explain accumulated chainwork, you might be wondering "what do you mean it can be exploited?!"

I was curious too, so I put together a simulation to see just what it would take to rebuild a new blockchain from the genesis block. It turns out that 0.1 EH/s or about $1.5 million in ASICs and ~2 weeks of hashing is enough to rebuild your very own consensus-valid chain from genesis, with a longer block-height than the current main chain, with the public tip being stamped with the appropriate epoch.

How? Well, there are a few important things to know:

1. Nodes only care that the blockchain tip isn't more than 2 hours into the future, and that any given block is no earlier than the median of the previous 11 blocks. Blocks don't even have to be in time-order to be consensus valid. You can instantly mine against the Genesis block, when difficulty was the lowest possible (1), but stamp each block as if they were exactly 10 minutes apart (thus keeping the difficulty low).
2. In 2009, the chain was on-average significantly slower than 10 minutes per block. That means that a modern ASIC farm can nearly instantly recreate that first year, pretending that it was mining at an even 10 minutes per block, and come into "2010" almost 20,000 blocks ahead of the real blockchain in terms of height, but still at 1 difficulty.
3. After that point, the modern chain starts to mine slightly ahead of 10 minutes per block, continuing to the present day. The attacker needs to start pretending that its blocks are being mined faster than every 10 minutes to be able to catch up to the existing chain, which increases difficulty and slows the attacker down. However, it still takes it far less than 10 minutes to create each new block, and eventually (like I said earlier, in about two weeks) the attacker chain has surpassed the real chain in block-height: a consensus-valid alternate history of Bitcoin.

Chainwork

So as you can see, block height is trivially exploited by a modestly financed attacker. Chainwork, on the other hand, completely foils this attack.

The key to the block height attack is that the attacker has calibrated their alternate chain so that the difficulty of each block stays as low as possible for as long as possible. The actual amount of total hashing work that went into their chain is a minuscule fraction of what went into the real chain. With chainwork, the difficulty each block was mined at is taken into account and added up across the entire chain, rather than just the number of blocks.

That takes us back to the beginning: When difficulty drops on an alternate chain, it may start producing blocks four times more quickly, but it's also getting 1/4th the credit. Difficulty doesn't save a minority fork; it's falling just as far behind as it was before a difficulty retarget.

I've been working with Opus on a web app for a word game, and recently I've been trying to get a rating on how obscure various words are (not by Claude itself, through existing corpuses). Based on the following interaction, I realized that Opus has absolutely no clue what's normal vocabulary for a human:

>You're right, and the diagnosis is straightforward: Zipf measures production frequency (how often people write/say words), but what you actually want is recognition / familiarity (do most adults know what this word means). Those diverge dramatically for:

>Recognized but rarely written: STETHOSCOPE, CAMPANILE, AGAVE — kindergarten-grade nouns for things adults rarely type about.

>Plurals/inflections of familiar words: PLAYBILLS, GROTTOES, CRUNCHES — the singular is everyday, the plural form barely shows up.

>Domain words people know but don't use: OXTAIL, RHYOLITE, MIMULUS — gardening, geology, biology common-knowledge.

>wordfreq's corpus (Wikipedia + news + subtitles + Reddit + Twitter) is heavily slanted toward modern internet/news prose. It systematically underweights "things you learned in school but don't post about."

By any objective metric, BIP-110 is dead. I feel like the people here have to understand that at some level.

Segwit had a more coherent narrative and technical chops behind it than BIP-110, and it still needed a heroic political effort culminating in the New York Agreement and BIP-91 lowering the activation threshold to get it over the finish line.

BIP-110 doesn't have any of that.

It's not hard to connect the dots that this is entirely a Luke project, given that:

September 2025: Texts from Luke leak where he is worried about CSAM, and talking about a fork.

October -> December 2025: An anonymous developer proposes a BIP that, in their own words, targets CSAM. The proposal credits Luke at the bottom.

January 2026 -> The anonymous developer PRs straight to Luke's Github and Luke's node implementation. When I looked at the PR review, I didn't see this developer push back on any of Luke's suggested changes.

There's essentially no daylight between the anonymous dev and Luke on twitter. This dev's twitter account has no history and appears to solely exist to advocate for BIP-110 and agree with Luke.

Why even bother with the anonymity? To actually do the political work necessary to get this across the finish line, BIP-110 needed more public figures with actual influence to get consensus from miners and exchanges. Instead you have Luke, Luke's anonymous sock puppet, and a handful of Twitter and Youtube personalities who are just using this for a following and content. Nobody is seriously getting Coinbase and FoundryUSA in a room together to agree to signal for this, so this isn't a serious project.

Whether you like it or not, Core is undefeated. Overcoming them required more than code, hubris, and tweets.

A couple days ago it was at 29%, so this implies that 27,000 nodes disappeared overnight.