Nostr notes by Fanis

Latest Strikes is out! In this issue: - splicing got merged baby ...

2026-04-02T20:50:22Z

Latest Strikes is out! In this issue:

- splicing got merged baby 🥳
- Lexe public release
- Eddy circular rebalancing

and more!

quoting
naddr1qv…ghn3

Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week gave us a finalized splicing specification, Lexe going public, and an uncoordinated off-chain rebalancing protocol.

Splicing

The splicing specification got merged into the main Lightning specification last week! Splicing lets node operators dynamically resize channels without having to close them. This is especially useful for Lightning Service Providers (LSPs), since it lets them onboard a user with a given liquidity, and then adjust it depending on the user's usage. For example, is the user ends up receiving a lot of funds, the LSP can increase the channel capacity in an operation called a splice-in: the channel's on-chain output is combined with external on-chain funds in a transaction that creates a "new" channel with higher capacity, but this new channel retains the initial's channel reputation in the network's topology.
┌──────────────────┐                                 
│     Channel      │                                 
│    User + LSP    ├──────┐                          
│     0.1 BTC      │      │                          
└──────────────────┘      │      ┌──────────────────┐
                          │      │     Channel      │
                          ├──────▶    User + LSP    │
                          │      │     0.1 BTC      │
┌──────────────────┐      │      └──────────────────┘
│     External     │      │                          
│       LSP        ├──────┘                          
│     0.05 BTC     │                                 
└──────────────────┘                                 
The opposite (decreasing the channel capacity) is also possible, in an operation called a splice-out. Of course, in both cases an on-chain transaction is required in order to modify the channel's capacity, but that still a two times improvement compared to closing a channel and then opening a new one -- not to mention the benefits of retaining a channel's reputation through splicing.

Splicing is a highly interactive process between the two peers sharing a channel, with a back-and-forth between the nodes that needed to be codified. After a few years, we now have interoperability between 3 implementations (Core Lightning, Eclair and LDK), which made the feature eligible for inclusion in the main specification¹. Congratulations to all the Lightning devs involved!

StackerNews Discussion

Lexe Public Beta

Lexe announced their public launch, with 2 new features on top of the beta we covered earlier this year, with 2 new features:

BIP353 Human Bitcoin Addresses (HBA), which wrap Bolt12 Offers behind a more readable, email-like address using DNS records ;

Lightning Addresses, which are functionally equivalent but leverage web servers rather than the DNS.

If you're a Lexe user, your HBA and your Lightning Address will be basically the same, just with an extra "₿"suffixing the HBA.

Lexe is a self-custodial Lightning wallet with a LSP, where your node runs inside a Trusted Execution Environment (TEE) in the cloud. Think Phoenix, but your node runs in a trust-minimized cloud server rather than your phone. This allows you to receive even while your phone is off(line).

The launch was also paired with the launch of 2 first SDKs (Python and Rust) for developers. Congrats to the Lexe team on the launch!

StackerNews Discussion

LND

Support for the new Taproot closing flow (where each party can increase the feerate with RBF using their own channel funds) has been enabled in LND. Now LND nodes can collaboratively close Taproot channels using Musig2 signatures, by exchanging nonces during channel shutdown. This addition also includes non rotation for secure RBF scenarios.

Eddy

wactario proposed a practical implementation of one of the mitigations proposed by René Pickhardt against the depletion of liquidity in channel even under perfect circular economy conditions. This solution requires multiple nodes to coordinate in order to replenish liquidity where it's beneficial. This would in theory require a central coordinator with full knowledge of the participants balance, a detail that the Lightning Network doesn't disclose natively.

This implementation consists in a separate daemon called Eddy that must be ran on top of a LND node. It leverages 2 features of LND:

custom P2P messages, which Eddy runners use to advertise their node's channel balances on the gossip network. Other Eddy nodes can collect this data, and look for cycles where every node would benefit from a liquidity displacement ;

LND's HtlcInterceptor and its RESUME_MODIFIED action, where an LND routing node can decide to forfeit its fee and forward the full amount they received from the previous node, to the next node in the route. This lets Eddy nodes join the circular rebalancing movement, as the author explains:

The initiator pays a zero-fee route to itself, each intermediate node’s interceptor forwards the full incoming amount, and the initiator receives back exactly what it sent. If any intermediate node doesn’t waive its fee, the payment fails. Participation is all-or-nothing.

The last remaining question that would warrant the need for a central coordinator is to determine who should initiate the rebalancing, since all Eddy nodes gather (approximately) the same gossip data, and should hence spot the same cycles. The Eddy protocol dictates that a node, finding itself in such a cycle where rebalancing would be beneficial, should only initiate the liquidity circulation if their own public key is the lowest of the cycle. Rebalancing can hence occur without a coordinator thanks to this non-interactive election method, and atomically thanks to the zero-fee circular route.

StackerNews Discussion

That's it for last week. Thanks a lot for reading this far. As always, feel free to reach out with feedback, and until next week!

https://stacker.news/items/1464021

The requirement is actually that 2 independent implementations achieved interoperability. See the specification modification process for more details.

Latest Strikes is out! In this issue: - agentic payments with ...

2026-03-26T18:39:00Z

Latest Strikes is out! In this issue:
- agentic payments with MPP, Spark and Lightning Labs
- John Cantrell bringing MoneyDevKit (cc nick (npub18ps…v73m) ) to Cloudflare Workers
- tiero (npub1w4s…s08a) 's ClawCash gives your agent a wallet
- geyser (npub1kmw…xqk9) 's Rootstock prisms
& also Boltz - Non-Custodial Bitcoin Bridge (npub1psm…8970) blitz (npub1cm3…96wt) & Voltage (npub15kl…4m73)

quoting
naddr1qv…rh8j

Welcome to Latest Strikes, your optimistic-weekly report of the latest Lightning-related news. Last week's thunder was very much AI and payments, but we'll also cover Rootstock prisms and a few other exciting things. Let's dive in!

Are Payment Channels Cool Again?

Agentic payments (the ability for AI agents to pay for things) was the big thing last week, with the launch of the Machine Payment Protocol (MPP) open standard, co-authored by Tempo (a "payment at scale" blockchain) and Stripe (probably the #1 online payment processor). The goal of MPP is to coordinate payments between a client (e.g. your AI agent environment) and a server, while minimizing the added complexity and round trips.

An MPP server uses the 402 HTTP error code ("Payment Required") to signal that a payment is expected to release the requested ressource. The server response also comes with one or many WWW-Authenticate: Payment headers, each containing a payment challenge. The client has to fulfill one of those challenges and provide a proof of such fulfillment in its follow-up request in order to be granted access to the ressource. MPP supports many payment protocols, but with Lighting the header would typically contain a Bolt11 invoice, and the corresponding preimage would be the challenge response, proving that the client paid the invoice.

The MPP launch also brought back to a wider audience the idea that payment channels are especially well-suited for agentic payments, due to their ability to easily handle high-frequency, small amounts payments without delaying settlement.

MPP comes with 2 basic payments "intents": charge and session:

charge: one payment per request,

session: prepay some usage on the first request, and only pay again once the prepaid credit is exhausted. Between payments, a bearer token authenticates the client so that the server can attribute requests to the corresponding balance.

Another neat thing about MPP is how agnostic it is. Not only does it support virtually every payment method (as long as a proof can be provided and easily verified), it also leaves the more intricate details open. For instance, while the immediate implementation of Lightning MPP is to use the invoice's preimage as proof of payment for both charge and session intents (as is the case in Spark's Lightning MPP SDK), one could imagine using Lightning Labs' L402 with macaroons instead. The core idea is the same, but macaroons allow for more flexibility by decorrelating payment reception from payment verification. The Lightning Labs team even seem to have the client part.

Of course, this freedom comes with a price: will both server and client support the same flavor of Lightning MPP? But that's precisely where MPP's ability to issue multiple payment challenges in the same response comes very handy.

MDK Cloudflare

Joh Cantrell released mdk-cloudflare, porting MoneyDevKit (MDK) into Cloudflare Durable Objects. This makes a ton of sense because:

MDK is built around the idea of integrating the Lightning node (LDK) directly into the web app, on the server side, waking up the node on demand ;

Durable Objects are a special kind of Cloudflare workers that combine quick on demand start¹ with a durable storage (as the name implies), perfect to store the Lightning node's state.

Shipping this required "building a custom [LDK] node that compiles to wasm to run on cloudflare’s js runtime", which is a feat the creators of the Mutiny LDK-based web wallet had envisioned a few years ago, assessing it would be possible but also quite a piece of work.

By the way, John also added support for MPP into mdk-cloudflare.

ClawCash

Marco Argentieri built ClawCash, a "wallet" designed to be use by your agent (e.g. OpenClaw, Claude Code, etc.). It runs in a TEE (AWS Nitro), is able to pay and receive on Lightning or various stablecoins through Arkade, and understand things like the MPP protocol. If you give it money, it'll be able to pay other agents or services required to fulfill the tasks with set it to do. Conversely, it can also work for you and charge other agents or even humans.

"Native" Prisms Via Rootstock

The Geyser team announced the release of a self-custodial "prisms" mechanisms, aimed at improving payment reliability while ensuring every participant (creators, affiliates and Geyser themselves) get their cut on donations.

Self-custodially and atomically splitting a Lightning payment between different beneficiaries has been a long-standing difficult problem to solve. The historical practical way to achieve that has been the Lightning Prisms idea, but it relies on Lighting Address server sending funds received to a Lightning Address to a set of other Lightning Addresses, some of which might be "prism addresses" themselves. Each server along the way needs to be trusted to properly split the payment, so this puts "self-custodial" part of the narrative into question.

Geyser approached the problem differently by using the Rootstock sidechain to perform the "business logic" part of the splitting. Each creator, when launching their project, get their own Rootstock wallet. When someone wants to donates to them, their Lightning or on-chain payment reaches Rootstock through a Boltz swap, and is then split between the creator, Geyser and any potential affiliates², via a Rootstock smart contract. When the creator wants to withdraw their funds, they can initiate another Boltz swap from their Rootstock wallet to on-chain or Lightning.

This allows the Geyser team to process payments to creators:

without having to take custody of the funds

without having to run a Lightning node

while taking a share of the payment, and ensuring affiliates can also pocket their part of the revenue.

Prior to this, Geyser relied on hodl invoices to process payments to creators in a self-custodial manner. The creator would provide a Lightning Address beforehand and every time someone wished to make a donation, Geyser would query the creator's Lightning Address for an invoice, wrap this invoice with one of theirs that requested a slightly bigger amount, forward the payment to the creator and pocket the difference. A big drawback of this method was that if the Lightning Address of the creator didn't work, or they didn't have enough inbound liquidity, the donation would fail. With Rootstock prisms, the donation and the final on-chain/Lightning settlement to the creator are two different steps, improving reliability.

Quick Strikes

USDT payments are back in Boltz. Any flavour that is part of the USDT0 standard is supported ;

seems like support for multiple Lightning implementations is coming to ThunderHub. Until now, the OG node interface software only supported LND ;

BlitzWallet shipped an interesting "contact check" feature, letting users quickly verify that they're sending money to the right contact

Voltage is hiring an Infrastructure Engineer!

That's it for last week! As always, thanks a ton for reading this far! Feel free to drop comments or questions below. And until next week!

https://stacker.news/items/1460719

See this article for a better understanding of the challenge Cloudflare Workers tackle.

People who shared the crowdfunding campaign with an affiliate link.

Thanks, glad you liked it! It'll certainly stick in Latest ...

2026-03-26T18:34:25Z

In reply to nevent1q…hqaw
_________________________

Thanks, glad you liked it! It'll certainly stick in Latest Strikes, at least!

Latest Strikes is out! Is this issue: Ark stuff, Liquid <> ...

2026-03-19T21:34:49Z

Latest Strikes is out! Is this issue: Ark stuff, Liquid <> LN swaps, rust-lighting, and laddered timeout-trees and more!

- ArkLabs (npub1hf5…dp8n)
- second (npub1ake…pfwt)
- Blockstream (npub1jg5…6n8n)
- æon (npub1ume…z93q)
- Roy (npub1ey6…szvp)
- Mostro (npub1m0s…40un)
- lightning-rust
- ZmnSCPxj (npub1p2u…74ms) and 8144225309

quoting
naddr1qv…l9xs

Welcome to Latest Strikes, your optimistic-weekly report of the latest Lightning-related news. In this issue, we'll cover Ark updates, Liquid <> Lightning swaps, improvements in rust-lightning, the release of a SuperScalar (aka "laddered timeout-tree structure") implementation, and more!

Arks

Arkade

Ark Labs announced a $5.2M raise, led by Tether, with participation from Ego Death Capital, Anchorage and others. This gives a new impulse to Arkade Assets, Ark Labs' tokens solutions, with an evident focus on stablecoins. Of course, Tether leading the round is a strong indicator, but it's not the first Bitcoin "L2" project to receive support from the stablecoin issuer¹. Up until now, the latest "USDT on Bitcoin" launches usually involved synthetic tokens wrapping actual USDT (as in "USDT emitted by Tether") from other chains, with the promise of a 1:1 convertibility. Whether this will be the same here is an open question, to which we'll probably very soon have an answer².

Rebounding on the announcement, Lendasat teased that something is coming soon™ on their end, that leverages Arkade and Arkade Assets. A few days later, Lendasat also announced a raise, which involved Fulgur Ventures, Initial Capital, but also Ark Labs. Trickle down economics, if you will.

Note: I'm always a bit hesitant to cover stablecoin-related news. Stablecoins have their use and their users, not only in the insular world of DeFi, but also for actual payments. They make sense for users, both merchants and customers, who wish to transact without having to handle the short-term volatility og Bitcoin ; and hence I'm interested to see their usage in payment pools. That being said, they mechanically introduce trust assumptions, which must be clearly laid out. I'm also worried that they could facilitate the enactment of a pseudo-CBDC system.

