Latest Strikes 72 - February 19th-25th 2024

Hey there, Lightninger! Looking for a good read to take your eyes away from that skyrocketing chat? You're in the right place! Let's get back in time together, back to 20:00 (Moscow Time), and see what happened since then in the electrifying world of Lightning.

Ecosystem

Amboss Reflex

Amboss launched Reflex, a software solution for businesses operating on the Lightning Network that want to restrict interactions with certain other nodes based on arbitrary policies. Such policies can be compliance consideration, for example avoiding the establishment of Lightning channels with known OFAC-sanctioned entities. Filtering can be done on Bitcoin addresses used to fund Lightning channels or IP addresses, but Amboss is also in a unique position to also inject Lightning-specific data, thanks to its already existing services.

As Amboss emphasizes, Reflex is not meant as an enforcement tool, but rather as a tool for companies to setup their own set of rules when it comes to who they want to interact with on Lightning. There are chances that big Lightning companies had already developed in-house solution when faced with compliance issues, and in this regard Reflex mostly helps businesses by cutting on compliance costs. Ultimately, the compliance attack vector will always be there for businesses operating in jurisdictions with such requirements. The really interesting question is: what would it take for such tools to effectively enable censorship on the Lightning Network?

Censorship occurs when a payment cannot be carried away between certain entities, independent of their willingness to carry out this payment. Assuming LSPs start using Reflex-like software, their users would still be able to reach any destination on the network (provided path finding occurs on the user's device), just by going through more hops. Instead of going Alice - LSP - Bob, the payment would go Alice - LSP - Carol - Bob: the LSP doesn't have a channel with Bob, and yet the payment reached them. The LSP can protect itself legally by stating that:

1. they maintained strict policies to avoid connecting to OFAC-sanctioned entities, and
2. they cannot know where payments are headed to, due to Lightning's onion routing.

However, this is not very likely to please regulators. They could ask the LSP to collect payment data before authorizing them (UMA hello) ; or they could require LSPs to not only screen peers with which they connect to ensure they're not tied to OFAC-sanctioned addresses, but also scan the peers of their peers, and so on, a bit like a truly consistent OFAC-compliant miner would also have to refuse blocks that contain OFAC-illicit transactions instead of just refusing to mine said transactions themselves. In the end, you'd end up with two distinct Lightning Networks, and achieved nothing. Regulated businesses would remain solely on the compliant network, while users willing to partake in activities deemed illicit (or borderline) would use the compliance-free network for this purpose, while potentially maintaining a presence in the compliant network to carry out more ordinary transactions.

In other words, while solutions like Reflex certainly facilitate the control of suits and politicians over Lightning, I think it remains foremost a useful tool for businesses. Setting aside the OFAC stuff, wouldn't it be desirable for businesses to be able to exclude a set of nodes (for example, known scammers or attackers) from their topology of the network? Such lists could be community-based (a bit like domain lists for ad-blockers) and help both businesses and individuals avoid indelicate peers.

Big Braiins Working On Lightning Payouts

Mining pool operator Braiins announced the incoming release of Lightning payouts for their miners. They would allow individual miners to withdraw their rewards from the pool instantly and without having to reach the current minimal threshold (20,000 sats), nor pay the payout fee (10,000 sats for payouts under 500k sats) for on-chain payouts. For small miners (for example, individuals using only a few machines, or mining intermittently, for example when using miners as heaters in winter) this makes Braiins a very interesting pool option, especially since the pool's payout mechanism relies on FPPS, where any share contributed is paid for, and machines can hence work intermittently.

The Lightning payout solution is powered by Voltage, and uses LNURL-Withdraw to make the process as seamless as possible. Tests are currently being carried out with a subset of users, with a general release being planned for the coming weeks.

Lagos Lightning Bootcamp

There will be a Lightning Development Bootcamp happening in Lagos at the end of March! The 5-day event is organized by Africa Free Routing, in partnership with IBEX, Bitnob, Btrust, Fedi, Blink, Base58 and African Bitcoiners. Quite the dream team!

The event is intended for developers eager to build on Lightning, and inscription close on March 15th.

Wallets & Tools

Phoenix

Acinq published a new release for Phoenix which considerably improves the wallet privacy when it comes to on-chain operations, as well as reducing fees.

In a previous update Acinq had introduced splicing into Phoenix, with user now having only one channel with Acinq's node, which size can be changed dynamically depending on then user's needs. While this update was great for liquidity management, it introduced some drawbacks when it comes to privacy: splice-in transactions (where funds are added to the channel) used P2WSH with a very distinctive script, making them easy to recognize on-chain, and always paid to the same address, thus making it trivial to link different splice-in transactions to the same user.

Both issues are addressed in Phoenix's latest release, thanks to Taproot, Musig2 and Miniscript/descriptors:

• with Taproot and Musig2, the splice-in transaction looks like any "regular" pay-to-public-key transaction ;
• Miniscript and descriptors are useful when it comes to using different addresses for splice-ins, while making sure users will always be able to recover their funds, even in the extreme scenario where Acinq would disappear. Phoenix can now rotate addresses safely, and users will always be able to recover their funds by using any descriptors-enabled wallet.

A Lightning PoS In Telegram?

The sats.mobi Telegram-based Lightning wallet now includes a Point of Sale applet, which doubles as a link that can be opened in any browser. Having Lightning wallets embedded right inside Telegram as bots is a killer feature, since in a lot of situations the simple requirement to install yet another app can be a no-go (limited storage on the phone, incompatible data plan, etc.). Now that sats.mobi also carries along a PoS, it's even easier for merchants to accept Lightning payments with just a phone and a Telegram account!^[1]

Buying Channels In Core Lightning

Remember the LSP specification? We're starting to see more and more implementations, the latest being this interesting command line tool for Core Lightning nodes, enabling operators to buy liquidity from any node on the network that follows the LSP specification (a list of nodes offering channels can be found here).

Spec & Implems

Liquidity Provider UTXO Management

Richard Meyers proposed a coin selection and UTXO management algorithm tailored for liquidity providers that, as the name implies, frequently provide liquidity on Lightning, for example by responding to Liquidity Ads.

Given the amounts of the funds to be provided can be known in advance (for example, a provider could provide liquidity in 0.001 BTC increments), an efficient liquidity provider would seek to maintain a set of disposable UTXOs corresponding to this amounts, plus various admissible fee rates, under control of their Lightning node. For example, assuming a liquidity provider that funds either 0.001 or 0.005 BTC at a time, and with fees of either 0.00'001'000 BTC or 0.00'010'000 BTC, the provider would need to keep 4 buckets of UTXO sizes to respond to any funding request:

• 0.00101 BTC,
• 0.0011 BTC,
• 0.00501 BTC,
• 0.0051 BTC.

Meyers' algorithm would then aim at ensuring this four buckets are refilled regularly with fresh spendable UTXOs, while keeping the overall on-chain fees paid by the provider as low as possible, for example by optimizing change outputs: the algorithm would try to avoid change when possible, but would use change to create UTXOs that refill depleted buckets if a change output is required anyway.

Running some tests on an implementation of his algorithm, Meyers reached a 15% reduction in fees when compared to Bitcoin Core's default coin selection algorithm. Not too bad!

Closing Bit

Déjà le matin point
Final, applaudissements, rideau
L'oeuvre en suspens est cloturée
D'une belle aurore rosée.