This week’s newsletter announces a planned security disclosure and includes our regular sections describing new releases, release candidates, and notable changes to popular Bitcoin infrastructure software.

News

  • ● Impending btcd security disclosure: Antoine Poinsot posted to Delving Bitcoin to announce the planned disclosure on October 10th of a consensus bug affecting the btcd full node. Using data from a rough survey of active full nodes, Poinsot surmises that there about 36 btcd nodes that are vulnerable (although 20 of those nodes are also vulnerable to an already disclosed consensus vulnerability, see Newsletter #286). In a reply, btcd maintainer Olaoluwa Osuntokun confirmed the existence of the vulnerability and that it was fixed in btcd version 0.24.2. Anyone running an older version of btcd is encouraged to upgrade to the latest release, which was already announced as security critical.

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 28.0 is the latest major release of the predominant full node implementation. It’s the first release to include support for testnet4, opportunistic one-parent-one-child (1p1c) package relay, default relay of opt-in topologically restricted until confirmation (TRUC) transactions, default relay of pay-to-anchor transactions, limited package RBF relay, and default full-RBF. Default parameters for assumeUTXO have been added, allowing the loadtxoutset RPC to be used with a UTXO set downloaded outside of the Bitcoin network (e.g. via a torrent). The release also includes many other improvements and bug fixes, as described in its release notes.

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

  • ● Bitcoin Core #30043 introduces a built-in implementation of the Port Control Protocol (PCP) to support IPv6 pinholing, allowing nodes to become reachable without manual configuration on the router. This update replaces the existing libnatpmp dependency for IPv4 port mapping with PCP, while also implementing a fallback mechanism to the NAT Port Mapping Protocol (NAT-PMP). Although the PCP / NAT-PMP functionality is disabled by default, this may change in future releases. See Newsletter #131.

  • ● Bitcoin Core #30510 adds an inter-process communication (IPC) wrapper to the Mining interface (See Newsletter #310) to allow a separate Stratum v2 mining process to create, manage, and submit block templates by connecting to and controlling the bitcoin-node process (see Newsletter #320). Bitcoin Core #30409 extends the Mining interface with a new waitTipChanged() method that detects when a new block arrives and then pushes new block templates to connected clients. The waitfornewblock, waitforblock and waitforblockheight RPC methods have been refactored to use it.

  • ● Core Lightning #7644 adds a nodeid command to the hsmtool utility which returns the node identifier for a given hsm_secret backup file, to match the backup to its specific node and to avoid confusion with other nodes.

  • ● Eclair #2848 implements extensible liquidity advertisements as specified in the proposed BOLTs #1153, which allows sellers to advertise rates at which they are willing to sell liquidity to buyers in their node_announcement message, and then buyers can connect and request liquidity. This can be used when creating a dual-funded channel, or when adding additional liquidity to an existing channel via splicing.

  • ● Eclair #2860 adds an optional recommended_feerates message for nodes to inform their peers of acceptable fee rates they wish to use for funding channel transactions. If a node rejects a peer’s funding requests, the peer will understand that this was due to the fee rates.

  • ● Eclair #2861 implements on-the-fly funding as specified in BLIPs #36, allowing clients without sufficient inbound liquidity to request additional liquidity from a peer via the liquidity advertisements protocol (see PR above) in order to receive a payment. The liquidity seller covers the on-chain transaction fee for the dual-funded channel or splicing transaction, but is later paid by the buyer when the payment is routed. If the amount isn’t sufficient enough to cover the on-chain fee required for the transaction to confirm, the seller can double-spend it to use their liquidity elsewhere.

  • ● Eclair #2875 implements funding fee credits as specified in BLIPs #41, allowing on-the-fly funding (see PR above) clients to accept payments that are too small to cover the on-chain fees for a channel. Once sufficient fee credits have been accumulated, an on-chain transaction such as a channel funding or splice is created using the fee credits. Clients rely on liquidity providers to honour the fee credits in future transactions.

  • ● LDK #3303 adds a new PaymentId for inbound payments to improve idempotent event handling. This allows users to easily check if an event has already been handled when replaying events during node restarts. The risk of duplicate processing that was possible when relying on the PaymentHash is eliminated. The PaymentId is a hash-based message authentication code (HMAC) of the HTLC channel identifier and HTLC identifier pairs included in the payment.

  • ● BDK #1616 signals opt-in RBF by default in the TxBuilder class. The caller can disable the signal by changing the sequence number.

  • ● BIPs #1600 makes several changes to the BIP85 specification, including specifying that drng_reader.read (responsible for reading random numbers) is a first-class function rather than an evaluation. This update also clarifies endianness handling, adds support for testnet, includes a new reference implementation in Python, clarifies that an HD wallet seed wallet import format (WIF) uses the most significant bits, adds the Portuguese language code, and corrects test vectors. Finally, a new champion for the BIP specification has been designated.

  • ● BOLTs #798 merges the offers protocol specification which introduces BOLT12, and also brings several updates to BOLT1 and BOLT4.

Want more?

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