Second

The Second team shipped a lot of quality of life improvements in v0.1.0-beta.8 of Bark, their implementation of the Ark protocol. Notably:

the Bark server now applies a fee schedule for all sends, including Lightning payments, which varies depending on the age of the VTXO sent, reflecting the increase in liquidity cost to the ASP as a VTXO grows older ;

Lightning overpayments are now allowed (and, of course, credited to the user) instead of failing³ ;

a payment's metadata now includes the preimage (if known), useful for users needing a proof of payment.

LN <> Liquid Swaps

Jade

Blockstream launched "Jade Lightning Payments", enabling users of the Jade hardware wallet to protect their balance accrued from Lightning payments received and swapped to Liquid with their signing device. The public key is saved on the Blockstream app, so the hardware signer is not required for receiving. Sending however, including on Lightning through another Boltz swap, requires signing the transaction with the Jade device.

Strictly speaking, this is more of a Liquid feature than a Lightning one, but if you're going to use LN <> Liquid swaps (with Blockstream App or Aqua for example), you might as well protect your funds with a hardware wallet at rest.

Ibis

aeon shared a sneak peek of their integration of "Lightning payments" inside Ibis wallet, using Liquid swaps. You can think of Ibis as the "Sparrow for mobile", so I find it interesting that it's dipping its toe in Lightning, since it makes more sense for a mobile wallet than for a desktop one (which Sparrow is).

LNURL-Verify in Breez

The Breez SDK now supports LNURL-Verify, which lets the consumer of a LNURL Pay link to also check with the LNURL server whether the invoice has been successfully paid or not. This is commonly used to build point of sale, such as elsirion's LNURL PoS: without the "verify" part, the merchant would have to check their wallet for every transaction. LNURL-Verify lets the PoS check for the merchant, and also provides a useful feedback to the customer.

To showcase the LNURL-Verify support, Roy from Breez built glow-pay, a standalone web-based PoS.

NWC in Mostro

Version v1.2.1 of Mostro (a decentralized peer-to-peer Bitcoin trading platform) brings Nostr Wallet Connect (NWC) support, making trades even more seamless. From my experience, Mostro is sadly lacking liquidity, but it's also the hardest part to crack. With the Mostro team relentlessly improving the user experience, hopefully this mobile-first complement to Robosats catches on.

Improvements in rust-lightning

Trampoline

The rust-lightning team laid the ground for Trampoline routing last week. The Bitcoin Optech did a great job covering it. Basically, last week's commits implement the required logic for a trampoline routing node to properly claim or fail HTLCs, as well as handle trampoline claims on restart.

Dust Limit

When using anchor outputs, the HTLC transactions (i.e. HTLC-success or HTLC-timeout) are presigned without fees, and rely on being spent with additional inputs in order to pay a reasonable fee⁴. This means that the trimming logic prevailing in legacy (i.e. non-anchor) channels, where an HTLC would be removed from the commitment transaction if it couldn't pay its fees, must be replaced. This is achieved via the dust_limit_satoshis variable negotiated when opening a channel, which indicates the minimum value that an output must carry in order to be considered economically viable and be included in the commitment transaction.

Since HTLC outputs require an additional transaction to be spent (the HTLC-success/timeout transaction), the Lightning specification was recently updated to explicitly state that the dust limit used by Lightning implementations should be higher than that of the underlying Bitcoin node (e.g. Bitcoin Core) in order to account for this extra weight. This means that Lightning implementation must be permissive enough when it comes to dust limit negotiation when opening an anchor channel, while still being restrictive enough to prevent a class of griefing attacks.

Until last week, rust-lightning lacked some permissiveness, which could lead to nodes refusing to establish channels if the counterparty requested a "big" dust limit. This was fixed by allowing a higher dust limit (up to 10,000 sats) for anchor channels, while the dust limit for legacy channels is still capped at 546 sats⁵.

SuperScalar

This is probably the thing that caught my attention the most last week: a SuperScalar implementation!

SuperScalar is a channel factory design proposed by ZmnSCPxj, and it seems another hashling⁶ going by the name 8144225309 has stepped in to release an implementation, as well as very nice website explaining the technical details around this scalability solution.

To put it in a nutshell, the goal of SuperScalar is to help scale Lightning by going from a world where every channel is a UTXO (and hence, only 2 users share one UTXO) to one where one UTXO can be the backbone of many channels (and hence, say 8 users share one UTXO). SuperScalar is designed to work with today's Bitcoin rules, leveraging N-of-N multisignature (using Musig2) and timelocks, and coordinated by a Lightning Service Provider (LSP), but could scale even better with covenants like OP_CHECKTEMPLATEVERIFY (CTV) or SIGHASH_ANYPREVOUT (APO).

SuperScalar is structured like a tree. Let's take the example of factory with 8 users:
                                                                         ┌──────────────────┐                                                                          
                                                                         │       Root       │                                                                          
                                                                         │      9-of-9      │                                                                          
                                                                         │                  │                                                                          
                                                                         └─────────┬────────┘                                                                          
                                                                                   │                                                                                   
                                         ┌─────────────────────────────────────────┴────────────────────────────────────────┐                                          
                                         │                                                                                  │                                          
                                         │                                                                                  │                                          
                                         │                                                                                  │                                          
                                ┌────────┴─────────┐                                                               ┌────────┴─────────┐                                
                                │       Left       │                                                               │      Right       │                                
                                │   A...D + LSP    │                                                               │   E...H + LSP    │                                
                                │                  │                                                               │                  │                                
                                └────────┬─────────┘                                                               └────────┬─────────┘                                
                     ┌───────────────────┴─────────────────────┐                                       ┌────────────────────┴─────────────────────┐                    
           ┌─────────┴────────┐                      ┌─────────┴────────┐                     ┌────────┴─────────┐                      ┌─────────┴────────┐           
           │    Left-Left     │                      │    Left-Right    │                     │    Right-Left    │                      │   Right-Right    │           
           │   A + B + LSP    │                      │   C + D + LSP    │                     │   E + F + LSP    │                      │   G + H + LSP    │           
           │                  │                      │                  │                     │                  │                      │                  │           
           └────────┬─────────┘                      └─────────┬────────┘                     └────────┬─────────┘                      └────────┬─────────┘           
          ┌─────────┴──────────┐                   ┌───────────┴─────────┐                  ┌──────────┴───────────┐                  ┌──────────┴──────────┐          
╔═════════╧════════╗ ╔═════════╧════════╗ ╔════════╧═════════╗ ╔═════════╧════════╗ ╔═══════╧══════════╗ ╔═════════╧════════╗ ╔═══════╧══════════╗ ╔════════╧═════════╗
║    Channel A     ║ ║    Channel B     ║ ║    Channel C     ║ ║    Channel D     ║ ║    Channel E     ║ ║    Channel F     ║ ║    Channel G     ║ ║    Channel H     ║
║     A + LSP      ║ ║     B + LSP      ║ ║     C + LSP      ║ ║     D + LSP      ║ ║     E + LSP      ║ ║     F + LSP      ║ ║     G + LSP      ║ ║     H + LSP      ║
║                  ║ ║                  ║ ║                  ║ ║                  ║ ║                  ║ ║                  ║ ║                  ║ ║                  ║
╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝ ╚══════════════════╝
Each node in the tree is a N-of-N multisignature output, but crucially N decreases as we go down the tree (from the root to the leaves⁷), which means that local changes do not need the signatures of all 9 members of the tree. The leaves (represented with double stroke) are actual Lightning channels (Poon-Dryja), just not backed by an on-chain UTXO, but by a Decker-Wattenhofer channel (such as "Left-Left" for example). Unlike Poon-Dryja (PD), which relies on a penalty-based mechanism to prevent misconduct, Decker-Wattenhofer (DW) uses decreasing relative timelocks on every state update to ensure that the most recent states always becomes valid first. A major limitation of DW is that it hence reduces the number of state updates: if you want one day (144 blocks) between two timelocks to ensure other parties have sufficient time to react, but don't want to block the first state update for more than 3 days (432 blocks), then you can only have 4 states and 3 state updates (s0(432) --> s1(288) --> s2(144) --> s3(0)). This is impractical for actual payment channels, but still manageable for channel factories (mother channels, if you will), where every updates opens, closes or resizes a (daughter) channel.

SuperScalar expands this number of channel updates by leveraging its tree structure to form an "odometer": every DW channel is only allowed 4 states (3 updates), but a parent DW channel only needs to transition from one state to another when one of its two child DW channels has exhausted it's 3 state updates. When this happens, the parent channel consumes one state update, but the child's counter resets. With 3 layers, the number of channel updates jumps to 64. The only downside is that updating a parent channel requires cooperation from the other child's users, and if a child DW channel updates far more frequently that its sibling, it imposes its cadence to its sibling.

This is a very nice setup: end-user channels are regular Lightning channels with an LSP, enabling them to transact easily with the rest of the network while retaining full self-custody. Channel operations (including resizing) are performed off-chain, except for the initial transaction funding the factory. Factories are short-lived (~30 days), but users have a 3-days window during which they can migrate to the next factory. A LSP can have 33 factories at the same time, with staggered lifetimes (1 factory dies and 1 factory is born each day), each serving 8 users, for a total amount of 264 users, at the cost of 1 on-chain transaction per day. This cost is diluted across the multiple off-chain channel operations that this setup enables, making it especially cost-efficient for high-usage LSPs.

There are of course many more details(Zero-UTXO onboarding, migrations(including across different LSPs), etc.), which are extensively and very clearly covered on the SuperScalar website. All things considered, this is a very interesting scheme, with very high self-custody guarantees and a nice scaling improvement factor. As far as I understand, the main drawbacks are:

worst worst case scenario when it comes to settling on-chain, compared with classic Lightning ;

the LSP must commit funds that will be used in the factory beforehand (including funds for splicing-in into channels).

It's very nice to have a reference implementation, and I'll certainly play around with it!

That's it for today! Thanks a lot for reading this far, and see you next week!

https://stacker.news/items/1457117

TaprootAssets, RGB, etc.

Arkade Assets basically commit assets metadata and transactions into in Ark VTXOs (that can be committed on-chain eventually), using OP_RETURNs. Asset balances are tracked by indexers, using the data in said VTXOs. My understanding is that users are expected to run their own private, small indexer in order to track their own balances ; while the general balance is handled by a public Arkade Indexer (especially to track balances across Ark and on-chain). To dig deeper, check the specification.

The Lightning specification allows a payment to send up to twice the amount requested in the invoice. The primary use case for this is to increase privacy, reducing "information leakage by altering the amount" in a "limited" amplitude. Another use case is tipping.

See Bolt05. This is enabled by HTLC transactions using the SIGHASH_SINGLE|SIGHASH_ANYONECANPAY flags, allowing them to be combined with other transactions.

It matches Bitcoin Core's default dust limit for P2PKH outputs.

That's what I decided to call these enigmatic pseudonymous developers with barely pronounceable names.

Should we say "up the tree"?

Latest Strikes is out! 🚀 In this issue we take a close look at ...

2026-03-10T20:03:46Z

Latest Strikes is out! 🚀

In this issue we take a close look at the recent cakewallet (nprofile…xssz) release. We also cover Boltz - Non-Custodial Bitcoin Bridge (nprofile…3478) mandatory update for Boltz Client and BTCPay plugin, as well as changes in LND, LDK and Eclair.
Enjoy!

quoting
naddr1qq…9r3l

Welcome to Latests Strikes, your optimistic-weekly report of the latest Lightning-related news. In this issue, we'll cover a wallet release that made some noise last week (dare I say it also sparked some controversy?), share the word about a mandatory Boltz update, and review some implementations developments.

Wallets & Tools Releases

Get Some Cake

Cake Wallet rolled out Lightning support last week! A long-awaited addition to the infamous privacy-oriented wallet, this integration leverages Spark to connect users to the wider Lightning network. This sparked some controversy around the use of the term "self-custodial" to qualify this "Lightning" setup, as well as questions around its privacy tradeoffs.

