Latest Strikes 56 - September 25th-October 1st
Hello, Lightninger! Welcome to your recap of the latest news of the Lightning Network! Last week was another vibrant one, full of Lightning DLCs, payment reliability enhancements and new liquidity tools. Let's dive in!
Ecosystem
Lightning DLCs FTW
Seems like last week was the week for Lightning DLCs!
- The Human Rights Foundation (HRF) awarded $50,000 to Gee Deer for their work on Lightning DLCs, as part of a larger new gifts round that totalled around 19 BTC, going to a variety of contributors and projects worldwide, from Bitcoin developers to educational initiatives ;
- Théo Mogenet published an amazing research paper on Bitcoin money market funds, and how DLCs (and hence Lightning DLCs, if we want this thing to scale) could play a crucial role by removing counterparty risk from the equation ;
- 10101 released perpetual futures into their app. This new feature leverages the fact that DLCs on Lightning can be rolled over without hitting the chain. The only difference with more traditional perpetual futures (such as the one currently trading on LN Markets) is that the user needs to come online to renew the DLC, since only them have the private key required to do so. With the power of self-custody comes some responsibility!
The Data-driven Quest To Payment Reliability
The Mutiny team shared an interesting retrospective on how they're trying to tackle payment reliability, achieving a whopping +600% in reliability over the course of a few months. In their blog post, they give some details around the various strategies they implemented and their effectiveness.
When trying to improve reliability, there are mostly two aspects you can play with:
- the quality, accuracy and freshness of the data you're using to find routes in the network,
- your route selection algorithm and its parameters, i.e. which kind of routes you'll prefer and try first.
The Mutiny team played on both sides, tweaking some parameters to favor hubs and reduce the number of hops, while providing users with more up-to-date gossip data, as well as probing data. Notably sending up-to-date gossip data more frequently was instrumental, since an estimated 90% of payment failures came from inappropriate fees (due to out-of-date fee rates data). Impressive!
Wallets & Tools
New Liquidity Pool Service
LN+ launched a new service called the Lightning Liquidity Pool. The LN+ platform is mainly known for its Liquidity Swaps feature, where Lightning node operators coordinate to open channels with each other so that every user that contributes a given amount of sats in inbound liquidity (by opening a channel) will receive the same amount (by having a channel opened to them).
This new Pool feature builds on the same idea of reciprocity, but instead of users engaging in punctual "channel opening parties", LN+ keeps track of who contributed liquidity to the network with an internal accounting system called "credits". When you open a channel to a node that already has some "credits" and keep it open over (at least) a 50-days period, some of the credits of the user will flow to you, proportional to the size of the channel you opened. This ensures that, over time, anyone who opened a channel to someone will have a channel opened to them.
For nodes with high inbound liquidity requirement, it is also possible to directly buy credits from LN+, which will incentivize other node operators to open channels with them.
It's an interesting new mechanism, quite complementary to LN+'s Liquidity Swaps, as the LN+ team highlighted. Notably, the Pool provides users with more control over who they share channels with, since you can freely accept or refuse channel offers. You credits will hence only be paid towards nodes that you deemed interesting to open a channel with. This a great improvement over Swaps (where you don't really have a say on who your peers are), which better captures the fact that all inbound liquidity is not equal.
Phoenix New Splicing Feature Fully Rolled Out
The Splicing update of Phoenix wallet started being deployed to all users (both iOS and Android) last week. The Acinq team had already started rolling out the release a few weeks ago (as we reported here), but temporarily paused the deployment amidst high on-chain fees, since the migration requires closing existing channels and opening a new one (hence N +1 on-chain transactions, where N is the number of channels before the migration). Neat!
Spec & Implems
Reducing On-chain Footprint Of LN/DLC Channels
When I wrote above that last week was Lightning DLC week, I meant it! Thibaut Le Guilly (from Crypto Garage, one of the pioneers in DLCs on Lightning) shared some thoughts on how the current implementation of Lightning DLCs could be enhanced to minimize on-chain footprint. Indeed, some of the design decisions around DLCs inside Lightning channels can be narrowed down to a balance between interactivity requirements and on-chain footprint in case of channel force closes.
Thibaut's proposal could reduce the number of on-chain transactions required to force close a DLC Lightning channel from 6 to 4 transactions, notably by removing an intermediate transaction (called the buffer transaction), at the cost of requiring both parties to sign each Contract Execution Transaction (CET) twice instead of once when renewing a DLC (for example when trading perpetual futures). The actual absolute cost of doing so greatly depends on the specifics of each DLC, since the number of CETs can greatly differ from contract to contract. Ultimately, peers could decide to optimize for on-chain footprint or interactivity, depending on their use case.
Blinded Path(finding) In LND
Support for paying to a blinded path has been merged to LND!
As a reminder, the core idea behind blinded path is that instead of the sending node computing the whole route leading to the receiver, the receiver actually computes "half" of the route. The sender then only needs to find a route that leads to the node that begins the receiver-computed part of the route. For example, if Alice wants to send a payment to Bob, Bob computes a route that goes Carol - Daniel - Bob ; while Alice computes a route that goes Alice - Eve - Carol. The route computed by the receiver (Bob) is hidden to Alice (through encryption), so the sender doesn't know precisely where their recipient is on the network.
This means LND node will now be able to properly find a route up to the node at the middle of both route fragments, and pass along the (encrypted) blinded route so that this node will know what to when it's their time to forward the payment.
Trivia Of The Week
What is the minimum channel reserve value that a node needs to keep on their side of a channel at all times?
Answer
The specification suggests 1% of the channel capacity as the minimum reserve to be held by each peer on their side of the channel. This reserve ensures that each party always has some skin in the game to discourage cheating attempts, as cheating could result in losing this reserved amount. Indeed, if a peer was to have nothing on their side, they could engage in bad behavior and try to steal funds by broadcasting a revoked state, since Lightning's penalty mechanism can only strip them of money they have in the channel at stake.Depending on the trust you place in your peer, you can jointly decide to lower or increase this requirement on a per-channel basis.
Closing Bit
Un étroit pied planté dans le sol infini
Leurs trois ailes battant en cadence l'air enfuis
Ce sont les albatros des temps de l'alumine.
Pareil est le poète, rivé à son ferment
Agitant en tout sens ses bras démesurés
Et mu par un courant qu'il ne contrôle pas
S'efforce de tourner sans rompre ni plier.
