This week’s newsletter discloses vulnerabilities in LND and describes a project for running a virtual machine in an embedded secure element. Also included are our regular sections describing changes to services and client software, summarizing popular questions and answers of the Bitcoin Stack Exchange, and examining recent changes to popular Bitcoin infrastructure software.

News

  • ● Critical vulnerabilities fixed in LND 0.19.0: Matt Morehouse posted to Delving Bitcoin about critical vulnerabilities fixed in LND 0.19.0. In this disclosure, there are three vulnerabilities mentioned including one denial-of-service (DoS) and two theft-of-funds.

    • ● Message processing out-of-memory DoS vulnerability: This DoS vulnerability took advantage of LND allowing as many peers as there were available file descriptors. The attacker could open multiple connections to the victum and spam 64 KB query_short_channel_ids messages while keeping the connection open until LND ran out of memory. The mitigation for this vulnerability was implemented in LND 0.19.0 on March 12th, 2025.

    • ● Loss of funds due to new excessive failback vulnerability: This attack is a variant of the excessive failback bug, and while the original fix for the failback bug was made in LND 0.18.0, a minor variant remained when the channel was force closed using LND’s commitment instead of the attacker’s. The mitigation for this vulnerability was implemented in LND 0.19.0 on March 20th, 2025.

    • ● Loss of funds vulnerability in HTLC sweeping: This theft-of-funds vulnerability took advantage of weaknesses in LND’s sweeper system, which enabled an attacker to stall LND’s attempts at claiming expired HTLC’s on chain. After stalling for 80 blocks then the attacker could steal essentially the whole channel balance.

    Morehouse urges users to upgrade to LND 0.19.0 or higher to avoid denial of service and loss of funds.

  • ● A virtualized secure enclave for hardware signing devices: Salvatoshi posted to Delving Bitcoin about Vanadium, a virtualized secure enclave for hardware signing devices. Vanadium is a RISC-V virtual machine, designed to run arbitrary applications, called “V-Apps”, in an embedded secure element, outsourcing memory and storage needs to an untrusted host. According to Salvatoshi, Vanadium’s aim is to abstract the complexities of embedded development, such as limited RAM and storage, vendor-specific SDKs, slow development cycles, and debugging, to make innovation in self-custody faster, more open, and standardized.

    Salvatoshi notes that from a performance perspective, the virtual machine only runs the application business logic, while the heavy operations (i.e. cryptography) run natively via ECALLs.

    While the threat model is the same as existing hardware wallets, Salvatoshi points out that this approach allows memory access-pattern leakage, where the host can observe which code and data pages are accessed and when. This is particularly important for cryptography developers.

    The project is still not deemed production-ready, and there are some known limitations, such as performance and UX. However, Salvatoshi asked developers to try it out and provide feedback to lay out the roadmap for the project.

Changes to services and client software

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

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.

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 #33528 prevents the wallet from spending outputs of unconfirmed TRUC transactions with an unconfirmed ancestor, to comply with TRUC policy limits. Previously, the wallet could create such transactions, but they were rejected when broadcast.

  • ● Bitcoin Core #33723 removes dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us from the list of DNS seeds. Maintainers found that it was the only seed omitting newer Bitcoin Core versions (29 and 30), violating the policy stating “seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network”.

  • ● Bitcoin Core #33993 updates the help text for the stopatheight option, clarifying that the target height specified to stop syncing is only an estimate and that blocks after that height may still be processed during shutdown.

  • ● Bitcoin Core #33553 adds a warning message indicating potential database corruption when headers are received for blocks that were previously marked as invalid. This helps users realize they might be stuck in a header sync loop. This PR also enables a fork detection warning message that was previously disabled for IBD.

  • ● Eclair #3220 extends the existing spendFromChannelAddress helper to taproot channels, adding a spendfromtaprootchanneladdress endpoint that allows users to cooperatively spend UTXOs accidentally sent to taproot channel funding addresses, with MuSig2 signatures.

  • ● LDK #4231 stops force-closing zero-conf channels when a block reorganization unconfirms the channel funding transaction. LDK has a mechanism to force-close locked channels that become unconfirmed due to the risk of double-spending. However, the trust model is different for zero-conf channels. The SCID change is also now properly handled in this edge case.

  • ● LND #10396 tightens the router’s heuristic for detecting LSP-assisted nodes: invoices with a public destination node or whose route hint destination hops are all private are now treated as normal nodes, while those with a private destination and at least one public destination hop are classified as LSP-backed. Previously, the looser heuristic could misclassify nodes as LSP-assisted, resulting in more probing failures. Now, when an LSP-assisted node is detected, LND probes up to three candidate LSPs and uses the worst-case route (highest fees and CLTV) to provide conservative fee estimates.

  • ● BTCPay Server #7022 introduces an API for the Subscriptions feature (see Newsletter #379), enabling merchants to create and manage offerings, plans, subscribers, and checkouts. About a dozen endpoints have been added for each specific operation.

  • ● Rust Bitcoin #5379 adds a method for constructing Pay-to-Anchor (P2A) addresses, to complement the existing method for verifying P2A addresses.

  • ● BIPs #2050 updates BIP390, which specifies MuSig2 descriptors, to allow musig() key expressions inside of a rawtr() in addition to the already allowed tr(), aligning the description with existing test vectors and Bitcoin Core’s descriptor implementation.

Happy holidays!

This is Bitcoin Optech’s final regular newsletter of the year. On Friday, December 19th, we’ll publish our eighth annual year-in-review newsletter. Regular publication will resume on Friday, January 2nd.