Latest Strikes #31 - July 27 - August 2nd 2026 - Boltz, BIP110, & more!

• Boltz Disabled Until Further Notice
• BIP110
• Stable Channels
• Quick Strikes

Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Today we’ll dive into what BIP110 means for Lightning nodes, Boltz recent disruption, Stable Channels, and more.

§Boltz Disabled Until Further Notice

The Bolz team announced that their swap services will remain halted until further notice, citing multiple contained exploits over the past weeks and concerns over potential future exploits as the ground for this decision. To te best of my knowledge, this isn’t related to the Coldcard incident, nor does it indicate a bigger flaw in some Lightning implementations, as has been surfaced without backing on social media.

Of course, as Boltz’ post explains, this decision should be analyzed through the prism of the growing asymmetry between cyber attackers and maintainers of open source projects, which often consist of small teams with non-extensibles budgets and schedules. This harsh assessment makes initiatives such as the “Bitcoin Red Team”, spear-headed by Rob Hamilton, calle and others, all the more welcomed.

When it comes to the impact of the Boltz “outage”, it seems the team’s decision was sudden, with little time available for a heads up to the numerous projects that rely on Boltz infrastructure to brigde onto the Lightning Network. Notably, wallets that rely on atomic swaps between Liquid and Lightning (such as those using Breez’ Liquid SDK, Bull Wallet or Aqua).

My deepest sympathy to the Boltz team in this trying moment! They’re some of the most brilliant builders at the forefront of Lightning and Bitcoin. As such, they’ve become both a central pillar to many projects in the space, and a target of choise of bad actors.

§BIP110

With the BIP110 fork date around the corner (ETA ~ 3 days), I thought it’d be a good idea to provide some information as to what will happen on Lightning at this date (or block).

First, if you’ve been lucky enough to remain unaware of the BIP110 proposal and its activation window, here’s a quick primer. BIP110 temporarily limits the size of data fields in Bitcoin transactions at the consensus level, for a period of 52,416 blocks (roughly a year) after its activation. As of writing these lines, we are currently at the near end of the “optional signaling” period, during which miners may signal support for BIP110. On block 961,632 (this week-end), the mandatory signaling phase will begin. During this stage, BIP110 nodes will consider non-signaling blocks as invalid in an attempt to nudge miners into signaling if they forecast BIP110 nodes represent the economic majority. If this fails, this is where we will see a fork between the “canon” Bitcoin chain and a BIP110 chain. With BIP110 nodes rejecting non-signaling blocks, the activation threshold of 55% signaling blocks over a window of 2016 blocks will be reached at block 963,648 for nodes on the BIP110 chain, at which point BIP110 rules will be locked in, and then become active starting on block 965,664 (another 2016 blocks period later) for a year.

Miner signaling is currently very low, and the BIP110 camp seems to have failed to gather enough economic significance to nudge miners through a UASF. Therefore, it is likely that on or after block 961,632 a fork will occur, between:

• the “canon” Bitcoin chain, with a majority hashrate
• the BIP110 chain.

BIP110 miner signaling is currently at around 2.5%. Let’s be conservative and extrapolate to 5% on mandatory signaling day. This means the BIP110 chain will on average find a block for every 20 blocks found on the canon chain. There is an asymmetry in that BIP110 nodes reject non-signaling blocks, while “canon” nodes accept them and would hence join the BIP110 chain if it became the chain with the most proof-of-work. However, with such a low hashrate proportion, it is very unlikely to happen in any sustained fashion. We’d hence have a “canon” chain that finds blocks at almost the same rate as before (~1 block every 10 minutes and 30 seconds until the next difficulty adjustment); and a BIP110 chain that moves at a laborious 1 block every 200 minutes on average. At such a pace, the next difficulty adjustment (which coincides with the lock-in block) would occur 280 days later.

Now on to Lightning-specific impacts. First, as Amboss details in their blog post, there’s nothing in the BIP110 set of rules that goes against any of the operations performed by a Lightning node (modulo a small hiccup on P2A spends¹). Potential issues come from the fork itself. Let’s consider a couple of scenarios.

