Latest Strikes 51 - August 21st-27th 2023

Welcome to the 51st edition of Latest Strikes! In case you're new here, Latest Strikes are a weekly recap of the news from the Lightning Network ecosystem, brought to you by the LN Markets team. Last week was a big one, with a vulnerability disclosure, a nice self-custodial Lightning Address mechanism, and two Lightning implementations shipping! Let's dive in!

Ecosystem

Zaprite Update & Pricing Model

Zaprite, a nice invoicing tool we already covered back when they relaunched, just released a bunch of new features, with payment links, Strike support, and a nice Unchained Capital integration.

Zaprite distinctive stance is that it doesn't aim to be a fully fleshed payment processor. It should rather be seen as an invoicing tools which connects to other software that takes in charge the actual payment, be it a Lightning Node, a LNBits or Strike account, or a multisig vault.

The company also rolled out its pricing model, which will come into effect in a few months for current users, while new users will enjoy a free trial. The pricing is in line with Zaprite motto of never touching users funds, and is hence a monthly subscription rather than a per-payment fee. Refreshing!

Donations In PeerTube

PeerTube users rejoice! A PeerTube admin called Don just released a PeerTube plugin that, when enabled by the admin of the PeerTube instance, will allow content producers to display a tip button below their videos. Interestingly, the admin can configure a percentage which will be channeled to their own Lightning Address on any payment. It seems like a really nice revenue stream for people running PeerTube servers, compensating them for their bandwidth and storage costs.

Ah, and you can live stream on PeerTube. So the next time Twitch further devalues streamers compensation (which recently went from 70% to 50% of subscriptions revenue), maybe that'll be a more interesting alternative for streamers.

Scaling Lightning Roadmap

The Scaling Lightning initiative (which aims at building a testing toolkit for Lightning developers) published their roadmap, comprised of 5 big phases, which can be briefly summed up as:

1. Create the very basic software, working with all 4 main implementations and minimal API ;
2. Develop the tools to test Lightning applications ;
3. Lightning implementation testing ;
4. Testing tools for researchers
5. Make it easy to spin up new signets to perform public and wider tests.

Wallets & Tools

CLBOSS Is Back

Vincenzo Palazzo and Ken Sedgwick announced that they've taken over the maintenance of the CLBOSS tool. CLBOSS' ambition is to completely automate your Core Lightning node so that the only things you'd have to worry about as a node runner are installing Core Lightning and CLBOSS and ensuring stable power and internet connection. However the tool was deprecated and didn't follow up with the latest Core Lightning Updates. The current work at hand is hance to restore CLBOSS functionalities and make it fully compatible with Core Lightning again.

Judging by some reactions it seems CLBOSS was really an appreciated tools, so this revival is definitely a very nice thing to see!

VLS Release

Validating Lightning Signer (VLS) has released a new version focused on improving performance for low resource signers. The release includes features such as running in a no-std environment, compatibility with CLN 23.08, and performance tuning for embedded processors. Developers and companies are invited to try out the new release and provide feedback, but also to proceed with caution and only use VLS on testnet or with a limited amount of real funds, since the software doesn't yet cover all cases where a user might lose funds.

The team also shared a roadmap with their plans for future developments, which include multi-signer support, improved latency and memory usage, exposing VLS monitoring data, and Docker support. Later on, the team plans to add support for Bolt12, as well as enhanced multi-signer setups using actual multisigs (powered by Musig2 or FROST, which are two different Taproot-enabled multisignature schemes currently being brought to Lightning).

No Server Lightning Address

SuperTestnet strikes again! The prolific developer released a new piece of software called ZapLocker which allows users to receive payments to a Lightning Address (including zaps) in a "self-custodial" manner, and without the need to setup a server or a Lightning node.

The main idea behind how it works is that it uses Nostr to notify you when someone is trying to pay you. You'll then need to manually claim the payment (either on-chain or on Lightning^[1]). The service is "self-custodial" because as a receiver you give the server a bunch of hashes for which you know the preimage when you create an account there. If the server uses this hashes to create invoices when requested by a sender, it will hence not be able to claim the payment on your behalf. The transfer will hence remain pending until you claim it manually, or it expires a few hours later. It's basically Hampus Sjöberg's Lightning Box, but with HODL invoices.

