This week’s newsletter summarizes a vulnerability affecting old versions of LND, describes an idea for improving privacy when using co-signer services, and examines the impact of switching to quantum-resistant signature algorithms on HD wallets, scriptless multisig, and silent payments. Also included are our regular sections summarizing popular questions and answers on the Bitcoin Stack Exchange, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

  • ● LND gossip filter DoS vulnerability: Matt Morehouse posted to Delving Bitcoin about a vulnerability affecting past versions of LND that he previously responsibly disclosed. An attacker could repeatedly request historic gossip messages from an LND node until it ran out of memory and was terminated. The vulnerability was fixed in LND 0.18.3, released September 2024.

  • ● Chain code withholding for multisig scripts: Jurvis Tan posted to Delving Bitcoin about research he performed with Jesse Posner into improving the privacy and security of multisig collaborative custody. In a typical collaborative custody service, a 2-of-3 multisig may be used with the three keys being:

    • A user hot key that is stored on a networked device and signs transactions for the user (either manually or through software automation).

    • A provider hot key that is stored on a separate networked device under the exclusive control of the provider. The key only signs transactions according to a policy previously defined by the user, such as only allowing spending up to x BTC a day.

    • A user cold key that is stored offline and is only used if either the user hot key is lost or the provider ceases signing authorized transactions.

    Although the above configuration can provide a significant boost to security, the setup method almost always used involves the user sharing with the provider the BIP32 extended public keys for the user’s hot and cold wallets. This allows the provider to detect all funds received by the user’s wallet and to track all spends of those funds even if the user spends without provider assistance. Several ways to mitigate this privacy loss have previously been described, but they are either incompatible with typical use (e.g. using separate tapleaves) or complex (e.g. requiring MPC). Tan and Posner describe a simple alternative:

    • The provider generates half of a BIP32 HD extended key (just the key part). They give the public key to the user.

    • The user generates the other half (the chain code). They keep this private.

    When receiving funds, the user can combine the two halves to create an extended public key (xpub) and then derive multisig addresses as usual. The provider doesn’t know the chain code, preventing them from deriving the xpub or discovering the address.

    When spending funds, the user can derive from the chain code the necessary tweak that the provider needs to combine with their private key to create a valid signature. They simply share this tweak with the provider. The provider can’t learning anything from the tweak except that it’s valid for spending from the specific scriptPubKey that received funds.

    Some providers may require that the change output for a spending transaction sends the money back to the same script template. Tan’s post describes how this can easily be accomplished.

  • ● Research indicates common Bitcoin primitives are compatible with quantum-resistant signature algorithms: Jesse Posner posted to Delving Bitcoin several links to research papers that indicate that quantum-resistant signature algorithms provide comparable primitives to those currently used in Bitcoin for BIP32 HD wallets, silent payment addresses, scriptless multisignatures, and scriptless threshold signatures.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

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.

  • ● Libsecp256k1 v0.7.0 is a release of this library containing cryptographic primitives compatible with Bitcoin. It contains a few small changes that break API/ABI compatibility with previous releases.

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 #32521 makes legacy transactions with more than 2500 signature operations (sigops) non-standard in preparation for a potential consensus cleanup soft fork upgrade that would enforce the limit at the consensus level. If the softfork took place without this change, miners who don’t upgrade could become targets of trivial DoS attacks. See Newsletter #340 for additional details on the legacy input sigops limit.

  • ● Bitcoin Core #31829 adds resource limits to the orphan transaction handler, TxOrphanage (See Newsletter #304), to preserve opportunistic one-parent-one-child (1p1c) package relay in the face of DoS spam attacks. Four limits are enforced: a global cap of 3,000 orphan announcements (to minimize CPU and latency cost), a proportional per‑peer orphan announcements cap, a per‑peer weight reservation of 24 × 400 kWU, and a variable global memory cap. When any limit is exceeded, the node evicts the oldest orphan announcement from the peer that has used the most CPU or memory relative to its allowance (highest Peer DoS Score). The PR also deletes the ‑maxorphantxs option (default 100), whose policy of evicting random announcements allowed attackers to replace the entire orphan set and render 1p1c relay useless. See also Newsletter #362.

  • ● LDK #3801 extends attributable failures to the payment success path by recording how long a node holds an HTLC and propagating those hold‑time values upstream in the attribution payload. Previously, LDK only tracked hold times for failed payments (see Newsletter #349).

  • ● LDK #3842 extends its interactive transaction construction state machine (See Newsletter #295) to handle the signing coordination for shared inputs in splicing transactions. The prevtx field of the TxAddInput message is made optional to reduce memory usage and simplify validation.

  • ● BIPs #1890 changes the separator parameter from + to - in BIP77 because some HTML 2.0 URI libraries treat + as if it is a blank space. In addition, fragment parameters must now be ordered lexicographically, rather than in reverse, to simplify the async payjoin protocol.

  • ● BOLTs #1232 makes the channel_type field (see Newsletter #165) mandatory when opening a channel because every implementation enforces it. This PR also updates BOLT9 by adding a new context type T for features that can be included in the channel_type field.

Want more?

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