Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week gave us a finalized splicing specification, Lexe going public, and an uncoordinated off-chain rebalancing protocol.
SplicingSplicing
The splicing specification got merged into the main Lightning specification last week! Splicing lets node operators dynamically resize channels without having to close them. This is especially useful for Lightning Service Providers (LSPs), since it lets them onboard a user with a given liquidity, and then adjust it depending on the user's usage. For example, is the user ends up receiving a lot of funds, the LSP can increase the channel capacity in an operation called a splice-in: the channel's on-chain output is combined with external on-chain funds in a transaction that creates a "new" channel with higher capacity, but this new channel retains the initial's channel reputation in the network's topology.
┌──────────────────┐
│ Channel │
│ User + LSP ├──────┐
│ 0.1 BTC │ │
└──────────────────┘ │ ┌──────────────────┐
│ │ Channel │
├──────▶ User + LSP │
│ │ 0.1 BTC │
┌──────────────────┐ │ └──────────────────┘
│ External │ │
│ LSP ├──────┘
│ 0.05 BTC │
└──────────────────┘ The opposite (decreasing the channel capacity) is also possible, in an operation called a splice-out. Of course, in both cases an on-chain transaction is required in order to modify the channel's capacity, but that still a two times improvement compared to closing a channel and then opening a new one -- not to mention the benefits of retaining a channel's reputation through splicing.
Splicing is a highly interactive process between the two peers sharing a channel, with a back-and-forth between the nodes that needed to be codified. After a few years, we now have interoperability between 3 implementations (Core Lightning, Eclair and LDK), which made the feature eligible for inclusion in the main specification[1]. Congratulations to all the Lightning devs involved!
Lexe Public BetaLexe Public Beta
Lexe announced their public launch, with 2 new features on top of the beta we covered earlier this year, with 2 new features:
- BIP353 Human Bitcoin Addresses (HBA), which wrap Bolt12 Offers behind a more readable, email-like address using DNS records ;
- Lightning Addresses, which are functionally equivalent but leverage web servers rather than the DNS.
If you're a Lexe user, your HBA and your Lightning Address will be basically the same, just with an extra "₿"suffixing the HBA.
Lexe is a self-custodial Lightning wallet with a LSP, where your node runs inside a Trusted Execution Environment (TEE) in the cloud. Think Phoenix, but your node runs in a trust-minimized cloud server rather than your phone. This allows you to receive even while your phone is off(line).
The launch was also paired with the launch of 2 first SDKs (Python and Rust) for developers. Congrats to the Lexe team on the launch!
LNDLND
Support for the new Taproot closing flow (where each party can increase the feerate with RBF using their own channel funds) has been enabled in LND. Now LND nodes can collaboratively close Taproot channels using Musig2 signatures, by exchanging nonces during channel shutdown. This addition also includes non rotation for secure RBF scenarios.
EddyEddy
wactario proposed a practical implementation of one of the mitigations proposed by René Pickhardt against the depletion of liquidity in channel even under perfect circular economy conditions. This solution requires multiple nodes to coordinate in order to replenish liquidity where it's beneficial. This would in theory require a central coordinator with full knowledge of the participants balance, a detail that the Lightning Network doesn't disclose natively.
This implementation consists in a separate daemon called Eddy that must be ran on top of a LND node. It leverages 2 features of LND:
- custom P2P messages, which Eddy runners use to advertise their node's channel balances on the gossip network. Other Eddy nodes can collect this data, and look for cycles where every node would benefit from a liquidity displacement ;
- LND's HtlcInterceptor and its
RESUME_MODIFIEDaction, where an LND routing node can decide to forfeit its fee and forward the full amount they received from the previous node, to the next node in the route. This lets Eddy nodes join the circular rebalancing movement, as the author explains:
The initiator pays a zero-fee route to itself, each intermediate node’s interceptor forwards the full incoming amount, and the initiator receives back exactly what it sent. If any intermediate node doesn’t waive its fee, the payment fails. Participation is all-or-nothing.
The last remaining question that would warrant the need for a central coordinator is to determine who should initiate the rebalancing, since all Eddy nodes gather (approximately) the same gossip data, and should hence spot the same cycles. The Eddy protocol dictates that a node, finding itself in such a cycle where rebalancing would be beneficial, should only initiate the liquidity circulation if their own public key is the lowest of the cycle. Rebalancing can hence occur without a coordinator thanks to this non-interactive election method, and atomically thanks to the zero-fee circular route.
That's it for last week. Thanks a lot for reading this far. As always, feel free to reach out with feedback, and until next week!
The requirement is actually that 2 independent implementations achieved interoperability. See the specification modification process for more details. ↩