Latest Strikes 45 - July 10th-16th 2023

Last week was massive for Lightning wallets! We got an impressive Phoenix update, Mutiny coming out of beta, and Zeus literally unleashing the thunder! So take your umbrella, because we're headed in a hell of a storm!

Ecosystem

More OpenSats Grants!

OpenSats distributed the first wave of Bitcoin grants last week, which will support various open-source projects and educational initiatives. Among the grantees are some prominent Lightning-related projects, such as:

• Bolt12 for LND, which aims to bring Bolt12 Offers to LND ;
• Dusty Daemon's work on splicing ;
• Raspiblitz, a DIY node stack which enables users to easily run a Lightning node on a Raspberry Pi ;
• BTCPay Server, the open source payment processor, with full Lightning support ;
• Mutiny Wallet, a browser-first self-custodial Lightning wallet ;
• a LNURL-Auth provider for the popular Next-auth library ;
• Lightning-native Chaumian e-cash solution Cashu ;
• lnproxy, a tool that helps you conceal your node's public key from the sender when receiving money over Lightning ;
• BlixtWallet, a self-custodial Lightning wallet for Android, iOS and macOS.

Congratulations to all the grantees, and kudos to the OpenSats team and to all the donors!

Lightning At Surfin' Bitcoin

The Surfin'Bitcoin conference in France this summer will host a "Lightning Day", with talks, workshops and panels from Bastien Teinturier, Lisa Neigut, Christian Decker, Tadge Dryja, Olivier Gugger and Francisco Calderón. I won't be able to be there despite living in France, but it will definitely be an interesting conference!

Wallets & Tools

Splicing Goes Live In Phoenix

Acinq announced a huge update bringing splicing to the Phoenix wallet! This brings some nice improvements to the user experience, mainly:

• smaller setup fee (although it still depends on on-chain fees),
• a unified balance, fully held in only one channel.

Let's dive in a bit more on what this means and how it works, starting with a brief overview of what using Phoenix typically looks like. When a user receives a Lightning payment for the first time on their Phoenix wallet, they don't have any channel to accept this payment yet. However, they've informed the sender to route their payment through Acinq's node which, when it finds out about the payment, automatically opens a zero-conf channel to the user's Phoenix wallet. This is great because it means that, as soon as they receive their first Lightning funds, Phoenix users take full custody of them in a trust-minimized fashion. However, one of the UX drawbacks of this mechanism is that it incurs a one-time setup fee, which corresponds to the cost of opening a new Lightning channels. This fee, which amounts to 1% of the incoming payment (and minimum 3,000 sats) adds a lot of friction to the onboarding process, because you need to explain to someone using the app for the first time why so much of the payment goes into fees, and how it is only a one-time fee that won't affect their future Lightning payments. It also makes Phoenix less interesting for use cases such as tipping a waiter for the first time, since the fee would then eat up a decent portion of the actual payment.

But that's not it! When opening your first Lightning channel, the Acinq node must decide of its size. Of course, it must be at least big enough to accommodate the incoming payment, but it makes sense to make it a little bit bigger so that the user can receive again without needing another channel. On the other hand, Acinq needs to use their liquidity as efficiently as possible, since it is the scarce resource on Lightning: they can't just open a big channel every time, just to be safe. This means that, if a receiver keeps receiving without sending much on Lightning, it will be necessary to open new channels from time to time, which will incur a fee again. It also means that a given Phoenix user might quickly end up with 5+ channels, which is far from ideal for Acinq from a wallet management perspective, since every channel is a UTXO that needs to be accounted for, and which might have to be spent on-chain later on.

The good news is, thanks to splicing, all of this is behind us. Splicing allows for the resizing of channels without closing them. When a user receives their first Lightning payment on Phoenix, the Acinq node will open a new channel with the wallet. Should a bigger channel be required to receive a new payment, the existing channel can simply me made bigger. It still costs an on-chain transaction, but at least there is now only one UTXO per user. This simplification of the UTXO/channel management for Acinq might seem slight, but it alone allows Acinq to remove the minimum 3,000 sats opening fee they had in place. Indeed, this fee was there to account that each channel would have to be closed some day, which would cost Acinq money for the closing on-chain transaction, since Acinq was the channel initiator and, in Lightning, the initiator is the one responsible for paying the closing fee. That's a pretty substantial improvement!

That's not all. Now that each user has only one channel, it also enables a pretty slick single-balance UX. The entirety of a user's funds are held into one single channel (e.g. only one UTXO), from where they can be spent either via Lightning or on-chain using trustless swaps. The emphasis here is on trustless: Phoenix had swaps before, but they were trusted. With splicing in place, a swap is just a splice out: we're removing liquidity from the channel using a Bitcoin transaction that updates the channel size itself.

Another change this update brings is that Lighting fees are now fixed to 0.4%, compared to a previous variable fee comprised between 0.05% et 0.5%. It is worth noting that, based on past transactions, this new fee seems to be a little more costly for Lightning transfers, but at the same time it provides:

