Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week got us a small LND release, an interesting consensus change proposal that would enable expiring HTLCs without free transaction relay, and more!

LND Release

Version 0.21.1 of LND was released last week, notably fixing a nasty bug that could lead to silent loss of funds when using the HTLC Interceptor. The interceptor basically lets a node hold on incoming HTLCs instead of forwarding them right away, then reject, resume or settle them (settling of course requires the node to know the preimage). When a channel was closed while an HTLC was intercepted, said HTLC would be automatically presented again to the interceptor for on-chain settlement. That’s expected behavior, since it lets the node collect the HTLC even though the channel was closed. However, one confirmation after the HTLC was initially made available off-chain, the interceptor would stop recognizing the on-chain HTLC as something it can claim. Eventually, after the HTLC expires, the other party would claim it using the expiry path, leading to loss of funds for the impacted node¹.

This was fixed, and the interceptor is now able to claim HTLCs on-chain as long as they’ve not been claimed by the other party, i.e. as long as they’re not expired yet.

Voltage Sunsetting Self-Serve Product

Lightning cloud company Voltage announced they’ll be sunsetting their historic self-serve product. Existing customers can add new infrastructure to their account until July 13th, and the whole thing will be shut off on August 31st.

Voltage lets individuals and companies run Lightning nodes in their cloud, hence reducing the operational hassle. They started with a model that resembles a lot how cloud providers in general work: customers could provision new Lightning nodes on their cloud infrastructure, with a fixed and transparent price depending on the kind of deployment (e.g. lite node with neutrino, standard node on a shared server, or professional node on a dedicated machine, as can be seen in this Google Cloud blog post). In parallel, the company managed to onboard an ever increasing number of corporate and institutional customers with tailored solutions, and even novel products such as Lightning nodes operating on a credit line. With the scale of these new customers, Voltage’s growth skyrocketed, and maintaining the self-serve product started to become a burden.

In their documentation, Voltage lists a number of alternatives for self-serve customers whose scale doesn’t justify onboarding into the “company offering”. They’re all great suggestions, most of them with automated channel management through an LSP, but I’d also like to add that the tooling for running your own full Lightning node on a VPS has considerably improved over the years. Of course, the one remaining challenge is channel management, and to my knowledge nothing today beats the simplicity of LSP-powered Just-in-Time channels. But once again, depending on a project’s size, going the DIY way can be worthwhile.

StackerNews Discussion

Expiring HTLCs Without Free Relay

Josh proposed a consensus change that would enable expiring HTLC success paths without free relay. This would provide protection against replacement cycling attacks in a way similar to Peter Todd’s OP_EXPIRE (making the preimage spending path expire once the timeout path becomes available), but without the free relay problem it introduces.

The central idea behind both proposals is to render the path that spends the HTLC output with the preimage invalid after a certain time. In OP_EXPIRE, this is done by making the transaction expire in the mempool itself ; whereas Josh’s proposal achieves a similar result by splitting the preimage spend path into 2 sequential transactions. This approach has 2 significant benefits:

• since the preimage timeout is enforced through block confirmations, it reduces (removes?) the need for nodes to constantly monitor the mempool,
• it removes the free relay problem, which arises in OP_EXPIRE because an attacker could just spam the network with HTLCs that it never spends and end up expiring in the mempool, thus without incurring any mining fee.

To achieve this, Josh proposes to add a new consensus rule when it comes to interpreting the value of the nSequence and nLockTime. Currently, with BIP68, bits 31 and 22 of the nSequence are used to signal how its value (more precisely, the value of the lowest 16 bits) should be interpreted. Josh proposes adding another signal on bit 21, which if set (and bits 22 and 31 are unset) tells a Bitcoin node to enforce the value of the nLockTime such that the transaction is valid if and only if:

• nLockTime < 500 million, which indicates that it encodes an absolute timelock in the form of a block height and not a UNIX timestamp
• nLockTime >= H, where H is the block height at which the relative timelock that encumbers the transaction expires (H hence depends on the block where the transaction that created the input being spent confirmed)
• the relative timelock is at least 100 blocks long.

As stated above, the preimage spend is also split into 2 transactions:

1. In the first transaction (Tx1), the HTLC receiver spends the HTLC funds, using the preimage, into a “staging output”. This transaction also has one anchor that only the receiver can spend (allows CPFP while preventing pinning).
2. The staging output created in Tx1 can be spent using one of two paths: a. A presigned transaction (Tx2) that transfers the funds to the HTLC receiver and where the bit 21 of the nSequence is set, along with a 100-block relative timelock and where an absolute timelock is set (through the nLockTime) to the block at which the HTLC expires b. A more traditional path where the offerer of the HTLC can claim the HTLC a few blocks after it expired².

With this design, the receiver has until 100 blocks before the HTLC expires to claim it using the preimage. After expiry, not only can the offerer claim it with the timeout path, but the preimage path becomes invalid. Indeed, the nLockTime of Tx2 is fixed at the HTLC expiry height, on signing time. The new rule makes Tx2 valid only if that expiry is at least 100 blocks after Tx1 confirmed. If the receiver reveals the preimage (in Tx1) less than 100 blocks before expiry, Tx2 is invalid and the funds are gone for them. In short, if the receiver waits too long before publishing Tx1, Tx2 becomes invalid and they can’t claim the funds anymore. This solves the replacement cycling attack³ (or at least makes it impossible to profit from) without introducing free relay, and more generally removes the need for nodes to constantly monitor the mempool to detect preimage spends, since it is enough to monitor the confirmed blocks.

As Josh highlights, this design has some minor limitations, but also 2 more important ones:

• the HTLC receiver must wait until HTLC expiry to ultimately claim the funds after preimage publication (because the nLockTime of Tx2 prevents it from being mined right away). This is mitigated by an optimized design that Josh also details in his post ;
• the receiver must also pay for 2 transactions instead of one.

I think this is a pretty smart design, with quite few downsides. Settling HTLCs on-chain can already be uneconomical in some situations (low amount and/or high fees), and making the preimage spending path span over 2 transactions instead of one seems to only marginally worsen this situation. Excited to see this proposal further discussed!

Quick Strikes

• Andrew Camilleri released a very interesting BTCPay Server plugin called Terminal, which lets brick-and-mortar businesses charge customers using NFC stickers that redirect to the current active invoice. Once the NFC tags are set up, the cashier can initiate a sale by tapping their phone on the cashier-facing tag, which opens a web page where they can create the charge. Then, the customers only needs to tap their phone onto the customer-facing tag, which takes them to a page where they can settle the invoice. No installation needed on either end!
• Electrum wallet now supports CLINK offers through a (still experimental) plugin. The CLINK uprising continues! (StackerNews Discussion)

---

That’s it for last week! As always, thank you for reading this far! Next week, we’ll notably take a look at unilateral exits, which sparked a lot of debates in the last few days.

Footnotes

1. If the impacted node knew the preimage in order to claim the HTLC on-chain, then they probably already forwarded the funds to another party, and hence lose money if they’re unable to settle the incoming HTLC. ↩

2. Since Tx2’s nLockTime prevents it from being mined before the HTLC expires, we must give the HTLC receiver at least a few blocks to broadcast Tx2. ↩

3. Because the HTLC receiver can no longer play mempool games where it reveals the preimage in a “covert” fashion: it must reveal the preimage in a block at least 100 blocks before the HTLC expiry. This 100-block buffer serves as a protection against deep chain reorgs, and was chosen to be the same as the coinbase maturity. ↩