Latest Strikes 68 - January 15th-21st 2024

Hey there, Lightninger! You may have already seen it but we recently shared an updated graph of the trading volume on LN Markets since its inception. As you can see, it took us 3 years to reach 1 billion dollars of trading volume, and only 3 months to crush the 2 billion milestone! Of course that doesn't divert us from our track: we keep building, and we'll have some exciting news to share pretty soon (yes, consider it an announcement of an announcement).

And now, to our exploration of what happened in the Lightning world last week! En garde!

Ecosystem

Bitfinex Integrates Blocktank

Synonym and Bitfinex partenered to bring a fully-fleshed Lightning Service Provider (LSP) to the OG exchange! You can now request a channel from Bitfinex to your node using Blocktank, an open source^[1] and customizable tool developed by Synonym that lets any business run their LSP with ease, while providing a modern interface for users.

This integration makes a lot of sense. After all, if you're buying your bitcoin on Bitfinex and withdrawing to your self-custodial solution (which you should), then you might as well get a Lightning channel directly on Bitfinex as well. You'll pay a one-time set up fee^[2], but then enjoy instant and cheap withdrawals and, since the channel is bidirectional, you'll also be able to pay others with Lightning. You can also request inbound liquidity for future receiving, which makes a lot of sense for businesses. All that with a real channel, where you have absolute control over your funds. Isn't it the whole purpose of Lightning after all?

There are, however, a few things to keep in mind:

• from what I could gather, you're not buying a direct node with Bitfinex, but rather a node with Synonym, which is itself connected to Bitfinex. In theory this is interesting privacy-wise, but it comes at the expense of additional routing fees when withdrawing or depositing to and from Bitfinex ;
• buying a channel through Bitfinex is probably not as private as buying through other means (such as Blocktank directly for example), as it is tied to your Bitfinex account.

