This week’s newsletter describes a vulnerability affecting old versions of Bitcoin Core and includes our regular sections summarizing a Bitcoin Core PR Review Club meeting, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

• ● Disclosure of a vulnerability affecting Bitcoin Core versions before 25.1: Antoine Poinsot announced to the Bitcoin-Dev mailing list the final vulnerability disclosure predating Bitcoin Core’s new disclosure policy (see Newsletter #306). The detailed vulnerability report notes that Bitcoin Core versions 25.0 and earlier were susceptible to an inappropriate P2P protocol response that would delay a node from re-requesting a block for up to 10 minutes. The solution was to allow blocks to “be requested concurrently from up to 3 high-bandwidth compact block peers, one of which is required to be an outbound connection.” Versions 25.1 and later include the fix.

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.

Ephemeral Dust is a PR by instagibbs that makes transactions with ephemeral dust standard, improving the usability of both keyed as well as unkeyed (P2A) anchors. This is relevant for several off-chain contracting schemes including those used by Lightning Network, Ark, Timeout Trees, and other constructs with large pre-signed trees or other large-N party smart contracts.

With the ephemeral dust policy changes, zero-fee transactions with a dust output are allowed in the mempool if a valid fee-paying child transaction that immediately spends the dust output is known to the node.

• Is dust restricted by consensus? Policy? Both?

  Dust outputs are only restricted by policy rules, they are not affected by consensus. ➚

• How can dust be problematic?

  Dust (or uneconomical) outputs are worth less than the fees required to spend them. Since they can be spent, they cannot be pruned from the UTXO set. Because spending them is uneconomical, they often remain unspent, increasing the UTXO set size. A larger UTXO set raises the resource requirements for nodes. However, UTXOs may still be spent due to external incentives beyond their satoshi value, such as in the case of anchor outputs. ➚

• Why is the term ephemeral significant? What are the proposed rules specific to ephemeral dust?

  The term ‘ephemeral’ indicates that the dust output is intended to be spent quickly. Ephemeral dust rules require the parent transaction to be 0-fee and to have exactly one child transaction that spends the dust output. ➚

• Why is it important to impose a fee restriction?

  A key goal is to prevent dust outputs from remaining unspent when confirmed. By requiring the parent transaction to be 0-fee, miners lack the incentive to mine the parent without the child. Since ephemeral dust is a policy rule, not a consensus rule, economic incentives play a crucial role. ➚

• How are 1P1C relay and TRUC transactions relevant to ephemeral dust?

  As an ephemeral dust transaction must be 0-fee, it cannot be relayed alone, making mechanisms like 1-parent-1-child (1P1C) essential. TRUC (v3) transactions are limited to a single unconfirmed parent, aligning with the ephemeral dust requirement. TRUC is currently the only way to allow transactions with a feerate below the minrelaytxfee. ➚

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 Core 27.2 is a maintenance update for the previous release series containing bug fixes. Any users who will not soon upgrade to the latest version, 28.0, should consider updating at least to this new maintenance release.

• ● Libsecp256k1 0.6.0 is a release of this library of Bitcoin-related cryptographic operations. “This release adds a MuSig2 module, adds a significantly more robust method to clear secrets from the stack, and removes the unused secp256k1_scratch_space functions.”

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.

• ● LDK #3360 adds rebroadcasting of channel_announcement messages every six blocks for one week after the public channel is confirmed. This removes the dependency on peers for rebroadcast and ensures that channels are always visible to the network.

• ● LDK #3207 introduces support for including invoice requests in the async payments’ onion message when paying static BOLT12 invoices as an always online sender. This was previously missing from the PR covered in Newsletter #321. The inclusion of invoice requests in payment onions also extends to retries, see Newsletter #321.

Want more?

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