If you're a frequent reader of this newsletter, you might be wondering a bit at this point: how can I be sure as a receiver that the server will provide senders with invoices featuring a hash that I provided in the first place? Zaplocker has a elegant solution to this problem: when the receiver gives hashes to the server, they also provide a signature for each of them using their Nostr key. The server then displays the signature alongside the hash on the endpoint where senders request invoices, allowing senders wallets to check that the hash was indeed signed by the right Nostr key.

However, even if the server does use the hashes I (the receiver) provided, how can I ensure it doesn't reuse hashes once it learns the preimage after the first successful payment? And even if the server doesn't reuse hashes, how can I be sure that it will transfer the whole amount to me, and not help itself without asking? The question is important because, in all three cases, it would allow the server to undetectably steal funds that were meant to reach me.

Well, of course, SuperTestnet thought about that. They came up with a mechanism that involves the sender broadcasting a Nostr note when paying the invoice, stating both the hash used and the amount paid. This note is signed by the recipient to acknowledge reception, and future senders can request this type of nodes from relays when performing a payment, to check whether the hash provided by the server has already been used. This solution isn't implemented by any wallet at the moment, involves additional queries when performing a payment, and the fact remains that it is impossible to prove that a hash hasn't been used, but that's still a very interesting proposal!

Spec & Implems

Vulnerability Disclosure

Last week we got to learn about a vulnerability affecting Lightning nodes released prior to certain versions^[2], and discovered by Matt Morehouse. Said nodes are vulnerable to a DoS attack involving the creation of fake channels, where the attacker can force a victim node to consume resources by opening fake channels and not publishing them on-chain. In other words, the attacker negotiates a channel opening as usual, exchanges signatures with the victim, but never broadcasts the funding (i.e. "channel opening") transaction. The attack can result in performance degradation and, ultimately, the risk of funds being stolen due to the node being unable to properly watch the blockchain anymore because its resources are exhausted, even after a restart (with the notable exception of Core Lightning, for which it didn't seem to be the case because it uses different processes for different functionalities of the node).

All major lightning implementations have released updates with defenses against the DoS attack. However, this vulnerability highlights the usefulness of watchtowers to assist you in publishing justice transactions in case your node is unable to.

Core Lightning Update

Blockstream has released Core Lightning v23.08, featuring numerous changes and improvements, which we already covered in recent issues for some of them. Notable changes are:

• fixes for (rare) channel failures with Eclair and LND nodes, as well as minor tweaks and bug fixes ;
• a new parameter called ignorefeelimits has been added to insulate channels against fee negotiation disagreements with peers, on a per-channel basis ;
• Taproot address support has been introduced, allowing users to issue Taproot addresses for on-chain funds ;
• the pay plugin has been enhanced for faster and more reliable payments, based on feedback from Blockstream's Greenlight project ;
• a new command called setconfig enables users to change node settings without restarting, and logging capabilities have been improved ;
• the ability to save and restore a node's secret key in the BIP 93 format has been added ;
• the reckless plugin manager now supports installation from local copies of plugins ;
• channel closure handling has been improved to prevent cascading failures in the event of fee spikes.

Make sure to read the full blog post and the release notes to get a deeper grasp of all the things that changed.

LND 0.17.0

The first release candidate for the version 0.17.0 of LND has been released. Among many other improvements it features a new channel type, called Simple Taproot Channels (a.k.a "musig2-based taproot channels", but we'll go with "simple taproot channels", right?).

Simple Taproot Channels, as the name implies, are the first step toward using Taproot to improve the way Lightning channels work. This first step consists in replacing the funding output of the funding transaction of a channel, which is currently a 2-of-2 p2wsh multisignature address, with a musig2 2-of-2 multisignature address, while also changing a few scripts to reduce on-chain footprint. One of the main benefits of using musig2 is that the address of the Lightning channel now resembles any regular address: it is not obvious anymore to an outside observer that it is a 2-of-2 multisig, and hence probably a Lightning channel.

This new LND version isn't out yet, but Zeus wallet is ready already!

Closing Bit

Le train passe
-- Presque sans un bruit.
On dirait que c'est le vent qui le pousse
Tendre comme un amant
Aux dernières heures du jour.