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.

News

• ● Disclosure of past LN vulnerability related to fake funding: Matt Morehouse posted to the Lightning-Dev mailing list the summary of a vulnerability he had previously responsibly disclosed and which is now addressed in the latest versions of all popular LN implementations. To understand the vulnerability, imagine that Bob runs an LN node. He receives a request from Mallory’s node to open a new channel and they go through the channel opening process up to the stage where Mallory is supposed to broadcast a transaction that funds the channel. In order to later use that channel, Bob needs to store some state related to it and begin scanning new blocks for the transaction to become sufficiently confirmed. If Mallory never broadcasts the transaction, Bob’s storage and scanning resources are wasted. If Mallory repeats the process thousands or millions of times, it might waste Bob’s resources to the point where his LN node is unable to do anything else—including performing time-sensitive operations that are necessary to prevent loss of money.

  In Morehouse’s testing against his own nodes, he was able to cause significant problems with Core Lightning, Eclair, LDK, and LND, including two cases that (in our opinion) could likely lead to loss of funds among many nodes. Morehouse’s full description links to the PRs where the issue was addressed (which includes PRs covered in Newsletters #237 and #240) and lists the LN releases that addressed the vulnerability:

  • Core Lightning 23.02
  • Eclair 0.9.0
  • LDK 0.0.114
  • LND 0.16.0

  There was some follow-up discussion on the mailing list and on IRC.

• ● 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.

• ● Is there an economic incentive to switch from P2WPKH to P2TR? Murch walks through common wallet usage patterns while comparing weights of transaction inputs and outputs for P2WPKH and P2TR output types. He concludes by saying: “Overall, you’d save up to 15.4% in transaction fees by using P2TR instead of P2WPKH. If you make vastly more small payments than you receive payments, you may save up to 1.5% by sticking to P2WPKH.”

• ● What is the BIP324 encrypted packet structure? Pieter Wuille outlines the network packet structure for version 2 P2P transport as proposed in BIP324 with progress tracked in Bitcoin Core #27634.

• ● What is the false positive rate for compact block filters? Murch answers from BIP158’s section on block filter parameter selection that notes a false positive rate for compact block filters of 1/784931, the equivalent of 1 block every 8 weeks for a wallet monitoring about 1000 output scripts.

• ● What opcodes are part of the MATT proposal? Salvatoshi explains his Merkleize All The Things (MATT) proposal (see Newsletters #226, #249, and #254), including its currently proposed opcodes: OP_CHECKTEMPLATEVERIFY, OP_CHECKCONTRACTVERIFY, and OP_CAT.

• ● Is there a well defined last Bitcoin block? RedGrittyBrick and Pieter Wuille point out that while there is not a block height limit, the current consensus rules will not permit a new block beyond Bitcoin’s unsigned 32-bit timestamp limit in the year 2106. Transaction nLockTime values have the same timestamp limit.

• ● Why are miners setting the locktime in coinbase transactions? Bordalix answers a long-open question about miners seemingly using the coinbase transaction’s locktime field to communicate something. A mining pool operator explained that they “repurpose those 4 bytes to hold the stratum session data for faster reconnect” and went on to elaborate on the scheme.

• ● Why doesn’t Bitcoin Core use auxiliary randomness when performing Schnorr signatures? Matthew Leon asks why BIP340 recommends using auxiliary randomness when generating a schnorr signature nonce for protection against side channel attacks, yet Bitcoin Core doesn’t provide auxiliary randomness in its implementation. Andrew Chow answers that the current implementation is still safe and that no PR has been opened to address the recommendation.

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.