Latest Strikes 34 - Apr. 24th-30th 2023

Good morning, Lightning! Last week was an interesting one for Lightning, with a full mempool and some interesting news around submarine swaps, voting mechanisms, and node management. Let's review what happened!

Ecosystem

BlueWallet Postpones Sunsetting Of Custodial Offering

BlueWallet postponed the date where they'll stop serving custodial Lightning users to May 31st, giving one more month to users who didn't move their funds yet.

The wallet team also stated that there will still be a way for users to reach out and claim their funds after this date, but better move this capital now than later. So if you haven't done so yet, now is a good time to get your funds out of the wallet, and pass the word to those you might have had install BlueWallet too.

Amboss Raises 4 Million Dollars

Amboss announced a $4M raise, led by Stillmark and with the participation of Lightning-focused Fulgur Ventures and early-stage VC firms Draper Associates, Ride Wave Ventures and Valor Equity Partners. This raise will help Amboss develop its data offering to bolster Lightning reliability (and hence adoption) by providing companies with the data they need to allocate capital as efficiently as possible.

Phoenix Withdrawals In THNDR Games

A few weeks ago we covered (among other statistics) the distribution of funds withdrawn from THNDR across different wallets. Indeed, THNDR doesn't allow users to withdraw to any wallet, but rather gets them to pick one across a few possibilities. This limitation is most likely there for user experience^[1], with the added benefit that it helps keep the cost of withdrawals (fully paid by THNDR) low^[2].

THNDR just added a new wallet to the list: users can now withdraw to their non-custodial Phoenix wallet. Although it isn't really practical for users who don't have a Phoenix wallet yet (since the setup fee is at least 3,000 sats), it definitely makes sense for those who already have a Phoenix wallet to be able to withdraw to their own self-custodial wallet. Kind of cool!

StreamSats

This cool service by Judy Imasuen allows streamers to very easily give away sats during their streams. Simply create an account, fund it by paying an invoice, and you're ready to create vouchers. Once you have at least one of them, you can make it appear in your stream simply by copy-pasting a link into OBS (using a "Browser" source). The voucher will then appear as a QR code in your stream (you choose where and how big it is from OBS) which your viewers can scan with any LNURL-Withdraw enabled wallet to claim the funds. If you have multiple vouchers they will rotate randomly until they are claimed. And you can even add a "Sats claimed" banner that will show up when a viewer successfully claimed a voucher.

I tried it myself, and I must say it works very well and the setup process is really quite seamless! Also, it doesn't require any personal information to create an account (just a username/password). Very cool and useful for streamers who wish to thank they community but don't want the hassle of running their own node and web server.

Vote With Your Sats

Last week we mentioned the Bitcoin Gaming Grant launched by Zebedee and Guilds on the Geyser platform, with the interesting mechanism that the 10 million sats grant would be distributed to projects in proportion to the votes they received, and where each vote is in fact 1 sat tossed into the grant's pool of funds. The grant is live since April 26th, and it has already collected 1.2 million sats worth of votes which will add up to the grant's 10 million sats funding sponsored by Zebedee and Guilds.

But it's not the only place where Bitcoiners can let their sats speak for them: the BTCPrague conference is having a vote on which startups should pitch during this year's contest. This voting system is powered by Mash (which we already covered here when they got a makeover). The team has built a whole voting module that Mash users can create at will and embed on their websites. A few examples of that are listed in this StackerNews post and in a blog post, where the Mash team also explains the reasoning behind this new feature.

The key idea is that a 1 sat = 1 vote model helps prevent spammers and bots from voting. Traditionally, the way to do so is by restricting who can vote to a subset of a community (for example, paid subscribers). Here, anyone can vote for as low as 1 sat, and in that way is more committed to their vote since it cost them something. On top of this, it can represent an additional revenue stream for content creators who query inputs from their community this way, while community members can signal their wishes more precisely.

On the other hand, such mechanisms can be abused. For example, in the startup pitch contest, a project that really wants to be drafted could quite cheaply (less than 1 million sats) take the lead. But since everyone can effortlessly do the same, maybe it's not that bad. What's sure is it's an interesting, fun way to take decisions among a large community.

VIDA Is Now Non Custodial

The VIDA team shipped an update with two new features that, put together, make VIDA fully non-custodial! Indeed, you can now login to VIDA using nothing more than your Nostr keys, by allowing access using an extension (such as Alby or nos2x) thus never actually trusting the website with your private key. Knowing your Nostr public key, VIDA can then automatically get your Lightning Address from your profile and payments you receive on VIDA will hence be made to this Lightning Address directly. On top of that, WebLN payments are now fully supported (as we already reported back in March), which means people can pay you in VIDA without even having a VIDA account simply by using a WebLN-compatible browser extension (such as, again, Alby).

In other words, and as Lyle emphasizes: with the right configuration, it is now possible to use VIDA in a self-custodial way from end-to-end. Noice!

