Bitcoin has a date with block 961,632 in early August. That is when BIP110, the most contested soft fork proposal in years, enters its forced activation window whether miners support it or not.

We took a close look at what that means for the Lightning Network. The short version: the proposed rules change nothing for Lightning as it runs today. The activation mechanism is the part worth preparing for.

The rules do not touch LightningThe rules do not touch Lightning

BIP110, the Reduced Data Temporary Softfork, would tighten Bitcoin's consensus rules for roughly one year to limit arbitrary data storage in transactions. New output scripts would be capped at 34 bytes, OP_RETURN data at 83 bytes, and data pushes at 256 bytes. The stated goal is to curb inscriptions and other non-payment data.

Measure Lightning against those caps and nothing breaks:

1. Channel funding and commitment outputs are exactly 34 bytes, precisely the proposed cap. This is defined in BOLT 3, the Lightning commitment transaction specification.
2. The largest routine channel scripts, the HTLC scripts that secure in-flight payments, come in under 150 bytes. That is far below the 256-byte push limit.
3. Channels use witness version 0 and taproot, the only two versions BIP110 leaves spendable.
4. Coins created before activation are exempt from the new spending rules entirely, so existing channels can force close normally under either outcome.

Every transaction type a standard Lightning channel puts on-chain fits inside BIP110's limits. Anyone telling you the proposal breaks Lightning payments has not read the spec against BOLT 3.

The activation mechanism is another storyThe activation mechanism is another story

Past soft forks required overwhelming miner support and failed gracefully without it. BIP110 works differently. It activates early if 55% of blocks in a single difficulty period signal support: 1,109 of 2,016 blocks. If that never happens, a mandatory signaling phase begins at block 961,632 anyway, guaranteeing lock-in, with enforcement starting roughly two weeks later.

There is no failure state. That is the design choice everything else hangs on.

The current numbers make network-wide activation a long shot. Jason Hughes, an early Bitcoin miner writing under @wk057, reviewed the signaling data: 0.6% of blocks signaled support over the past 60 days, while somewhere between 7 and 15% of reachable nodes signal it. He put the odds of success at less than 5%. Bitcoin Core, the software most of the network runs, does not enforce the rules at all.

Hughes also challenged the premise itself: "Byte-for-byte the same contiguous arbitrary data can provably end up stored in the current chain or the BIP-110 chain."

Why Lightning operators should still pay attentionWhy Lightning operators should still pay attention

Low support does not reduce the flag-day risk to zero. Because enforcing nodes reject non-compliant blocks outright after the mandatory phase begins, even a small enforcing minority can briefly maintain a separate chain.

Lightning is uniquely sensitive to that. Its security model assumes your node can see the Bitcoin blockchain. If a counterparty broadcasts an outdated channel state, you have a limited window to respond with a penalty transaction. During a chain split, a node watching the losing chain never sees a theft attempt on the winning one. The response window can expire unanswered.

The severity spans a range. At current support levels the likeliest outcome is a fizzle: a handful of enforcing nodes stop following the majority chain and their view of Bitcoin simply stalls. With meaningful enforcing hashrate, a minority chain could persist for days.

Either way, one detail matters more than any prediction: a Lightning node never picks a chain itself. It inherits its view from the Bitcoin backend it runs on. The software underneath your Lightning node decides which side of a split you experience.

Routing operators are already positioning. Lightning Network Liquidity put it plainly in its transition statement: "As a routing node, we aren't voting; we are positioning ourselves where we believe the economic gravity is strongest."

The preparation checklistThe preparation checklist

For most businesses and node operators, preparing costs almost nothing:

1. Do not mass-close channels. Pre-activation coins are grandfathered, and closing creates on-chain transactions during exactly the window you want to avoid them.
2. Avoid opening or splicing channels from shortly before block 961,632 until well past activation.
3. Require extra confirmations for on-chain deposits around the window, since a split elevates reorg and double-spend risk.
4. Confirm which rules your Bitcoin backend enforces, and check that your channel counterparties and watchtower follow the same chain.
5. Keep your node online. Going dark voluntarily disables your own breach detection exactly when response windows matter most.
6. Hold an on-chain fee reserve so an emergency force close can confirm if fees spike.
7. Keep normal Lightning payments flowing. Off-chain payments never touch the chain and carry the least fork exposure of any Bitcoin transaction type.

Where this landsWhere this lands

BIP110 will most likely pass into Bitcoin history as a governance argument rather than a consensus change. But the days around block 961,632 deserve the same operational caution exchanges apply to any contested fork: fewer irreversible actions, more confirmations, closer monitoring.

If you run payment volume on Lightning through a managed provider, most of that checklist is your provider's job. That is how we think about it at Amboss: consensus events should reach our customers as a status update, not an engineering project.

The full analysis, including the spec-by-spec comparison against BOLT 3 and live network monitoring resources https://amboss.tech/blog/bip110-lightning-network

I found the full article (the link above) pretty helpful. It has a bit more detail and does a nice job of explaining some of the stuff not covered in this shorter X version