Hey Stackers,

***Latest*** ***Strikes*** #72 is here, packed with news from last week!

***Latest*** ***Strikes*** 72 - February 19th-25th 2024

lightning

Hey Stackers,

Latest Strikes #72 is here, packed with news from last week!

🔍 A nuanced look at Amboss' Reflex (prolly gonna take some heat for this one 😅)
🧠 Big Braiins bringing Lightning payouts to mining
🥕 Phoenix getting Taproot-y
🪙 Enhanced coin selection for LSPs
& more! 

Stackers mentioned in this issue: @ambosstech @braiins_systems @gkrizek (don't know if Voltage accounts here are the real deal) @africafreerouting.

🧡 & ⚡️

Latest Strikes 72 - February 19th-25th 2024

fanis

***Latest*** ***Strikes*** 11

bitcoin

Latest Strikes 11

***Latest*** ***Strikes*** 4

Latest Strikes 4

***Latest*** ***Strikes*** 3

Latest Strikes 3

***Latest*** ***Strikes*** return! After a little break, your weekly Lightning newsletter is back.

***Latest*** ***Strikes*** 66 - December 4th 2023-January 7th 2024

Latest Strikes return! After a little break, your weekly Lightning newsletter is back. In this issue:

🧧 OpenSats Grants
👻 Ghost Addresses
🫤 Sadly, vulnerabilities
🚀 Many updates to wallets & tools
🐝 Alby's Bitcoin Connect
🗺️ A new topological algorithm
😅 An innovative new way of locking coins forever
& more!

As always, baked with 🧡 & ⚡️

Latest Strikes 66 - December 4th 2023-January 7th 2024

***Latest*** ***Strikes*** 6 - Oct 16th

Latest Strikes 6 - Oct 16th

***Latest*** ***Strikes*** 10 - Nov 13th

Latest Strikes 10 - Nov 13th

***Latest*** ***Strikes*** 12 - Nov 27th

Latest Strikes 12 - Nov 27th

TNStacker

I hope you like this new issue of ***Latest*** ***Strikes***, your weekly recap of the ***latest*** news in the Lightning

***Latest*** ***Strikes*** 64 & 65 - LN News November 20th-December 3rd 2023

Hey SN, long time no see! I've not been hanging much in the Saloon later, but I'm back. I hope you like this new issue of Latest Strikes, your weekly recap of the latest news in the Lightning ecosystem.

Oh, and I'd like to thank @TNStacker for posting the LS issues while I was out of town. Here are a few sats for ya.

🧡 & ⚡️,
Fanis

Latest Strikes 64 & 65 - LN News November 20th-December 3rd 2023

***Latest*** ***Strikes*** 9 - Nov 6th

Latest Strikes 9 - Nov 6th

***Latest*** ***Strikes*** 7 - Oct 23rd

Latest Strikes 7 - Oct 23rd

***Latest*** ***Strikes*** 8 - Oct 30th

Latest Strikes 8 - Oct 30th

If you've followed my prior work, you might be familiar with the previous instance of the ***Latest*** ***Strikes*** ... I want to take this first issue of the ***Latest*** ***Strikes*** newsletter reenactment as an opportunity to share

***Latest*** ***Strikes*** ⚡ S03E01

*Summary of Lightning Network news for the 47th week of 2025 (November 17th to November 23rd).*

Welcome to a weekly summary of noteworthy news and developments in the Lightning Network ecosystem. If you've followed my prior work, you might be familiar with the previous instance of the Latest Strikes newsletter, which ran (roughly) from September 2022 to February 2024[^1]. What you're currently reading is a modest attempt at relaunching this thing, with no strings attached.

And now, without further ado, let's dive right in!

## Money Dev Kit

Last week, [moneydevkit](https://moneydevkit.com/) (MDK) launched their public beta. The MDK's goal is to allow developers to integrate self-custodial Lightning payments into their app with just a few lines of code.

One way to sum it up is that it's basically [phoenixd](https://phoenix.acinq.co/server) but without having to run phoenixd on a server alongside your actual app (say, a store or a blog). Instead, your LN node runs on-demand inside your app, on the backend. For now, only the [Nextjs](https://nextjs.org/) framework is supported.

Like in similar Lightning Service Provider (LSP) setups, your node is connected to one of MDK's always-on nodes, which provides inbound liquidity and abstracts away channel management. When someone tries to pay you, your MDK node will create an invoice, specifying its private Lightning channel with MDK as a routing hint. When the payment reaches MDK's infrastructure, they ping your node to let it know it can claim the incoming HTLC. Since the invoice was crafted by *your node*, which keys are only on *your* infrastructure (the one where you deployed you app), MDK can't steal the payment from you since they don't know the preimage.

Received payments stack up on your side of the channel. You can then decide to transfer them to another node (via LN Address or Bolt12) from your MDK account, on MDK's website. The MDK infrastructure then issues a request to your MDK node, which only pays if the LN Address/Bolt12 matches one that you provided during the initial config[^2]. This ensures this setup is actually self-custodial, since payments can only be sent to whitelisted destinations. In case anything goes wrong you can also, of course, recover on-chain with the seed phrase and some (yet unreleased?) recovery tool that lets you force close the channel.

A great thing about the MDK Nextjs package is that it is meant to run in serverless environments, thus making it fairly easy to deploy Lightning-enabled apps. For example, it took me around half an hour to build this (quite rudimentary) [tipping page](https://mdk-tips.vercel.app/), built with the MDK and deployed on Vercel. Bear in mind MDK this is still in beta, but it's definitely promising!

## Gossip Observer

Jonathan Harvey-Buschel [shared](https://delvingbitcoin.org/t/gossip-observer-new-project-to-monitor-the-lightning-p2p-network/2105) his work on [Gossip Observer](https://github.com/jharveyb/gossip_observer), a tool for collecting and analyzing Lightning gossip traffic.

Gossip messages are chunks of data exchanged by Lightning nodes, in which they communicate to each other the existence of new nodes or new channels, as well as node updates (e.g. alias change) or channel updates (e.g. fees change). It takes its name from the way this data is propagated across the network in a *gossip*/*flooding* protocol where each peers communicates new data it learned (either by changing something themselves, or by receiving an update from a peer) to all of their peer[^3]. 

The preliminary findings of a short 24 hours data collection are that the time for a gossip message to propagate to 75% of the network has dropped from ~500 seconds in 2022 (obtained with similar measurements) to ~200 seconds today. Also, it appears some nodes are (probably not intentionally) "spamming" the network with unnecessary messages, such as node announcements repeated more than 144 times in the span of 24 hours, while we expect such messages to only be send a few times in the lifetime of a node[^4].

In a following comment, Jonathan also opened a discussion on the opportunity to adopt a design similar to that of [Erlay](https://bitcoinops.org/en/topics/erlay/) (intended to be used for transaction propagation on Bitcoin) for broadcasting gossip messages, where Lightning nodes would first determine what messages an other node is missing, and then only send them those messages instead of broadcasting all messages. However, the approach would have to be adapted to the nature of Lightning gossip, with 3 different kinds of messages and relaxed privacy considerations.

## The Lightning Custody Spectrum

The Validating Lightning Signer ([VLS](https://vls.tech/)) team published an interesting blog [post](https://vls.tech/posts/lightning-custody-models/) about the Lightning custody spectrum. They define 4 levels of custodianship: custodial, shared custody, self-custody and self-custody with validation. The main difference between the last two lies in whether the node's logic is all in the same place, or split between the **validating** signer on the user's device and the rest of the node's features on a remote server. The shared custody, on the other hand, is characterized in VLS' taxonomy by the fact that the signer on the user's device does not validate what is presented to them by the server before signing.

Typically, the MDK package we mentioned earlier in this issue seems to fall into the "self-custody with validation" category, since the embedded node initiates receiving payments, and only accepts to send payments to whitelisted destinations.

## What to expect from this newsletter

Thank you for reaching the end of this issue! I truly hope it provided you as much value as I enjoyed writing it. I want to take this first issue of the Latest Strikes newsletter reenactment as an opportunity to share what I intend to do with this thing, and what pitfalls I intend to avoid, learning from past experiences.

The goal is simple: a concise, technical weekly summary of new developments and discussions in the Lightning Network world. To ensure this works, I've set a few rules to myself:

- issues should be published on Mondays (take this 1st one as the exception to the rule) ;
- issues should not take me more than 2 hours to write, and hence ;
- issues might no be exhaustive.

That's basically it. Thanks again for reading this far, and feel free to reach out on [nostr](nostr:npub1fanjsgy7jghu7d3l5hfq79a3c9kt959x638d5qhjmeeseyr7xp2qert4f0) for comments! Zappy week!

[^1]: You can find all issues except the first ones on LN Markets' [blog](https://blog.lnmarkets.com/), and all issues except a good chunk of the most recent ones on my personal [blog](https://fanismichalakis.fr/categories/strikes/). Thankfully, it overlaps!

[^2]: I'm guessing the option to withdraw on-chain will come later on, for example by specifying a xpub in the app configuration ; and with MDK splicing funds out of the channel(s) as requested.

[^3]: Updates are not sent immediately, but rather batched prior to broadcast.

[^4]: Typically when changing alias or color, or when updating the set of supported features.


Latest Strikes ⚡ S03E01

***Latest*** ***Strikes*** 5 - Oct 9th 2022

Latest Strikes 5 - Oct 9th 2022

improvements for large nodes,
improved wallet backup,
updates to the splicing implementation to match the ***latest*** ... this point, LND notices that the published commitment transaction has one less in-flight HTLC than the ***latest***

***Latest*** ***Strikes*** S03E03 - December 1st - December 7th

*Summary of Lightning Network news for the 49h week of 2025 (December 1st to December 7th)*

Welcome to your weekly summary of noteworthy news and developments in the Lightning Network ecosystem. This issue is a bit delayed because milady and I went on an extended citadel tour. To make up for this, here are a couple pics of those nice castles (*château* in French) we visited.

![](https://m.stacker.news/121508)
*Château de Villerouge-Termenès. Remarkable in that it was not standing on any kind of high ground, but rather next to the village, down a valley. It was used by the Church to house the officers sent by the local Archbishop, which also acted as the local Lord, and store the collected taxes. Also remarkable by its conservation and restoration.*

![](https://m.stacker.news/121511)
*Château de Queribus. Very high ground, never fell.*

![](https://m.stacker.news/121512)
*The view on the Pyrenees from the Château de Queribus* 

And now, on to Lightning! Last week we almost got the *grand slam* with 3 out of the 4 major Lightning implementations shipping a new release. We also got our quarterly vulnerabilities disclosure from the great Matt Morehouse, with 3 LND vulnerabilities disclosed. Let's dive in!

## Core Lightning Release

Version 25.12 of Core Lightning was [released](https://github.com/ElementsProject/lightning/releases/tag/v25.12) bringing:

- significant speed and reliability improvements for large nodes,
- improved wallet backup,
- updates to the splicing implementation to match the latest version of the specification,
- partial (and still experimental) support for Just-in-Time (JIT) channel negotiation as part of the Lightning Service Provider (LSP) specification,
- and of course, many more improvements, bug fixes and new features ([full changelog](https://github.com/ElementsProject/lightning/blob/v25.12/CHANGELOG.md#2512---2025-12-04-boltzs-seamless-upgrade-experience)).

### Speed & Reliability Improvements

With bigger and bigger Core Lightning nodes appeared some bottlenecks addressed in this release. [Optimizations](https://github.com/ElementsProject/lightning/pull/8677) introduced in this release should notably prevent some freezes under high load when trying to inspect a node's operations (using the `bookkeeper` plugin). The `xpay` plugin, responsible for sending payments, also saw improvements with [better handling](https://github.com/ElementsProject/lightning/pull/8688) of multi-parts payments (notably to try to conform with expectations from [Phoenix nodes](https://github.com/ElementsProject/lightning/pull/8537)) and enhanced liquidity management (see [this PR](https://github.com/ElementsProject/lightning/pull/8685)).

### Wallet Backup

New nodes will [now](https://github.com/ElementsProject/lightning/pull/8400) use a 12 words [BIP0039](https://bips.xyz/39) seed phrase as their "master private key" instead of a "bare" 32-bytes secret as was previously the case. Existing nodes still rely on their existing secret.

This also adds support for an optional passphrase and introduces a new derivation format for Taproot wallets, making them standard taproot wallets. Recovering a wallet will also be easier since it can be done directly with the 12-words seed without additional tooling.

### Splicing

Core Lightning upgraded its splicing implementation to be on par with new changes in the specification. Be aware that this is a breaking change, and that if you have splicing enabled[^1] both nodes sharing a channel must upgrade in unisson. See pull requests [8506](https://github.com/ElementsProject/lightning/pull/8506) and [8646](https://github.com/ElementsProject/lightning/pull/8646) for more details.

### LSP JIT Channels Experimental Support

This release also added experimental support for part of the [LSPS2](https://github.com/lightning/blips/blob/master/blip-0052.md) specification, which details Just-in-Time (JIT) channels negotiation. A JIT channel is a channel that is "opened in response to an incoming payment from the public network to a client, via the LSP". Since a new channel is opened by the LSP (incurring a cost for them) concurrently to a payment being received by the client (i.e. the user, which can always refuse the payment by not revealing the preimage), one party has to trust the other one to some extent. The choice is usually made and advertised by the LSP, which depending on its trust and business models will either:

- open the channel first, and trust the client to actually claim the payment so that the LSP can charge it's channel-opening fee on this first payment ;
- have the client reveal the preimage first and trust the LSP to open the channel and push the amount of the payment, minus the LSP's fee, to the client's side of the channel.

In this release a partial version of the specification was [implemented](https://github.com/ElementsProject/lightning/pull/8569), focusing on the LSP-trusts-client model and without support for Multi-Part Payments.

This is still flagged as experimental, but a great step forwards for LSPs decentralization, and positioning Core Lightning as one of the best implementation choices (maybe along with Eclair) for LSPs, especially now that its book-keeping plugin has been further optimized for larger nodes with millions of events.

## LDK Node Release

The Lightning Dev Kit ([LDK](https://lightningdevkit.org/)) is a modular Lightning implementation, meaning that the bare LDK cannot be used as a fully-functional Lightning node by itself. Rather, its modularity allows developers to plug the LDK to whatever data storage, network interface, wallet tools and on-chain data source they see fit. However, the LDK team also maintains the [LDK Node](https://github.com/lightningdevkit/ldk-node), which combines the LDK with the [Bitcoin Dev Kit](https://bitcoindevkit.org/) and other useful tools into a library that can be leveraged to create and interact with Lightning nodes. It's not user-facing (i.e. you can't just "install" the LDK Node), but rather code that can be to integrated an existing stack, but with more batteries included that with the LDK itself.

Last week, both the [LDK](https://github.com/lightningdevkit/rust-lightning/releases/tag/v0.2) and the [LDK Node](https://github.com/lightningdevkit/ldk-node/releases/tag/v0.7.0) repositories got a new release, with many things in common since the LDK Node leverages the LDK. Some of them resonate with the Core Lightning release we just covered:

- experimental [support](https://github.com/lightningdevkit/ldk-node/pull/677) for splicing, compatible with Eclair and Core Lightning ;
- support for the client-trusts-LSP model of the JIT channels negotiation specification (LSP-trust-client was already supported).

On top of this, this releases also bring:

- the [ability](https://github.com/lightningdevkit/ldk-node/pull/526) to source chain data directly from a Bitcoin Core node's REST interface (previously only RPC or Electrum-based server were supported),
- [keysend payments](https://github.com/lightningdevkit/ldk-node/pull/549) (i.e. spontaneous, invoice-less payments where the preimage is created by the *sender* and passed to the recipient (encrypted) inside the onion),
- an initial version of [asynchronous payments](https://bitcoinops.org/en/topics/async-payments/), with now both server and client side support,
- support for zero-fee commitment channels.

## LND Release

LND [v0.20](https://github.com/lightningnetwork/lnd/releases/tag/v0.20.0-beta) brings, among other things, a lot of gossip and topology related enhancements. Notably, the channel graph is [migrated](https://github.com/lightningnetwork/lnd/issues/9795) from the existing key-value database to a more performant native SQL database (this is part of a larger ongoing effort to migrate LND from its legacy key-value database system, which has been a major pain point for larger nodes, to native SQL).

## LND Vulnerabilities

[Matt Morehouse](https://morehouse.github.io/about/) is a software engineer and security researcher currently focusing on improving the security of Lightning implementations, supported by an OpenSats [grant](https://opensats.org/blog/matt-morehouse-lightning-security-lts-grant). He works closely with Lightning implementation to responsively disclose vulnerabilities, then shares the technical details once the embargo period is over.

Last week Matt Morehouse disclosed 3 LND vulnerabilities affecting versions 0.18.5 and below, 2 of which allowed attackers to steal funds from the node. Node operators are **strongly** advised to update their node to version 0.19.0 or later.

### LND: Excessive Failback Exploit #2

This [vulnerability](https://morehouse.github.io/lightning/lnd-excessive-failback-exploit-2/) is a variant of another [exploit](https://morehouse.github.io/lightning/lnd-excessive-failback-exploit/) affecting LND v0.17.5 and below, fixed in v0.18.0 and disclosed by Morehouse back in March of this year. The gist of this vulnerability is that, while routing a payment and under some specific conditions, an LND node could both settle the downstream HTLC (i.e. pay the next node in the route) and fail the upstream HTLC (i.e. refund the previous node in the route) at the same time, leading to loss of funds. This would happen when:

- the downstream node reveals the preimage and claims the HTLC,
- the victim node turns to the upstream node to in turn claim the HTLC by revealing the preimage, but the upstream node doesn't respond,
- in the meantime, the victim and downstream nodes start transitioning from the "in-flight HTLC" state of the channel, to the new state where the value of the HTLC has been sent from the victim's side to the downstream's node side, and the HTLC is not in the channel anymore. The victim node sends its signature for the new commitment transaction to the downstream node, but the downstream node (which now has both signatures for the new commitment transaction) refuses to revoke the previous one and force-closes the channel by publishing the new commitment transaction.

At this point, LND notices that the published commitment transaction has one less in-flight HTLC than the latest valid commitment transaction it holds for this channel. Normally, this wouldn't be a problem because it still remembers that it has already sent the preimage upstream. However, if the node is restarted in the meantime (for example by leveraging a DoS attack vector), it would forget about the preimage, understand the difference between the published commitment and the one in its database as meaning the payment failed, and hence fail the HTLC upstream. The downstream node could therefore claim the HTLC with the preimage, while the upstream node gets a refund for the same HTLC, leaving the victim with a loss.

That's for the previous vulnerability, affecting v0.17.5 and below. The new one disclosed last week is very similar, except that the commitment transaction being published is LND's instead of the downstream node's. The same attack could hence be triggered by the attacker simply by having the victim force-close the channel themselves (which is easy to do, for example by returning an error message).

The mitigation is similar to the one for the previous failback exploit: preventing the failback of an HTLC for which the preimage is already known.

### LND Infinite Inbox DoS

This [one](https://morehouse.github.io/lightning/lnd-infinite-inbox-dos/) is a denial-of-service attack that doesn't directly allows an attacker to steal funds, but can be used that way in conjunction with attacks such as the excessive failback exploit we just covered.

This DoS attack causes the LND node to run out of memory and crash. To do so, an attacker can open many p2p connections to the victim and spam it with messages. Since LND queued up to 1,000 messages per peer and allowed too many peers, with a maximal message size of 64 kB a node with 8 GB or RAM could be remotely crashed in minutes.

The mitigation consists in reducing the queue size (from 1,000 to 50 messages) and allowing only 100 connections from peers without channels.

### LND Replacement Stalling Attack

Leveraging this [vulnerability](https://morehouse.github.io/lightning/lnd-replacement-stalling-attack/), an attacker could steal almost the total capacity of the channel shared with the victim at a fixed cost.

When a channel is force-closed with in-flight HTLCs being routed from A to B, a race begins for node A to have this close transaction confirm before the upstream HTLCs (sent by a previous node to A) expire, or else the value of these HTLCs could be completely lost (they could be refunded to the upstream node(s) while the downstream node(s) (e.g. B) claim the in-flight HTLCs on-chain with the preimage).

To ensure a quick-enough confirmation of the closing transaction, LND uses a *sweeper* which batches the spending of multiple claimable unspent outputs that have the same deadline in one transaction, and aggressively increase the fee-rate of this transaction (though RBF) as the deadline approaches. However, if one of these UTXOs which are being used as inputs of the *sweep* transaction is double-spent while the transaction sits in the mempool, LND crafts a new sweep transaction (leaving out the double-spent output) but mistakenly resets the fee-bumping strategy. An attacker could therefore tamper with LND's sweeper's fee-bumping strategy by sending many HTLCs to themselves through the victim's channel and claiming them on-chain one-by-one using the preimage. Each time the attacker claims an HTLC, LND's fee-bumping strategy resets to the lower initial fees and, with enough in-flight HTLCs and a sufficiently low CLTV delta, the attacker could steal the value of any remaining HTLC(s) at their expiration.

Matt Morehouse gives the example of an attacker opening a direct channel to their victim and sending 40 HTLCs to themselves through this channel, using the minimum default allowed value of 80 blocks for the CTLV delta. The attacker wants to steal the last HTLC, so the 39 others can be as low as the dust limit, and the last one could be as close to the full channel's capacity as possible. Then, the attacker holds the HTLCs until they expire and the victim force-closes the channel. At this moment, the 80-blocks window opens. Since all 40 HTLCs share the same deadline, LND's sweeper batches them as inputs of one sweeping transaction and broadcasts it.

Seeing the transaction in their mempool, the attacker then claims one of the low-value HTLCs on-chain using the preimage. By paying enough fees (estimated by Morehouse at around 4,500 sats/HTLC under current network conditions), the attacker's transaction spending the HTLC replaces the victim's sweeping transaction, which becomes invalid since it tries to spend an output that was already spent. LND would wait one block after the replacing transaction confirmed before crafting and broadcasting a new sweeping transaction that resembles the previous one, just with one less input (the claimed HTLC). Crucially, at this point LND also resets the fee-bumping strategy to the initial lower fees. By repeating this every time LND publishes a new transaction (i.e. every 2 blocks at most), the attacker ensures that LND's sweeper never actually increases the fees. After 80 blocks, the last HTLC standing expires upstream and the sweeping transaction is still unconfirmed. The attacker can then claim both upstream and downstream HTLCs (respectively via the timeout and the preimage paths), stealing the HTLC amount from the victim.

In an "Attack Cost" [section](https://morehouse.github.io/lightning/lnd-replacement-stalling-attack/#attack-cost), Morehouse estimates that this attack could cost as low as ~100,000 sats. Crucially, this cost doesn't scale with the "stealable" amount (nearly the whole channel capacity), making this attack very cost-efficient.

This vulnerability was fixed in v0.19.0 of LND by eliminating the reaggregation delay (the fact that LND would wait for the next block after the replacing transaction confirmed before broadcasting a new sweeping transaction) and not resetting the fee-bumping strategy between broadcasts.

---

That's it for this week. Thank you for reading so far! If you have any comment or feedback, please do share them, I'll read them all. Until next week!

[^1]: Splicing is still marked as experimental in Core Lightning, and hence turned off by default.


Latest Strikes S03E03 - December 1st - December 7th

***Latest*** ***Strikes*** 25 - Feb. 20th-26th 2023

Latest Strikes 25 - Feb. 20th-26th 2023

***Latest*** ***Strikes*** 35 - May 1st-7th 2023

Latest Strikes 35 - May 1st-7th 2023

cryptocoin

***Latest*** ***Strikes*** 69 - January 22nd-28th 2024

🧧 Another OpenSats grant
👛 The best LN self-custodial wallet
💸 Is ecash self-custodial?
🤺 Duels!
💱 Swaps! (🥕 & 🌊)
& more!

Stackers in this issue: @OpenSats @anita @TonyGiorgio @calle @geyserfund @boltz. Missing any? Tag 'em!

As always, baked with 🧡 & ⚡️

Latest Strikes 69 - January 22nd-28th 2024

***Latest*** ***Strikes*** 36 - May 8th-14th 2023

Latest Strikes 36 - May 8th-14th 2023

I got you with this short recap of the ***last*** two weeks in Lightning!

***Latest*** ***Strikes*** 71 - February 5th-18th 2024

Hi SN 🖖

Feeling a bit out of sync? Bored with the COPA v Wright trial? I got you with this short [recap](https://blog.lnmarkets.com/latest-strikes-71-february-6th/) of the last two weeks in Lightning!

❌ No fake L2s
❌ No faketoshi

... but:

☂️ New Umbrel (hard|soft)ware
🥜 Cashu Addresses
🔌 The SN Connection
🚀 Lots of releases
⚡️ A new Lightning wallet
🤝 Dual funding merged
& more!

Stackers in this issue: @calle @egge @koob @ekzyis @BlakeKaufman17 @niftynei

Cheers! 🧡⚡️

Latest Strikes 71 - February 5th-18th 2024

You weekly recap of ***latest*** Lightning news is served!

***Latest*** ***Strikes*** 68 - January 15th-21st 2024

Hey there! You weekly recap of latest Lightning news is served!

We notably explore:

- LSP integration into exchanges
- crowdfunding with Semaphore
- ecash over radio
- LNHANCE
- and we get into some details over the current cluster mempool + package relay + transaction V3 + ephemeral anchors proposal.

As always, baked with 🧡 and ⚡️