BoltObserver

The BoltObserver team has been busy lately! Last week they shipped new automation features, as well as the premise of a plugin system for their open source agent. The essence of this new automation functionality is to enable users to easily create scenarii where a trigger (for example, the inbound liquidity on a given channel drops below a certain amount) automatically activates a set of actions (for example, rebalancing the channel). In parallel to this automation flow, they also integrated Boltz API to perform submarine swaps automatically when a channel is depleted. Until now, BoltObserver users could only receive alerts when a channel's liquidity dropped below a certain threshold. Now, not only can they still receive an alert, but they can set up an automation flow so that the agent will automatically perform a swap-out through Boltz to regain some inbound liquidity.

What's also cool about this new feature is it's not some kind of a black box the user has no control over. Instead, users can edit the configuration of their agent, for example to set the maximum amount of fees their willing to pay for swaps, or even to specify an alternative swap server^[3].

The team is also cooking something with plugins, which will allow users to further customize their agent and tailor it to their specific use case and situation.

The driving force behind the agent plugin system is to empower you, our users, to effortlessly extend its functionality while still reaping the benefits of our platform's features – the data we provide, monitoring, and workflows. This combination ensures a seamless and efficient experience in managing and expanding your node operations.

-- BoltObserver's Blog Post (Highlight)

Strike Globally In Guatemala

Strike partnered with Osmo to enable Guatemalans to receive from Lightning directly into their local currency (quetzales). This is part of Strike's "Send Globally" campaign addressing the remittance market across the world.

Lightning Conferences

Lightningcon Vietnam 2023 talks are now available online, as well as this recap of the event. The two-days conference took place in Đà Nẵng, Vietnam.

Also, the btc++ conference last week seems to have been a blast! Can't wait to watch the replays.

Wallets & Tools

RGB Web Wallet On Umbrel

Diamond Hands struck again! The largest Japanese Lightning community (which we already covered in this columns when they launched their own instance of Boltz swapping service (also see note^[3:1] regarding the recent licensing change in Boltz software)) published the first RGB wallet on Umbrel, a popular, user-friendly Bitcoin and Lightning node distribution.

The wallet is still very much in alpha, and only works with testnet for now. It already allows users to play with RGB by issuing, sending and receiving RGB tokens. All of this, of course, is open source, and interestingly was built using the rgb-lib Rust library, which allows developers to build RGB wallets without having to worry too much about RGB internals.

Mutiny Node

Mutiny Node is the backend/SDK powering the web-based Mutiny Wallet, which officially launched last month. Last week, the Mutiny team published nothing less than 3 releases of the Mutiny Node, including migration to the Bitcoin Dev Kit and IndexDB, update to the latest Lightning Dev Kit release, enhancements to the Lightning Service Provider flow and more.

Decentralized Order Book For Onchain<>LN Submarine Swaps Over Nostr

SuperTestnet released an open source submarine swap service that any node operator (for now, LND-only) can run to get a yield on their bitcoins. It has quite a prototype vibe for now, but the idea is neat: you configure a little app with your Lightning node's macaroons and the minimum and maximum amounts you want to provide liquidity for, as well as your fee (either absolute or proportional to the swapped amount), and start it. On start, the app will create a new pair of Nostr keys, which it will use to advertise this submarine swap offer on the network, where anyone can view them (and, if they correspond to what they're looking for, take them).

LND Tools Update

Speaking of swaps, Lightning Labs submarine swap service got a nice update, with musig2 now being the default swap protocol. Use of musig2 enhances privacy and reduces fees.

On a different note, a new version of chantools was released. Chantools (short for "channel tools") is an amazing piece of software designed to help you recover funds stuck in LND channels when the LND node itself doesn't work properly anymore. It's the kind of tool that you'd prefer to never have to use, but that you're grateful for when you actually need it.

Litd

Lightning terminal got a big update last week, with a flock of new features, including:

• automatic channel fee management,
• custodial off-chain accounts,
• refined permissions control in Lightning Node Connect,
• an Order Board to interact with Lightning channels marketplace Pool in a simpler way.

As Michael Levin explains in Lightning Labs blog post, Lightning Terminal (aka Litd) "bundles the base version of [the] lnd Lightning implementation with liquidity services such as Loop and Pool, a web-based node management UI with Terminal, the ability to remotely connect nodes with Lightning Node Connect, and a set of accounting features with Faraday into a single software package"^[4].

The automatic channel fee management feature takes another step toward node management automation by trying to determine whether the fee of a channel should be increased or decreased based on the channel's past routing performance. It can be enabled for the whole node or on a per-channel basis, and data is obfuscated before reaching Lightning Terminal (channel names are randomized, transactions amounts and times are modified to prevent correlation, etc.). On top of this, the dashboard UX has been re-designed to give node runners actionable insights regarding their return on investment, taking into accounts all costs (channel opens and closes, submarine swaps, rebalancing) and gains (routing fees, Pool revenue, etc.).

