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

  • ● A mathematical theory of payment channel networks: René Pickhardt posted to Delving Bitcoin about the publication of his new paper called “A Mathematical Theory of Payment Channel Network”. 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) 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)

    • An analysis on different mitigation strategies 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). Pickhardt also provided his collection 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.

  • ● Electrum server for testing silent payments: Frigate Electrum Server implements the remote scanner service from BIP352 to provide silent payment 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.

  • ● BDK WASM library: The bdk-wasm library, originally developed and used 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.

  • ● Core Lightning 25.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 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).

  • ● LND 0.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 for more details.

Notable code and documentation changes

Notable recent changes in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

  • ● Bitcoin Core #32471 fixes a bug where calling the listdescriptors RPC with the private=true parameter (see Newsletters #134 and #162) would fail if any descriptor had a missing private key. This issue affected wallets containing both non-watch-only and watch-only descriptors, as well as multisig descriptors without all the private keys. This PR ensures that the RPC correctly returns the available private keys, enabling users to back them up properly. Calling listdescriptors private=true on a strictly watch-only wallet still fails.

  • ● Bitcoin Core #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.

  • ● Core Lightning #8831 fixes a critical bug where nodes created with v25.12 could not spend funds sent to non-P2TR addresses. Although all address types were derived based on BIP86 for those nodes, the signing code only used BIP86 for P2TR addresses. This PR ensures signing uses BIP86 derivation for all address types.

  • ● LDK #4261 adds support for mixed-mode 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.

  • ● LDK #4152 adds support for dummy hops on blinded payments paths, paralleling the feature for blinded message paths added in Newsletter #370. Adding additional hops makes it significantly harder to determine the distance to or the identity of the receiver node. See Newsletter #381 for previous work enabling this.

  • ● LND #10488 fixes a bug where channels opened with the fundMax option (see Newsletter #246) were limited in size by the user-configured maxChanSize setting (see Newsletter #116), 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.

  • ● LND #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 from 2016.

  • ● Rust Bitcoin #5402 adds validation during decoding to reject transactions with duplicate inputs, related to CVE-2018-17144. Transactions containing multiple inputs spending the same outpoint are invalid by consensus.

  • ● BIPs #1820 updates BIP3 to status Deployed, replacing BIP2 as the guideline for the Bitcoin Improvement Proposal (BIP) process. See Newsletter #388 for more details.

  • ● BOLTs #1306 clarifies in the BOLT12 specification that 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.

  • ● BLIPs #59 updates BLIP51, also known as LSPS1, to add support for BOLT12 offers as an option for paying Lightning Service Providers (LSPs), alongside the existing BOLT11 and on-chain options. This was previously implemented in LDK (see Newsletter #347).

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 17:30 UTC on January 27. The discussion is also recorded and will be available from our podcasts page.