Latest Strikes 36 - May 8th-14th 2023

Kaboom! Lightning never stop, does it? Let's see what caught my attention last week!

Ecosystem

Our Companies Ecosystem

LightningNetwork+ published one of those nice market map where you can glance at many of the companies working in Lightning right now with only one look. If you're a Lightning company and would like to be listed there, you can submit your business on the Lightning Market page.

Human Rights Foundation Grants 16.5 BTC

The Human Rights Foundation gifted 16.5 BTC to 12 Bitcoin projects worldwide, through its Bitcoin Development Fund.

Some of the grants are more focused on Bitcoin itself (with very important things such as Calvin Kim's work on Utreexo or 0xB10C on Bitcoin P2P and mempool observability), but others were awarded to Lightning-centric projects. For instance, a $50,000 grant went to Raspiblitz maintainer rootzoll ; while a $25,000 grant went to Hampus Sjöberg for his work on the non-custodial Blixt wallet.

Some other grants were awarded to Bitcoin education and adoption initiatives in Africa (notably Kenya, Senegal, Zambia) and Asia (Thailand). Check out the whole thread to find out more!

Adopting Bitcoin 2023

The Adopting Bitcoin conference will return in 2023, with a partnership with the LA-based Pacific Bitcoin conference and events throughout a whole month! The Bitcoin Month will start at the Pacific Bitcoin conference on October 5th and 6th in Los Angeles, and end at Adopting Bitcoin on November 7th to 9th in El Salvador. There will be a public calendar of all events taking place during the month, worldwide. Anyone can organize an event in their city, or even online, and submit it to be part of this great celebration. The only requirement is to be Bitcoin-only.

Regarding the Adopting Bitcoin conference itself, it will take place in San Salvador and feature two main tracks, as in previous editions: an ECON stage for non-technical topics, and a DEV stage for technical discussions. There will also be workshops, networking sessions, and a Hackspace for builders. Get your tickets while they're still cheap: the price will rise $50 every month until the conference, from $150 today to around $400 just before the conference.

Magic Webstore

SuperTestnet released another super cool marketplace tool called Magic Webstore. It's basically a more polished version of the Superstore proof-of-concept they published a few weeks ago, now with Lightning support!

The promise is very interesting: being able to host a static store front, on the most inexpensive web server (even on free ones), without having to setup any wallet beforehand. When you create a new store, your web browser will locally create a new Nostr key pair. This keys will of course be used to publish your store's products to Nostr relays, making them visible to anyone listening, but they'll also allow you to receive on-chain payments directly to your own wallet.

Indeed, Magic Store uses Whisper Addresses, where your customers can pay you to a different on-chain address every time without the need for you to run anything dynamic (such as a BTCPay Server for example). Lightning payments are handled custodially by automatically creating a new LNBits account upon store creation. For now, the UI doesn't allow you to point your store to your own node, but it can still be done by cobbling a bit in the browser console.

Since the database part is outsourced to Nostr relays, and with payments being taken care of without the need to create any wallet yourself, all you need is really just a frontend. And to backup your Magic Store by saving its "Magic String" somewhere safe (yes, that's a lot of magic!). Pretty neat!

ZapPlanner

So far one of the missing pieces of the Lightning Value4Value economy (where consumers of content give back value to creators in the form of sats) was recurring, automatic payments. That's one field where fiat services such as Patreon still have an edge, by providing creators with a steady income flow thanks to recurring credit cards subscriptions.

On Bitcoin and Lightning, things don't work like that. There is no notion of debiting from an account, only the act of sending. To cover the recurring payment use case, we hence need to add another building block. Enters ZapPLanner.

ZapPlanner still only pushes payment, meaning no one can debit from your wallet. All you do is create a new "Periodic Payment" on a ZapPlanner service (such as Alby's) and link it to your Lightning node/wallet through a Nostr-enabled bridge. From then on, every set period of time (say, every month), the service will send a Nostr message to the bridge, which will in turn tell your node/wallet that it's time to send a payment to the configured Lightning Address.

ZapPlanner hence leverages two building bricks on top of Lightning:

• LNURL-Pay/Lightning Address to provide a unique identifier to which your node can pay without requiring an invoice ;
• Nostr Wallet Connect (NWC) to tell your node every time they need to push a payment.

As Alby highlights in their blog post, the real strength of NWC is that it acts as a bridge between a client (in this case the ZapPlanner service) and your wallet. Developers don't need to handle multiple wallet APIs for different Lightning implementations because it is already being taken care of by the bridge. All they need to focus on is connecting to the NWC bridge itself.

Take the example of Keet. The application enables you to send sats while on video calls or text chats, but only supports LND right now. That's because they made the choice to have the Keet app connect directly to your Lightning node: you need to input your node's endpoint (host:port) and admin macaroon in the Keet app settings. If you're using multiple applications that all want to connect directly to your node, you need to repeat the process for every one of them (hopefully with a different macaroon each time, so that you can safely sever each connection independently).

With a NWC, you only need to connect one app to your node: the NWC bridge itself. It will then act as a proxy between your node and all the other apps you wish to connect it to. And since the NWC bridge is nothing more that an always-on Nostr relay connected to your node, it can quite easily be self-hosted.

Staking Credentials Specification

Remember Civ Kit? Last week they released the architecture of the staking credentials part of the protocol, which aims at protecting participants from DoS attacks. It (logically) borrows a lot from the staking credentials architecture envisioned to solve channel jamming, as it solves a similar problem. The paper is an interesting read, but the key idea is that users wanting to access a service (for example publish an offer on a Civ Kit bulletin board) will first need to obtain stake certificates from an issuer by presenting them scarce resources (proof-of-payment, ecash tokens, RIDDLE-like proof of ownership, etc.).

If the presented assets are satisfactory, the issuer will blindly sign certificates to the user (or to a proxy of the user, for example its LSP), which can then use them when interacting with a service provider, as a "proof" that they can be trusted. The word "proof" is used quite loosely here, but the idea is that stake certificates attest that the user demonstrated the ownership of some scarce assets. The user can still misbehave, but it would difficult for them to misbehave at scale, since it requires a lot of certificates, and hence a lot of scarce assets (which are, by definition, hard to obtain).

In other words while any regular user will have no trouble obtaining enough certificates to access a service, a big player trying to perform a lot of actions (either legitimate or malicious) will need to have enough stake to do so.

What's particularly interesting with this architecture model is its modularity: credential issuers can accept the presentation of whatever scarce resources they deem acceptable, while service providers can accept credentials issued by whatever issuer they deem trustworthy. It has applications far wider than Civ Kit, and is a very interesting alternative to proof-of-work based anti-DoS mechanisms.

Some Incidents & Postmortems

Submarine swaps provider Boltz had to temporarily go offline last week amidst high on-chain fees. The team promptly shared a postmortem of the incident. The summary is: the problem had nothing to do with Lightning, but rather lied in on-chain fee estimation. As on-chain fees steadily rose for several consecutive days, Boltz on-chain transactions found themselves stuck in the mempool, always lagging behind the latest fee rate. Boltz funds kept pouring into the mempool, and at some point they had to pause the service to avoid running out of funds completely.

Breez also experienced a brief outage, which was resolved by upgrading to the latest LND version.

Going Back To Lightning & Big Onchain Fees

Coming back to our discussion from last week around the impact of high on-chain fees on Lightning nodes, LN Capital shared an awesome Twitter thread detailing force closes and how they're impacted. Recommended read!

Wallets & Tools

WoS PoS

Wallet of Satoshi Point of Sale feature is now live for all users, and supports NFC payments. It's not as powerful as things such as Swisspay for managing a whole fleet of devices and employees, but can still be a good start for small businesses.

Muun Is Working On Their Lightning Infrastructure

Muun wallet has long been under scrutiny in the Lightning community due to its distinctive approach to what a Lightning wallet is. Indeed, instead of providing users with actual Lightning channels, the way the wallet works is that it would keep the user's funds on-chain and perform submarine swaps anytime the user needs to send or receive an actual Lightning payment.

As Hampus puts it, Muun is not a Lightning wallet, but rather an on-chain wallet with Lightning capabilities. Interestingly, on Muun's website itself, the wallet is described as a "self-custodial wallet for bitcoin and lightning". But I'd say the critique is right in stating that the distinction is not apparent enough for newcomers, who today find themselves faced with high fees when trying to send or receive with the wallet.

Confronted with the current high on-chain usage and the resulting high fees, Muun had no choice but to reevaluate their approach, as they stated in a tweet.

Alby Update

Alby got a new major release last week with the v2.0.0, quickly followed by v2.0.1 will small fixes.

Version 2.0.0 brings a lot of things into Alby, with a revamped UI, new account management features, and more!

Spec & Implems

Core Lightning v23.05 Released

A new release of Core Lightning dropped last week. "Core Lightning v23.05: Austin Texas Agreement" doesn't feature any hard fork block size increase, but a lot of very nice improvements.

Users can now input two new parameters when specifying the fee rate for their on-chain transactions: minimum which is the minimum fee the underlying bitcoind node will accept ; and the number of blocks in which the user wants its transaction to be confirmed. It should be noted that using the minimum fee rate might result in the transaction not being properly propagated if the local mempool has a different policy than the majority of other mempools in the network. On the on-chain fees front, another improvement is that spending from a unilateral close transaction now uses a dynamic fee rate instead of a fixed one, and this spending transaction can be RBF'd.

Three other improvements I noticed are:

• blinded payments are now supported by default (e.g. they're not considered experimental anymore) ;
• Core Lightning will now double-check the on-chain addresses it generates to detect and fix data corruption (which is rare, but can happen and have dire consequences when it comes to addresses) ;
• new commands to list closed channels and help manage commando connections.

There's a lot more packed into this release, so feel free to check the full changelog.

Closing Bit

L'étang a fugué :
Soulevé par le vent
Il s'est enfui par la route.