Custodial off-chain accounts in Lightning Terminal allow you yo give access to a specific part of your node's funds to someone else (for example, a relative, a friend or a customer) with the security of macaroon cryptography that already secures your own connection to your node. We already have such accounting systems on top of Lightning nodes with the likes of LNBits and LndHub, but having it shipped directly into Terminal is huge!

Zeus & BTCPay Releases

The stable release of Zeus v0.7.5 is out. On top of what was already in the alpha, this update brings bug fixes and UX enhancements.

BTCPay Server published a new update with a bunch of bug fixes, notably in the Point of Sale and the NFC module.

Control Your Core Lightning Node Through Nostr

A cool new Core Lightning plugin dropped last week enabling node runners to receive notifications from their node in their Nostr private messages, as well as issuing commands to their node using the same communication channel.

Users can receive notifications when a channel opens or closes, on payment success or failure, when their node routes a payment, and so on. They can also create invoices, send payments and get new on-chain addresses. Cool!

Zap Android Rebrands To BitBanana

Zap Android was forked and rebranded to BitBanana by developer Michael Wünsch who is maintaining it without input from Strike anymore (the Zap wallet was initially developed by Strike). The rebranding aims at clarifying the fact that Strike isn't involved in the development anymore, as well as further set the Android version of the wallet from its iOS and desktop counterparts, which each have their own codebase and set of features.

Spec & Implems

LND 0.16.1 & 0.16.2

Two new LND releases dropped last week, namely v0.16.1 and v0.16.2, where the latter is mostly a hot fix to performance regressions introduced by the former.

The 0.16.1 brings enhancements to how LND performs under a busy mempool environnement (such has the one we've been experiencing in the past week), notably with an extended default CLTV delay (from 40 blocks up to 80 blocks, a two times increase). This makes the default more conservative and "can help to avoid unnecessary force closures due to persistent mempool backlog, or node downtime". Other enhancements in this area include better mempool monitoring (for example to faster extract the preimages of timed-out HTCLs when settled on-chain ; or enhanced transaction rebroadcasting).

This release also includes important security fixes, and there has been vocal calls across the Lightning community to quickly update to the latest version. So upgrade, folks!

LDK Update

Last week Lightning Dev KIt update shipped a lot of bug fixes and enhancements, including when it comes to transaction rebroadcasting. Seems like the recent spikes in the mempool size really helped developers across various Lightning implementations identify mempool-related issues, and they are being fixed!

Lightning Specification Meeting

A Lightning Specification Meeting took place last week, gathering developers across all implementations. As always, the main goal of those meetings is to advance interoperability, especially for new features being developed. For instance, last week discussions addressed implementations convergence on Offers, blinded paths, or Taproot-enabled channels. LND also announced they're looking into including inbound fees in an upcoming release.

Papers

Sending Lightning Payments With No Internet Connection

A new research paper was published last week exploring how local mesh networks could be used to conduct Lightning transactions in a community even without internet connection. Indeed, the off-chain and localized nature of Lightning channels makes it so that two nodes sharing a direct channel can transact without telling anyone else. In other words, two Lightning nodes can transact on their own channel as long as they have a way to communicate and agree on the new state of the channel, be it with radio communication, WiFi, Bluetooth, or even avian carriers.

The real challenges arise when trying to do this at scale, with many nodes forming a mesh network, and where you want every node to be able to pay any other node. "At scale" here means having a connection graph that is efficient and resilient: how can we ensure everyone can reach everyone, with a minimal amount of channels, and while nodes might move in the physical word, which means the mesh network topology can change if it relies on short-range communication media such as WiFi or Bluetooth.

To address this challenges, the authors propose a two steps methodology. First, observe the moving network topology during a period of time to create a "mobility-aware mesh topology". Then, using graph theory, assign channels between nodes in this mobility-aware graph to minimize the required number of channels while ensuring full connectivity between nodes. The authors devise two approaches:

• one based on a connected dominating set (CDS), where a set of "super nodes" forms the backbone of the network ;
• another approach involving computing an uniform spanning tree, where every node is assigned one channel, so that every node is connected to all other nodes through a few hops.

The researchers performed simulations to assess the relative effectiveness of each approach, as well as see how things such as the number of nodes can affect them. The results indicate that the CDS-based network performs the best (in avoiding payments failures), while the spanning tree approach still performs better than the "baseline" approach where each node is connected to its neighbors in the mobility-aware mesh network. Interestingly, success rates higher than 95% are achievable using both the CDS and spanning tree approaches. Members of a local community could hence efficiently and reliably transact with one another without ever touching the internet, powering a local Lightning circular economy. Additionally, some nodes can be connected to the internet and act as gateways to the outer Lightning Network.

Closing Bit

D'une terre à l'autre les rivages se ressemblent
Et tous les hommes ont la mer en partage.