This week’s newsletter announces the disclosure of a vulnerability affecting old versions of LND and summarizes continued discussion about PSBTs for silent payments. Also included are our regular sections describing recent changes to services and client software, announcing new releases and release candidates, and summarizing notable changes to popular Bitcoin infrastructure software.

News

  • ● Disclosure of vulnerability affecting old versions of LND: Matt Morehouse posted to Delving Bitcoin the disclosure of a vulnerability affecting versions of LND before 0.17.0. LN relays payment instructions and onion messages using onion-encrypted packets that contain multiple encrypted payloads. Each payload is prefixed by its length, which since 2019 has been allowed to be any size up to 1,300 bytes for payments. Onion messages, which were introduced later, may be up to 32,768 bytes. However, the payload size prefix uses a data type that allows indicating a size up to 264 bytes.

    LND accepted a payload’s indicated size up to 4 gigabytes and would allocate that amount of memory before further processing the payload. This is enough to exhaust the memory of some LND nodes, resulting in them crashing or being terminated by the operating system, and it could be used to crash nodes that have more memory by sending multiple onion packets constructed this way. A crashed LN node cannot send time-sensitive transactions that may be necessary to protect its funds, potentially leading to funds being stolen.

    The vulnerability was fixed by reducing the maximum memory allocation to 65,536 bytes.

    Anyone operating an LND node should upgrade to version 0.17.0 or above. Upgrading to the latest version (0.18.0 at the time of writing) is always recommended.

  • ● Continued discussion of PSBTs for silent payments: several developers have been discussing adding support for coordinating the sending of silent payments using PSBTs. Since our previous summary, the discussion has focused on using a technique where each signer generates an ECDH share and a compact proof that they generated their share correctly. These are added to the input section of the PSBT. When shares from all signers are received, they are combined with the receiver’s silent payment scan key to produce the actual key placed in the output script (or multiple keys with multiple output scripts if multiple silent payments are being made in the same transaction).

    After the transaction’s output scripts are known, each signer re-processes the PSBT to add their signatures. This results in a two-round process for the complete signing of the PSBT (in addition to any other rounds required by other protocols, such as MuSig2). However, if there’s only one signer for the entire transaction (e.g. the PSBT is being sent to a single hardware signing device), the signing process can be completed in a single round.

    All active participants in the discussion at the time of writing seem roughly agreed on this approach, although discussion of edge cases is continuing.

Changes to services and client software

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

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.

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 #29325 begins storing transaction versions as unsigned integers. Since the original version of Bitcoin 0.1, they were stored as signed integers. The BIP68 soft fork began treating them as unsigned integers, but at least one Bitcoin re-implementation failed to reproduce this behavior, leading to a possible consensus failure (see Newsletter #286). By always storing and using transaction versions using unsigned integers, it is hoped that any future Bitcoin implementations based on reading Bitcoin Core’s code will use the correct type.

  • ● Eclair #2867 defines a new type of EncodedNodeId to be assigned for mobile wallets in a blinded path. This allows a wallet provider to be notified that the next node is a mobile device, enabling them to account for mobile-specific conditions.

  • ● LND #8730 introduces a RPC command lncli wallet estimatefee which receives a confirmation target as input and returns a fee estimation for on-chain transactions in both sat/kw (satoshis per kilo-weight unit) and sat/vbyte.

  • ● LDK #3098 updates LDK’s Rapid Gossip Sync (RGS) to v2, which extends v1 by adding additional fields in the serialized structure. These new fields include a byte indicating the number of default node features, an array of node features, and supplemental feature or socket address information following each node public key. This update is distinct from the proposed BOLT7 gossip update similarly referred to as gossip v2.

  • ● LDK #3078 adds support for asynchronous payment of BOLT12 invoices by generating an InvoiceReceived event upon reception if the configuration option manually_handle_bolt12_invoices is set. A new command send_payment_for_bolt12_invoice is exposed on ChannelManager to pay the invoice. This can allow code to evaluate an invoice before deciding whether to pay or reject it.

  • ● LDK #3082 introduces BOLT12 static invoice (reusable payment request) support by adding an encoding and parsing interface, and builder methods to construct a BOLT12 static invoice as a response to InvoiceRequest from an offer.

  • ● LDK #3103 begins using a performance scorer in benchmarks based on frequent probes of actual payment paths. The hope is that this results in more realistic benchmarks.

  • ● LDK #3037 begins force closing channels if their feerate is stale and too low. LDK continuously keeps track of the lowest acceptable feerate its estimator returned in the past day. Each block, LDK will close any channel that pays a feerate below that past-day minimum. The goal is “to ensure that channel feerates are always sufficient to get our commitment transaction confirmed on-chain if we need to force close”.