This week’s newsletter includes our regular sections summarizing discussion about changing Bitcoin’s consensus rules, announcing new release and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

No significant news this week was found in any of our sources.

Changing consensus

A monthly section summarizing proposals and discussion about changing Bitcoin’s consensus rules.

• ● Details about the design of Simplicity: Russell O’Connor made three posts (1, 2, 3) so far to Delving Bitcoin about “the philosophy and design of the Simplicity language.” The posts examine “the three major forms of composition for transforming basic operations into complex operations,” “Simplicity’s type system, combinators, and basic expressions,” and “how to build logical operations starting from bits […up to…] cryptographic operations, such as SHA-256 and Schnorr signature validation, using just our computational Simplicity combinators.”

  The most recent post indicates further entries in the series are expected.

• ● Draft BIP for adding elliptic curve operations to tapscript: Olaoluwa Osuntokun posted to the Bitcoin-Dev mailing list a link to a draft BIP for adding several opcodes to tapscript that will allow elliptic curve operations to be performed on the script evaluation stack. The opcodes are intended to be used in combination with introspection opcodes to create or enhance covenant protocols in addition to other advances.

  Jeremy Rubin replied to suggest additional opcodes to enable additional features, as well as other opcodes that would make it more convenient to use some features provided by the base proposal.

• ● Draft BIP for OP_TWEAKADD: Jeremy Rubin posted to the Bitcoin-Dev mailing list a link a draft BIP to add OP_TWEAKADD to tapscript. He separately posted notable examples of scripts enabled by the addition of the opcode, which include a script to reveal a taproot tweak, proof of order of signing a transaction (e.g., Alice must have signed before Bob), and signing delegation.

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 v25.09 is a release of a new major version of this popular LN node implementation. It adds support to the xpay command for paying BIP353 addresses and simple offers, offers improved bookkeeper support, provides better plugin dependency management, and includes other new features and bug fixes.

• ● Bitcoin Core 29.1rc2 is a release candidate for a maintenance version of the predominant full node software.

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 #3726 adds support for dummy hops on blinded paths, enabling receivers to add arbitrary hops that serve no routing purpose but act as decoys. A randomized number of dummy hops is added each time, but is capped at 10 as defined by MAX_DUMMY_HOPS_COUNT. Adding additional hops makes it significantly harder to determine the distance to or the identity of the receiver node.

• ● LDK #4019 integrates splicing with the quiescence protocol by requiring a quiescent channel state before initializing a splicing transaction, as mandated by the specification.

• ● LND #9455 adds support for associating a valid DNS domain name with a Lightning node’s IP address and public key in its announcement message, as allowed by the specification and supported by other implementations such as Eclair and Core Lightning (see Newsletters #212, #214, and #178).

• ● LND #10103 introduces a new gossip.peer-msg-rate-bytes option (default 51200), which limits the outgoing bandwidth used by each peer for outbound gossip messages. This value limits the average bandwidth speed in bytes per second, and if a peer exceeds it, LND will start queuing and delaying messages sent to that peer. This new option prevents a single peer from consuming all the global bandwidth defined by gossip.msg-rate-bytes introduced in LND #10096. See Newsletters #366 and #369 for related LND work on gossip requests resource management.

• ● HWI #795 adds support for the BitBox02 Nova by updating the bitbox02 library to version 7.0.0. It also makes several CI updates.