• the user with a predictable fee, which they can review before sending the payment,
• the service provider (eg Acinq) with a more sustainable revenue,
• aligned incentives, since the service provider is now incentivized to find the cheapest route possible to keep as much of the fixed fee for themselves, which wasn't the case with the variable fee.

The new Phoenix with splicing is currently in a closed beta (for Android only), to which one can apply by emailing the Acinq team. The beta is conducted through Google Play, so you'll need a Google Play account to partake.

Kudos to the Acinq team for this huge release! They're once again paving the way towards improved usability of the Lightning Network!

Mutiny Available To Everyone

Mutiny Wallet is now available to everyone! As a reminder, Mutiny is a web-based Lightning wallet that enables the full Lightning experience right into the browser, thus escaping app store censorship and making it the most widely available Lightning wallet ever.

First things first: keep in mind that Mutiny is still in beta. Caution is strongly advised, so consider this a spending wallet, and don't put more money than what you'd carry in cash in your wallet. That being said, Mutiny is pretty awesome:

• Just-in-Time channels provided through Voltage's Flow 2.0 service, which means user get their first Lightning channels without the hassle ;
• at the same time, you can still open your own channels with any node in the network ;
• backup with 12-words seed and a remote Versioned Storage Service for channels state, which allows users to backup both their on-chain and Lightning funds ;
• Nostr Wallet Connect (NWC) working out of the box, which among other things enables a "Subscription" feature where users can pay a monthly fee to access "Mutiny+" (Mutiny+ features are coming soon™, so for now consider Mutiny+ mostly a demo for subscriptions, and a cool way to support Mutiny's development).

The release has also sparked some criticism regarding the web-based nature of Mutiny making it intrinsically less secure than a native app. However, as this comment highlights, the Mutiny developers are aware of the tradeoffs. And, to reiterate once again, Mutiny should still be considered as experimental, so don't put too much money it it!

Zeus Brings The Action

Evan Kaloudis, founder of Zeus, announced that the app will soon enable users to run an embedded self-custodial Lightning node right in their phone. Up until now, the Zeus app could only be connected to a remote node (or an abstraction of a node such as a lndhub account), and act as an interface to this node. With this coming release, users will be able to choose between connecting the app to a remote node, or run a new node in the app itself.

We still don't have much details as to what this will look like exactly, but Odell's report mentions that no channel management will be needed, suggesting the use of a Lightning Service Provider (LSP). This is coherent with Zeus prior announcement of a new LSP called Olympus back in April this year.

One thing is for sure: that's intriguing, and very promising!

Lightning In Blockstream Green

BTCSessions shared a sneak peek of what the Lightning integration in Blockstream's Green wallet looks like. Seems like it's going to be available to the rest of use pretty soon now. Looking forward to it!

Zapgoals

It's still quite early, but a new way of raising money is coming to Nostr. Zapgoals look a bit like Amethyst's Zapraisers, allowing users to create a note with a set amount they're looking to raise. As other users zap this note, clients can display a progress bar showing how much was collected with respect to the aforementioned goal. Quite simple, but that's where the nostr magic lies!

A Nostr Improvement Proposal (NIP) will be published soon™. Interestingly, Zapraisers are already integrated into zap.stream, a streaming "platform" where the chat uses nostr. A streamer can set a "zap goal" for their stream, and it will show up both at the top of the chat on zap.stream and on the Zapgoals website, since it is nothing but yet another nostr note.

Other Releases

Last week blessed us with other releases, including:

• the Breez SDK got a new release, which brings support for seamless realtime backup and sending on-chain (using reverse swaps), as well as performance optimizations ;
• a BoltCard NFC Programmer app for iOS, while it previously only available on Android. This app allows to write on supported NFC cards to create one's own BoltCard ;
• BitBanana evolved nicely over the last weeks, with enhanced support for a variety of LNURL schemes, including LNURL-Pay.

Spec & Implems

Self-Payment On Lightning

The security disclosure by Calle from LNBits a few weeks ago evolved into a conversation around adding self-payment into Lightning implementations, where a node can pay its own invoices. This would simplify the development of custodial solutions relying on accounts built on top of a common Lightning node, such as LNBits, since they wouldn't need to write the custom logic of settling an invoice between two users of the same custodian locally (e.g. on the local database) instead of needlessly going to the network. Such internal payments could therefore be handled as any regular Lightning invoice simply by enabling the self-payment options in the Lightning node, and would hence result in less bug-prone custom logic for the critical part of the software that payment handling is.

Closing Bit

Tu te réveilles, ma ville, le vent remue ta fange
Tes odeurs sont la marée qui s'étend doucement
Le soleil déjà caresse doucement le dos de tes ivrognes
Il est encore doux, bientôt il sera brûlant,
Amant inextinguible à l'ardeur étouffante.