Latest Strikes 70 - January 29th-February 5th 2024

Hey there Lightninger! Last week was a big week for us with the reveal of our brand new service, DLC Markets. But it was also a big week for Lightning: real-word asynchronous payments, new stats, a security disclosure, and much more! Let's dive in!

Ecosystem

Big Announcement: DLC Markets

Last week we announced a brand new product: DLC Markets. Its purpose is simple: provide a solution to OTC derivatives traders that don't want to completely give up the custody of their coins to a third party. Using a Discreet Log Contract (DLC), two parties can collaboratively enter a trade which is settled when an oracle publishes an attestation regarding the price of the underlying asset (e.g. the price of Bitcoin). DLC Markets provide an easy-to-use web interface, where all the cryptography involved in creating the DLC is performed client-side (i.e. in the user's browser), while the funding of the DLC can be achieved through any Bitcoin wallet that supports the PSBT standard.

On top of this, DLC Markets acts as a coordinator between both participants of a trade, solving the free option problem (where the last party to sign has a free option to not sign if they see the market heading in the "wrong" direction) and easing the management of the DLC, with features such as liquidations, margin calls and contract renewal.

To learn more about DLC Markets, feel free to visit our website, or give our white paper a read.

LDK Hackathon

The Lightning Dev Kit (LDK) team announced that the first LDK Hackathon will take place at Advancing Bitcoin in London from March 13th to 15th. That's right, a 3-days hackathon, with pretty nice prizes in Bitcoin. The morning of the first day will be dedicated to lectures and workshops to get everyone on board with Lightning and the LDK, while the rest of the schedule will be for the actual hackathon, with presentations by the competing projects occurring on the afternoon of the third day.

An interesting thing to note is that, while the usual 1st, 2nd and 3rd prizes are up for grab, there are also specific categories catering to important aspects of Lightning such as easy self-custodial use, Bolt12, watchtower security and remote signing, and privacy. Projects can hence focus on tackling issues in one of this decisive areas.

Some Stats

Sorukumar shared a very interesting data visualization dashboard they made. You can plot the classics, such as a channel sizes histogram, but also other graphs that I hadn't seen elsewhere yet. For instance, there's this nice plot of the size of each channel vs the number of channels of the most connected peer involved in this channel (i.e. the peer with most channels altogether). You can easily view some patterns in terms of channel sizes, and some nodes are so special that they have their own pattern. For example, the horizontal line at the top of the graph is all the channels people opened with ACINQ. We can also see, as expected, that nodes that open very big channels are also well-connected nodes with a lot of channels.

Another StackerNews user reproduced Rene Pickhardt 2022 estimations of the likelihood of a payment of a certain size to succeed in the Lightning Network, but with new data from a more recent (Feb. 2024) snapshot of the network. Interestingly, they found that

[professional nodes] can relay payments with 99.9% probability [which is] order of magnitudes higher than in 2022. In contrast, the full network cannot relay any payments with >97.5% probability. In fact, SLA's for most payment sizes decreased for the full net, except for the larger payments whose SLA's increased slightly.

Now, a 99.9% probability of success is pretty sweet. Of course, that's a simulation on top of actual data extracted from the network, but I'd wager to say that actual reliability is probably in the same range. We're coming at you, VISA!

Wallets & Tools

Offline Payments In Breez SDK

Breez shared some very interesting demos (here and here) of asynchronous/offline payments, where the recipient is able to receive money although their Lightning wallet is not open. This new feature, which is integrated into the Breez SDK, uses a push notification sent to the recipient's device by its LSP (Lightning Service Provider) to wake the Lightning wallet app and perform the necessary signatures to receive the payment. Even more impressive, payment to a Lightning Address can be handled this way, by sending a notification to the phone every time it needs to do something (i.e. retrieving the receiver's payment info, then an invoice, and then performing the actual reception of the payment).^[1]

That's a pretty huge deal! One of the most cumbersome UX challenges for Lightning today is the need for the recipient to be online to receive a payment, leading to many users favoring custodial solutions that enable them to receive while they're away. Now, with solutions like this, this big hurdle is about to be resolved.

