Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. In today's issue, we cover Lightning Labs' new scaling proposition, an interesting cross-layer routing protocol, and more!
Lightning Labs Unveils LayerTree#
Lightning Labs unveiled LayerTree, a new scaling protocol with 2 core characteristics:
- many (thousands to tens of thousands) users share one single on-chain UTXO, while retaining unilateral exit rights;
- a user leaving the tree requires only one on-chain transaction, independent of the number of users in the tree.
To simultaneously realize these 2 often contradictory properties, LayerTree leverages an off-chain Merkle-sum tree to keep a record of balances, and a set of yet-to-be-activated opcodes (basically, covenants). The exact set of opcodes depends on the targeted implementation (or maybe the other way around), with the minimal version requiring OP_CAT and OP_TWEAKADD.
Lexe Connect#
Lexe unveiled Lexe Connect, a protocol and specification that lets apps request scoped access to your Lexe node. As a reminder, Lexe is a self-custodial Lightning wallet featuring an LSP, where the node runs in a remote TEE (Trusted Execution Environment) rather than on your phone1.
Such a feature makes a lot of sense in Lexe, since it means you can have one always-online Lightning node and connect your apps to it, rather than having one wallet, often custodial, baked into each app. All this with no channel management, since the LSP takes care of that.
Landfall#
Speaking of Lexe, Vincenzo Palazzo unveiled Landfall, an app (web, desktop and agent CLI) aimed at making it easier for Ocean miners to receive their payouts in Lightning. As Palazzo explains, one of the hiccups is that Ocean requires the miner to sign a message using BIP322, which is not often offered by Lightning wallets. Ocean miners hence need to find a Lightning wallet that supports Bolt12 and a way to sign a message with the same seed used by the wallet.
Landfall does precisely that: it generates a new seed, displays it to the user for backup, and uses it to both create a new Lexe wallet (and node)2 and sign the requested message. What was previously quite the headache becomes only a few steps, easy to follow for anyone who has already set up a wallet before.
Disclaimer: as Palazzo puts it, "Landfall is a showcase, not a production wallet".
Cassis#
Cassis is an interesting formalization (as a protocol) of the idea that multiple Bitcoin layers can be composed in a single payment, as long as each of them supports HTLCs. While such composition is already routinely used today, it's often (always?) limited to one transition: paying a Lightning wallet from a Cashu mint, doing a swap between Liquid and Lightning, depositing on an Ark with a Lightning payment, etc. There might be multiple hops involved in the Lightning part of the payment itself, but there's only one additional hop before or after this Lightning part. While it's theoretically possible to bridge across even more layers in a single payment atomically, it becomes a manual process rather than something that happens behind the scenes when the user hits "Pay"3.
Cassis simplifies all that with a routing protocol. Nodes advertise which networks they support through Nostr (e.g. a specific Fedimint instance, Lightning, Liquid, a specific Ark, on-chain Bitcoin, etc.) and can be reached through iroh when someone wants to route a payment through them. This is basically onion routing, but instead of routing nodes passing down and peeling an onion, the payer's wallet coordinates the whole payment by pinging each node when it's their turn to forward the payment4. So not onion routing at all. Should we call it Cassis Routing?
I think it's great to have a formalized protocol implementing and coordinating multi-layer hops. Of course, it's still very early, but I'll be very curious to see if it catches on!
Zeus Release#
Zeus v13.2.3 was released, fixing bugs and bringing the usual amount of improvements and security hardenings. A few editorial picks:
- the embedded LDK node was bumped to version 0.2.7 of rust-lightning, bringing in LDK's October 1st security release;
- for receiving, Zeus now checks that the invoice wrapped by the LSP matches the one it initially generated, before showing it to the user;
- LNURL-Auth now checks that the callback host matches the signing domain, preventing a class of man-in-the-middle attack where a malicious party could pose as the website the user wants to connect to, and intercept the valid login to access the victim's account on the website themselves;
- Zeus can now parse (and thus, pay) BIP353 records that contain more than one payment method, e.g. a silent payment address and a Bolt12 Offer. Neat!
- and many, many more things. Check the release notes for more details.
Quick Strikes#
- Alby Hub v1.24.3 was released, bringing back on-chain <> Lightning swaps, and many improvements and bug fixes. Note that this is not the latest, since v1.24.4 was released yesterday;
- the (sunset) nix-bitcoin project was rebooted as bitcoinix by a group of developers, including Trezor co-founder Pavol Rusnak;
- Lightning in a Jar (LiJ) is a browser on-chain and Lightning wallet, powered by LDK compiled to WebAssembly. The team is also building LIJOX, an open list of LSPs that any LND operator can join by running an adapter on top of their node. They're looking for such operators to give it a try, as well as eyes on their LDK patch set.
- lxdev (we covered their dark pools prototype here) announced Zark, a privacy-focused blinded statechain protocol that basically tries to improve on MercuryLayer's design by adding zero-knowledge to further reduce the (already small) level of information leak when transacting on the statechain. It's definitely great to see the privacy-focused approach of statechains make a comeback!
That's it for last week! Thank you so much for reading this far, and until next week!
https://stacker.news/items/1600810
Basically Phoenix in the cloud. Which makes sense for a bird. ↩︎
This leverages a yet-unreleased feature of Lexe that lets users bring their own seed when provisioning a new node. ↩︎
For example, you could initiate an Ark onboarding, take the on-chain address returned by the server, use it as the destination of a Lightning-to-bitcoin atomic swap, and pay the Lightning invoice returned by the swap service from your Cashu wallet. ↩︎
More precisely, the payer's wallet first builds a route, and sends a
preparemessage (through iroh) to each node in that path. Each of them can review the terms (amount, fees, destination, involved networks, etc.) and accept or reject. Once all accept, the payer's wallet locks the route and initiates the payment, sending an HTLC to the first node, and sending them anexecutemessage, which contains details about the incoming HTLC. The first routing node proceeds to forward the payment to the next node, using another HTLC, and reports back to the payer. The payer then uses the information from this response to send anexecutemessage to the next node, with details about the incoming HTLC from the first routing node, and so on. ↩︎
Comments
No comments yet. Start the conversation.