This week’s newsletter describes a vulnerability affecting older versions of LDK, looks at a newly disclosed aspect of a vulnerability originally published in 2023, and summarizes renewed discussion about compact block reconstruction statistics. Also included are our regular sections summarizing popular questions on the Bitcoin Stack Exchange, announcing new releases and release candidates, and describing recent changes to popular Bitcoin infrastructure software.

News

• ● Vulnerability in LDK claim processing: Matt Morehouse posted to Delving Bitcoin to disclose a vulnerability affecting LDK that he responsibly disclosed and which was fixed in LDK version 0.1. When a channel is unilaterally closed with multiple pending HTLCs, LDK will attempt to resolve as many HTLCs as possible in the same transaction to save on transaction fees. However, if the channel counterparty is able to confirm any of the batched HTLCs first, that will conflict with the batch transaction and make it invalid. In that case, LDK would correctly create an updated batch transaction with the conflict removed. Unfortunately, if the counterparty’s transaction conflicts with multiple separate batches, LDK would incorrectly only update the first batch. The remaining batches would not be able to be confirmed.

  Nodes must resolve their HTLCs before a deadline, or the counterparty can steal back their funds. A timelock prevents the counterparty from spending HTLCs before their individual deadlines. Most older versions of LDK put those HTLCs in a separate batch that it was sure to confirm before the counterparty could confirm a conflicting transaction, ensuring that no funds could be stolen. For HTLCs that didn’t allow funds theft, but which the counterparty could resolve immediately, there was a risk that the counterparty could cause funds to become stuck. Morehouse writes that this can be fixed by “upgrading to LDK version 0.1 and replaying the sequence of commitment and HTLC transactions that led to the lock up.”

  However, the release candidate LDK 0.1-beta changed its logic (see Newsletter #335) and began batching all types of HTLCs together, which could allow an attacker to create a conflict with a timelocked HTLC. If the resolution of that HTLC remained stuck after the timelock expired, theft was possible. Upgrading to the release version of LDK 0.1 also fixes this form of the vulnerability.

  Morehouse’s post provides additional details and discusses possible ways to prevent future vulnerabilities stemming from the same root cause.

• ● Replacement cycling attacks with miner exploitation: Antoine Riard posted to the Bitcoin-Dev mailing list to disclose an additional vulnerability possible with the replacement cycling attack he originally publicly disclosed in 2023 (see Newsletter #274). In short:

  1. Bob broadcasts a transaction paying Mallory (and possibly other people).

  2. Mallory pins Bob’s transaction.

  3. Bob doesn’t realize he’s been pinned and bumps the fees (using either RBF or CPFP).

  4. Because Bob’s original transaction was pinned, his fee bump doesn’t propagate. However, Mallory receives it somehow. Steps 3 and 4 may repeat multiple times to greatly increase Bob’s fee.

  5. Mallory mines Bob’s highest fee bump, which nobody else is trying to mine because it didn’t propagate. This allows Mallory to earn more fees than other miners.

  6. Mallory can now use replacement cycling to move her transaction pin to another transaction and repeat the attack (possibly with a different victim) without allocating additional funds, making the attack economically efficient.

  We don’t judge the vulnerability to be a significant risk. Exploiting the vulnerability requires specific circumstances that might be rare and can result in an attacker losing money if they judge network conditions poorly. If an attacker did regularly exploit the vulnerability, we believe their behavior would be detected by community members who build and use block monitoring tools.

• ● Updated stats on compact block reconstruction: following up on a previous thread (see Newsletter #315), developer 0xB10C posted to Delving Bitcoin updated stats on the frequency at which his Bitcoin Core nodes needed to request additional transactions to perform compact block reconstruction. When a node receives a compact block, it must request any transactions in that block that it does not already have in its mempool (or in its extrapool, which is a special reserve that aims to help with compact block reconstruction). This significantly slows down block propagation speed and contributes to miner centralization.

  0xB10C found that the frequency of requests increases significantly as the size of the mempool grows. Several developers discussed possible causes, with initial data indicating that the missing transactions were orphans—child transactions of unknown parents, which Bitcoin Core only stores briefly in case their parents arrive within a short time. Improved tracking and requesting of the parents of orphan transactions, recently merged into Bitcoin Core (see Newsletter #338), could help improve this situation.

  Developers also discussed other possible solutions. Nodes can’t reasonably keep orphan transactions for a long time because an attacker can create them for free—but it might be possible to persist a larger number of them and other evicted transactions for a longer time in the extrapool. The discussion was inconclusive at the time of writing.

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.

• ● Who uses or wants to use PSBTv2 (BIP370)? In addition to posting to the Bitcoin-Dev mailing list (see Newsletter #338), Sjors Provoost posted to the Bitcoin Stack Exchange seeking users and potential users of PSBTv2. Optech readers interested in BIP370 should reply to the question or mailing list post.

• ● In the bitcoin’s block genesis, which parts can be filled arbitrarily? Pieter Wuille points out that none of the fields of Bitcoin’s genesis block are subject to the normal block validation rules saying, “Literally all of them could have had any content. It looks like a normal block where possible, but it didn’t need to”.

• ● Lightning force close detection Sanket1729 and Antoine Poinsot discuss how the mempool.space block explorer uses nLockTime and nSequence fields to determine whether a transaction is a Lightning force close transaction.

• ● Is a segwit-formatted transaction with all inputs of non-witness program type valid? Pieter Wuille distinguishes between BIP141, which specifies the structure and validity around the segwit consensus changes and computation of wtxids, and BIP144, which specifies the serialization format for communicating segwit transactions.

• ● P2TR Security Question Pieter Wuille quotes from BIP341 that specifies taproot to explain why a public key is directly included in an output, and related considerations around quantum computing.

• ● What exactly is being done today to make Bitcoin “quantum-safe”? Murch comments on the current state of quantum capabilities, recent post-quantum signature schemes, and the proposed QuBit - Pay to Quantum Resistant Hash BIP.

• ● What are the harmful effects of a shorter inter-block time? Pieter Wuille highlights the advantage conveyed, as a result of block propagation time, to a miner that just found a block, how that advantage is magnified with shorter block times, and the potential effects of the advantage.

• ● Could proof-of-work be used to replace policy rules? Jgmontoya wonders if attaching proof-of-work to non-standard transactions could achieve similar node resource protection goals as mempool policy. Antoine Poinsot points out that there are other goals of mempool policy beyond protecting node resources including efficient block template building, discouraging some transaction types, and protecting soft fork upgrade hooks.

• ● How does MuSig work in real Bitcoin scenarios? Pieter Wuille elaborates on the differences between MuSig versions, calls out the Interactive Aggregated Signature (IAS) variant of MuSig1 and its interplay with cross-input signature aggregation (CISA), and mentions threshold signatures before answering lower level questions on the specifications.

• ● How does the -blocksxor switch that obfuscates the blocks.dat files work? Vojtěch Strnad describes the -blocksxor option for obfuscating Bitcoin Core block data files on disk (see Newsletter #316).

• ● How does the related key attack on Schnorr signatures work? Pieter Wuille answers that “the attack applies when the victim chooses a related key, and the attacker knows the relation” and that related keys are extremely common.

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.

• ● LDK v0.1.1 is a security release of this popular library for building LN-enable applications. An attacker willing to sacrifice at least 1% of channel funds could trick the victim into closing other unrelated channels, which may result in the victim unnecessarily spending money on transaction fees. Matt Morehouse, who discovered the vulnerability, posted about it to Delving Bitcoin; Optech will provide a more detailed summary in next week’s newsletter. The release also includes API updates and bug fixes.

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 #31376 extends a check that prevents miners from creating block templates that exploit the timewarp bug to apply to all networks, not just testnet4. This change is in preparation for a possible future soft fork that would permanently fix the timewarp bug.

• ● Bitcoin Core #31583 updates the getmininginfo, getblock, getblockheader, getblockchaininfo and getchainstates RPC commands to now return a nBits field (the compact representation of the block difficulty target) and a target field. In addition, getmininginfo adds a next object that specifies the height, nBits, difficulty, and target for the next block. To derive and obtain the target, this PR introduces the DeriveTarget() and the GetTarget() helper functions. These changes are useful for the implementation of Stratum V2.

• ● Bitcoin Core #31590 refactors the GetPrivKey() method to check pubkeys for both parity bit values when retrieving private keys for an x-only pubkey in a descriptor. Previously, if the stored pubkey didn’t have the correct parity bit, the private key couldn’t be retrieved and transactions couldn’t be signed.

• ● Eclair #2982 introduces the lock-utxos-during-funding configuration setting, allowing liquidity advertisement sellers to mitigate a type liquidity griefing attack that could prevent honest users from being able to use their UTXOs for extended periods. The default setting is true, meaning that UTXOs are locked during the funding process and are vulnerable to abuse. If set to false, UTXO locking is disabled and the attack can be completely prevented, but this may adversely affect honest peers. This PR also adds a configurable timeout mechanism that automatically aborts incoming channels if a peer becomes unresponsive.

• ● BDK #1614 adds support for using compact block filters as specified in BIP158 for downloading confirmed transactions. This is done by adding a BIP158 module to the bdk_bitcoind_rpc crate, along with a new FilterIter type that can be used to retrieve blocks that contains transactions relevant to a list of script pubkeys.

• ● BOLTs #1110 merges the specification for the peer storage protocol, which allows nodes to store encrypted blobs up to 64kB for peers who request them, and charge for this service. This has already been implemented in Core Lightning (see newsletter #238) and Eclair (see newsletter #335).

Want more?

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