Spark uses a technology called statechains. In a statechain, the ownership of an on-chain UTXO is transferred between users with the help of a central server (or set of servers), known in Spark as the Spark Entity (SE). To achieve this, the private key that can spend the on-chain UTXO is split into 2 "shards" - one for the SE and one for the user. When the user (say, Alice) wants to send the funds to another user (let's call them Bob), the SE deletes their previous shard and collaborate with Bob to derive a new set of shards that still add up to the same underlying private key.

There are very legitimate critics that can be made around Spark's self-custodial qualification. The main point is that users are trusting the Spark entity (and thus its individual constituents, the Spark operators) to actually run the open source code they claim to be running. You trust them to delete "expired" keys and not collude with past owners of the statechains¹. To make things worse, the first owner in the statechain is often the Spark entity itself, or a partner of the Spark entity.

To put it another way: Spark lacks the guaranteed self-custody that pre-signed transactions provide in Lightning². Calling it self-custodial is, I think, a stretch we should be warier of making.

That is not to say that Spark isn't useful. I've been a proponent of statechains back when Mercury Layer was around (more on them later). I believe it solves a transitory problem of Lightning:

Lightning requires new users (or their service providers) to commit funds ahead of time while their Lightning usage is still unclear ;

Lightning is a solution to a problem that isn't evenly distributed yet (instantaneous Bitcoin payments).

The transitory nature of the problem Spark solves is hence twofold, with both faces of the coin strongly coupled. Lightning works remarkably fine for users who already need to perform instantaneous Bitcoin payments on a weekly/daily basis. It has very strong self-custody guarantees, and reasonable privacy assumptions. For these users, it makes sense to commit funds to a channel, just as it makes sense to have funds in a checking account. However, if you just want to receive your first bitcoins on Lightning and have no idea yet of when, where or whether you'll spend them at all, or you're dealing with fairly small amounts (e.g. pocket change), then indeed Lightning is too much, and Spark makes much more sense:

it let's newcomers play around with Lightning payments with no significant commitment ;

the trust assumptions are more okay-ish when dealing with pocket change ;

users can later graduate to an actual Lightning wallet if their Lightning usage increases.

Regarding the privacy implications of using Spark, it is important to note that right now the Spark entity can see every transaction. This can be changed by using blind signing (which Mercury Layer did), and Seth from Cake stated that they'll keep pushing heavily for Spark to prioritize this development. However, given Spark track record around privacy, I am inclined to take this with a grain of salt.

TL;DR: Lightning via Spark in Cake Wallet is a great and useful development, but it's not "self-custodial" Lightning, and privacy guarantees are always preferable to privacy promises.

StackerNews Discussion

Boltz Mandatory Update

If you're running the Boltz client or BTCPay plugin, you should update to at least versions 2.11.1 and 2.2.20 (respectively), both released last week, before April 15th. Passed this dateline, older versions will stop working with Boltz' backend.

X Post

Implementations Thunder

LDK: Contributing to Splice as Acceptor

Rust Lightning fixed an issue where in some cases the acceptor would not contribute to a splice. This arose when both parties wanted to splice simultaneously: in order to get things going, one of them would be picked, at random, to be the splice initiator ; the other party would then not contribute to this splice session, necessitating a second session in order to get their changes added.

PR 4416 fixes this by making the acceptor contribute directly to the elected initiator's splice. Since the acceptor pays for less things in the splice transaction, the fees contributed by the accepting party are reduced to match their desired feerate, and the excess is moved into their change output.

LND: Aux HTLC Validator

Under some timing conditions, several HTLCs could be added to the same channel and overflow the channel's bandwidth limit. An auxiliary HTLC Validator is added to LND to ensure routing is performed with an up-to-date view that includes all the not-yet-committed HTLCs. Those HTLCs are now taken sequentially, and once the bandwidth threshold is reached remaining HTLCs are failed.

Eclair: Interactive Transactions Validation Plugin

PR 3258 introduces a new plugin connector in Eclair for fine-grained control over UTXOs and addresses involved in interactive transactions (e.g. funding channels, closing channels, splicing). This can for example be used to automatically force-close channels³ based on certain operator-defined heuristics (such as usage of blacklisted UTXOs, or sending to blacklisted addresses), as demonstrated by this example plugin.

That's it for today, I hope you enjoyed this issue! As always, feel free to drop any feedback in the comments or by reaching out on social media. Thank you so much for reading this far, and until next week!

https://stacker.news/items/1451608

It is important to stress out here that if they collude with a past owner (or are themselves a past owner), the Spark Entity can spend the funds instantly, without having to wait for any timelock. Timelocks are present in statechains, but only as an unilateral recovery path for users. If both as past owner and the SE collude to spend the funds by combining their respective shards, they can do so without any timelock, leaving the user with no recourse. See for example the discussions around this post for more details.

Note that on the self-custody spectrum Ark is hence much closer to Lightning. The base Ark protocol gives similar self-custody guarantees (since the user always has pre-signed transactions they can use to unilaterally exit). The more practical flavors of Ark (e.g. with out-of-round transactions) introduce opt-in trust requirements. See Shinobi's recent X thread.

The plugin immediately force-closes channels (before they gather enough confirmations to become usable) rather than refusing to cooperate in the transaction because "in some cases only the remote node has access to the fully signed transaction" (see here). I believe in Acinq's case such a situation can arise when dealing with splice-out that sends funds to sanctioned addresses. It should be also possible to optimistically try to reject "infringing" channel operations at the negotiation level.

Latest Strikes is out! This issue covers 3 weeks, so it's a ...

2026-02-18T19:04:00Z

Latest Strikes is out! This issue covers 3 weeks, so it's a big one, and it even got some drawings!

Featured in this issue:
- Voltage (npub15kl…4m73) & SDM
- Lexe
- Amboss (npub19tc…nlea)
- Alby (npub1get…0nfm)
- MoneyDevKit (cc nick (npub18ps…v73m) )
- Clams (npub136h…th6q)
- Nadav Kohen
- Super Testnet (npub1yxp…399s)

quoting
naddr1qv…r8p5

Welcome to your weekly summary of the latest news and developments in the Lightning Network world. We did not publish in a while, so this issue covers 3 weeks, from January 26th to February 15th. Let's dive in!

$1M Lightning Payment Settled

On Wednesday 28th January, Secure Digital Markets sent a 1 million dollars transaction to Kraken, leveraging Voltage's infrastructure. The payment settled in 0.47 seconds, per Voltage's X post.

Now of course the transaction very likely went through a single big direct channel between SDM's Voltage node and Kraken. But still, the $1M mark is loud enough that it sends a clear signal that Lightning can indeed be used for large, enterprise-scale transactions, and not only for micropayments, as it is sometimes misconceived to be. Of course, a transaction of this size could have been conducted on-chain¹. But even outside of the PR operation, conducting such transaction off-chain can make sense, for example:

to preserve some degree of confidentiality around the exact flows of funds ;

to be able to achieve instant settlement by committing funds beforehand, while still retaining self-custody as long as they're on SDM' side of the channel² ;

to act as a blazingly fast "clearing house" that is setup once, and can be reused numerous times for free.

StackerNews Discussion

Bolt12 In Lexe

Lexe added support for Bolt12 Offers, enabling users to receive funds to a static Lightning payment identifier. Since Lexe leverages Trusted Execution Environments (TEEs) to run users' nodes in the cloud, the user is not required to have the Lexe app open, nor their phone to be even connected to the internet or powered on, for a payment to successfully settle. This contrasts with other Bolt12-enabled wallets such as Phoenix, where the user's device is needs to be connected for the payment to settle (or even to begin, since the first step with Bolt12 Offers is for the sender's node to reach out to the recipient's to request a Bolt11 invoice)³.

All the user needs to do is get their Bolt12 Offer in the Lexe app, and then share it to receive payments. If you want to try it out and support my writing at the same time, you can give it a try with the offer below (wink).

lno1zr5qx998w53arh9utk6kpq0de0py4wpqkd0rgwnvva53wm08qlqh34zhqvhuz7pmelcx8e7anetk7k807knc0728983e3g6djpdwhfzgaejfuqsrs8ugw9ke824eqd6grqn98jvn4frrzuj35250m47wncwt597fvazsqvey2jllxhsee5xfsh0zenf50tvlgut7epj29q8k74mg4e7qanvfaup0zvrms4un52ye83spafdreavc8kxxqvfduy4v0l3hssgn2ezj22262yqd29jp09yc2m8pvl0whhj4s4emxqpva0x489kks6muwf5kp6ejcnx53qh9d28nl9u8gyq5ltjqvmr07yt66c98rk6dx650mrnum7qkyypdmuskxsr6pkr62qhfuukrt4pjtrak6x7g5gkclxd7vvuwxkdc4cs

StackerNews Discussion

Amboss Reveals RailsX

Amboss revealed RailsX, an extension to their Rails product bringing stablecoins into the mix.

Rails is first and foremost a "self-custodial" yield product built on top of Bitcoin's Lightning Network⁴. Liquidity Providers (LPs) deposit bitcoins into a Lightning node, and give Amboss permissions to perform a limited set of actions, such as viewing the details of the node, opening and closing channels, adjusting the routing policies of channel, or creating an invoice. Crucially, this permissions don't include paying invoices or sending to an on-chain address. Such fine-grained permissions are enabled by LND's macaroons system. The LND node itself can either run in the cloud (powered by Voltage), or run on the LPs premises. Once everything is setup, Amboss leverages its "machine learning algorithms"⁵ to deploy liquidity in the right places. In other words, from a LP point-of-view, things can be as simple as launching a node in the cloud, topping it up and letting Amboss take care of generating the yield.

RailsX extends this by adding stablecoins support. From what I grasp, the offering caters to both stablecoin issuers and stablecoin holders. RailsX helps the former distribute their token across the "Rails cluster", making it available for real payment usage ; and lets the latter earn yield by deploying the stablecoins they own in optimized spots to maximize routing revenue. As of today, it remains unsure which stablecoins will be available, but a requirement is that they are deployed on LND's Taproot Assets (TapAss) protocol⁶.

The "consumer" use cases of RailsX are twofold:

they enable stablecoin payments (e.g. a customer could send sats and the merchant receive their favorite stablecoin, by going through one the RailsX nodes) ;

they enable a form of self-custodial decentralized trading, which is basically an extension of the above payment use case where the customer and the merchant are the same person: a trader can select an available order published by a RailsX (e.g. 100 USDT in exchange for 100,000 sats), and compute a route that goes through this node and back to themselves, enabling P2P, atomic and self-custodial trading by leveraging TapAss and HTLCs.

Trader --- 101,100 sats --> Alice --- 101,090 sats --> Counterparty --- 100.09 USDT ---> Bob --- 100.00 USDT ---> Trader

Crucially, routing nodes on one side of the route (using the counterparty as the pivot) need to be TapAss aware in order to be able to route tokens. It's hence very likely that trading will mostly take place inside the RailsX cluster, at least in the beginning.

Lightning Sandbox && Agent Wallet

The Alby team blessed us with a new fantastic Lightning playground last week! The Alby Sandbox lets you easily play with different scenarios, ranging from a simple invoice payment to subscriptions, payments prisms or wrapped invoices. Everything happens in the browser, and leverages Nostr Wallet Connect to interact with the different Lightning wallets that are part of a given scenario.

using Alby's faucet means that you're given a sub-wallet (ie, an account) on one Alby Hub instance dedicated to serving the sandbox. There are no channels between these sub-wallets. Rather, they leverage Alby Hub's self-payment capabilities to "emulate" actual payments going through channels, meaning things like HODL invoices still work the same as in an actual channel (modulo the fact that the funds are, at all time, cryptographically controlled by the operator of the underlying Lightning node). You can also connect a real Lightning wallet through NWC, for example if you're running your own Alby Hub. But you can't of, course, send payments between a real wallet and a "virtual" one, since the sandbox's Alby Hub doesn't have any channel.

The Alby Sandbox also comes with an AI dimension, enabling users to create scenarios via plain-text prompts. As a matter of fact, the Sandbox itself was built using Claude Code leveraging the Alby Agent Skill, which tells the agent everything its need to know about NWC, LNURL or WebLN.

Speaking of Agents, MoneyDevKit also joined the party with the Agent Wallet, an AI agent skill that lets agents run their own self-custodial Lightning wallet - in similar way that MoneyDevKit lets you run a Lightning node inside your NextJS or Replit web app.

Clams

Clams V1 beta is live, with a full Rust rewrite of the core logic, and a huge focus on accounting. Clams (cloud or self-hosted) lets you bring your own node (Electrum, Esplora or Bitcoin RPC) and connect multiple wallets (incl. Lightning wallets, notably through NWC) to generate capital gains records, balance sheets, portfolio summarizes and full audit records.

Nested MuSig2

Nadav Kohen from Chaincode Labs published a paper on Nested MuSig2. The goal of this paper is to establish that the security and efficiency benefits of Musig2 can be conserved by using aggregate Schnorr signatures obtained with Musig2 as inputs of another Musig2 aggregation. The security of such an operation was always assumed, but so far no paper had formalized an actual signature scheme for Nested Musig2.

For more context on Musig and Musig2, see this Optech Summary.

Nested Musig2 could play an important role in multi-party contracts protocols (such as Lightning, Ark, etc.). A very direct and pragmatic outcome for Lightning is that it would enable a simple mechanism for signing and verifying simple taproot channels announcements.

When verifying the announcement of a channel between Alice and Bob, a Lightning node wants to check that:

Alice's node owns a Bitcoin key alice_bitcoin_key

Bob's node owns a Bitcoin key bob_bitcoin_key

the channel funding transaction pays to alice_bitcoin_key and bob_bitcoin_key

The latter is verified by finding the on-chain transaction thanks to the short channel id (which indicates block height, transaction index and output index) and verifying that the script hash matches an OP_CHECKMULTISIG with those keys.

Verifying the ownership of the keys is done by having the channel announcement message⁷ be signed by 4 keys:

alice_bitcoin_key

bob_bitcoin_key

alice_node_key, which corresponds to the public key identity of Alice's node

bob_node_key, which is the same for Bob

This ties the node identities to the on-chain funds underlying the channel, which allows other nodes to verify that:

the announced capacity matches the amount committed to the channel

both peers agreed on opening the channel and routing through it

With Taproot channels, things get a little bit trickier because the funding transaction pays to a P2TR output like OP_1 <taproot_output_key>. The taproot_output_key will most likely be a Musig2 aggregate of multiple keys belonging to the parties, with a least 1 key from each party, but it can be more subtle than a 2-of-2, paving the way for threshold-based channels. The channel announcement verification hence becomes verifying the Musig2 signature of a key resulting from the Musig2 aggregation of alice_node_key, bob_node_key and taproot_output_key. Since taproot_output_key is a Musig2 aggregate itself, Taproot channels announcement would require a Nested Musig2 scheme, such as the one this paper provides.

Of course, Lightning developers have not waited on Nested Musig2 to start working on Taproot channels announcements. The (still draft) specification explores the Nested Musig2 path for when schemes such as Kohen's will be widely available, but also devises a practical solution in the meantime that all implementations can work on, which aggregates (with Musig2) the four keys used in P2SWH channels, and specifies how the `taproot_output_key should be derived from the alice_bitcoin_key and bob_bitcoin_key keys.

Connector Swaps

Supertestnet made an interesting proposal earlier last January that I had missed. Luckily, Scoresby resurfaced this gem on StackerNews, so I figured I'd cover it in this issue. Connector Swaps are a new kind of Lightning-to-bitcoin protocol (sending funds from a Lightning channel to a Bitcoin address, without closing the channel), bridging the benefits of swaps and splices while removing some of their disadvantages.

Swaps: don't change the channel capacity, but they require two on-chain transactions per submarine swap ;

Splicing: requires only one transaction, but changes the channel capacity (note that sometimes this is the result sought).

We can also mention PeerSwap here, which is basically a swap (as you'd do on Boltz), but with your channel partner directly. This makes it easier to reliably perform the swap (no routing), and theoretically decentralizes swaps away from central coordinators. Since they're regular submarine swaps, PeerSwaps require two on-chain transactions per swap, with one transaction "opening" the "smart contract", and a second claiming the funds. This has two drawbacks:

increased on-chain cost

if the swap is interrupted between the two transactions, the counterparty that created the on-chain smart contract loses funds to on-chain fees without gaining anything in return.

Connector Swaps addresses both limitations, while still adhering to this idea of performing swaps with your direct peers.

As the name implies, Connector Swaps leverage connector outputs (which were popularized by the Ark protocol) to achieve capacity-preserving Lightning-to-bitcoin swaps in only one transaction. Before we go deeper, SuperTestnet also gives a clear and concise reminder on what a connector output is:

a connector output is a bitcoin utxo, typically small (e.g. a segwit output at the 294 sat dust limit qualifies), which allows users to conditionally “revoke” presigned bitcoin transactions. They require a setup procedure, which consists of adding the connector output to a bitcoin transaction as one of its inputs, and then signing it. This procedure creates a presigned transaction that can be revoked in the following manner: if anyone “spends” the connector output, one or more of the signatures in the presigned transaction become “revoked,” or invalidated, because a bitcoin signature is invalid if it signs a transaction with an input that has already been spent

Now, let's consider a scenario where Alice wants to send 20,000 sats from her channel with Bob, to the Bitcoin address of her friend Carol. What Alice wants to achieve is:

push 20k sats (plus fees) to Bob's side of the channel ; and at the same time

use one of Bob's UTXOs to send 20k sats on-chain to Carol ;

if Bob stops responding mid-swap, be able to recover her 20k sats sent in the channel.

Bob wants to:

help Alice perform the swap in exchange for a small fee ;

if Alice stops responding mid-swap, not lose his 20k sats.

Let's say Bob charges 1,000 sats for the swap. To achieve their stated goals, Alice and Bob co-sign an off-chain transaction (inside their channel) that creates a new output of 21k sats, that is still a 2-of-2 multisig (we'll call it the "shared output"). They then co-sign 2 competing off-chain transactions that both spend this output: one to allow Alice to recover her funds, and the other to enable Bob to do the same.

Alice's recovery transactions spends the shared output and a dust output that she controls (the connector output) to create a 21k sats output that she controls.

Bob's recovery transaction spends only the shared output, creating an output that Bob can spend alone but after a timelock (e.g. 10 blocks) expires.

Once this 3 off-chain (still unpublished) transactions are signed by both parties, they collaborate to create a fourth transaction, called the "payment transaction", which will effectively send funds to Carol. This transaction consumes one or many of Bob's UTXO(s), as well as Alice's connector output. It sends 20k sats to Carol's address, and creates a new connector output for Alice, which can be used later for a future swap. Once the payment transaction is confirmed, the initial connector output ceases to exist, rendering Alice's recovery transaction invalid, and hence the only available path is Bob's recovery path. This means that if the channel was to close at this point, Bob's would be able to recover his 21k sats that Alice still owed him inside the channel. Of course, if both parties behave honestly, the 21k sats off-chain UTXO is resolved inside the channel, moving the funds to Bob's side.

On the other hand, if for any reason Bob doesn't publish the payment transaction and stops responding, then Alice can close the channel and claim her 21k sats back using her recovery transaction.
                               ┌──────────────┐   
                               │     79k      │   
                               ├──────────────┤   
                               │   Channel    │   
                        ┌─────▶│    2-of-2    │   
  ┌──────────────┐      │      └──────────────┘   
  │     100k     │      │                         
  ├──────────────┤      │                         
  │   Channel    │      │                         
  │    2-of-2    │──────┤                         
  └──────────────┘      │      ┌──────────────┐   
                        │      │     21k      │   
                        │      ├──────────────┤   
                        │      │ Swap Output  │   
                        └─────▶│    2-of-2    │   
                               └──────────────┘   


┌────────────────────────────────────────────────┐
│ 1. Creation of the swap output in the channel  │
└────────────────────────────────────────────────┘
   ┌──────────────┐                                 
   │     21k      │                                 
   ├──────────────┤                                 
   │ Swap Output  │                                 
   │    2-of-2    │───────┐       ┌──────────────┐  
   └──────────────┘       │       │     21k      │  
                          │       ├──────────────┤  
                          │       │   Recover    │  
                          ├──────▶│    Alice     │  
   ┌──────────────┐       │       └──────────────┘  
   │  Connector   │       │                         
   │ Output Alice │───────┘                         
   └──────────────┘                                 






  ┌──────────────┐                 ┌──────────────┐ 
  │     21k      │                 │     21k      │ 
  ├──────────────┤                 ├──────────────┤ 
  │ Swap Output  │                 │   Recover    │ 
  │    2-of-2    │───10 blocks────▶│     Bob      │ 
  └──────────────┘    timelock     └──────────────┘ 

┌──────────────────────────────────────────────────┐
│     2. Creation of the recovery transactions     │
└──────────────────────────────────────────────────┘
      ┌──────────────┐          ┌──────────────┐    
      │     20k      │          │     20k      │    
      ├──────────────┤          ├──────────────┤    
      │     Bob      │          │    Carol     │    
      │              │─┐    ┌──▶│              │    
      └──────────────┘ │    │   └──────────────┘    
                       │    │                       
                       ├────┤                       
      ┌──────────────┐ │    │   ┌──────────────┐    
      │  Connector   │ │    │   │New Connector │    
      │ Output Alice │─┘    └──▶│ Output Alice │    
      └──────────────┘          └──────────────┘                                      

┌──────────────────────────────────────────────────┐
│      3. Creation of the payment transaction      │
└──────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│                                                                                         │
│                                 ┌──────────────┐                                        │
│                                 │     79k      │                                        │
│                                 ├──────────────┤                                        │
│                                 │   Channel    │                                        │
│                          ┌─────▶│    2-of-2    │                                        │
│    ┌──────────────┐      │      └──────────────┘                                        │
│    │     100k     │      │                                                              │
│    ├──────────────┤      │                                                              │
│    │   Channel    │      │                                                              │
│    │    2-of-2    │──────┤                                                              │
│    └──────────────┘      │      ┌──────────────┐                ┌──────────────┐        │
│                          │      │     21k      │                │     21k      │        │
│                          │      ├──────────────┤                ├──────────────┤        │
│                          │      │ Swap Output  │   10 blocks    │   Recover    │        │
│                          └─────▶│    2-of-2    ├────timelock───▶│     Bob      │        │
│                                 └──────────────┘                └──────────────┘        │
│                                         │                                               │
│                                                                                         │
│                                         │                                               │
│                                                                                         │
│                                         └ ─ ─ ─ ─ ─ ─ ─                                 │
│                                                        │        ┌──────────────┐        │
│                                 ┌──────────────┐                │     21k      │        │
│                                 │  Connector   │       │        ├──────────────┤        │
│                                 │ Output Alice │─ ─ ─ ─ ─ ─ ─ ─▶│   Recover    │        │
│                                 └──────────────┘                │    Alice     │        │
│                                         │                       └──────────────┘        │
│                                         │                                               │
│                                         │                                               │
│                                         │                       ┌──────────────┐        │
│                                         │                       │     20k      │        │
│                                         └────────────────┐      ├──────────────┤        │
│                                 ┌──────────────┐         │      │    Carol     │        │
│                                 │     20k      │         │  ┌──▶│              │        │
│                                 ├──────────────┤         │  │   └──────────────┘        │
│                                 │     Bob      │         │  │                           │
│                                 │              │─────────┴──┤                           │
│                                 └──────────────┘            │   ┌──────────────┐        │
│                                                             │   │New Connector │        │
│                                                             └──▶│ Output Alice │        │
│                                                                 └──────────────┘        │
│                                                                                         │
│                                                                                         │
│                                                                                         │
│      ┌────────────────────────────────────────────────────────────────────────┐         │
│      │      Example: payment confirms and Bob claims the funds on-chain.      │         │
│      └────────────────────────────────────────────────────────────────────────┘         │
│                                                                                         │
└─────────────────────────────────────────────────────────────────────────────────────────┘
That's it for today's issue. Once again, thank you so much for reading this far, and feel free to drop any feedback or questions in the comments. See you next week!

https://stacker.news/items/1436810

Whereas, interestingly, a lot of micro-transactions (e.g. below ~300 sats) cannot.

This comes very handy, for example, in derivatives or lending markets, to quickly send funds to a position when a liquidation is near.

Phoenix relies on FCM notifications to wake the user's device when someone tries to send to the user's Bolt12 Offer. This works okay for most devices with good connection, but starts falling apart in poor network conditions, or when FCM isn't available (for example on devices running GrapheneOS).

My understanding is that only LND is supported as of today.

Source

This requirement can be more easily worked with by using TapAss tokens that are a representation of tokens on different chains, a process known as wrapping.

More precisely, the hash of the message excluding signatures. See Bolt7 for more details.

The 1.0.0 @nprofile…p4dj release is very nice, congrats & ...

2026-02-11T17:24:25Z

The 1.0.0 Zapstore (nprofile…p4dj) release is very nice, congrats & thanks team! 🙏

Huge

2026-02-02T17:48:08Z

In reply to nevent1q…04ec
_________________________

Huge

I'm gonna guess: basically Umbrel Home with a small miner ...

2026-01-31T17:35:08Z

I'm gonna guess: basically Umbrel Home with a small miner inside.

quoting
nevent1q…27a2
we cooked

Zapoï !

2026-01-30T07:12:24Z

In reply to nevent1q…vlkf
_________________________

Zapoï !

Latest Strikes is out! Features in this issue: - @npub1yad…98zt ...

2026-01-28T17:38:16Z

Latest Strikes is out! Features in this issue:

- GetBittr (npub1yad…98zt)
- Gregory Sanders (a.k.a. instagibbs)
- ThomasV (npub1zqn…v2pm) and Felix (npub1z9n…vycf)
- ZEUS (npub1xnf…lpr5) and MoneyBadger

quoting
naddr1qv…hcgt

Summary of Lightning Network news for the 4th week of 2026 (January 19th 2026 to January 25th 2026).

Hey there, welcome to your weekly recap of the latest Lightning developments.

The Bittr App Is Here

Bittr released their new app (iOS TestFlight only for now). Bittr is an OG Swiss dollar-cost-averaging (DCA) service where users can setup and forget recurring Bitcoin buy orders that are delivered straight to their self-custodial wallet. Up until now, Bittr worked with a "bring your own wallet" model, meaning users had to already have a Bitcoin wallet and communicate Bittr an address from this wallet when setting up the recurring buy order the first time¹. With the Bittr app, this last remaining friction point is on the way out. The app embarks a self-custodial on-chain and Lightning wallet, leveraging both the BDK and LDK. On the user's first buy, a Lightning channel is opened² between Bittr and the node running inside the app, sufficiently large to process this payment and many future ones. From then on, recurring buys will be sent straight through the channel until it's full. Larger payments will be sent immediately on-chain.

At first glance, DCA-ing into a Lightning channel may sound a bit peculiar to users who view Bitcoin more as long term savings rather than money to spend regularly³. Yet, Lightning is actually a very good fit for DCA as it simplifies UTXO management. Let's say a user wants to buy 50 euros worth of Bitcoin every week, without holding them on a custodial exchange. Usually, that would mean creating a new small UTXO every week, and hence increased block space usage and fees, notably when moving them in the future. With Lightning, one big shared UTXO is created in the beginning, and as buy orders are executed more and more of this UTXO belongs to the user. When all the funds are on the user's side, the channel is closed and the user ends up with one big UTXO instead of multiple smaller ones, without any manipulation on their hand or really having to think about it. There are, of course, tradeoffs: the exchange has to allocate capital to the channel beforehand, incurring an opportunity cost ; and while the channel is open the funds in it are held on a hot wallet rather than a colder storage solution.

It's very cool to see another DCA solution take a leap with Lightning, after Relai gave it a try but ultimately discontinued it due to low demand. I remain convinced that Lightning's trustless UTXO-sharing capabilities are still undervalued in the spot exchange space, and if one company can succeed at it, I think Bittr is well-positioned to be the one.

Lightning Symmetry Update

Gregory Sanders updated their Lightning Symmetry proof-of-concept to include some of the latest developments of Bitcoin's transaction relay (e.g. ephemeral anchors), cooperative close support, increased test coverage and more.

Electrum Release

Electrum v4.7.0 brings 2 new Lightning-related features:

"submarine payments", which is the ability to pay an on-chain address from the Lightning balance using submarine swaps. Interestingly, Electrum's swap implementation is more flexible than many in that it enables any person running Electrum to be a swap provider⁴, and users to choose among this multiple providers, using Nostr for discovery;

LNURL-Withdraw support, enabling user to claim "Lightning vouchers" (such as Azteco vouchers for example).

StackerNews Discussion

Moneybadger Support In Zeus?

Following Blink, Zeus added native support for scanning MoneyBadger payment QR codes (called CryptoQRs). MoneyBadger is an impressive Lightning payments success story⁵, with now literally hundreds of thousands of stores supported across South Africa. A key to this success is how they retrofitted Bitcoin/Lightning payments into existing payment providers infrastructure in South Africa, where QR Code based payments were already quite mainstream. MoneyBadger integrated with the solutions of various vendors, linking their payment rails to the Lightning Network. Typically, the payment flow at the point of sale would be:

when prompted to choose, the customer selects "QR Code" as the payment option ;

a proprietary QR Code displays on the terminal (different QR depending on the vendor/store) ;

the customers opens MoneyBadger's app and scans the QR Code ;

behind the scenes, MoneyBadger converts this proprietary QR Code into a Lightning invoice and prompts the customer to open the invoice in their favorite Lightning wallet ;

the customer opens the invoice in their wallet, clicks pay, and MoneyBadger handles the rest (i.e. routing the payment to the right store).

Now that more and more wallets support directly scanning the proprietary QR codes of MoneyBadger's partners, users can just pop out their wallet (Blink, Zeus, Aqua, etc.) and pay directly, just as if they were scanning a regular Lightning invoice. Behind the scenes, the wallet fetches the invoice from MoneyBadger's servers with a Lightning Address based mechanism. First, the wallet recognizes that the QR Code is from a MoneyBadger partner through simple pattern matching, and convert it to a @cryptoqr.net Lightning Address. For example, a QR Code reading http://example.com/za.co.electrum.picknpay/confirm123 would be translated into the Lightning Address http://example.com/za.co.electrum.picknpay/confirm123@cryptoqr.net, and MoneyBadger's servers would then return the appropriate invoice when this address is called. Leveraging Lightning Address in this way makes MoneyBadger/CryptoQR integration into Lightning wallets easier, since all that is required is basic pattern matching at the QR code scan level, and the rest is just a regular Lightning Address request. Pretty smart.

I personally find MoneyBadger's approach of integrating into existing systems (aided by an already established QR payments culture) very powerful. Of course, it has the drawback of centralizing payments around a central actor for QR code translation, but I see it as a pragmatic step to bringing vast payment processor networks into Lightning.

That's it for today! As always, feel free to drop any feedback in the comments. Thank you very much for reading this far, and until next week!

https://stacker.news/items/1421486

At some point in the past Bittr supported xpubs and derived a new address for each buy, but this features has been discontinued, I suspect for regulatory reasons (Bittr asks you to sign a message with the key corresponding to the address to demonstrates that you control the wallet).

Incurring a one time cost to cover channel operations (open & close), right now 10,000 sats.

For those already living under a Bitcoin standard and spending regularly, this feature let's them easily and automatically refill a spending wallet.

Of course, swap providers are expected to be available 24/7, so you'd typically run Electrum with the swap server enabled in an always-on setup. This can be a VPS, but interestingly the swap server doesn't need any port to be opened, so it can very well run on an always-home computer in a home network.

Which we first covered back in November 2022.

And don't get me started on copyright laws: I'm enraged ...

2026-01-26T10:54:24Z

In reply to nevent1q…zfwr
_________________________

And don't get me started on copyright laws: I'm *enraged* that Aaron Swartz died for freeing research articles, when those companies broke the lock and put their own in its stead, and nobody bat an eye.

Breaking: company that trained their models on petabytes of ...

2026-01-26T10:50:34Z

Breaking: company that trained their models on petabytes of illegally-obtained data pinky swear not to use your data if you subscribe to the paid tier.

The 6th issue of Latest Strikes ⚡️ (season 3) is out! ...

2026-01-21T18:21:54Z

The 6th issue of Latest Strikes ⚡️ (season 3) is out!

Featured:
- 8333.mobi (npub1nv4…x0gr)
- TunnelSats (npub1n9z…sp8y)
- Polar ( jamaljsr (npub1hdp…nuf5) )
- Core Lightning ( Blockstream (npub1jg5…6n8n) )
- Eclair
- Rene Pickhardt

quoting
naddr1qv…2avn

Summary of Lightning Network news for the 2nd and 3rd week of January 2026 (January 5th 2026 to January 18th 2026).

Welcome to your "weekly" recap of the latest technical news in the Lightning ecosystem. Now, before you ask: no, you didn't miss the last issue, I did. Let's say that between work and personal matters, time fell short last week, and so I decided to postpone Latest Strikes to the next week (now!), covering the last 2 weeks.

Wallets & Tools

Machankura Self-Custodial App

On January 3rd, Machankura released a build of their new self-custodial wallet to people in the Google Play waiting list. The team had announced this new app back in November 2025, giving more details into the tech stack it uses:

Acinq's lightning-kmp implementation (the same one that runs in Phoenix wallets) ;

Lightning Service Provider (LSP) support.

A few things remain unclear (for instance, who will act as a LSP in the wallet) but it's really great to see the Machankura team add a real self-custodial Lightning solution on top of their well-established custodial solution. The two seem highly complementary, with the custodial solution tailored for no-internet (GSM-only) feature phone usage leveraging the USSD protocol ; while the new self-custodial app can serve user with smartphones and reliable internet access.

TunnelSats v3

TunnelSats released the v3 of their Lightning node VPS service. The idea is to enable Lightning node operators to more easily expose their node to clearnet without revealing their IP address or having to open ports on their router. With the v3, TunnelSats users can now enjoy:

a management API for automation,

Nostr Wallet Connect for automatic renewal payment,

new, enhanced scripts for installing and managing your VPN tunnel.

Another thing I really like about TunnelSats is how they openly provide the scripts for you to run on your node, instead of black-boxing them behind an interface. This way, users can audit and understand what's happening, and it can even help them create their DIY solution if they want to take a leap at managing their own VPN server.

Polar

The v4.0.0 release of regtest Lightning Network tool Polar was a huge one, bringing:

LLMs agents control over local regtest network through the Polar MCP, enabling agents to manage the topology of networks, as well as payments ;

support for automated simulations of realistic payment activity through the integration of the SimLN tool ;

improved performance on ARM64 chips ;

and the usual update to available nodes.

X Announcement

Implementations & Spec

Core Lightning Release

Core Lightning v25.12.1 was released, notably continuing the integration of mnemonic-based (12 words) seeds into the implementation's tooling. As a reminder, as of v25.12 new Core Lightning nodes are created using a 12 words seed phrase.

Accountability in Eclair

Eclair implemented accountability signal, replacing the previous endorsement mechanism as a mitigation against channel jamming.

Channel jamming is a problem that has been identified for quite a long time (see for example our early coverage on the matter here and there), where an attacker could at virtually no cost jam Lightning channels, i.e. block channels so that no payments can go through while the attack is ongoing. Such an attack is achieved by sending payments through the target channel(s) with no intention of ever settling them. There are 2 (porous) categories of jamming attacks:

quick jamming, where the attacker sends a lot of payments through channels in order to exhaust the max limit of 483¹ simultaneous in-flight HTLCs in a channel ;

slow jamming, where the attacker exhausts the liquidity of a channel by sending one or multiple payments that mobilize this liquidity and letting them expire, thus blocking the liquidity and rendering in usable for the processing of other payments until the expiration of the fake payments.

Jamming is fought through the combination of 3 mechanisms:

a local reputation system, maintained by each node on its neighbors, keeping track of how well they behaved in the past (quick settlement, etc.) ;

a signaling mechanism to "coordinate" reputation across the network (more on that later) ;

the compartmentation of a channel's liquidity into different buckets that can be used (or not) depending on the current liquidity congestion, received signal, and downstream node reputation.

Previous jamming mitigation mechanisms used an endorsement signal where a node extending an HTLC could signal to the next node whether they're ready to have their reputation impacted by the behavior of the HTLC. Endorsed HTLCs coming from a peer with a good reputation would be allowed into the "protected" bucket, while others could only use resources (liquidity and HTLC slot) from the general bucket. The signal would propagate across a payment route: the sender would endorse the HTLC if they expect the payment to succeed quickly (i.e. they hold the final recipient and all the intermediate routing nodes to be honest actors), and each node along the way would endorse their forwarded HTLC if and only if the incoming HTLC was endorsed and the incoming peer has a good reputation.

However, some limitations were found in the context of a "attackathon", leading to the replacement of the endorsement signal with an accountability signal. Accountability goes the other way around: when offering an HTLC, the incoming peer flips the accountable flag to signal to the downstream forwarding node that their reputation will be affected by how quick this HTLC settles (ie, they will be held accountable). A node (Alice) would typically flip the accountable flag when forwarding the HTLC requires them to use resources outside of the general cluster, thus indicating to the next forwarding node (Bob) that their (Alice's) resources are constrained (which might indicate an ongoing jamming attempt) and that they (Bob) should behave, or else risk their reputation being degraded. A node receiving an HTLC with the accountable flag enabled (such as Bob in our example) has incentives to give special treatment to this HTLC, provided the incoming node has a good reputation, thus extending it resources outside of the generic cluster and marking their own forwarded HTLC as accountable.

Channel (un)jamming is a fascinating topic, and I plan on releasing a more in depth article on its history, going into more technical details around the endorsement abandoned mechanism and the new accountability solution. I'll link to it in an upcoming issue when it's ready.

See also: Optech's coverage in the newsletter and podcast.

Research

Pickhardt Paper

Rene Pickhardt published a paper formalizing his work. I plan on doing a full article diving deeper in the paper, but the cusp of it is:

given the network topology and channel depletion over time, some payments (and gradually more and more of them) become infeasible, and enabling them requires adjusting liquidity in channels through on-chain transactions (opening/closing channels, splicing, etc.) ;

the need to come back on-chain puts a lower bond on Lightning's transactional throughput ;

channel factories would allow Lightning operators to alleviate channel operations costs and increase their frequency, lifting up this lower bond.

Thank you for your work Rene, enjoy your sabbatical!

See also: this StackerNews post giving a summary of the paper.

That's it for this week! I hope you found this issue informative and, as always, please share any feedback you may have in the comments. See you next week!

https://stacker.news/items/1416853

This is a hard limit that rooter in rules limiting the size of on-chain Bitcoin transactions. In practice, Lightning implementations may default to using lower bonds.

Hey, that's awesome and great news! Does Machankura act as an ...

2026-01-06T17:51:25Z

In reply to nevent1q…f4qs
_________________________

Hey, that's awesome and great news! Does Machankura act as an LSP, or is an external LSP used? And is the goal to offer a "gradual wallet" experience (users would start with a "legacy" phone-linked Machankura account and then move to self-custody when reaching a certain amount), or is it more to offer self-custody from the start to users equipped with smartphones?

Agreed, that's why Phoenix tries to abstract pretty much ...

2026-01-01T07:47:21Z

In reply to nevent1q…jj9n
_________________________

Agreed, that's why Phoenix tries to abstract pretty much everything away from the user. Maybe they could abstract even more things, but then since it's self custody there are things you **have** to tell the user. And when you charge them fees, users **want** to know how much and why. Seems to me that's the only two things Phoenix still explains in its interface.

Honestly I don't get why we get into convoluted trusted ...

2025-12-31T14:22:03Z

In reply to nevent1q…23tq
_________________________

Honestly I don't get why we get into convoluted trusted solutions (trust the statechain entity bro, trust the federation bro) when Phoenix exists.
People will freak out at the onboarding fee without realizing how cheap it is compared to the cost of DIY (I'm talking "mental cost"). IMHO there are 3 factors that can explain this:

- people don't understand how LN works and are afraid of using Phoenix (vs custodial solutions)
- people don't care about self-custody
- people don't use Bitcoin as payment enough to see the point of Phoenix.

L'Île de Man ?

2025-12-29T20:35:10Z

In reply to nevent1q…0cpe
_________________________

L'Île de Man ?

WORD5 #445 6/6 🟧⬛⬛⬛🟪 ⬛⬛⬛🟧🟪 ...

2025-12-23T09:25:01Z

WORD5 #445 6/6

🟧⬛⬛⬛🟪
⬛⬛⬛🟧🟪
⬛⬛🟪🟪🟪
⬛🟪🟪🟪🟪
⬛🟪🟪🟪🟪
🟪🟪🟪🟪🟪

https://word5.otherstuff.ai

WORD5 #444 3/6 ⬛🟧🟪🟪⬛ 🟪🟧🟪🟪⬛ ...

2025-12-22T09:24:16Z

WORD5 #444 3/6

⬛🟧🟪🟪⬛
🟪🟧🟪🟪⬛
🟪🟪🟪🟪🟪

https://word5.otherstuff.ai

WORD5 #443 4/6 ⬛⬛🟪⬛⬛ ⬛⬛🟪🟧⬛ ...

2025-12-21T17:09:51Z

WORD5 #443 4/6

⬛⬛🟪⬛⬛
⬛⬛🟪🟧⬛
⬛🟪🟪🟪🟪
🟪🟪🟪🟪🟪

https://word5.otherstuff.ai

WORD5 #441 4/6 ⬛⬛⬛🟧⬛ ⬛🟧🟧🟧⬛ ...

2025-12-19T07:43:43Z

WORD5 #441 4/6

⬛⬛⬛🟧⬛
⬛🟧🟧🟧⬛
🟧🟧🟧🟧🟧
🟪🟪🟪🟪🟪

https://word5.otherstuff.ai

WORD5 #440 3/6 ⬛⬛⬛🟧⬛ 🟧🟧⬛🟧⬛ ...

2025-12-18T15:49:10Z

WORD5 #440 3/6

⬛⬛⬛🟧⬛
🟧🟧⬛🟧⬛
🟪🟪🟪🟪🟪

https://word5.otherstuff.ai

Latest Strikes is out! Featuring: - @nprofile…2pcj - ...

2025-12-15T18:21:22Z

Latest Strikes is out! Featuring:

- Blockstream (nprofile…2pcj)
- fountain_app (nprofile…am06)
- Alby (nprofile…7yqy)
- Chaincode Labs
- Beulah Evanjalin
- second (nprofile…ydyt)
- Vora (nprofile…pr6s)

quoting
naddr1qq…nnlh

Summary of Lightning Network news for the 50th week of 2025 (December 8th to December 14th)

Welcome to your weekly summary of noteworthy news and developments in the Lightning Network ecosystem. Last week was quite quiet, but still brought a few interesting updates, blog posts and announcements.

LN <> Liquid Swaps in Blockstream App

Version 5.1.4 of the Blockstream App introduced submarine swaps between Lightning and Liquid, via Boltz. This comes as a replacement for the previous Lightning support in the app, which relied on Blockstream Greenlight and was discontinued.

Users of the Blockstream App hold their funds as on-chain Bitcoin and/or Liquid balances, and can now pay Lightning invoices directly from the Liquid balance via a Liquid-to-Lightning swap ; and conversely receive a Lightning payment into their Liquid balance via a Lightning-to-Liquid swap.

This move by the Blockstream App team away from Greenlight and into LN <> Liquid swaps is reminiscent of the similar pivot operated by Breez with the introduction of the Nodeless SDK which quickly gained "market shares" over the Native/Greenlight SDK, which is no longer maintained.

Fountain Update

Fountain, a Lightning-native podcasting 2.0 app, now supports Nostr Wallet Connect (NWC) and paying any Lightning Address. The NWC integration lets users send and receive payments on Fountain directly with their own external Lightning wallet (e.g. Alby Hub) without having to deposit sats on Fountain.

This release also brings a tight Strike integration, which enables podcasters to withdraw to Strike in their currency of choice.

Modularizing Alby Hub: Part 2

Continuing on their previous post (which we covered 2 weeks ago), the Alby team shared a glimpse of their experiments around suspendable signers. As a reminder, their goal is to find ways to propose a hosted but "self-custodial" Lightning solution with a free tier. Currently, Alby Hub is a paid service, because it runs 24/7 and Alby cannot afford to offer this as a free tier given the associated hosting costs. The alternative is self-hosting (which is great!), but a third path could be a "suspendable Alby Hub", which would make some compromises but be available for free.

In this post, the Alby teams explores the idea of users running their "suspendable hub" in a serverless environment such as Vercel. This enables users to "own" the code they deploy, while keeping the service free since normal users should typically fall under the free tiers of serverless providers. This also makes it possible to handle "offline receive", since serverless environments allow the "apps" running on them to be woken up on demand¹. To make setup easier, the Alby website could offer an integration with serverless hosting providers via their OAuth APIs.

In the blog post, they share their preliminary work on an Arkade signer proof-of-concept. It remains to be seen if the step of having "layman" users interact with serverless services isn't one that is too big to take, but surely LLMs could also help in that regard.

Human Bitcoin Addresses

The Spiral team published a blog post on DNS-based payment identifiers (as described in BIP0353), which they refer to as Human Bitcoin Addresses (HBAs). HBAs are meant to be easier to read and transmit for humans that Bitcoin addresses or Lightning invoices.

HBAs follow a user@domain structure (e.g. fanis@fanismichalakis.fr), much like Lightning Addresses, but using DNS instead of web servers for resolution. It is also more versatile than Lighting Addresses, since it can be used to resolve any static payment identifier (e.g. a Silent Payment address). Since HBAs don't rely on centralized web servers, they should also provide better privacy and censorship resistance, as well as enhanced security. However, it still relies on the DNS infrastructure and authority hierarchy, which is a bit counter to Bitcoin's ethos.

The blog post sparked interesting discussions on X regarding the "spoofability" of HBAs. For example, someone trying to pay me could be convinced by a scammer to send sats to fanis@fanismichalakis.gr, believing the address belongs to me, while it is actually controlled by the scammer. Traditional fintech apps largely circumvent this scenario due to the large walls they erected around their garden, but that's not the case for open systems such as Bitcoin or Lightning².

I think to some extent contacts, as implemented in Phoenix, solve this issue: you have to be very careful the first time you pay someone to make sure you got their HBA right³ ; but then you can just save it as a contact and reuse it very easily later on with the touch of a button.

That's it for today. Before you leave, I wanted to tell a few words about the ₿OSS Challenge, a Chaincode Labs initiative for developers wanting to bootstrap a career in Bitcoin open source software. Admissions are open until the end of the month. If that rings a bell and you're serious about it, check their website out and apply. Developers of the 2025 program now work on very diverse Bitcoin-related projects and receive funding, with for example Second and Vora announcing last week that they are funding a year-long grant to Beulah Evanjalin to implement nested MuSig in libsecp256k1-zkp, which will benefit all Bitcoin L2s.

Again, thanks for reading this for, and see you next week!

https://stacker.news/items/1343539

See for example how Money Dev Kit handles that in Latest Strikes S03E01.

Interestingly, when it comes to error detection (i.e. ensuring the user makes no mistake when copying/scanning an address or an invoice), the Bitcoin ecosystem is usually quite good.

Presumably this can be facilitated by being in person and/or with assistive technologies such as QR Codes, NFC, etc.

The third issue of Latest Strikes ⚡ Reborn is out! It's a ...

2025-12-11T17:58:15Z

The third issue of Latest Strikes ⚡ Reborn is out! It's a bit late because I was visiting citadels with the gf during an extended week-end. To make up for it, there are a few castle pics inside 🏰📸

Also inside:
- Blockstream (nprofile…2pcj) 's Core Lightning release
- Spiral (nprofile…z06h) 's LDK release
- LND release
- 3 LND vulnerabilities discloses, courtesy of Matt Morehouse

quoting
naddr1qq…6sds

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.

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.

Château de Queribus. Very high ground, never fell.

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 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).

Speed & Reliability Improvements

With bigger and bigger Core Lightning nodes appeared some bottlenecks addressed in this release. Optimizations 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 of multi-parts payments (notably to try to conform with expectations from Phoenix nodes) and enhanced liquidity management (see this PR).

Wallet Backup

New nodes will now use a 12 words BIP0039 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¹ both nodes sharing a channel must upgrade in unisson. See pull requests 8506 and 8646 for more details.

LSP JIT Channels Experimental Support

This release also added experimental support for part of the LSPS2 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, 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) 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, which combines the LDK with the Bitcoin Dev Kit 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 and the LDK Node 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 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 to source chain data directly from a Bitcoin Core node's REST interface (previously only RPC or Electrum-based server were supported),

keysend payments (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, with now both server and client side support,

support for zero-fee commitment channels.

LND Release

LND v0.20 brings, among other things, a lot of gossip and topology related enhancements. Notably, the channel graph is migrated 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 is a software engineer and security researcher currently focusing on improving the security of Lightning implementations, supported by an OpenSats 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 is a variant of another 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 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, 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, 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!

https://stacker.news/items/1330295

Splicing is still marked as experimental in Core Lightning, and hence turned off by default.

Honestly it amazes me. I've been using it on and off, with ...

2025-12-04T09:23:25Z

In reply to nevent1q…08em
_________________________

Honestly it amazes me. I've been using it on and off, with extended periods (years) where it was sitting in a drawer. I guess the battery probably degraded a bit, but I recharged it yesterday, left it idle all night and listened to some music this morning, and the displayed battery level hasn't moved.
Another great thing is that it's still natively supported inside Apple Music on Mac, letting me easily put music inside. Apple doesn't even sell iPods anymore!

Stiller rocking this thing 15 years later ...

2025-12-04T09:00:39Z

Stiller rocking this thing 15 years later

The 2nd issue of the Latest Strikes revival is out, cross-posted ...

2025-12-02T08:43:16Z

The 2nd issue of the Latest Strikes revival is out, cross-posted here using stackernews (npub1jfu…m0gx) nostr cross-post feature!

In this issue: Boltz - Non-Custodial Bitcoin Bridge (npub1psm…8970) Alby (npub1get…0nfm) & Bitcoin Core 🚀

quoting
naddr1qv…sdcu

Summary of Lightning Network news for the 48h week of 2025 (November 24th to November 30th)

Welcome to your weekly summary of noteworthy news and developments in the Lightning Network ecosystem. Last week the Boltz team released some of what they had been cooking in the past months, Alby shipped multiple relays support for their Hub's Nostr Wallet Connect features, and cluster mempool got merged to Bitcoin Core!

Boltz Backend & Client Releases

The Boltz team shipped last week with releases to both Boltz' backend and Boltz' client.

The backend release is a huge one, featuring an impressive list of bug fixes, new features and improvements. Among all these niceties, here are a few ones I delved into a bit more.

Swaps Restorations

Up until now, Boltz offered a rescue endpoint for refunding submarine swaps (swaps that move funds from on-chain to Lightning) even when the client had lost its local swap data, by using the xpub to rescue funds. This endpoint is now deprecated and replaced with a restore endpoint, which does the same thing but also supports claiming funds using the appropriate preimage, as long as said preimage was derived deterministically using Boltz' method. It is hence now possible to refund failed swaps or resume still ongoing swaps using only a seed phrase, referred to as the "Boltz Rescue Key". On Boltz' web app, this rescue is generated and persisted locally (in the user's browser) and should be backed up.

Magic Routing Hints watcher

One of the dominant usages of Boltz nowadays is inside wallet apps such as Aqua or the Bull Bitcoin wallet, where it's abstracted away from users. The core idea is to enable users to send and receive on Lightning without ever running a Lightning node. Instead, the user's balance is kept on-chain (e.g. Bitcoin or Liquid) at rest, and sending or receiving to or from Lightning involves a swap through Boltz. With the increased popularity of such wallets arose the opportunity to simplify the payment flow in some cases by removing useless swaps.

For example, if a user of Aqua wants to pay a Bull Bitcoin user, then the naive flow would involve two swaps:

Liquid On-chain Aqua ---submarine swap---> Lightning ---reverse swap---> Liquid On-chain Bull Bitcoin

What if, instead of this convoluted route, the payment could be a simple Liquid send?

Liquid On-chain Aqua ---Liquid---> Liquid On-chain Bull Bitcoin

Since the lingua franca of all these wallets is Lightning, they use Lightning invoices for payment requests. Simplifying the payment flow hence requires passing extra data inside the invoice to help wallets figure out the payment could be made directly on Liquid. To do so, Boltz introduced Magic Routing Hints (MRH) back in February 2024. The core of the idea is to encode some data inside the Bolt11 invoice's routing hints, which wallets can then leverage to decide if the payment can be made directly (or with fewer swaps).

Today's release further simplifies this management for wallets by exposing a new websockets endpoint that watches payments to the final receiving address (e.g. Liquid on-chain address in Bull Bitcoin). This helps the receiving wallet detect that the incoming payment was made directly and not through a swap, but it remains the wallet's responsibility to then verify that the payment was indeed made (i.e. wallets should not blindly trust Boltz' backend).

Speaking of Boltz, they got the upcoming release of Core Lightning (CLN) named after them, probably since their big and heavily used CLN node revealed some improvement directions for the open-source Lightning implementation. How cool is that? But we'll cover this new release in greater details when it's fully out...

Modularizing Alby Hub & Alby Release

The Alby team shared their thoughts on what a Nostr Wallet Connect (NWC) "suspendable signer" could look like. Taking a step back, the notion of "suspendable Lightning node" is implemented by solutions such as Greenlight, Lexe or Money Dev Kit (which we covered last week). The core idea behind these solutions is to offer users a self-custodial Lightning experience without all the fuss of running a node. In Greenlight, the user's node runs in Blockstream's cloud but the underlying keys remain on a user-controlled device (e.g. their phone) ; in Lexe the user's node runs inside a Tusted Execution Environment (Intel SGX) ; and in the MDK the node runs inside the user's web app (MDK users are typically developers). In all cases, hosting costs (for the provider in Greenlight and Lexe, for the user in the MDK) are reduced by "suspending" the node when it's not in use and "waking it up" when it needs to receive or send a payment. This "wake up" feature typically relies on the provider acting as a Lightning Service Provider (LSP).

In their article from last week, the Alby team explores how things could be taken even further by stripping as much things from the "suspendable node" as possible, thus turning it into a "suspendable signer" that doesn't need to manage channels. One of the motivations behind this is to reduce the operational costs of Alby Hub instances hosted inside Alby's cloud, which currently run 24/7. Building such a stripped-down signer would likely mean connecting to Spark or Ark entities, which would operate a Lightning Node on behalf of multiple users, but with security and privacy tradeoffs compared to each user running their own node. Therefore, I'm not sure it actually makes sense to look at integrating Spark/Ark though the lense of cloud compute cost reduction, since the benefits seem marginal compared to suspendable Lightning nodes, and the real cost benefits of Spark/Ark lie in the mutualization of channels (which is still an avenue for cost reduction, just not strictly related to compute).

Alby's article nonetheless contains some very interesting considerations around the integration of NWC in suspendable nodes/signers. Indeed, one of the issues is that NWC requires websockets, hence a persistent connection, incompatible with the notion of "suspendability". I think an interesting solution, explored but not found fully suitable by the Alby team, would be to double the NWC interface with an endpoint for short-lived HTTP connections that could be used to wake up the node. Through standardization, this could allow users to choose across different LSPs, that would each be able to issue "wake up calls" for receiving incoming payments¹. But that's easier said than done, especially the standardization part.

Source: xkcd. CC BY-NC 2.5.

In v1.21.0 of the Hub, Alby also introduced support for multiple relays. This means NWC messages can be sent through a backup relay if the main relay is down, and allows Alby Hub self-hosting users to rely on their own relay instead of Alby's if they so see fit. Right now relay configuration isn't available directly in the UI, but can be changed through the RELAY environment variable.

Cluster Mempool Merged

The cluster mempool pull request got merged into Bitcoin Core last week! After 2+ years of hard work (only counting from when the original pull request was opened in October 2023), it completes this new mempool implementation which partitions a node's mempool into fixed-size clusters that are sorted by fee-rate. The goal is to make transaction selection more tightly aligned with economic incentives, i.e. ensuring miners running Bitcoin Core always produce the block paying the highest total fees, given a set of transactions eligible for inclusion into the block.

However, it comes with new rules, such as the cluster size limit, making the CPFP carve-out exemption useless since new transaction pinning vectors are now available. Luckily, ephemeral anchors and 0-fee channels have been rolled out in the meantime and are more and more broadly available across Lightning implementation, as well as part of the Lightning specification now that 2 compatible implementations support them. With CPFP Carve-out going for the exit, Lightning node runners should gradually migrate to ephemeral anchors.

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

https://stacker.news/items/1298304

As Alby reminds us: "it’s much more likely for channels to be closed if a user does not keep a high uptime". It is hence very likely that suspendable nodes will always need LSP, even with a standardized "wake up" HTTP endpoint provided by the cloud host. But the ability for users to source LSPs as they see fit is still a significant improvement.

Gonna get toasted this December 👌 ...

2025-12-01T20:17:35Z

Gonna get toasted this December 👌

Muliple relays support is huge! Is relays configuration available ...

2025-11-28T15:59:46Z

In reply to nevent1q…dwml
_________________________

Muliple relays support is huge! Is relays configuration available in the UI, or only through the env?

Hey! First thanks to the team for their phenomenal work? Do you ...

2025-11-27T15:48:37Z

In reply to nevent1q…aruy
_________________________

Hey! First thanks to the team for their phenomenal work? Do you have any ETA for Amber support? I saw it's in projected to be in the 0.3.0 release, so should we expect it to come around in December/January?

Hey @npub10r8…t2p8 I noticed a discrepancy for the Obsidian app ...

2025-11-27T10:05:30Z

Hey Zapstore (npub10r8…t2p8) I noticed a discrepancy for the Obsidian app between the hash indicated in Zapstore and the one advertises on GitHub and that I was able to obtain as well by downloading the APK from GH and computing the hash.

Noticed this because Zapstore refused to install, since hashes don't match (which is great!). What could cause such a mismatch? Does it mean the file was replaced on the Obisidian GH release page?

Thanks!

Don't mind me, trying something #naddr1qq…td7d

2025-11-26T12:47:30Z

Don't mind me, trying something

quoting naddr1qq…td7d

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¹. 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 (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 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 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². 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, 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 his work on 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³.

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⁴.

In a following comment, Jonathan also opened a discussion on the opportunity to adopt a design similar to that of 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) team published an interesting blog post 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 for comments! Zappy week!

You can find all issues except the first ones on LN Markets' blog, and all issues except a good chunk of the most recent ones on my personal blog. Thankfully, it overlaps!

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.

Updates are not sent immediately, but rather batched prior to broadcast.

Typically when changing alias or color, or when updating the set of supported features.

Still more accurate than Twitch 😂

2025-11-24T11:25:42Z

In reply to nevent1q…rghu
_________________________

Still more accurate than Twitch 😂

Welcome!

2025-11-18T09:26:10Z

In reply to nevent1q…yahk
_________________________

Welcome!

Exactly!

2025-11-14T09:34:56Z

In reply to nevent1q…qg3w
_________________________

Exactly!

Vine revival developed by @npub1wmr…g240 with @npub1sg6…f63m ...

2025-11-14T09:34:29Z

In reply to nevent1q…fktn
_________________________

Vine revival developed by rabble (npub1wmr…g240) with jack (npub1sg6…f63m) backing. They already include old Vine videos salvaged by the Internet Archive.
https://divine.video/

The news coverage on Divine is quite impressive. If it manages to ...

2025-11-14T08:58:29Z

The news coverage on Divine is quite impressive. If it manages to deliver on the user experience under the influx of new users, it could be an actual tipping point for the Nostr.

Imo the "no-AI slop" stance is really selling. Nostr is for humans.

Voici les slides de mes 2 dernières interventions chez ...

2025-10-20T15:57:55Z

Voici les slides de mes 2 dernières interventions chez l'école Alyra. Sous licence CC BY-SA 4.0.

https://fanismichalakis.fr/slides/alyra1.pdf
https://fanismichalakis.fr/slides/alyra2.pdf

#nostrfr #bitcoin

You just need to be super quick. Literally lightning fast

2025-10-14T13:02:19Z

In reply to nevent1q…2vr6
_________________________

You just need to be super quick. Literally lightning fast

Ah yeah, would make sense indeed 👍

2025-10-08T12:09:50Z

In reply to nevent1q…mmn2
_________________________

Ah yeah, would make sense indeed 👍

New TIDAL terms introduced P2P payments. Sounded like Bitcoin, ...

2025-10-08T10:22:23Z

New TIDAL terms introduced P2P payments. Sounded like Bitcoin, might just be Paypal.

> Peer to Peer Payments. As part of the TIDAL Service, you may be allowed to send or receive payments directly with other users ("P2P Payments") through a third-party payment provider. All P2P Payments are processed by such third-party provider and are subject to their terms and policies. TIDAL is not responsible for the payment provider's services and disclaims all liability for issues with P2P Payments, which must be resolved directly with the payment provider. You may use P2P Payments only for lawful purposes and in accordance with these Terms and our Content Guidelines. You may not use P2P Payments to engage in fraud, launder money, purchase prohibited content or services, artificially inflate engagement, or otherwise violate applicable law or our policies.

https://tidal.com/terms-2026?eu=true#:~:text=Peer%20to,or%20our%20policies

Neat, does it work in Turkey?

2025-10-07T13:22:30Z

In reply to nevent1q…u0cj
_________________________

Neat, does it work in Turkey?

I now have an ad for an electricity company right in my banking ...

2025-09-09T15:31:25Z

I now have an ad for an electricity company right in my banking app, presented on my bank statement on the exact same level as my operations 🫠 #bankstr

Thank you!

2025-08-25T20:14:28Z

In reply to nevent1q…l44y
_________________________

Thank you!

Are there any known limitations re/ browser compatibility? ...

2025-08-23T06:49:06Z

In reply to nevent1q…kjtc
_________________________

Are there any known limitations re/ browser compatibility? Can't seem to make fanfares work on Vanadium (GrapheneOS), the website just freezes.

Yeah that's totally understandable. I guess you might try to ...

2025-06-26T05:38:59Z

In reply to nevent1q…7ykr
_________________________

Yeah that's totally understandable. I guess you might try to crowdfund this, but I'm really not sure it'd work 😅

From the above phrasing I thought it would also translate notes. ...

2025-06-25T18:12:30Z

In reply to nevent1q…9602
_________________________

From the above phrasing I thought it would also translate notes. That'd be neat, although you'd have to figure out who pays for the translations, especially since newbies probably don't have sats. Maybe ads?

Merci pour cette bulle artistique quotidienne 🙏

2025-05-25T21:11:10Z

In reply to nevent1q…gdve
_________________________

Merci pour cette bulle artistique quotidienne 🙏

Nostr event nevent1qqsfqheydpgn08vsmtyd5qnga75mtqvqzv3pk58a6r9360dqtu6xlzszyp8kw2pqn6fzlnek87jayrchk8qkevks5m2yaksz7t08xrys0cc9g86d0h8

2025-05-22T11:31:20Z

The customary pizza has been eaten.

We'll probably cover liquidity sourcing at the end (so around ...

2025-05-20T12:58:39Z

In reply to nevent1q…nt4s
_________________________

We'll probably cover liquidity sourcing at the end (so around 5 pm CET), in case it's more compatible with your schedule. And either ways replay will be available ;)

Another abduction attempt in Paris. 🇫🇷 Une nouvelle ...

2025-05-13T11:00:32Z

Another abduction attempt in Paris.

🇫🇷 Une nouvelle tentative d'enlèvement à Paris.

https://www.leparisien.fr/faits-divers/paris-des-proches-dun-patron-dune-societe-de-cryptomonnaie-echappent-a-un-enlevement-en-pleine-rue-13-05-2025-XAVCRDAHFBAY5KZDI6SC3KFBGY.php

This is huge and completely redefines the landscape on Cashu v ...

2025-05-05T14:44:25Z

This is huge and completely redefines the landscape on Cashu v fedimint

All your eggs spread across many baskets that can be used in concert, or all your eggs in one big basket protected by multiple entities?

In Cash, one mint rugging means you lose all that is on this mint, but only that. On Fedimint you lose nothing until a majority of guardians rug, in which case in you lose everything.

Now that both approaches achieve the same level of practicality, the determing factor is your threat model. And that's great 🔥

quoting
nevent1q…7x8l
Holy shit it's working! Paid a 100k sats Lightning invoice from two different Cashu mints at the same time.

Enter atomic multinut payments.

All Cashu wallets let you use multiple mints. To reduce rug risk, we encourage users to leave only small amounts on each mint. This introduces a big UX challenge which forces users to distribute funds on different mints in a smart way. It's particularly problematic when you're trying to pay a bigger Lightning invoice from your small balances. Who has time for that?

The Lightning protocol allows nodes to split a single payment HTLC into multiple parts to increase the chance of reaching the destination, called Multi-Path Payments (MPP). Typically, that's done from one sender to one receiver. What if... you can just break the rules?

A multinut payment originates from multiple Lightning nodes to pay a single invoice, atomically. Even if none of your mint balances can cover an invoice, as long as your total balance is large enough, you can pay the invoice.

I don't think anyone was crazy enough to do this before. Pretty sure what you see here is the first invoice being paid using a CLN and an LND node at the same time. Amazing work by the team, special thanks to a1denvalu3 (nprofile…y93w).

If I'm not mistaken Fornelli is the small town that made the ...

2025-05-02T06:44:20Z

In reply to nevent1q…v3yt
_________________________

If I'm not mistaken Fornelli is the small town that made the news recently for its high number of physical shops accepting Bitcoin. You can check this on BTC Map (nprofile…8qzu), the number of merchants is very high given the size of the city.

Huge props to whoever started this ⚡

Nous sommes le 30 avril 2025, l'occasion de ressortir ...

2025-04-30T11:29:28Z

Nous sommes le 30 avril 2025, l'occasion de ressortir https://bitcoin.fr/fanis-michalakis-avril-2025-leffondrement-du-cartel-bancaire-histoire-dun-aveuglement/

Écrit à l'époque en réaction à cette merveille https://www.lopinion.fr/economie/philippe-brassac-avril-2025-le-bitcoin-sous-un-dollar-histoire-dun-aveuglement

Amitiés à Philou

Bien reçu Monsieur Nakamoto @nprofile…uwxl, merci ! Encore ...

2025-04-18T12:51:42Z

Bien reçu Monsieur Nakamoto zed-erwan☕️✏️🎨 (nprofile…uwxl), merci ! Encore plus beau en vrai qu'en photo 🤩

Lequel d'entre vous a fait ça ? ...

2025-04-16T10:40:25Z

Lequel d'entre vous a fait ça ?

https://fr.wiktionary.org/wiki/%C3%A9pitome

Wanna come to our ̶p̶o̶d̶c̶a̶s̶t̶ study group? We just ...

2025-04-08T16:20:37Z

In reply to nevent1q…dr65
_________________________

Wanna come to our ̶p̶o̶d̶c̶a̶s̶t̶ study group? We just had this discussion (Liquid, Fedimint, Cashu & Lightning Auditor mentioned). Would love to go a bit deeper with you on the loop!

https://www.youtube.com/live/WZATyYXJ3l8?si=2KHBegZpca_1kmFN&t=5889

In 1 hour (6 blocks)! #nevent1q…88x0

2025-04-08T13:02:08Z

In 1 hour (6 blocks)!

quoting
nevent1q…88x0
On Tuesday we'll take a look at Preimage Piracy 🏴‍☠️

If you want to get a more practical understanding of it, I created a small exercise, leveraging Polar.

The idea of the Polar exercises is to play with a local, fake Lightning Network, and write small scripts to control nodes in this network.

Ideally, if you intend to try it, do so before the live next Tuesday 😉

https://github.com/fanismichalakis/polar-exercises

We'll also cover some news from the Lightning ecosystem ⚡️

nevent1q…jhvs

On Tuesday we'll take a look at Preimage Piracy 🏴‍☠️ ...

2025-04-04T15:25:38Z

On Tuesday we'll take a look at Preimage Piracy 🏴‍☠️

If you want to get a more practical understanding of it, I created a small exercise, leveraging Polar.

The idea of the Polar exercises is to play with a local, fake Lightning Network, and write small scripts to control nodes in this network.

Ideally, if you intend to try it, do so before the live next Tuesday 😉

https://github.com/fanismichalakis/polar-exercises

We'll also cover some news from the Lightning ecosystem ⚡️

quoting
nevent1q…jhvs
⚡ Plan ₿ Labs Lightning – Session 5 Incoming! ⚡

Fanis (nprofile…ve7r) is back next Tuesday with more hands-on Lightning action!

This session will feature:
📰 Wallet-focused news roundup
💡 Topic & exercises on “Preimage Stealing”

🔥 Don’t miss it.

Rumble: https://rumble.com/v6rmtpb-plan-labs-lightning-5-lightning-news-round-up.html
Youtube: https://youtube.com/live/WZATyYXJ3l8

Le "cloud" ça veut dire un serveur tiers entre les deux ...

2025-03-20T16:19:31Z

In reply to nevent1q…vc6l
_________________________

Le "cloud" ça veut dire un serveur tiers entre les deux clients. Donc dans le contexte du transfert de fichier, p2p et "sans cloud" me paraissent à peu près équivalent.

Seems to be working 👏

2025-03-10T15:11:46Z

In reply to nevent1q…emfw
_________________________

Seems to be working 👏

You guys do realize civil asset forfeiture is a ...

2025-03-07T09:30:00Z

You guys do realize civil asset forfeiture **is** a budget-neutral way to stack coins into the stockpile, right?

If I can hear the solo in my head from seeing the thumbnail, then ...

2025-02-14T21:33:36Z

In reply to nevent1q…pkwd
_________________________

If I can hear the solo in my head from seeing the thumbnail, then it's a pretty darn good solo

You won't know, you'll be routing sats. Independent of ...

2025-01-31T06:31:45Z

In reply to nevent1q…ge07
_________________________

You won't know, you'll be routing sats. Independent of your Lightning implementation.

David Balland's new X bio is wild ...

2025-01-26T12:11:08Z

David Balland's new X bio is wild

What would you say were the most instrumental developments in ...

2025-01-26T08:47:49Z

What would you say were the most instrumental developments in Lightning last year? I'm talking protocol updates, implementations, wallets, tools, services, research, etc.

I think one core goal of @nprofile…qss4 with the Hub is to get ...

2025-01-23T16:03:53Z

In reply to nevent1q…0hmz
_________________________

I think one core goal of Alby (nprofile…qss4) with the Hub is to get rid of all potential legal burdens that come with custody. I believe they checked into HC, but those don't really help in that regard.

> TC only implemented filters on the UI as they couldnt ...

2025-01-20T21:10:28Z

In reply to nevent1q…hu7h
_________________________

> TC only implemented filters on the UI as they couldnt implement them on the contract level – kind of the idea of "immutable"

I think you can write modular smart contracts with dedicated functions that allow for things like replacement by a new contract when called by the right account. But I was definitely under the impression that it wasn't the case for TC, thanks for confirming!

That being said, I expect contract-level filters to be more and more the norm that regulators will expect devs to adhere to. Some companies are building it because there is profit to be made. When the tools are there, and maybe they are already, the immutability argument becomes weaker.

Stands for "Free and Open Source Software"

2025-01-20T20:38:07Z

In reply to nevent1q…9xay
_________________________

Stands for "Free and Open Source Software"

I didn't know the TC team implemented filters at the contract ...

2025-01-20T20:34:17Z

In reply to nevent1q…yvpe
_________________________

I didn't know the TC team implemented filters at the contract level, thought it was only the UI. If *this* is not enough to keep the DOJ at bay, I don't know what is.

The DOJ might even be shooting themselves in the foot with this move: if the reward for compliance is still prosecution, why bother to comply?

Do you them here? #naddr1qq…mtak

2025-01-19T16:59:25Z

In reply to nevent1q…hppz
_________________________

Do you them here?

quoting
naddr1qq…mtak

And there are those who react with pokemons, thanks to ...

2025-01-18T18:45:53Z

In reply to nevent1q…wmfu
_________________________

And there are those who react with pokemons, thanks to OceanSlim (nprofile…9nk4)

Chain analysis is a pseudo-science episode 169 #nevent1q…pdsn

2025-01-17T19:11:32Z

Chain analysis is a pseudo-science episode 169

quoting
nevent1q…pdsn
Oopsiedoozles, Chainalysis wrongfully attributed almost twice the volume of hacked funds to North Korea than funds it found actually related "upon further investigation"

This software is used to put people in jail

I memba

2025-01-15T16:22:56Z

In reply to nevent1q…4k3u
_________________________

I memba

Is there an existing NIP-47 server implementation that calls a ...

2025-01-10T14:25:29Z

Is there an existing NIP-47 server implementation that calls a NIP-46 bunker to sign the zap receipt?
And is there an existing NIP-46 implementation that would only sign zap receipts, and refuse to sign any other kind of event?

The combination of the two would let users receive zaps self-custodialy by running the NIP-47 server on a cheap VPS without exposing their npriv, while running the bunker at home (for example behind TOR).

What's the sauce?

2025-01-08T07:26:50Z

In reply to nevent1q…sp35
_________________________

What's the sauce?

Bien reçu @nprofile…pkne 🥳 Et juste à temps pour commencer ...

2024-12-06T11:28:53Z

Bien reçu PVH éditions (nprofile…pkne) 🥳
Et juste à temps pour commencer la distribution 😇

You're not supposed to eat before donating? Here in France ...

2024-12-04T10:25:58Z

In reply to nevent1q…zef7
_________________________

You're not supposed to eat before donating? Here in France they insist on you eating before and after the donation, all they provide free stuff for you to eat on site.

Trying out this little guy today ☕ cc @nprofile…h3ur ...

2024-11-27T12:25:30Z

Trying out this little guy today ☕
cc Louferlou (nprofile…h3ur)

FYI Ledger's Bitcoin app is open source, although the BOLOS ...

2024-11-27T06:19:17Z

In reply to nevent1q…5twe
_________________________

FYI Ledger's Bitcoin app is open source, although the BOLOS operating system itself is not.

https://github.com/LedgerHQ/app-bitcoin-new

Yes, everyone, everytime 🙌 To be fair, I kinda understand ...

2024-11-05T14:35:15Z

In reply to nevent1q…52wh
_________________________

Yes, everyone, everytime 🙌

To be fair, I kinda understand their point in that it is indeed theoretically possible to perform KYC on every redemption, and thus only rugpull a specific subset of users. But it's probably the costliest way to rugpull someone, because you'd have to do a KYC check for every claim until you're sure that the remaining ones all belong to the subset you wish to rugpull. And from the point of view of the rugpulled, the outcome is no worse than if the rugpull was general.

What if mints KYC the auditor? Doesn't work anymore, gotcha!

2024-11-05T13:59:15Z

In reply to nevent1q…4zlt
_________________________

What if mints KYC the auditor? Doesn't work anymore, gotcha!

Reading the end of Children of Dune with a fever is a bit of a ...

2024-11-05T06:22:20Z

Reading the end of Children of Dune with a fever is a bit of a mystical experience

Bienvenue !

2024-11-04T15:25:01Z

In reply to nevent1q…f7dk
_________________________

Bienvenue !

Please @nprofile…wl6r don't rebuild it Nikólaos Balános ...

2024-09-19T14:13:20Z

In reply to nevent1q…jlx3
_________________________

Please nprofile1qqszmxrnkfdl9hdxzstgf4zdt6mk4avlzemc3fvwxcatzeclalhg0uspzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtczgwl6r (nprofile…wl6r) don't rebuild it Nikólaos Balános style

J'en ai pas vu mais ça vaut le coup d'essayer en effet. ...

2024-09-13T13:11:14Z

In reply to nevent1q…emep
_________________________

J'en ai pas vu mais ça vaut le coup d'essayer en effet. Par contre l'aiguille en métal j'ai peur d'abîmer les broches ...

Qui aurait pu deviner ? Sauce : ...

2024-09-13T09:08:44Z

Qui aurait pu deviner ?

Sauce : https://www.lcb-ft.fr/blog/plateformes-cryptoactifs-bilan-enregistrements-agrements

Am I the only one to often get issues with USB-C charging on my ...

2024-09-13T08:08:39Z

Am I the only one to often get issues with USB-C charging on my phone? Works like a charm for months, and someday it becomes harder and harder to use: the thing is plugged-in, but it seems even the slightest misplacement stops charging.
Is it that I'm pushing too hard on those when I plug them in?

Is there a Nostr equivalent of Google Maps / TripAdvisor ratings ...

2024-08-27T18:23:08Z

Is there a Nostr equivalent of Google Maps / TripAdvisor ratings & recommendations?

By "deniability" you mean the defence that developers are ...

2024-08-27T18:18:55Z

In reply to nevent1q…p6e2
_________________________

By "deniability" you mean the defence that developers are not responsible for the usage of the software they produce?

I think it's a bit different here, since relays are running code, not writing it.

Nostr event nevent1qqsrhk6q0juedkeduu37v53cknhqjyejxumg0utsh2f496ryg64kkwgzyp8kw2pqn6fzlnek87jayrchk8qkevks5m2yaksz7t08xrys0cc9gv9hmc4

2024-08-27T17:59:51Z

In reply to nevent1q…jctv
_________________________

Nostr event nevent1qqs9d9jc4q3u0qaq0x3xhfu57nsazdhdgpm2r8d8e32dqfh9xx6ccxszyp8kw2pqn6fzlnek87jayrchk8qkevks5m2yaksz7t08xrys0cc9g3md4tj

2024-08-27T17:53:22Z

On light of the Pavek Durov arrest: do you think nostr relays ...

2024-08-25T07:54:04Z

On light of the Pavek Durov arrest: do you think nostr relays should implement basic moderation on clear (i.e. unencrypted) content? E.g. ban pedo-pornographic content.

On an OP_CAT enabled Bitcoin test network *

2024-07-18T08:37:58Z

In reply to nevent1q…6kt4
_________________________

On an OP_CAT enabled Bitcoin test network *

I'm not sure I find David J. Peterson reasoning behind ...

2024-07-18T08:36:23Z

I'm not sure I find David J. Peterson reasoning behind distancing Neo-Chakobsa (movie) from Chakobsa (books) and current Earth-spoken languages very convincing.

One of his main arguments is that in the the 20k years timeframe that separates us from the events unfolding in Dune, it is unlikely that contemporary (or a bit more ancient) languages would have survived, except for barely recognisable influences.

That could work for most sci-fi settings, but imo it misses the target on Dune.

- Great Houses have roots that go back to the Earth days of humanity, and language is a great part of a House's identity, as is perfectly conveyed in both the books and the movies. Houses would therefore protect their historical languages ;
- the Bene Gesserit Reverend Mothers have access to the memories of their female ancestors, and given the organisation's influence in the Imperium, they could very much act (consciously or not) as "seed crystals" for the survivance of old languages (the name Bene Gesserit itself is Latine, ffs) ;
- in the specific case of Fremen, who are the main speakers of Chakobsa, their culture involves a figure very similar to Reverend Mothers, as well as the Tau "orgy", where minds can experience very close connections. Spice consumption increases life expectancy. In this setting, I don't see why Fremen couldn't speak an old language, kept alive by Reverend Mothers and tradition.

🇫🇷 Lettre ouverte à la Représentation Permanente de la ...

2024-06-19T14:31:21Z

🇫🇷 Lettre ouverte à la Représentation Permanente de la France auprès de l'Union Européenne, également transmise par email.
Je vous invite à faire de même et à manifester votre opposition.

🇬🇧 Open letter to the Permanent Representation of France at the EU, also sent per email. I encourage you to do the same and demonstrate your disagreement.

r/place but you can actually pay a pool to produce a specific ...

2024-03-26T13:41:26Z

r/place but you can actually pay a pool to produce a specific block template and it's there forever https://mempool.space/block/0000000000000000000341cc26cda4af82cd25f7063c448772228cbf2836915b?audit=false

Just so you know, brands like Melitta produce very similar ...

2024-03-25T18:59:42Z

In reply to nevent1q…kwas
_________________________

Just so you know, brands like Melitta produce very similar descaler for half the price. Been using them for my DeLonghi, works like a charm.

PayPerQ (https://ppq.ai/) joins the long list of awesome products ...

2024-03-25T18:52:06Z

PayPerQ (https://ppq.ai/) joins the long list of awesome products with a name that accidentally sounds funny in French 🇫🇷

A common slang for toilet paper in French is "Papier Q" ("papier cul", butt paper). And, you guessed it, PayPerQ pronounced with an impeccable French accent sounds very much like Papier Q.

Nostr notes by Fanis

Latest Strikes is out! In this issue: - splicing got merged baby ...

Splicing

Lexe Public Beta

LND

Eddy

Latest Strikes is out! In this issue: - agentic payments with ...

Are Payment Channels Cool Again?

MDK Cloudflare

ClawCash

"Native" Prisms Via Rootstock

Quick Strikes

Thanks, glad you liked it! It'll certainly stick in Latest ...

Latest Strikes is out! Is this issue: Ark stuff, Liquid <> ...

Arks

Arkade

Second

LN <> Liquid Swaps

Jade

Ibis

LNURL-Verify in Breez

NWC in Mostro

Improvements in rust-lightning

Trampoline

Dust Limit

SuperScalar

Latest Strikes is out! 🚀 In this issue we take a close look at ...

Wallets & Tools Releases

Get Some Cake

Boltz Mandatory Update

Implementations Thunder

LDK: Contributing to Splice as Acceptor

LND: Aux HTLC Validator

Eclair: Interactive Transactions Validation Plugin

Latest Strikes is out! This issue covers 3 weeks, so it's a ...

$1M Lightning Payment Settled

Bolt12 In Lexe

Amboss Reveals RailsX

Lightning Sandbox && Agent Wallet

Clams

Nested MuSig2

Connector Swaps

The 1.0.0 @nprofile…p4dj release is very nice, congrats & ...

Huge

I'm gonna guess: basically Umbrel Home with a small miner ...

Zapoï !

Latest Strikes is out! Features in this issue: - @npub1yad…98zt ...

The Bittr App Is Here

Lightning Symmetry Update

Electrum Release

Moneybadger Support In Zeus?

And don't get me started on copyright laws: I'm *enraged* ...

Breaking: company that trained their models on petabytes of ...

The 6th issue of Latest Strikes ⚡️ (season 3) is out! ...

Wallets & Tools

Machankura Self-Custodial App

TunnelSats v3

Polar

Implementations & Spec

Core Lightning Release

Accountability in Eclair

Research

Pickhardt Paper