First, if two nodes sharing a channel are on the same chain, then they’ll see the same blocks and there should be no issue. Note that routing payments across the larger network might still be affected, more on that later.

Now if two channel partners are not following the same chain, things can get a little bit more spicy, and the longer the fork lasts the spicier. Let’s imagine the BIP110 chain becomes “longer” (i.e. accrues more proof-of-work) than the canon chain. At this point, the canon node switches to the BIP110 chain. If the fork lasted long enough for the BIP110 node to force-close the channel and sweep all the funds (for example by using an old commitment), they successfully stole funds from the canon node. Note that as of today this scenario seems highly unlikely to me, but some operators envision an influx of BIP110 signaling among miners once mandatory signaling begins.

Let’s now consider the opposite: the canon chain maintains the highest proof-of-work. Since the BIP110 node considers non-signaling blocks as invalid, they will never join the canon “longer” chain. We’d then have effectively 2 distinct Bitcoin networks, each with its own Lightning network. Since nodes disagree on the actual underlying chain, it becomes impossible for nodes to exchange HTLCs: they disagree on block heights, and can’t hence agree on HTLC timelocks or short channel IDs (SCIDs) of newly opened channels². Luckily, the Lightning specification only recommends failing HTLC when such discrepancies arise, and not closing channels. However, since nodes may have a hard time coordinating a cooperative close due to divergence in fee estimation, doing a force close may be the only option to get the funds of the channel back if the situation was to persist (note that cooperative close may work, it’s just an unknown). Luckily, force close transactions should be valid on both chains (provided you don’t do anything exotic), so you should be able to get your funds back on both chains (as Murch highlights, transactions tend to propagate naturally on both sides during this kinds of splits). Once you’ve got your funds on an address you control, I’d look into getting replay protection for this new UTXO(s) in order to be able to use them safely (here as well, see Murch’s article).

TL;DR: What should I do?

• If all your channel partners plan on running the same chain as you, nothing. You’re fine. Just monitor the situation.
• If some don’t, you may want to cooperatively close ahead of time. The window is a bit short but fees are pretty low. On the other hand, while force closing channels ahead of time is still possible, it likely means having to then handle timelocks on 2 separate chains with different timelines. Generally speaking, you should avoid transacting on-chain close to the mandatory signaling starting block.
• If you’re using watchtowers, make sure they follow the same chain as your node.
• Avoid on-chain operations (channel open, close, splices) around block 961,632 and until well past activation.

Ressources:

• StackerNews discussions here and there
• Printer on Nostr
• Amboss
• LNL node operator

§Stable Channels

Tony Klausing published a very nice demo of StableChannels. The idea is a few years old now, but execution in this demo is quite impressive, as well as the integration of newer Lightning tech such as splicing into the mix, as well as reliance on a Lightning Service Provider to smoothen the user experience.

At its core, the idea remain the same: give a user a stable USD-denominated balance inside a Lightning channel by doing frequent payments between the user and the LSP to ensure the balance stays the same in fiat terms even when the price of Bitcoin fluctuates. Of course, this requires the user’s app to be frequently online, which is probably why the stable balance is overcollateralized.

§Quick Strikes

• CLINK ubiquity continues, with many plugins from WoompaLoompa for a variety of systems (e.g. WooCommerce, Vendure, etc.) and across nostr ;
• Alby introduced l402.space, a proxy that takes Lightning and pays in one of L402, x402 and MPP ;
• a new “Lightning explorer“ lets you analyse invoices, offers, and payer proofs ;
• Blink revealed the Blink Terminal, a full point-of-sale as a webapp, which replaces the old “Cash Register” app and ships with additional new features, such as Bolt Card (NFC) support.

That’s it for last week! Once again, thanks a lot for reading this far. If you liked this issue, want to pat my back or disagree with me on something, the comments section is yours! You can fin this issue and subscribe on the Latest Strikes website. Cheers!

https://stacker.news/items/1541262