Howdy Lightninger! This is yet another late recap, but here it is. Let's call it a mise en bouche before monday's recap, where we'll get a close look at the Lightning vulnerability that made headlines this week. And with that, I wish you a pleasant Satsturday!
Another Outstanding River Report
River blessed us with another fantastic report on the state of the Lightning Network. As we've touched on several times already in this newsletter, getting actually interesting data on Lightning is hard due to the design of the network. The publicly available metrics (public nodes and announced channels) are at best a proxy to the actual numbers that matter (for example, economic activity, volume of transactions, etc.) and, even worse, the accuracy of this proxy is hard to measure and can change greatly over time.
In other words, you can't rely only on publicly available data for any kind of useful work. Being well-aware of that, the River team went out and collected data voluntarily shared by some companies and entities in the space, such as mobile games studio THNDR or prominent exchange Bitfinex. I engage the reader to delve into the report on their own, but here are a few key elements I found especially interesting:
- the ratio of the volume routed in the network to the network's capacity is 7 to 1, which means every satoshi publicly deployed in the network on average facilitated the transfer of 7 satoshis. That's pretty sweet, and the trend seems to be in nodes becoming even more efficient with their capacity, with the volume of transactions increasing far steeper than the public capacity (which even slightly shrunk recently). It might be a bit hard to understand for TVL-poisoned brains, but this is actually a good thing and a sign of health for the network. Do more with less, and reallocate the funds you don't need to more productive endeavors (or just back to the safety of cold storage) ;
- only around 12.5% of Lightning wallets are self-custodial. Now, that's a bad number. It goes to showing that self-custodial Lightning isn't yet practical enough, and/or that some usages of Lightning are still better served with custodial solutions (notably low-frequency, low-value transactional use cases).
- Lightning is, as theorized, both an alternative and a complement to using Bitcoin on-chain. Half of the transactions on Lighting in 2023 were below 1,000 sats, making them impossible or uneconomical to carry out on-chain. Behind this transactions are novel use cases such as gaming rewards, Value4Value sats-streaming, or social media tipping.
P2P Self-Custodial Wagering
THNDR unveiled a new banger in the world of Lightning gaming last week! Picture it: you can now play against another user, wagering sats on the outcome of the game, but without the game developer taking custody of the funds at any time. Pretty sweet, innit?
The user experience is pretty simple: you sign up on the Clinch website, link a Lightning Address, and a start a new game with an attached stake (right now, players can wager 100, 1,000 or 10,000 sats). Pass the game's link to your friend to let them join. Each player will be asked to pay an invoice of the amount at stake (say 100 sats) before the game can begin. The invoice pays the other player, but going through THNDR's node, and isn't settled right away. At the end of the game, the invoice that pays the winner is settled, while the invoice paying the loser is simply canceled. In other words, the winner gets the loser's money, as you'd expect. In the middle, THNDR is able to collect some fees, which could prove to be an interesting funding mechanism for game developers.
So how does this works exactly? Clinch leverages two powerful Lightning mechanisms: hodl invoices and invoice wrapping. Invoice wrapping is the process through which a third party can act as a proxy between the receiver and the sender of a payment, but without being in custody of the funds at any time. The receiver creates an invoice, which as usual carries a payment hash only them know the preimage of. The third party will then take the payment hash and use it to craft another invoice, which pays them and can be for a different amount. The third party then sends their invoice (called the wrapped invoice) to the sender. When the sender pays this invoice, the third party can't claim this payment immediately because they don't know the underlying preimage. The only way for them to learn this secret is to in turn pay the initial invoice that the receiver sent them. To claim this payment, the receiver must reveal the preimage to the third party, which the third party will then use to claim their payment from the sender. This way, the sender indirectly paid the receiver through the third party, which didn't have any hold on the funds in the process, while being able to claim a fee if the amount of their wrapped invoice was bigger than the amount of the receiver's invoice.
An hodl invoice, on the other hand, simply consists in the receiver of the payment (which crafted the invoice) waiting on an external event before they reveal the preimage to the sender and claim the payment.
In a Clinch game, THNDR gets an invoice from both players using their respective Lightning Address, wraps each invoice and sends the wrapped invoice to the other player (e.g. Alice gets Bob's invoice, wrapped by THNDR). Each player pays the invoice they're presented with, but the settlement of the payment is withhold by THNDR. Once the game is over and the winner is known to THNDR, THNDR can simply cancel the wrapped invoice they sent to the winner, and pay the invoice they received from the winner in the beginning using their Lightning Address. Knowing the winner's preimage, they can now claim the payment the loser made to the wrapped invoice, which was still on hold.
Interestingly, Lightning gaming OG Christian Moss had already come with a similar idea back in 2019. A key difference is that Moss's scheme was fully peer-to-peer, with no entity in the middle. While it may seem desirable (since it means no fee), it exposes the winner to a (moderate) griefing attack where the loser could refuse to cancel the winner's payment to their invoice, thus letting the payment in a "hodl" state until the invoice expires. This is a problem because the winner can't use the funds they committed to this payment while the loser is still "hodling" to it. The cryptography-era version of a sore loser, if you will. Having THNDR in the middle in Clinch addresses this issue, since THNDR is responsible for cancelling the hodl payment to the loser when the game is over, instead of letting it expire an hour or so later. Pretty smart!
Wallets & Tools
Blockstream's Greenlight Now Open For Business
Greenlight, Blockstream's self-custodial Lightning-as-a-Service solution, is now officially available for commercial use!
Even More Testing Tools
Voltage unveiled Doppler, their Domain-Specific Language built for Lightning. To put it in a nutshell, Doppler is a simple language that allows developers and researcher to create, deploy and export complete Lightning local test networks with simple, concise scripts. A very nice and useful tool, which can also help ensure different tests or research experiments are easily reproducible, since the backbone of the test is the same.
Last week also witnessed the official announcement of SimLN, a bring-your-own-network (BYON) toolkit focused on accurately simulating random payments. It could notably be paired with Voltage's Doppler, using the intuitive language to bootstrap a local test network, and leveraging SimLN capabilities to populate this test network with realistic payment activity. More tests and more research can only lead to a more robust network!
Here are a few noteworthy from wallets we love:
- Phoenix fixed a few bugs, and clarified that some legacy (i.e. prior to the splicing update) services will be disabled starting November 1st. Notably, swap-in and pay-to-open will be discontinued, since their use case (adding liquidity to the Lightning wallet) is better served using splicing ;
- Alby version 3.3.0 was released, bringing new on-chain feature, as well as better support for hodl invoices, which I suppose was driven by the Clinch release. When paying an hodl invoice, the wallet popup will now close on its own, even if the payment isn't settled yet.
Trivia Of The Week
Q: What is the short_channel_id and how is it constructed?
AnswerA: The short_channel_id is a unique identifier for a channel and is used for efficient routing. It is constructed from the funding transaction by combining the block height, the transaction index within the block, and the output index, usually in a format like `block_height`x`transaction_index`x`output_index`.
L'ombre de la bougie vacille
Au rythme du ressac.
La Lune sans doute s'en amuse
Depuis sa lointaine couche glacée.