Latest Strikes 53 - September 4th-10th 2023
Hey Lightninger! Welcome to your weekly recap of the Lightning Network news, brought to you by LN Markets. Last week brought us hackathons, rich protocol design discussions, marvellous updates and promising announcements!
Ecosystem
TabConf Hackathon
TabConf took place last week in Atlanta with a lot of talks, workshops, chess games, and a Hackathon in the Lightning Village. Organized by Zebedee and PlebLab, the contest welcomed 9 competing teams attempting to win one of the four prizes (Best Hack Overall, Nostr, LNURL, and Lightning). Out of those 9 projects, here are the three that caught my eyes:
- Satogram is a tool that lets you spontaneously send sats to announced LND nodes and Wallet of Satoshi Lightning Addresses, along with an attached message. You can think of it as email spam, but where the recipient gets paid. I hence don't think it really is spam, and some wallets allow you to hide small transaction, thus making such broadcasts either invisible or quite costly ;
- Ben Carman added e-cash support (via Fedimint) in Mutiny, which makes possible a very interesting flow others and I have been advocating for recently: users can start custodial and seamlessly reach self-custody once their balance makes it economically possible/relevant to do so. Indeed, one of the remaining setbacks for Lightning adoption is that opening channels require on-chain transactions. This is what makes self-custodial wallet solutions such as Phoenix or Mutiny apparently costlier that custodial ones (such as Wallet of Satoshi). Adding e-cash helps mitigate the issue: when a user first receives a few sats, they are held custodially by the wallet, which in exchange gives e-cash tokens to the user. Once the user balance at least covers the cost of opening a channel, the wallet can propose to open a real channel, hence starting the user's journey into self-custodial Lightning[1] ;
- lnplay is an easy-to-setup Lightning playground, very useful for workshops, demonstrations, or even hassle-free development. The service lets you pay an invoice to start a bunch of remote Core-Lightning nodes on a regtest network (i.e. a "closed" network, with fake sats, running on a computer somewhere in the "cloud"), and interact with them using the Clams app, as simply as scanning a QR Code. Really nice, open source, and quite handy !
Speaking of conferences, Baltic Honey Badger 2023 hosted several brilliant talks, including ones by Roy (from Breez), Severin (from Synonym) and Sam (from River).
Duels In THNDR Games
THNDR Games introduced a new feature called Duels which brings Player-vs-Player (PVP) to their games, starting with Bitcoin Solitaire. Both participants put some bolts (a new in-game currency) at stake before starting the duel, and the winner is rewarded with both stakes (minus around 10%, which I guess is there to discourage bots and abuse).
I've been in touch with THNDR Games' CMO (Chief Meme Officer), a cute little cat which is incidentally the CMO of LN Markets as well. He confirmed that using an in-game currency is only the beginning, as the (still legally challenging) endgame is to use sats all the way. Players could then play against each other for sats, and even maybe bet on other players duels. Cool!
Fountain
Lightning-native podcast player Fountain published an interesting release which brings support for the new timeValueSplit podcasting 2.0 tag. To put it shortly this tag allows podcast hosts to redirect the incoming flow of sats sent by listeners to different destinations, during specific moments of their show. This can for example be used to air music of artists that agree to be compensated this way, in exchange for the right to use their creation (as is the case for all artists in the Wavlake catalog). That's quite a thing, since one of the reasons behind why there is so few music in podcasts (and especially "amateur" podcasts) stems from the difficulty to acquire the rights to play a certain track. A problem which is "effortlessly" solved with Podcasting2.0 and Lightning!
Wallets & Tools
RBG Is Out Of Beta!
RGB is now officially out of beta! This marks a new milestone for the project, which brings scalable and private smart contracts on top of Bitcoin and Lightning.
Mutiny Update Brings Nostr Contacts List
Mutiny got a big update last week that brought some interesting Nostr functionalities into the wallet.
Simply pasting your Nostr public key (also known as npub) lets the wallet fetch your Nostr contacts. You'll then be able to see in real-time who they are publicly zapping (which is fun, as Zaplife demonstrated) and, more interestingly, use the Lightning Address they specified in their Nostr profile to pay them privately.
Nostr hence brings to Lightning wallets a piece of UX they lacked at large: contacts lists. Such lists are everywhere in traditional payment apps, and really enhance the user experience by making it fairly easy to send money to someone you already know. Incidentally, the same week, the eNuts mobile app was released, with the exact same Nostr contacts list functionality, this time in an e-cash (Cashu) wallet. Gradually, then suddenly?
The BTCPay S̶e̶r̶v̶e̶r̶ App
On top of the talks we covered in the beginning of this newsletter, Baltic Honey Badger 2023 was also the theater of quite an announcement. The BTCPay Server team announced that work has began for a BTCPay App, bringing the same functionalities BTCPay Sever provides to online businesses inside an easy-to-use app for brick and mortar shops.
The BTCPay App will use the Lightning Dev Kit under the hood, providing merchants with a self-custodial real node running inside their phone, with automated liquidity management provided by Lightning Service Providers (LSPs), NFC support, and proper accounting. Very, very exciting!
Spec & Implems
Scaling Lightning With Simple Covenants
John Law published a new research paper detailing how even simple covenants could significantly enhance Lightning's scalability by multiple orders of magnitude.
The core idea is that scaling Lightning (e.g. setting up and using channels) comes down to efficiently sharing the ownership of a single on-chain UTXO between many users. Indeed, Lightning today (e.g. with the current set of rules for the Bitcoin protocol) has already met the practical least bound, where each users co-owns one (and only one) UTXO with a channel partner, and splices funds out whenever they want to perform an on-chain transaction - which is received on the other end as a splice-in. Creating more than 2-parties channel is exponentially hard, due both to current state asymmetries in Lightning and the difficulty to coordinate signatures between multiple users (2 users can already prove quite difficult at times!)[2].
Covenants (even simple ones, brought by a soft fork such as APO or CTV) would enable one single UTXO to represent the channels of potentially millions of end users, using a tree structure and rolling out channels over time as they get closer to their expiration time.
Remotely Control Your Node From Your Favorite HSM
Bastien Teinturier proposed a simple way for node operators to issue commands to their node from the security of their favorite signing device (a.k.a "hardware wallet", such as a Ledger Nano for example).
The flow is quite simple:
- A private key is generated and stored on the signing device, which displays the corresponding public key on the screen and exports it to a companion app running on the user's computer or phone. Because the computer is untrusted, the user verifies that the public key in the companion app matches the one displayed on the signer's screen.
- The public key is added to the Lightning node's configuration, which will then accept commands that are signed with the corresponding private key.
- Every time the operator wants to send a command to the Lightning node, they will craft the command on the companion app (and hence on the untrusted computer), which will then send it to the signer. There, the user can check on the screen that all the details are correct and, if so, sign the command. The signed command is sent back to the companion app, which forwards it to the Lightning node.
I find the idea quite interesting. I think there are probably some nice design optimizations to make to ensure users can safely and quickly check the validity of commands on the (often small) signer screen, a bit like what is being down for miniscript policies.
Taproot Assets Channels
Olaoluwa Osuntokun published a draft of Bitcoin Lightning Improvement Proposal (bLIP) that extends simple taproot channels with Taproot Assets (formerly Taro) support. The draft describes how Taproot assets are accounted for in the channel (that's the Taproot-magic part), as well as how exchange-rates are negotiated.
Indeed, one of the strengths of Taproot Assets on top of Lightning is that only the two ends of a Taproot Asset transfer need to be aware of the Taproot Assets stuff. Routing nodes in the middle don't need to bother with any of that, as to them the payment is nothing but a regular Lightning payment moving sats across the network.
Let's consider an example where Bob wants to receive $10 worth of a dollar-backed Taproot Assets stablecoin called lnUSD. He needs to have a channel with a liquidity provider that provides the conversion from sats to lnUSD, and will start by requesting a quote from this liquidity provider. Then, Bob will create a regular invoice, denominated in BTC, so that the amount of sats specified by the invoice matches the quote communicated by the liquidity provider. Bob sends this invoice to Alice, who simply pays it as any regular invoice. When the payment reaches the liquidity provider, they perform the conversion and send lnUSD to Bob inside the Taproot Assets enabled channel they share with Bob. As you may see, a strength of this mechanism is that Alice doesn't need to care about exchange rate, or even about what Bob wants to receive in the end. And, as long as Alice is connected with the appropriate liquidity provider, she can even pay using whatever token she likes, which will be converted into sats, routed across the Lightning Network, and converted back to lnUSD for Bob at the end of the route.
Trivia Of The Week
What is the maximum theoretical number of payments that can be in-flight at the same time in a Lightning channel?
Answer
483. It comes from the fact that each in-flight payment needs to be represented as a dedicated output in the closing transaction, should the channel be closed while the payments are still in progress. On top of that, we want the closing transaction to propagate quickly in the network, and hence be *standard*. Standardness requires the transaction to weight at most 400,000 weight units, which (given inputs and outputs typical sizes) limits the number of simultaneous inflight payments to 483.Closing Bit
L'air est chargé des dernières odeurs de l'été
On sent dans les murmures et le fracas des verres
Que l'automne déjà s'avance.
The same result could be achieved using hosted channels. The advantage of hosted channels here is that they quite mimic the way regular channels work, hence reducing the overall complexity of the wallet. On the other hand, e-cash seems to be easier to operate in a federation, and provides better privacy guarantees if the pathfinding part of Lightning payments is performed locally on the user's device (as is the case with hosted channels). ↩︎
Notably, this coordination issue would still be a problem, at least to some extent, should we have ln-symmetry. ↩︎