What actually happens to your Lightning node in every chain split scenario, and what to do about it. No sides taken. My side is the Lightning Network. Disclaimer: I'm just a Node Operator, while this article contains zero AI slop, it could contain mistakes. If so, please point them out in the comments. When in doubt, verify against your own implementation.
Why you should care (even if you don't)#
BIP-110, the "Reduced Data Temporary Softfork", is a proposed one-year soft fork that restricts arbitrary data in Bitcoin transactions. New outputs capped at 34 bytes, OP_RETURN at 83 bytes, data pushes and witness elements at 256 bytes. It ships in Bitcoin Knots, not Bitcoin Core. Whether you think it saves Bitcoin or breaks it is your business. This discussion is outside the scope of this guide. All we care about are your channels.
The dates that matter:
Mandatory signaling window: blocks 961,632 to 963,647 - projected for early August 2026
Activation: block 965,664 - projected around September 1, 2026
Current miner signaling: under 1%, almost entirely through Datum and Ocean
The reason this is a Lightning topic at all: BIP-110's activation design includes a UASF-style fallback. During the mandatory window, enforcing nodes reject every block that doesn't signal bit 4, regardless of how much hashrate is behind the rule. There is no replay protection, because the proposal isn't designed to split the chain, in the words of the proponents. But, Bitcoin doesn't care and might not have read those design documents.
One piece of positivity up front, so you don't panic-close your channels halfway through the intro: UTXOs created before activation are exempt. Your existing channel funding outputs don't become invalid. The risks hide elsewhere, and they're more nuanced.
The mechanism#
We can derive every scenario below from a single fact.
A soft fork tightens the rules. That makes BIP-110-valid blocks a subset of Core-valid blocks:
A Core node does not enforce BIP-110. It accepts signaling and non-signaling blocks alike and simply follows the longest chain with the most accumulated work. It cannot disconnect itself from the heaviest chain.
A Knots-110 node on the other hand rejects blocks. During the mandatory window: any block without bit 4. After activation: any block containing a rule-violating transaction. It follows the heaviest chain that is also BIP-110 compliant, even if that chain is shorter, slower, and possibly much lonelier.
Now layer Lightning on top. Your LN node's entire security model assumes one thing: the bitcoind underneath it sees the real, economically dominant chain. Penalty transactions, HTLC timeouts, breach detection and watchtowers, all of those depend on watching the chain your channel partners are actually on. Anything that silently pins your bitcoind to a minority or crippled chain breaks those guarantees. There's no error message. Your node just watches the wrong movie while the plot happens elsewhere.
So the real question behind "Bitcoin Core or Knots?" is not ideological. It's: which chain will my Lightning node be watching, and is that where my peers and their sats are?
The boring baseline#
As of mid-July 2026, signaling sits around 0.9% of blocks. No major pool (Foundry, Antpool, ViaBTC, F2Pool, MARA) has signaled. If nothing changes, the mandatory window produces a tiny minority chain crawling along at roughly one block every 18 to 24 hours until its first difficulty adjustment, while the main chain doesn't notice. Most analysts consider a serious split possible but not expected, but analysts are often wrong.
If you stop reading here and conclude "nothing to see", you've made the same mistake as everyone who priced BIP-148 at zero in June 2017. Which brings us to the more fun part.
Game theory#
The 0.9% number measures what miners are doing today, when signaling costs them nothing and commits them to nothing. It does not measure what they'll do when the mandatory window makes the choice real. Two mechanisms can move the number fast, and neither requires anyone to actually like BIP-110. Flipping a bit is, technically speaking, not a whole lot of effort.
1. Defensive signaling (the prisoner's dilemma)
Once the mandatory window is live and credibly enforced by at least some economic weight, every miner's calculation changes. It stops being "do I support this proposal?" and becomes "if this activates and I didn't signal, my blocks get orphaned by enforcing nodes and my coinbase reward evaporates." The individually rational move could be to signal as insurance, regardless of your opinion. If enough miners reason this way simultaneously, signaling cascades toward the threshold, and the cascade itself makes signaling even more rational. This is exactly the pressure mechanism BIP-148 used in 2017. It never had to fire, because SegWit locked in first. Whether that means the mechanism works, or was never really tested, is one of my favorite unresolved Bitcoin arguments.
2. Weaponized signaling
A large pool could signal late not because it wants BIP-110, but because forcing a split hurts a competitor or an ecosystem segment more than it hurts them. It's not free (their own reward on the losing chain is at stake), but "not free" has never stopped anyone in this industry from doing something expensive to make a point.
The takeaway for a node operator: prepare as if a split could happen. The cost of preparation is an afternoon. The cost of being wrong in the other direction is denominated in sats.
Is this unlikely? You tell me after taking a look at this post:
#
The 4 scenarios#
For every scenario: what happens if your LN node runs on top of Bitcoin Core, and what happens if it runs on top of Knots-110 (the enforcing build). We assume your priority is "don't lose channel sats", not "win the fork war". If your priority is winning the fork war, godspeed, but that's a different discussion.
Scenario A: The Fizzle (signaling stays near zero through the window)
The intuitively harmless case, and the one where an enforcing node quietly does the most damage to its owner.
If almost nobody signals during blocks 961,632 to 963,647, a Knots-110 node rejects essentially every block the network produces and accepts only the rare signaling ones. At block 961,632 it detaches from the main chain and crawls forward on a minority chain at the speed of an elderly turtle. This is by design. It's the node doing precisely what it was configured to do. The detachment is permanent for as long as that software runs, because from its perspective the main chain now contains invalid blocks.
LN on Core: Nothing happens. Your node follows the main chain, enforcement works, routing works. You read about the drama on socials.
LN on Knots-110: Your bitcoind's chain height effectively freezes while the real world moves on. If a counterparty force-closes on the real chain with an old state, your node never sees it. The CSV window on their to_self_delay, (the timelock protecting you from counterparty fraud) expires unwatched, they sweep, and your penalty transaction stays home. You lose channel sats to a breach you were technically online for. The bitter irony: the scenario where BIP-110 fails is the one where running its enforcing client costs an LN node operator the most.
Scenario B: Persistent minority chain (~ 10 to 40% hashrate)
Two real chains now exist: the BIP-110 chain (less work, slower blocks) and the standard chain (more work). Both keep producing blocks. Neither has replay protection.
LN on Core: Your node follows the heaviest chain, which is the standard chain, which is where the economic majority sits. Correct behavior, no action needed for chain-following. You still inherit the general split chaos: congested mempools, exchanges freezing deposits, fee spikes.
LN on Knots-110: Your bitcoin client is pinned to the minority chain. Enforcement now has to be reasoned about per chain. A force-close transaction may confirm on both chains, or only on one. If your peer's economic reality is on the majority chain and yours is on the minority chain, your views diverge exactly when they matter. And the hard edge case: if any of your pre-signed transactions (commitment outputs, HTLC scripts) has a construction that BIP-110 forbids (which is highly unlikely, but still possible), it's valid on the standard chain but unconfirmable on yours. Your own justice transaction gets bounced by your own chain, rekt. Frozen sats, self-inflicted.
Scenario C: The Cascade (signaling hits 55%, lock-in, BIP-110 becomes the majority or sole chain)
The prisoner's dilemma resolves in BIP-110's favor. Here the soft fork mechanism shows both its elegance and its trap.
LN on Core: Core doesn't enforce BIP-110, but BIP-110 blocks are Core-valid. If the BIP-110 chain becomes heaviest, Core follows it automatically. You get dragged along without touching anything, which is the soft fork design working as intended. Chain-following: solved. The residual risk: if one of your pre-signed LN transactions is non-compliant, your Core node happily accepts it into ts mempool, and the BIP-110 majority miners never include it. It just never confirms. The takeaway here is, core does not protect you from the enforcement edge case when BIP-110 actually wins.
LN on Knots-110: You're on the winning chain, chain-following correct, same edge case exposure for non-compliant transactions. In this scenario the client choice barely matters. Both converge.
Scenario D: The contested split (roughly balanced, both chains keep market value)
The one scenario educated LN node operators actually fear. Two living chains, active markets on both, no replay protection.
LN on Core: Follows whichever chain is heavier at the moment. If work is close, that can flip, meaning reorgs back and forth. Instability instead of a clean view. Chaos.
LN on Knots-110: Pinned to the BIP-110 chain, at least with a stable view of one chain.
Both clients: Replay means your force-close confirms on both chains. Your channels close twice. You now have to reason about penalties and HTLC timeouts independently on each chain, in congested and unreliable mempools on both sides, with the standing risk of losing sats on whichever chain you're not watching. This is the scenario where methodology beats luck, and where the operators who prepared an afternoon in July look very smart in September.
Read the table with your own priorities. If your priority is channel sats: Core tracks the heaviest valid chain in every scenario, never self-detaches, and auto-converges onto the BIP-110 chain if that one wins. Knots-110 under your LN node only breaks even if BIP-110 becomes the economic chain, and actively works against your watchtower in scenarios A and B. If your priority is enforcing BIP-110, you already know what you're running, and you should at minimum know which risks you're signing up for. Both are informed choices. Being uninformed is the only wrong one.
Should you close your channels?#
Some operators are already closing channels out of split fear, and it saddens me to lose channel partners I had for years. In my opinion, for standard channels, this is mostly solving a problem you don't have while creating several you didn't.
What preventative mass-closing gets you:
On-chain transactions in exactly the pre-window period when everyone else has the same idea, resulting in congestion and higher fees
Loss of routing revenue and channel positions you spent months (or years) building
New channel opens later, which means new on-chain transactions, possibly during post-window uncertainty
Zero protection against the actual dangerous edge cases, because closing standard channels that were never at risk protects nothing
What it protects you from: a scenario where your existing channel outputs become invalid. Which, per the spec, should not happen. Pre-activation UTXOs are grandfathered aka exempt.
The version I can get behind: if you're seriously worried and there's a specific channel you want closed anyway (dead peer, bad uptime, you never trusted them and their node smells like a Raspberry Pi Zero in a sock drawer), close it cooperatively and early, in calm conditions, weeks before the window. That would be about now. A cooperative close today is cheap and clean. A force-close during the window is expensive and exciting, and not the good kind of exciting!
Should you just take the whole stack offline?#
Tempting logic: "If chaos hits, I'll shut down bitcoind and LND and wait it out." This feels safe and is actually the single worst thing you can do, so let's kill it properly.
Going offline does not pause your risk. It pauses your defense. Your counterparties can still broadcast old channel states on the real chain while you're off. Your to_self_delay windows keep counting down whether you're watching or not. An offline Lightning node is a node that has voluntarily fired its own watchtower during the exact period when a watchtower matters the most. If a peer breaches during your node's nap and the CSV delay expires, your sats are gone, and finality means no amount of turning it back on afterwards can un-sweep them.
The failure mode is identical to Scenario A with Knots-110, just self-inflicted with extra steps: a blind enforcement node. At least the Knots operator can claim conviction.
What you actually might want instead:
Stay online, stay watching. Enforcement requires an awake node on a backend that tracks the economic chain.
Reduce exposure, not visibility. If you want to de-risk during the window, drain activity instead of pulling the plug: raise your routing fees to discourage forwards, or disable new HTLC forwarding entirely. Fewer in-flight HTLCs means fewer time-critical transactions you could be forced to enforce during mempool chaos. Your channels sit quietly, fully defended.
Don't initiate anything on-chain in the window. The most important part, imo. No opens, no closes, no splices, no boltz swaps between roughly block 961,600 and a comfortable margin past activation.
Keep fee-bumping ammo ready. A few free confirmed UTXOs for CPFP and anchors in case you must force-close into congestion anyway.
Backups current. Static channel backups fresh, seed backup solid. The importance of standard node hygiene just did a 10x.
Watch the signaling, not the timeline. Block heights are projections. Monitor bip110monitor.com or, preferably, your own node. The real tripwire is a sudden signal from a major pool. Small solo miners signaling is weather. Foundry or Antpool signaling is climate.
If you genuinely cannot keep your node online and monitored through the window, then reducing channel count is the honest fallback, because an unwatched channel is an unsecured channel, regardless of any fork. But be clear with yourself that you're solving an uptime problem, not a BIP-110 problem.
The actual risk candidates: custom channels#
If you've made it this far, thanks for reading. Now it's time to shrink the fear to its real size.
The vast majority of all public LN Channels are standard BOLT channels, and they are built from predictable, compliant primitives. Both funding output types don't violate anything afaik. Commitment and anchor outputs fit under the caps too. HTLC witness scripts sit comfortably below the 256-byte witness element limit. A lot of very technical words to say, if you run a stock LND, CLN, Eclair or LDK node with standard channels, none of your pre-signed transactions trip BIP-110's rules. The enforcement edge cases in Scenarios B, C and D exist for you as a category, not as a practical threat.
The candidates that deserve an actual look before the window:
Exotic taproot script paths. Custom tapleaf constructions with large script reveals or unusual data pushes. If you experimented with hand-rolled tapscript channels, review the reveal sizes?
Custom channel protocols. Anything non-BOLT-standard: experimental LSP constructions, research-grade channel types, protocols that stuff extra data into commitment transactions or use nonstandard output scripts.
Pre-signed transactions with embedded data. If any of your recovery or enforcement transactions carries payloads beyond the plain script logic, I have no idea what could happen.
Anything you can't fully explain. If you inherited a channel setup from a guide you half-followed in 2023 without fully understanding it, might be worth taking a close look at.
If you have any of the above, you're much more knowledgeable than me and don't need to read my layman's assumptions. You're welcome to do it anyway and chime in if I got something wrong, I'm admittedly out of my depth here.
80 IQ pleb takeaway. Standard channels pass without you lifting a finger. Custom ones can carry unkown risks if not checked in time.
TL;DR for the impatient#
Your existing channel UTXOs are grandfathered. Nobody's funding output turns into a pumpkin.
Your LN node's safety equals your bitcoind's view of the economic chain. Choose your backend knowing exactly what it does in each scenario, then own the choice.
Current sub-1% signaling is a snapshot, not a forecast. Game theory ccould move it fast in the mandatory window. Prepare accordingly.
Mass-closing standard channels trades real fees for imaginary safety. Close specific channels you distrust, cooperatively, early.
Taking your stack offline fires your own watchtower. Stay online, drain HTLC activity instead if you want to de-risk.
No on-chain activity you don't need between early August and well past activation. Keep CPFP ammo ready.
Only custom, non-standard channel constructions are genuine edge-case candidates. You explain to me how to prepare best.
Watch pool signaling, not twitter. One major pool flipping is signal. Everything else is noise.
Stay calm, stay online, and may all your force-closes confirm on the chain you're actually watching. That said, my node is staying online and you're welcome to open a channel to it if you found this useful. In any case, I hope this wall of text could help you make an informed decision amongst all the noise.
My fellow Noderunners, what's your preparation strategy? Let me know anything important I might have missed.
Peace
Comments2
LaserEyesPsy
···
CR¥P7ΩWØLF
···