Latest Strikes 41

Welcome to the 41st issue of Latest Strikes, your weekly recap of everything new and shiny in the Lightning world! Last week was another prime one, with a lot of interesting things happening. So buckle up, prime the engine, put your helmet on, and let’s dive into the stream. Prime time!

Ecosystem

Is Binance (Finally) On Lightning?

It seems like Binance finally set foot in the Lightning Network last week, a month after facing withdrawal issues and announcing work was in progress to enable Lightning withdrawals in Binance. Of course, a node alias is not conclusive evidence that the node actually belongs to Binance, but Binance themselves just confirmed yesterday that it is indeed their node.

Conducting basic chain analysis using a tool such as OXT also allows us to confirm that. For example, the UTXO used to open the first channel between Binance and Kraken comes almost directly from an address belonging to Binance’s hot wallet, as attested by Binance themselves in their 2022 transparency report. Welcome to the Lightning Network!

Seems Like Apple And Orange Don’t Mix (Again)

Almost 10 years after Apple banned Bitcoin wallets from its App Store (and hence from its devices), the Palo Alto firm seems ready for another battle against the orange colossus. This time again, the crux of the matter is about alternative payment networks that evade Apple’s lucrative walled garden, where the company usually charges a 30% fee.

While Apple now allows Bitcoin wallets to facilitate transfers, it still requires developers to go through its own payment system when it comes to in-app purchases. That’s precisely what led to Apple threats to remove Nostr client Damus from the App Store. Indeed Damus, as many other clients, offers a Zap functionality where users can tip each other using the Lightning Network. A “Zap” button is usually available on a user’s profile, as well as on every note they publish. And here comes the drama: Apple considers that the ability to tip under a specific post could be used to “sell digital content” ; and doing so via the Lightning Network would hence infringe on its terms and conditions.

Damus developer Will managed to get the app approved again by removing Zaps from posts, while keeping them on user profiles, but this episode sparked legitimate concern and outrage across the Bitcoin and Nostr communities. Will himself announced that he had been working on a cross-platform client since december, which takes more time to build but is of upmost importance, while he will still continue to support and build the iOS Damus app.

Ironically, this came a few days before we reached the one millionth Zap on Nostr. Here goes to an impressive milestone reached.

Also, a few days after the DamusGate, Apple rejected the latest Zeus update from its App Store. However it seems unrelated, and came from the miscategorization of Zeus as a cryptocurrency exchange by one of the reviewers. Things are now sorted out and Zeus is back on the App Store.

Avatars In THNDR

Mobile game studio THNDR announced a new avatar system, where users can collect avatar traits and combine them to create their own identity, which extends across the whole THNDR ecosystem. Those traits can be won by spinning a “wheel”: each spin gives three traits, and each user gets 2 free spin, as well as 20 units of a new in-game currency called “cubes”, which can be used to buy even more spins. Players will also be able to win free spins if they perform well in Leagues, as well as collect cubes by taking part in community events.

For now all of this exists only on THNDR’s database, but the interesting part is the studio will open the possibility to mint one’s avatar using Lightning Labs’ Taproot Assets protocol.

ACINQ’s Security Overview

Last week ACINQ (the company behind the Eclair Lightning Network implementation and the Phoenix wallet) shared a very interesting blog post giving some details as to how they manage the security of their Lightning node, which is the biggest in the network in terms of number of channels, and second in terms of capacity. They explain how they initially worked on a custom solution relying on off-the-shelf HSMs, but eventually decided to use AWS Nitro Enclaves instead because they provide distinctive features that their custom setup lacked.

Operating a Lightning Network routing node requires to keep the private keys in a hot wallet because it involves signing every new state of every channel. The challenge of securely operating a big routing node hence resides in keeping keys safe, making sure to only sign legitimate updates, while retaining a good transactional throughput.

ACINQ’s initial idea was to use off-the-shelf HSMs to perform the signing and keep keys safe. This involved writing a subset of the Lightning protocol right into the HSM (hence against a proprietary API) in order to perform the necessary checks (such as ensuring that every outgoing HTLC matches an incoming HTLC in a real, still open channel) on the data sent by the Eclair application, running on a more conventional environment. But HSMs are by nature very constrained in memory, and couldn’t hold all data at once: hence the need to store the data encrypted on the HSM’s host, and pass the data back and forth between the HSM and its host as needed. This led to further splitting the application, into three parts: the Eclair app running on a normal server, the HSM host, and the HSM itself. It worked in terms of security, but was clearly not ideal when it comes to operational complexity and transactional throughput.

However, they found out another tool might be better suited for the job: Confidential Computing Environments (CCEs). CEEs (such as Amazon’s Nitro Enclaves) are isolated, hardened virtual machines where any app can run. Data and code on such environments can’t be access by anyone, even employees et administrators of the hosting provider. They don’t write anything on disk, are only accessible from the host they’re running on, and can perform signature checks on applications before running them.

The ACINQ team hence created a secure setup using Nitro Enclaves: their Lightning node, which uses their own implementation of the Lightning Network called Eclair, runs inside a Nitro Enclave, where it can safely perform every necessary checks and securely sign state updates when routing payments. It is connected to the internet and to its Lightning peers through a custom proxy running on the host, but the Eclair app inside the enclave checks the authenticity of the connection by itself.

What’s particularly interesting with this setup is that updating the node’s software with a new version of Eclair isn’t particularly cumbersome. The ACINQ team signs the new software using Ledger devices and a custom Ledger app they developed (which they also use to authenticate management API calls) and pushes it to the Nitro Enclave’s host. Then, they run a script on the host that triggers a launcher in the enclave and pass it the updated software. Inside the enclave, the launcher checks the signature on the new package and, if it is valid and trusted, launches the program. The private keys don’t come bundled in the new software, and are instead fetched from another Nitro enclave over a secure channel. All the ACINQ team had to do was sign the package, push it to a server and run a script. Compare that to having to rewrite software against an HSM API every time Eclair changes, and you get a sense of how much easier to maintain this setup is.

