Bitcoin Optech Newsletter #389

By Bitcoin Optech January 23, 2026 · Edited February 5, 2026

This week’s newsletter links to a paper on the study of payment channel networks. Also included are our regular sections describing recent updates to services and client software, announcing new

This week’s newsletter links to a paper on the study of payment channel networks. Also included are our regular sections describing recent updates to services and client software, announcing new releases and release candidates, and summarizing notable changes to popular Bitcoin infrastructure software.

News

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#a-mathematical-theory-of-payment-channel-networks) A mathematical theory of payment channel networks: René Pickhardt posted (https://delvingbitcoin.org/t/a-mathematical-theory-of-payment-channel-networks/2204) to Delving Bitcoin about the publication of his new paper (https://arxiv.org/pdf/2601.04835) called “A Mathematical Theory of Payment Channel Networks”. In the paper, Pickhardt groups several observations, gathered during years of research, under a single geometric framework. In particular, the paper aims to analyze common phenomena, such as channel depletion (see Newsletter #333 (https://bitcoinops.org/en/newsletters/2024/12/13/#insights-into-channel-depletion)) and capital inefficiencies of two-party channels, assessing how they are interconnected and why they are true.

The main paper contributions are the following:



  • 
    A model for feasible wealth distributions of users on the Lightning Network

