Hey there, Lightninger! Last week was Taproot-y, last week was DLC-y, last week was swap-y. Ready to learn more? Grab a drink - hotty, coldy, I'll let you settle that - and follow me for another weekly!
New OpenSats Lightning Grant
OpenSats awarded a Long Term Support (LTS) grant to René Pickhardt, supporting is ongoing research on the optimization of routing algorithm in the Lightning Network. René's contribution has already been instrumental in fostering the network's reliability, with variations of his routing algorithm now implemented in most (if not all) major Lightning implementations.
Which is the best LN wallet?
Anita Posch published a very interesting article where she compares how different Lightning wallets behave under a low bandwidth environment. She had already done so in 2023, and now she's back to Zimbabwe's countryside to test how realistic self-custodial Lightning can be to the average users there. This year the study analyzed Blixt, Mutiny, Green, Zeus and Phoenix, and used Wallet of Satoshi as a point of reference, since it being custodial means it should work as good as any regular app - it's not trying to squeeze a Lightning node in there!
Anita compared the cost and ease of setting up a Lightning channel (while connected to a Zimbabwean residential Wi-Fi), and then that of sending and receiving Bitcoin with each wallet while on mobile data. In terms of performance and usability, Phoenix stands as the clear winner, while still being the second best when it comes to channel opening cost. The winner in that category is Green with a mere 3,500 sats cost to open a 100,000 sats Lightning channel, but Green performed quite poorly when it came to sending and receiving (but, as Anita points out, the wallet's Lightning functionalities are still very much experimental and recognized as such by Blockstream).
Mutiny ranked second overall, with higher setup costs and an okay usability. However, Blixt and Zeus seemed to be the more impacted by the poor connection, and were on multiple occurrences unable to sync at all. Of course, this differences can easily be explained by looking under the hood: Phoenix uses Trampoline Routing, leaving to Acinq's node the task of finding the best route to a payment's destination, while Blixt and Zeus perform this kind of operation on the device, and hence need an up-to-date view of the network before being able to send a payment. Of course, that is not to say that there isn't room for improvement, but simply an highlight that different technical trade-offs lead to different user experiences. In the light of which it seems Acinq's decisions when building Phoenix are paying off, since the self-custodial wallet even beat Wallet of Satoshi to the speed test. Impressive!
The Ecash Custodiality Discussion
Last week witnessed some interesting discussions around ecash, and wether it should be regarded as custodial or not. I know this is a Lightning newsletter, but ecash is tangent enough since it often interacts with Lightning, and the discussion around custody is also very present in the pure Lightning ecosystem.
As far as it goes, ecash is as self-custodial as regular cash: you can freely spend it as long as it has value. Because of the privacy properties of ecash, the mint cannot censor and discriminate against you in particular. All it can do is revoke certain notes at random (i.e. not knowing which users it impacts), revoke all notes but a subset (use cases: blackmail, KYC shotgun, etc.), revoke all notes and suspend convertibility (a.k.a. the rugpull), or modify the conversion rate overnight by changing how much Bitcoin it holds in reserve (the CFA Franc style rugpull). It is, quite literally, electronic cash: a bearer asset which value is directly coupled with the reputation of the entity emitting it. Notably, this makes it far better than account-based systems - such as exchanges or most custodial wallets - because the ecash itself is self-custodial. What is not guaranteed is that it will keep its value over time.
In contrast, protocols such as Lightning or statechains (a la Mercury) remove this dependance on the mint's reputation by implementing a trustless peg-out where users can autonomously exit the protocol - modulo the fees associated with the peg-out transaction. In his piece, Tony Giorgio argues that, however, "a sat on LN is valued differently than a sat on-chain", which is true because it's less certain, but this difference in value is tied to changes in the whole Bitcoin network (such as a fee spike) rather than the whims of a few actors. After all, Bitcoin on-chain itself can become unusable, ifn the fees rise so much that an UTXO becomes dust.
To me, it seems the best way to reason about ecash is to view them as gift cards. You can accept it as payment if you believe it will hodl its value, use it yourself later as you wish, and someone might try to exchange it back against sats at some point. Interestingly, ecash also has a nice property that make it resemble gift cards even more: when you send it to someone, they need to ask the mint to burn the one you sent and mint a new one with the same value. Else, you could very well try to double spend, much like someone handing you a gift card could have written down its secret number. Conversely, if you offer ecash to someone (as a gift or a tip for example) and they never claim it, you can take it back at anytime.
To me, calling bitcoin-denominated ecash "self-custodial" is a bit of stretch, because it induces the expectation that holding ecash is equivalent to holding Bitcoin (although Tony makes it abundantly clear that it's not). The only situation where such a definition would be suitable seem to be is the fiat world, where ecash is the asset itself, with nothing backing it. Else it is arguably custodial. Which ins't to mean that it's necessarily all bad: free banking has a lot of proponents, and ecash would be an outstanding building block. But there's no need to conflate ecash with self-redeemable representations of Bitcoin - sats on Lightning, a statechain - and blur a picture that is clearer as it is.
Some More News En Vrac
- The first peer-to-peer trade using the Mostro protocol and Lightning happened on mainnet last week. Mostro is essentially a marketplace for P2P on/off-ramp to Bitcoin (a bit like Robosats), where offers are published on Nostr and trades are facilitated by dedicated Mostro instances (basically a Nostr relay coupled with a Lightning node) that act as escrows during a trade.
- Geyser released new "Rewards" features, enabling projects using the crowdfunding platform to offer limited edition rewards and providing them with a dashboard to manage orders.
Wallets & Tools
Mutiny Experiments With DLCs
Mutiny released their first experiments with DLCs: Superposition and Note Duels, which both make great use of Nostr as a communication layer.
Superposition lets you become a DLC oracle by creating, signing and broadcasting an announcement ("I will attest to the outcome of X on date Y") and later sign and publish the corresponding attestation ("Regarding X, on date Y the outcome was Z"). Everything happens through Nostr, and you can either use your own Nostr identity to put your reputation behind your attestation (and make it easier for people who already follow you to find your attestations), or generate a whole new identity. Either way, others can then use your oracle inside their own DLCs.
Node Duel lets you take an event from Superposition and wager not money but a Nostr note over it. Instead of pre-signing Bitcoin transactions, both parties of the duel pre-sign Nostr notes whose signatures will only become valid when combined with the oracle's signature published on the attestation at the agreed upon date. It is hence limited to binary outcomes (i.e. "Yes/No questions"), but it's still quite interesting to see how DLCs can be settled on Nostr, not only Bitcoin. The design space is huge.
Boltz launched Taproot Swaps, which use Taproot to make on-chain to Lightning swaps cheaper and more reliable. Notable improvements are:
- if a swap fails the user doesn't necessarily need to wait 1-4 days for the timelock to expire. Instead, they can collaborate with Boltz to claim their funds back using a Musig2 keypath, which requires a signature from both the user and Boltz. Swaps can fail for a variety of reasons, which often have nothing to do with Boltz being offline or unresponsive, so having the ability to collaboratively and instantly refund the user is a huge win. And if Boltz was to disappear, the already existing timelock spending condition is still there, allowing the user to reclaim their funds safely on their own after a few days ;
- since it is now generally possible to be refunded instantly if a swap fails, the timelock can be extended to 7 days, which makes it easier for Boltz to find routes for the Lightning part of the swap, since the timelock constrains the length of the route (and, to some extent, which nodes can be considered for pathfinding)
- lower fees and increased privacy thanks to the magic of Taproot and Schnorr signatures!
Kilian from Boltz also shared how Lightning-to-Liquid atomic swaps could be used in conjunction with the covenants already implemented on Liquid to enable users to trustlessly receive to a Lightning Address, even when they are offline, with the tradeoff that the funds would be received on the Liquid side. It does so by constraining the Liquid coin so that it can only be swept to the user's Liquid address, enabling an online third-party to trustlessly claim the funds for the user.
Aqua Open Source
You've probably heard of the Aqua wallet recently launched by Samson Mow's Jan3 on, well, Jan 3rd. And maybe you've been wondering as to why it wasn't part of this newsletter, since it's supposed to focus on exciting Lightning news. Aqua is a Lightning wallet after all, right?
Well, the main reason I didn't mention the wallet just yet was because it wasn't open source, and I don't really see a point in covering self-custodial wallets if they're not open source (or at least source available), since it means nobody can verify the self-custodial characteristics of the wallet that make it so special. This changed recently, with Aqua becoming open source (for the most part) last week. With that ouf of the way, we're clear to delve into another contentious sentence: Aqua isn't a Lightning wallet. As a matter of fact, the Aqua websites don't even brand it as such. It's a Bitcoin and Liquid wallet with Lightning capabilities.
Aqua is actually to Liquid what Muun is to Bitcoin. Instead of running a Lightning node (either on the user's phone or in the cloud) it let's the user perform atomic swaps between the chain and Lightning anytime they need to send or receive over Lightning. That doesn't mean it's a bad wallet, and it definitely makes more sense for a wallet to operate in such a way between Liquid and Lightning rather than between Bitcoin and Lightning, but that's still something to be aware of. For instance, even when everything goes fine, you still lose Lightning's instant settlement, since Liquid transactions are settled in blocs every minute. A nice touch, however, is that since swaps are handled through Boltz, they should benefit from the latest Taproot-related innovations we just mentioned above.
Speaking of Lightning and Liquid support, Alby recently awarded a bounty for a Liquid web wallet compatible with the Alby browser extension. This means the signing of course happens inside the Alby extension, and you can either use Anser hosted frontend or use the source code to self host your own.
BitKit added support for paying to Lightning Addresses, and made it cheaper to transfer funds from the "spending" (i.e. Lightning) to the "savings" (i.e. on-chain) part of the wallet by using only one transaction instead of two.
Cybernétique au jaune étincelant
Tu frissonnes en cadence au milieu de l'essaim.
Ton voisin nonchalant se pose sur une fleur
Elle ouvre sa corolle et révèle l'ovaire
Cette rencontre fortuite accouche d'un beau bloc.