However, another pain point remains: since Lightning invoices are short-lived and single-use, we still need a way for the sender to get an invoice from the receiver without the receiver having to do anything. A way we solve this today is with Lightning Addresses, which are human-readable short identifiers, but it not perfect: it usually involves a server in the middle that receives requests from the sender and fetch invoices from the receiver, but can always cheat by responding to the sender with their own invoice rather than that of the actual recipient. 'till Bolt12 Offers?

Speaking of asynchronous payments, we covered the beta release of Zeus v0.8.1 about a month ago. Is is now available for everyone, featuring a standalone Point of Sale with product management, Nostr contacts and QR code contact sharing between Zeus wallets, as well as persistent LND node for Android users, enabling them to receive to their "Zeus Pay" Lightning Address while the app is closed. Yet another solution to the asynchronous payment problem.

LNBits Compliance Extension

Ben Arc is working on a compliance extension for LNBits. For now it is mostly a short list of jurisdiction-specific recommendations for merchants using LNBits to receive payments in Bitcoin, but the goal is to make the extension more powerful in the future. Having spoken with quite a few merchants about accepting Bitcoin for payment, one of the substantial resistance is often around the legal, fiscal and accounting implications. Having a fiscal and accounting tool that is tailored for their jurisdiction's laws in LNBits would definitely be a huge selling point for merchants who're still hesitant to take the plunge.

Zaps Via API

Bob from MakePrisms (a.k.a $prism) announced a new service: Zaps via API! The idea is simple: any app or service (for example, the admin of a Discord server) can use the API to register sending and receiving users: for sending users, the API will respond with a Nostr Wallet Connect (NWC) link that then communicates to the user for them to use it in their Lightning wallet ; for receiving users, they need to provide a Lightning Address on which they will receive.

From then on, anytime a user sends to another one, the $prism server behind the API will contact the sender's wallet through the NWC connection, asking it to send sats to the recipient's Lightning Address. If the recipient doesn't have a Lightning Address registered with $prism yet, the payment is reserved for later (i.e. the sender's wallet is not asked to send money for now, and will be once the recipient has given $prism their Lightning Address). In other words, while the $prism server makes it as easy to send money as writing /zap @alice in a Discord chat, it doesn't take custody of the funds at any point. All it does is coordinate the payment through NWC when asked to via an API call, and the payment itself takes place between the two users directly. Kinda neat!

Speaking of Nostr Wallet Connect, Start9 announced that NWC is now available on their home servers ; and Shinobi just posted an interesting article about NWC and what it achieves.

Spec & Implems

Bitcoin Core Lightning-related Vulnerability Disclosure

Eugene Siegel announced that he had responsibly disclosed a vulnerability in Bitcoin Core versions earlier than 22.0 that could be exploited to steal funds from Lightning routing nodes. The gist of the attack is that an attacker could significantly delay block propagation toward the Bitcoin Core node that a Lightning node uses, enough to steal the value of an in-flight payment that the attacker would route through the victim's node.

In the above example, an attacker controlling M1 and M2 purposefully routes a payment through B, and is able to steal the transacted amount from B by withholding blocks. In this example, the CLTV delta is taken to be the commonly used 40 blocks value.

In the initial phase of the attack, the attacker manages to occupy all the high-bandwidth compact block relay slots of the victim, for example by always delivering blocks faster than all its other peers. Once this position is secured, the attacker can make the victim unaware of new blocks by announcing the header of the new block on one of these connections, but not sending the block. In Core 22 and earlier, Bitcoin Core will wait 10 minutes before asking for the block from another connection. Once the time has elapsed, Bitcoin Core will ask the next peer, which is also a connection controlled by the attacker, and so on. Since 10 minutes is also the average time between two blocks, an attacker with something like 50 malicious connections can hide new blocks from its victim during more than the 40 blocks delta between the two in-flight HTLCs in the routed payment.

This vulnerability was patched in 22.0. It is strongly advised to update your Bitcoin Core node to at least v22.0 if you use it as the Bitcoin backend of a Lightning node.

CLosing Bit

Le dernier néon s'éteint
Fin de tournage.
Le manège s'est arrêté, ses cheveaux,
Parqués pour la nuit sans couverture
Frissonnent déjà sous la pluie fine.