given a channel graph

  • 
    A formula for estimating the upper bound of payment bandwidth for payments

  

  • 
    A method to estimate the likelihood that a payment is feasible (see

Newsletter #309 (https://bitcoinops.org/en/newsletters/2024/06/28/#estimating-the-likelihood-that-an-ln-payment-is-feasible))

  • 
    An analysis on different

mitigation strategies (https://delvingbitcoin.org/t/mitigating-channel-depletion-in-the-lightning-network-a-survey-of-potential-solutions/1640/1) for channel depletion

  • 
    The conclusion that two-party channels put strong constraints to the ability of liquidity to

flow between peers of the network

According to Pickhardt, the insights coming from his research were the motivation behind his

recent post about using Ark as a channel factory (see Newsletter #387 (https://bitcoinops.org/en/newsletters/2026/01/09/#using-ark-as-a-channel-factory)). Pickhardt also provided his collection (https://github.com/renepickhardt/Lightning-Network-Limitations) of code, notebooks, and papers that were used as groundwork for his research.

Finally, Pickhardt opened the discussion on his work to questions and feedback from the LN

developer community on how the protocol design could be influenced by his research and on the best use for multi-party channels.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#electrum-server-for-testing-silent-payments) Electrum server for testing silent payments: Frigate Electrum Server (https://github.com/sparrowwallet/frigate) implements the remote scanner (https://github.com/silent-payments/BIP0352-index-server-specification/blob/main/README.md#remote-scanner-ephemeral) service from BIP352 (https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki) to provide silent payment (https://bitcoinops.org/en/topics/silent-payments/) scanning for client applications. Frigate also uses modern GPU computation to decrease scanning time which is useful for providing multi-user instances that handle many simultaneous scanning requests.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#bdk-wasm-library) BDK WASM library: The bdk-wasm (https://github.com/bitcoindevkit/bdk-wasm) library, originally developed and used (https://metamask.io/news/bitcoin-on-metamask-btc-wallet) by the MetaMask organization, provides access to BDK features in environments that support WebAssembly (WASM).

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#core-lightning-25-12-1) Core Lightning 25.12.1 (https://github.com/ElementsProject/lightning/releases/tag/v25.12.1) is a maintenance release that fixes a critical bug where nodes created with v25.12 could not spend funds sent to non-P2TR (https://bitcoinops.org/en/topics/taproot/) addresses (see below). It also fixes recovery and hsmtool compatibility issues with the new mnemonic-based hsm_secret format introduced in v25.12 (see Newsletter #388 (https://bitcoinops.org/en/newsletters/2026/01/16/#core-lightning-8830)).

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#lnd-0-20-1-beta-rc1) LND 0.20.1-beta.rc1 (https://github.com/lightningnetwork/lnd/releases/tag/v0.20.1-beta.rc1) is a release candidate for a minor version that adds a panic recovery for gossip message processing, improves reorg protection, implements LSP detection heuristics, and fixes multiple bugs and race conditions. See the release notes (https://github.com/lightningnetwork/lnd/blob/v0.20.x-branch/docs/release-notes/release-notes-0.20.1.md) for more details.

Notable code and documentation changes

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#bitcoin-core-32471) Bitcoin Core #32471 (https://github.com/bitcoin/bitcoin/issues/32471) fixes a bug where calling the listdescriptors RPC with the private=true parameter (see Newsletters #134 (https://bitcoinops.org/en/newsletters/2021/02/03/#bitcoin-core-20226) and #162 (https://bitcoinops.org/en/newsletters/2021/08/18/#bitcoin-core-21500)) would fail if the wallet contained any descriptor (https://bitcoinops.org/en/topics/output-script-descriptors/) for which it had some but not all the private keys. This PR updates the RPC to return the descriptor with the available subset of private keys, enabling users to back them up. Calling listdescriptors private=true on a watch-only wallet still fails.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#bitcoin-core-34146) Bitcoin Core #34146 (https://github.com/bitcoin/bitcoin/issues/34146) improves address propagation by sending a node’s first self-announcement in its own P2P message. Previously, the self-announcement was bundled with multiple other addresses in response to a peer’s getaddr request, which could cause it to be dropped or to displace other addresses.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#core-lightning-8831) Core Lightning #8831 (https://github.com/ElementsProject/lightning/issues/8831) fixes a critical bug where nodes created with v25.12 could not spend funds sent to non-P2TR (https://bitcoinops.org/en/topics/taproot/) addresses. Although all address types were derived based on BIP86 (https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki) for those nodes, the signing code only used BIP86 (https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki) for P2TR addresses. This PR ensures signing uses BIP86 (https://github.com/bitcoin/bips/blob/master/bip-0086.mediawiki) derivation for all address types.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#ldk-4261) LDK #4261 (https://github.com/lightningdevkit/rust-lightning/issues/4261) adds support for mixed-mode splicing (https://bitcoinops.org/en/topics/splicing/), allowing for simultaneous splice-in and splice-out in the same transaction. The funding input pays the appropriate fees, as in the splice-in case. The net contributed value may be negative if more value is spliced out than spliced in.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#ldk-4152) LDK #4152 (https://github.com/lightningdevkit/rust-lightning/issues/4152) adds support for dummy hops on blinded (https://bitcoinops.org/en/topics/rendez-vous-routing/) payments paths, paralleling the feature for blinded message paths added in Newsletter #370 (https://bitcoinops.org/en/newsletters/2025/09/05/#ldk-3726). Adding additional hops makes it significantly harder to determine the distance to or the identity of the receiver node. See Newsletter #381 (https://bitcoinops.org/en/newsletters/2025/11/21/#ldk-4126) for previous work enabling this.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#lnd-10488) LND #10488 (https://github.com/lightningnetwork/lnd/issues/10488) fixes a bug where channels opened with the fundMax option (see Newsletter #246 (https://bitcoinops.org/en/newsletters/2023/04/26/#lnd-6903)) were limited in size by the user-configured maxChanSize setting (see Newsletter #116 (https://bitcoinops.org/en/newsletters/2020/09/23/#lnd-4567)), which is intended to only limit incoming channel requests. This PR ensures that the fundMax option uses the protocol-level maximum channel size instead, depending on whether the user and peer support large channels (https://bitcoinops.org/en/topics/large-channels/).

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#lnd-10331) LND #10331 (https://github.com/lightningnetwork/lnd/issues/10331) improves how channel closes handle blockchain reorgs by using scaled confirmation requirements based on channel size, where the minimum is 1 and the maximum is 6 confirmations. The chain watcher is revamped with the introduction of a state machine to better detect blockchain reorgs and track competing channel close transactions in such scenarios. The PR also adds monitoring for negative confirmations (when a confirmed transaction is later reorged out), though how to handle them remains unsolved. This PR addresses LND’s oldest open issue (https://github.com/lightningnetwork/lnd/issues/53) from 2016.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#rust-bitcoin-5402) Rust Bitcoin #5402 (https://github.com/rust-bitcoin/rust-bitcoin/issues/5402) adds validation during decoding to reject transactions with duplicate inputs, related to CVE-2018-17144 (https://bitcoinops.org/en/topics/cve-2018-17144/). Transactions containing multiple inputs spending the same outpoint are invalid by consensus.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#bips-1820) BIPs #1820 (https://github.com/bitcoin/bips/issues/1820) updates BIP3 (https://github.com/bitcoin/bips/blob/master/bip-0003.md) to status Deployed, replacing BIP2 (https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki) as the guideline for the Bitcoin Improvement Proposal (BIP) process. See Newsletter #388 (https://bitcoinops.org/en/newsletters/2026/01/16/#bip-process-updated) for more details.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#bolts-1306) BOLTs #1306 (https://github.com/lightning/bolts/issues/1306) clarifies in the BOLT12 (https://github.com/lightning/bolts/blob/master/12-offer-encoding.md) specification that offers (https://bitcoinops.org/en/topics/offers/) with an empty offer_chains field must be rejected. An offer with this field present but containing zero chain hashes makes invoice requests impossible since the payer cannot satisfy the requirement to set invreq_chain to one of the offer_chains.

• ● (https://bitcoinops.org/en/newsletters/2026/01/23/#blips-59) BLIPs #59 (https://github.com/lightning/blips/issues/59) updates BLIP51 (https://github.com/lightning/blips/blob/master/blip-0051.md), also known as LSPS1, to add support for BOLT12 offers (https://bitcoinops.org/en/topics/offers/) as an option for paying Lightning Service Providers (LSPs), alongside the existing BOLT11 (https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md) and on-chain options. This was previously implemented in LDK (see Newsletter #347 (https://bitcoinops.org/en/newsletters/2025/03/28/#ldk-3649)).

Reference: https://bitcoinops.org/en/newsletters/2026/01/23/

Write a comment

No comments yet.