Welcome to Latest Strikes, your weekly report of the latest Lightning-related news. Last week was quite interesting, with a Core Lightning release candidate, a peer-scoring system in Eclair, and zero-fee taproot channels making their first apparition in the specification.

Bolt12PayBolt12Pay

Alex71btc released LNDKPay, aka Bolt12Pay, a self-hosted "Lightning payment and identity server" combining:

• LNDK for Bolt12 Offers support on top of LND,
• a LNURL/Lightning address server,
• a "Nostr Identity" server (i.e. NIP05 and zaps),
• Nostr Wallet Connect (NWC) support for easily connecting the wallet to external apps (like Alby Hub, which also comes an Umbrel app, does).

Bolt12Pay is tailored for running in Umbrel and StartOS setups, and leverages Cloudflare DNS to easily and securely expose the server to the world (which is the whole point of running an Offer/LNURL server).

StackerNews Discussion

Core Lightning v26.04 Release CandidateCore Lightning v26.04 Release Candidate

Core Lightning v26.04 is at the release candidate stage, meaning the release isn't fully ironed out yet but is available for testing. This release brings a number of improvements and new features, notably:

• splice in and splice out commands, with the ability to splice out a channel into another channel,
• payment reliability improvements,
• options to specify one or many "fronting nodes" for route hints (Bolt11 invoices) or blinded paths (Bolt12 invoices and offers). Node operators can specify one fronting node in their config that will be included to Bolt11 invoices as a routing hint, and be used as the introduction point of blinded paths. They can also specify a list of fronting nodes when creating a Bolt12 Offer, and one of the specified nodes will be picked as the introduction node each time the offer is used to request a new invoice,
• peer messages are not padded to a fixed length, "mitigating traffic analysis and making it harder to infer node activity from message sizes".

LND Getting Ready For GDPRLND Getting Ready For GDPR

LND added an RPC endpoint for deleting forwarding history, following notably a request from supertestnet and a (concise) talk by Peter Todd at lightning++ in Berlin. The DeleteForwardingHistory allows operators to permanently delete forwarding events older than a specified
time threshold, without any node downtime". This is an important feature when it comes to user privacy (for example, for LPS running an LND node), since up until now forwarding events just accumulated in the node's database without a real way to delete them.

StackerNews Discussion

Peer Scoring In EclairPeer Scoring In Eclair

Acinq merged a per-peer profit scoring system into Eclair, that routinely identifies the top 10 peers in terms of routing revenue, and automatically expands the capacity toward these peers (by opening new channels or increasing the capacity of existing ones). It can also close idle channels, unless those channels are in an operator-configured whitelist. The scoring system can also dynamically adjust fees, increasing fees in top-earning channels (in an attempt to increase revenue per forwarded satoshi), or decreasing fees in idle channels as an alternative to closing them^[1].

Right now, these new features are disabled by default, and can also be configured very granularly.

RBF Minimum Feerate Fix in rust-lightningRBF Minimum Feerate Fix in rust-lightning

The rust-lightning team fixed a bug where the feerate picked for RBFing a transaction wouldn't necessary comply with the rules laid out in BIP125, because rust-lightning previously only considered the Lightning-specific rule that the feerate of the replacement transaction be "at least 1/24 greater than the last used feerate". At low feerates, the "25/24 rule" could be respected while not respecting the absolute fee increase required by BIP125. With this fix, rust-lightning now takes the lowest required increase to satisfy both requirements.

Jeffrey Czyz, who authored the fix, also proposed changing the Lightning specification to address this edge case.

Zero-fee Taproot Channels Using v3 TransactionsZero-fee Taproot Channels Using v3 Transactions

Speaking of the specification, Bastien Teinturier opened a draft for a new taproot_zero_fee_commitments channel type, merging the features of both zero_fee_commitments and simple_taproot channels.

As Bastien summarizes in his WIP implementation in Eclair:

Channels using this commitment format benefit from better protection against pinning attacks (thanks to TRUC/v3 transactions), don't need the update_fee mechanism, have less dust exposure risk, and use an overall simpler state machine, while benefiting from the privacy improvements of taproot channels.

We can quickly break down the core concepts of this new channel type as follows:

• Pay to Anchor and V3/TRUC transactions (inherited from the zero_fee_commitment channel type) remove the need for "actual" anchors, improving the design of Taproot channels by making it possible to use the revocation key as internal key everywhere, and also remove the need for additional 1 block timelocks ;
• Taproot brings the privacy that comes from Schnorr signatures and Musig2 key aggregation.

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!

You can also find Latest Strikes on https://lateststrikes.com. And subscribe to the newsletter there. See ya! 🖖

1. Yup, that's Lightning Network yield management. ↩