This week’s newsletter announces the responsible disclosure of a vulnerability affecting old LN implementations and summarizes a suggestion for a mashup of proposed covenant opcodes. Also included are our regular sections with selected questions and answers from the Bitcoin Stack Exchange, announcements of new software releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.


  • Covenant mashup using TXHASH and CSFS: Brandon Black posted to the Bitcoin-Dev mailing list a proposal for a version of OP_TXHASH (see Newsletter #185) combined with OP_CHECKSIGFROMSTACK that would provide most of the features of OP_CHECKTEMPLATEVERIFY (CTV) and SIGHASH_ANYPREVOUT (APO) without much additional onchain cost over those individual proposals. Although the proposal stands on its own, part of the motivation for creating it was to “clarify our thinking about [CTV and APO] individually and together, and potentially move toward consensus on a path toward enabling […] amazing ways to use bitcoin in the future”.

    The proposal received some discussion on the mailing list, with additional revisions posted and discussed on the Delving Bitcoin forum.

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.

  • Core Lightning 23.08 is the newest major release of this popular LN node implementation. New features include the ability to change several node configuration settings without restarting the node, support for Codex32-formatted seed backup and restore, a new experimental plugin for improved payment pathfinding, experimental support for splicing, and the ability to pay locally-generated invoices, among many other new features and bug fixes.

  • LND v0.17.0-beta.rc1 is a release candidate for the next major version of this popular LN node implementation. A major new experimental feature planned for this release, which could likely benefit from testing, is support for “simple taproot channels” as described in LND PR #7904 in the notable changes section.

Notable code and documentation changes

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

  • Bitcoin Core #27460 adds a new importmempool RPC. The RPC will load a mempool.dat file and attempt to add the loaded transactions to its mempool.

  • LDK #2248 provides a built-in system that LDK downstream projects can use for tracking the UTXOs referenced in gossip messages. LN nodes that process gossip must only accept messages that are signed by a key associated with a UTXO, otherwise they can be forced into processing and relaying spam messages, or attempting to forward payments over nonexistent channels (which will always fail). The new built-in UtxoSource works for LN nodes connected to a local Bitcoin Core.

  • LDK #2337 makes it easier to use LDK for building watchtowers that run independently from a user’s wallet but can receive encrypted LN penalty transactions from the user’s node. A watchtower can then extract information from each transaction in new blocks and use that information to attempt to decrypt the previously-received encrypted data. If the decryption succeeds, the watchtower can broadcast the decrypted penalty transaction. This protects the user against their counterparty publishing a revoked channel state when the user is unavailable.

  • LDK #2411 and #2412 add an API for constructing payment paths for blinded payments. The PRs help separate LDK’s code for onion messages (which use blinded paths) from blinded paths themselves. A follow-up in #2413 will actually add support for route blinding.

  • LDK #2507 adds a workaround for a longstanding issue in another implementation that leads to unnecessary channel force closures.

  • LDK #2478 adds an event that provides information about a forwarded HTLC that has now been settled, including what channel it came from, the amount of the HTLC, and the amount of fee collected from it.

  • LND #7904 adds experimental support for “simple taproot channels”, allowing LN funding and commitment transactions to use P2TR with support for MuSig2 scriptless multisignature signing when both parties are cooperating. This reduces transaction weight space and improves privacy when channels are closed cooperatively. LND continues to exclusively use HTLCs, allowing payments starting in a taproot channel to continue to be forwarded through other LN nodes that don’t support taproot channels.

    This PR includes 134 commits that were previously merged into a staging branch from the following PRs: #7332, #7333, #7331, #7340, #7344, #7345, #7346, #7347, and #7472.