In other words, this is a prime example of the kind of compromises users have to consider between ease of use, privacy, and resilience. On-ramp such as Bitfinex becoming LSPs is a huge gain for self-custodial Lightning, since it makes it easier to withdraw though Lightning and later use the same channel for your daily expenses. The alternative would be for a user to get a Lightning channel from another service (such as Amboss' Magma marketplace, LNBig, etc.), hope it is well connected to Bitfinex, and then try to withdraw their sats through Lightning. Here you have everything in the same place, accessible in a few clicks, and I expect things to become more and more abstracted and transparent for the user, as Bitcoin and Lightning mature. After all, who needs to know what a channel is?

Semaphore

SuperTestnet released Semaphore, an open source crowdfunding software that uses Nostr, Bitcoin and Lightning. It lets you set up a crodwfunding campaign where the campaign page is hosted on Nostr, and where payments take place with Bitcoin or Lightning. Note that there is no server and no intermediary (and hence, no service fee). Contributors only need a compatible client that knows where to look to find your campaign, such as Semaphore (dowload the html and open it on your machine, or visit semaphore.finance for a hosted version).

When you create a campaign, you can specify a Bitcoin on-chain address, as well as a Lightning Address, to receive donations. Then, when contributors pay, they can either chose to do an irrerversible pledge (i.e. sending Bitcoin straight to your on-chain/Lightning address)^[3], or a reversible pledge. A reversible pledge uses Bitcoin "smart contract" and signature aggregation capabilities (as well as a bit of Nostr for signature broadcasting) to ensure that the funds you pledge can either be claimed by the recipient when their campaign ends and if and only if they reached their campaign's goal amount ; or claimed back by you after the campaign is over if the recipient didn't reach their goal. Sadly, this refundable pledge only works with on-chain Bitcoin, but it's definitely an interesting mechanism!

Wallets & Tools

Ecash Over Radio

Juraj Bednár released and demoed nutband, a Cashu client that uses a mesh network called Reticulum to connect with the mint. The communication can hence take place over different media such as long range radio, and can even be routed across other nodes of the mesh network. The nutband repository also includes the Reticulum proxy that the mint needs to run to catch those messages and answer back to the client.

When sending ecash to someone over Reticulum, the client needs to:

1. Contact the mint over reticulum to create the tokens to be sent
2. Send the tokens (in the form of a string such as cashuAeyJ0b2tlbiI6W3sibWludCI6Imh0dHBzOi8vbGVnZW5kLmxuYml0cy5jb20vY2FzaHUvYXBpL3YxL0FwdEROQUJOQlh2OGdwdXl3aHg2TlYiLCJwcm9vZnMiOlt7ImlkIjoiT3k3RnVGRGFzaHpvIiwiYW1vdW50IjoxLCJzZWNyZXQiOiJLUGtoM3owTW8yeE9CRXVRWXM0Zk1sRnJSSStYaWxUME5ubU9MeXdNb3hVPSIsIkMiOiIwMzlhNjQ4ZGNkYWQ3NTRiNjkyYTIzNjcwZWUwYWJiNjI4OGY5YzI1NzM0ZTE2NzIyMTdkNTk0YjkyODgyMTk1MTgifSx7ImlkIjoiT3k3RnVGRGFzaHpvIiwiYW1vdW50Ijo0LCJzZWNyZXQiOiJEVW43RHhHQlB0aUNFUzNWbERSZVduQy8wTkVreXJUdnFZTkhBbkZuM0hFPSIsIkMiOiIwMjE3ODgyZGM4Zjc1YjkzYzA1OGQ4M2ZlZmExODYxZDhjMzcyZTNiYzdkZDQ0YjA2M2NiOWNkNTgwYWE1MTFlM2EifSx7ImlkIjoiT3k3RnVGRGFzaHpvIiwiYW1vdW50IjoxNiwic2VjcmV0IjoiNHZxN3h0NitHUWp4VkkwMnkrbEpHVmRmcEdLSUphUVpvOXhQb0NIcWF0az0iLCJDIjoiMDJmNzg2ZGEyYTIzNjMyNjllZjkyMGVjNmQ2NzZmYTIwODhhYWU1MTBiNmFiNWQ4OGQzMTRkNjUwMjdjZDFjOGU1In1dfV0sIm1lbW8iOiJXZWxsIGRvbmUhIn0) to the recipient, for example also over Reticulum using the Sideband messaging app.

The recipient can then redeem the tokens (i.e. burn them and create new one, thus preventing the spender from double-spending) by contacting the mint, also over Reticulum.

As you can see, the internet was not used anywhere in this transaction. Now, this is very much cypherpunk. For now, the latency of such a mesh network makes it impractical to run a Lightning sub-network on top (whereas Cashu, having less interactivity requirements, is doable), but future improvements might very well unlock this in the near future.

The Card Reader Is In Your Phone If The Merchant Doesn't Have One

Ever found yourself trying to pay with a BoltCard, but the merchant doesn't have a compatible point of sale, and you don't have any sats-loaded wallet on your phone - only your BoltCard? Now you can use your phone to scan the merchant's invoice and then pay by tapping the card on your phone, thanks to SwissBitcoinPay's Boltcard Tools Terminal. In other worlds, your phone temporarily becomes the merchant's Boltcard reader, just for the time of this transaction. Pretty niche, but still pretty sweet!

Spec & Implems

Lightning, Relay v3, and Ephemeral Anchors

Very interesting discussions about the design of the mempool and its policies have been going on in the last few months, with some direct implications on Lightning. While this newsletter is not the place to extensively cover this topic, I'll try to give some context, and expand on recent proposals regarding Lightning that was put forth with regard to this new mempool logic.

There is currently an extensive work toward a new mempool design called cluster mempool, which aims to ensure that when the mempool is full and nodes need to start evicting transactions from their mempool, they start by evicting transactions that they would have mined last (i.e. those that are the less profitable). Indeed, the current set of mempool policies in Bitcoin Core cannot fully ensure that, leading to missed revenue for miners. Cluster mempool fixes this issue by organizing transactions into clusters (transactions that are connected because some are the parents of the others), making it possible to sort the mempool and always evict first the transactions that bring the less revenue.

In addition to cluster mempool, another ongoing work is package relay, which lets nodes take a whole cluster of transactions into consideration when deciding wether to include them in their mempool, and relay the transactions on the P2P network. With both package relay and cluster mempool, nodes (and notably miners) would be able to effectively decide whether a cluster of transactions should be allowed to replace a conflicting cluster that is already present in their mempool.

This new design comes with its own set of rules when it comes to transaction replacement, with the notable goal of preventing transaction pinning, or at least making it less expensive for the victim. This new transaction policies, often called V3 transactions (because a transaction subscribing to these policies would signal so by setting its nVersion field to 3), include the fact that:

• an unconfirmed V3 transaction cannot have more that 1 descendant,
• a V3 transaction that has an unconfirmed V3 ancestor cannot be larger than 1000 virtual bytes.

Transaction replacement is a huge topic for Lightning. Indeed, every time funds transit inside a Lightning channels, both channel partners commit to the new state of the channel (i.e. the new distribution of funds inside the channel) by exchanging signature for a Bitcoin transaction that represents this new state. This transaction, called the commitment transaction, isn't published unless one of the parties wished to force close the channel. If that happens, the fees that the commitment transaction are locked, since modifying them modifies the whole transaction, and hence requires the other party to sign the new version of the transaction. If the other party stopped cooperating (which is one of the main reasons we may want to force close the channel), we can't change the fees. Should on-chain fees have risen up significantly since the signing of the transaction, the channel close transaction can take a long time to confirm, potentially leading to a loss of funds.

These rules hence have very interesting implications for Lightning: by using V3 transactions, Lightning nodes can ensure that they will always be able to fee bump (i.e. "increase the fees of") a channel force close transaction, using only one anchor output. Currently, two anchors are used, along with a special mempool policy called CPFP Carve-Out, to ensure that both parties always get a chance to fee bump the transaction with CPFP, without the other party being able to artifically increase the cost of the fee-bumping by pinning the transaction^[4]. With transaction V3 rules (and package relay), the worst that my peer can do in term of pinning the closing transaction is attach a 1000 vBytes descendant to it. To "unpin" the transaction, all I need to do is replace their two-transactions chunk with my own which pays a higher overall fee, using RBF but on the whole 2-transactions cluster^[5]. Before V3, I would have had to pay up to 100 times more to unpin the transaction, because the limit would have been the 100,000 vBytes per transaction standardness rule. In other worlds, V3 transaction are more restricted in terms of how they can be spent from, but the cost of unpinning a V3 transaction is 100 times less than that of a "regular" V2 transaction.

As Bastien Teinturier highlighted last week, using transaction V3 in commitment transaction would allow Lightning nodes to:

• replace the two 330 sats anchor outputs by a single "ephemeral" anchor output which anyone can spend, and which can have a value of 0 sats under the rules of package relay, as long as the commitment transaction is part of a two-transactions chunk where the second transaction spends from the anchor, thus destroying it (hence the name "ephemeral anchor). Ephemeral anchors are cheaper and more resilient to pinning attacks that "regular" anchors, as we've just seen above,
• put the value of trimmed HTLCs (i.e. HTLCs that are so small that it doesn't make sense to include them in the the commitment transaction, given the current fee environmenent and dust limit) into the ephemeral anchor, incentivizing miners to collect the anchor and thus include the whole chunk in their block,
• remove the 1-block relative delay on the main outputs and HTLC outputs, which was put in place to ensure CPFP Carve-Out could play out and both parties would get a fair chance to fee bump the transaction. This makes this outputs immediately available for spending.

Now, everyone does not agree that V3 transactions and anchor outputs are all that good. Notably, Peter Todd published an interesting analysis of the respective costs of CPFP and RBF. Two main arguments can be extracted from Todd's study:

• using CPFP to bump a transaction takes more block space than using RBF, and is hence more expensive, because it requires the confirmation of two transactions (the parent and the child that pays for the parent) instead of just one,
• this higher cost incentivizes Lightning node runners to reach miners out-of-band in order to fee-bump their transaction, instead of resorting to a costlier CPFP. Since only miners with a significant portion of the hashrate (say 10% and more) can reliably offer such services, using anchors and CPFP weakens the mining decentralization of Bitcoin.

Instead of CPFP, Todd suggests presigning multiple versions of the same commitment transaction everytime the channel state evolves, each with a different fee attached. Doing so would only add a 5 ms latency to payments, and commitment transactions could reliably be replaced with RBF, even when force closing a channel. However, as David A. Harding pointed out, a 5 ms latency in the signing of new channel states could actually be a significant hurdle for routing nodes, especially with stuckless payments where routing nodes are racing agaisnt each other to be the first to settle their part of a payment.^[6]

However, another big reason to prefer anchors (be them ephemeral or not) and CPFP over multiple fee-variants and RBF is that anchors completely removes a big issue Lightning currently faces: the coupling between the amounts you can send in your channel and the on-chain fees. Indeed, without anchors, the fee of the commitment transaction must be paid by the initiator of the channel, and this amount must hence be reserved on their side of the channel, limiting how much they can spend. Such coupling is quite problematic on an off-chain protocol that aims at making Bitcoin usable for everyone even when on-chain fees are high. Anchor outputs are a solution, as they allow for the fees of the transaction to be increased later with CPFP.

LDK

Version 0.0.120 of the Lightning Dev Kit (LDK) was released last week, bringing full route blinding (a.k.a. blinded paths) support and fixing a DoS vulnerability which could be triggered remotely by a peer.

LNHANCE

Discussions around Lightning-enhacing covenants continued last week, with Brandon Black proposing the implementation of BIP119 (a.k.a. CTV, a.k.a. OP_CHECKTEMPLATEVERIFY), OP_CHECKSIGFROMSTACK(VERIFY) and OP_INTERNALKEY in a bundle called LNHANCE. Formalizing this proposal, Brandon opened pull requests to have the OP_CHECKSIGFROMSTACK(VERIFY) and OP_INTERNALKEY proposals integrated into the BIPs repository, and opened a pull request on Bitcoin Core's repository for LNHANCE as a whole.

Such a bundle would enable everything that CTV does, plus interesting Lightning-related things such as LN-symmetry, channel factories and John Law's timeout trees proposal. It would also allow for the implementation of other scaling solutions such as Ark, payment pools, and more.

Closing Bit

Le ciel a rosi ce matin
Miroir de tes joues froides
Un frisson parcourt le port
Qui s'éveille.