This week’s newsletter announces three vulnerabilities affecting old versions of the Bitcoin Core full node, announces a separate vulnerability affecting old versions of the btcd full node, and links to a contributed Optech guide describing how to use multiple new P2P network features added in Bitcoin Core 28.0. Also included are our regular sections summarizing a Bitcoin Core PR Review Club meeting, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

  • ● Disclosure of vulnerabilities affecting Bitcoin Core versions before 25.0: Niklas Gögge posted to the Bitcoin-Dev mailing list links to the announcements of three vulnerabilities affecting versions of Bitcoin Core that have been past their end of life since at least April 2024.

    • ● CVE-2024-35202 remote crash vulnerability: an attacker can send a compact block message deliberately designed to fail block reconstruction. Failed reconstructions sometimes happen even in honest use of the protocol, in which case the receiving node requests the full block.

      However, instead of replying with a full block, the attacker could send a second compact block message for the same block header. Before Bitcoin Core 25.0, this would cause the node to crash, as the code was designed to prevent the compact block reconstruction code from running more than once on the same compact block session.

      This easily exploitable vulnerability could have been used to crash any Bitcoin Core node, which could be used as part of other attacks to steal money from users. For example, a crashed Bitcoin Core node would be unable to alert a connected LN node that a channel counterparty was attempting to steal funds.

      The vulnerability was discovered, responsibly disclosed, and fixed by Niklas Gögge, with the fix released in Bitcoin Core 25.0.

    • ● DoS from large inventory sets: for each of its peers, a Bitcoin Core node keeps a list of transactions to send to that peer. The transactions in the list are sorted based on their feerates and their relationships to each other in an attempt to ensure that the best transactions relay fast and to make it harder to probe the relay network topology.

      However, during a surge of network activity in May 2023, several users began noticing their nodes using an excessive amount of CPU. Developer 0xB10C determined that the CPU was being consumed by the sorting function. Developer Anthony Towns investigated further and fixed the problem by ensuring transactions left the queue at a variable rate that increases during periods of high demand. The fix was released in Bitcoin Core 25.0.

    • ● Slow block propagation attack: before Bitcoin Core 25.0, an invalid block from an attacker could prevent Bitcoin Core from continuing to process a valid block with the same header from honest peers. This especially affected compact block reconstruction when additional transactions needed to be requested: a node would stop waiting for the transactions if it received an invalid block from a different peer. Even if the transactions were later received, the node would ignore them.

      After Bitcoin Core had rejected the invalid block (and possibly disconnected the peer that sent it), it would restart attempting to request the block from other peers. Multiple attacking peers could keep it in this cycle for an extended period of time. Faulty peers that may not have been designed as attackers could trigger the same behavior accidentally.

      The problem was discovered after several developers, including William Casarin and ghost43, reported problems with their nodes. Several other developers investigated, with Suhas Daftuar isolating this vulnerability. Daftuar also fixed it by preventing any peer from affecting the download state of other peers, except in the case where a block has passed validation and been stored to disk. The fix was included in Bitcoin Core 25.0.

  • ● CVE-2024-38365 btcd consensus failure: as announced in last week’s newsletter, Antoine Poinsot and Niklas Gögge disclosed a consensus failure vulnerability affecting the btcd full node. In legacy Bitcoin transactions, signatures are stored in the signature script field. However, the signatures also commit to the signature script field. It’s not possible for a signature to commit to itself, so signers commit to all of the data in the signature script field except for the signature. Verifiers must correspondingly remove the signature before checking the accuracy of the signature commitment.

    Bitcoin Core’s function for removing signatures, FindAndDelete, only removes exact matches of the signature from the signature script. The function implemented by btcd, removeOpcodeByData removed any data in the signature script which contained the signature. This could be used to cause btcd to remove more data from the signature script than Bitcoin Core would remove before it respectively verified the commitment, leading one program to consider the commitment valid and the other invalid. Any transaction containing an invalid commitment is invalid and any block containing an invalid transaction is invalid, allowing consensus between Bitcoin Core and btcd to be broken. Nodes that fall out of consensus can be tricked into accepting invalid transactions and may not see the latest transactions the rest of the network considers to be confirmed, either of which can result in a significant loss of money.

    Poinsot’s and Gögge’s responsible disclosure allowed btcd maintainers to quietly fix the vulnerability and release version 0.24.2 with the fix about three months ago.

  • ● Guide for wallets employing Bitcoin Core 28.0: As mentioned in last week’s newsletter, the newly released version 28.0 of Bitcoin Core contains several new features for the P2P network, including one parent one child (1P1C) package relay, topologically restricted until confirmation (TRUC) transaction relay, package RBF and sibling eviction, and a standard pay-to-anchor (P2A) output script type. These new features can significantly improve security and reliability for several common use cases.

    Gregory Sanders has written a guide for Optech aimed at developers of wallets and other software that uses Bitcoin Core to create or broadcast transactions. The guide walks through the use of several of the features and describes how the features can be useful for multiple protocols, including simple payments and RBF fee bumping, LN commitments and HTLCs, Ark, and LN splicing.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Add getorphantxs is a PR by tdb3 that adds a new experimental RPC method named getorphantxs. Since it is intended primarily for developers, it is hidden. This new method provides the caller with a list of all current orphan transactions, which can be helpful when checking orphan behavior/scenarios (e.g. in functional tests like p2p_orphan_handling.py) or for providing additional data for statistics/visualization.

  • What is an orphan transaction? At what point do transactions enter the orphanage?

    An orphan transaction is one whose inputs refer to unknown or missing parent transactions. Transactions enter the orphanage when they are received from a peer but they fail validation with TX_MISSING_INPUTS in ProcessMessage. ➚

  • What command can you run to get a list of available RPCs?

    bitcoin-cli help provides a list of available RPCs. Note: since getorphantxs is marked as hidden as a developer-only RPC, it will not show up in this list. ➚

  • If an RPC has a non-string argument, does anything special need to be done to handle it?

    Non-string RPC arguments must be added to the vRPCConvertParams list in src/rpc/client.cpp to ensure proper type conversion. ➚

  • What is the maximum size of the result from this RPC? Is there a limit to how many orphans are retained? Is there a limit to how long orphans can stay in the orphanage?

    The maximum number of orphans is 100 (DEFAULT_MAX_ORPHAN_TRANSACTIONS). At verbosity=0, each txid is a 32-byte binary value, but when hex-encoded for the JSON-RPC result, it becomes a 64-character string (since each byte is represented by two hex characters). This means the maximum result size is approximately 6.4 kB (100 txids * 64 bytes).

    At verbosity=2, the hex-encoded transaction is by far the largest field in the result, so for simplicity we’ll ignore the other fields in this calculation. The maximum serialized size of a transaction can be up to 400 kB (in the extreme, impossible case that it consists only of witness data), or 800 kB when hex-encoded. Therefore, the maximum result size is roughly 80 MB (100 transactions * 800 kB).

    Orphans are time-limited and are removed after 20 minutes, as defined by ORPHAN_TX_EXPIRE_TIME. ➚

  • Since when has there been a maximum orphanage size?

    The MAX_ORPHAN_TRANSACTIONS variable was introduced back in 2012 already, in commit 142e604. ➚

  • Using the getorphantxs RPC, would we be able to tell how long a transaction has been in the orphanage? If yes, how would you do it?

    Yes, by using verbosity=1, you can get the expiration timestamp of each orphan transaction. Subtracting the ORPHAN_TX_EXPIRE_TIME (i.e. 20 minutes) gives the insertion time. ➚

  • Using the getorphantxs RPC, would we be able to tell what the inputs of an orphan transaction are? If yes, how would you do it?

    Yes, with verbosity=2, the RPC returns the raw transaction hex, which can be decoded using decoderawtransaction to reveal its inputs. ➚

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.

  • ● Bitcoin Inquisition 28.0 is the latest release of this signet full node designed for experimenting with proposed soft forks and other major protocol changes. The updated version is based on the recently released Bitcoin Core 28.0.

  • ● BDK 1.0.0-beta.5 is a release candidate (RC) of this library for building wallets and other Bitcoin-enabled applications. This latest RC “enables RBF by default, updates the bdk_esplora client to retry server requests that fail due to rate limiting. The bdk_electrum crate now also offers a use-openssl feature.”

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.

  • ● Core Lightning #7494 introduces a 2-hour lifespan for channel_hints, allowing pathfinding information learned from a payment to be reused in future attempts in order to skip unnecessary attempts. Channels that were considered unavailable will be gradually restored and become fully available after 2 hours, to ensure that outdated information doesn’t cause routes to be skipped that may have since recovered.

  • ● Core Lightning #7539 adds a getemergencyrecoverdata RPC command to fetch and return data from the emergency.recover file. This will allow developers using the API to add wallet backup functionality to their applications.

  • ● LDK #3179 introduces new DNSSECQuery and DNSSECProof onion messages, and a DNSResolverMessageHandler to handle these messages as the core functionality to implement BLIP32. This PR also adds an OMNameResolver that verifies the DNSSEC proofs and turns them into offers. See Newsletter #306.

  • ● LND #8960 implements custom channel functionality by adding taproot overlay as a new experimental channel type, which is identical to a simple taproot channel but commits additional metadata in the tapscript leaves for channel scripts. The main channel state machine and database are updated to process and store custom tapscript leaves. A config option TaprootOverlayChans must be set to enable support for taproot overlay channels. The custom channels initiative enhances LND’s support for taproot assets. See Newsletter #322.

  • ● Libsecp256k1 #1479 adds a MuSig2 module for a BIP340-compatible multisig scheme as specified in BIP327. This module is almost identical to the one implemented in secp256k1-zkp, but has some minor changes, such as removing support for adaptor signatures to make it non-experimental.

  • ● Rust Bitcoin #2945 introduces support for testnet4 by adding the TestNetVersion enum, refactoring the code, and including the necessary parameters and blockchain constants for testnet4.

  • ● BIPs #1674 reverts the changes to the BIP85 specification described in Newsletter #323. The changes broke compatibility with deployed versions of the protocol. Discussion on the PR supported creating a new BIP for the major changes.