If this summary intrigued I recommend giving the blog post a read, as it’s fairly well written and very informative. Kudos to the ACINQ team!

$150k Grant Awarded To Validating Lightning Signer Project

The Build on L2 (BOL2) community awarded a $150,000 grant to the Validating Lightning Signer (VLS) project. The VLS project produces open source software that helps separate private keys and validation logic from the rest of the Lightning node. For example, one can run a node in the cloud, while the signing logic happens on premise, using VLS.

The BOL2 community also announced that the VLS signer is now natively integrated into Greenlight, which means anyone using the Greenlight client can enjoy the benefits of this signer without having to write additional software.

Strike Reaches Mexico

Strike’s “Send Globally” initiative, where the financial app partners with local companies (such as banks or other Lightning platforms) to enable fast transfer of funds from dollars to local currencies using the Lightning Network rails, just reached Mexico! Joining forces with Relampago (which means “Lightning” in Spanish), Strike enables Mexicans to receive dollars from the US straight to their bank account, as Mexican Pesos, with no additional fee.

Mexico being the largest market for cross-border payments from the US, that’s a huge addition to the list of supported countries!

Speaking of cross-border payments, Sam from River wrote an amazing report on the role Bitcoin and Lightning can play in this massive industry. Go check it out!

Wallets & Tools

Node Management Tooling

The version 0.23.0 of node management solution Torq is out! This release includes a major fix for Core Lightning users, as well as other fixes and a bunch of telemetry/logging features, which come very handy when trying to determine what happened afterwards (especially when using automation).

On top of that, Michael Levin from Lightning Labs shared some insights on how to use the latest version of Lightning Terminal Web to manage multiple nodes from the same, unique interface. With, of course, the same security granted by Lightning Node Connect. Looks fresh!

Spec & Implems

Bundled Payments

An interesting discussion around prepayment in reverse submarine swaps and Just-in-Time (JIT) channels happened last week on the Lightning-dev mailing list – and is still ongoing.

A reverse submarine swap is when a user trustlessly sends bitcoins on Lightning and receives on-chain Bitcoin in exchange ; while a JIT channel is a channel that is opened by a node (usually a Lightning Service Provider or LSP) to another to accommodate a specific payment that the first node wants to forward to the second, but where there isn’t enough liquidity in existing channel(s) between the two nodes (or there is no channel altogether). JIT channel are particularly useful in mobile non-custodial wallets such as Phoenix, Breez or Blixt, where the LSP will open channels as needed for the user to receive incoming payments.

One thing these two situations have in common is that the service provider needs to send an on-chain transaction (either an on-chain HTLC in the case of a reverse submarine swap, or a channel opening in the case of a JIT channel), but will not be able to claim its commission/fee until the user claims the funds received¹. If the user becomes uncooperative and doesn’t claim the funds in time, then the service provider will have incurred a cost (in the form of on-chain transaction fees) without gaining anything in return. This is a known attack vector on service providers, which need to either charge a prepayment or double-spend their transaction in time when it becomes clear the user is uncooperative.

However, charging a prepayment to cover the mining fee upfront can be challenging. It requires having a first payment round where the user pays the prepayment, which can be achieved at the cost of a small UX hurdle in the case of reverse submarine swaps, but is rather unpractical when it comes to JIT channels, especially for the first channel between the LSP and the user. A solution would be for the LSP to ask the preimage to the user beforehand, but this means the LSP temporarily takes custody of the user’s funds, thus exposing them to regulatory havocs - and the user to theft of their funds. Hence the proposition put forth by Thomas Voegtlin (developer of Electrum) to bundle two payments inside the same Bolt11 invoice: one that is the “real”, original payment with its own preimage ; and a prepayment with another preimage which can be claimed independently by the LSP. This way, the LSP never needs to take custody of the user funds, and only claims upfront the small payment for the channel opening.

A central point in the discussion seems to be whether this prepayment feature should be included in Bolt11 invoices or Bolt12 offers. Proponents of adding this to Bolt11, such as Voegtlin, argue that it doesn’t make sense to use Bolt12 for this, since it doesn’t require any interactivity between the sender and the receiver (besides passing an invoice from the latter to the former) ; while proponents of using Bolt12 state that adding such a meaningful change to Bolt11 (and it being widely adopted) will be hard, while Bolt12 would be a good vector for this new mechanism since the design space is still very open. I’d say I’m rather on the Bolt12 side on this issue, especially since using Bolt12 could potentially open up more solutions. But timing is also important in this matter, and having this kind of prepayment feature sooner rather than later would ensure sane competition between service providers. So the question ultimately is: which will get widely adopted faster? A Bolt11 update or a fully fledged Bolt12?

Closing Bit

Une pensée glisse, aussitôt, on l’oublie
C’est un cygne noir qui vient, silencieux,
Troubler l’eau calme de l’étang.
Si ce n’était pour la Lune, on ne l’aurait pas vu
Plus rien n’atteste sa présence.
Est-il vraiment venu ?

---

Want to receive Latest Strikes straight to your inbox every week? Couldn’t be easier: subscribe to LN Markets Ghost blog and you’re all set (remember to confirm your subscription by clicking the link sent via email).

---

If you enjoyed this recap, you can show your appreciation by throwing a few coins to fanis @ lnmarkets.com, by scanning or clicking the QR code.

Thank you!