This week’s newsletter provides an update on compact block reconstruction discussions and relays a call to activate BIP3. Also included are our regular sections summarizing top questions and answers from the Bitcoin Stack Exchange, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure projects.

News

  • ● Stats on compact block reconstructions updates: 0xB10C posted an update to Delving Bitcoin about his statistics around compact block reconstruction (see Newsletters #315 and #339). 0xB10C provided three updates around his compact block reconstruction analysis:

    • He began tracking the average size of requested transactions in kB in response to previous feedback by David Gumberg.

    • He updated one of his nodes to include the lower minrelayfee settings from Bitcoin Core #33106. After updating, he found block reconstruction rates improved significantly for that node. He also saw an improvement in the average size of requested transactions in kB.

    • He then switched his other nodes to run with the lowered minrelayfee which caused most of the nodes to have a higher reconstruction rate and to request less data from peers. He also mentions that, in hindsight, it would have been better not to have updated all the nodes and to have kept some on v29 which would have made it easier to compare between node versions and settings.

    Overall, lowering the minrelayfee has improved his nodes’ block reconstruction rates and lowered the amount of data requested from his peers.

  • ● Motion to activate BIP3: Murch posted to the Bitcoin-Dev mailing list a formal motion to activate BIP3 (see Newsletter #341). The goal of this improvement proposal is to provide new guidelines for preparing new BIPs, thereby replacing the current BIP2 process.

    According to the author, the proposal, which has been in “Proposed” status for more than 7 months, has no unaddressed objections and a growing list of contributors left an ACK on BIPs #1820. Thus, following the procedure expressed by BIP2 for activating Process BIPs, he granted 4 weeks, until 2025-12-02, to evaluate the proposal, ACK the PR, or state concerns and raise objections. After that date, BIP3 will replace BIP2 as the BIP process.

    Some minor objections have been raised in the thread, mainly regarding the use of AI/LLM tools in the BIPs submission process (see Newsletter #378), which the author is currently addressing. We invite Optech readers to familiarize themselves with the proposal and provide feedback.

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.

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.

  • ● LND v0.20.0-beta is a major release of this popular LN node implementation that introduces multiple bug fixes, a new noopAdd HTLC type, support for P2TR fallback addresses on BOLT11 invoices, and many RPC and lncli additions and improvements. See the release notes for more details.

  • ● Core Lightning v25.12rc1 is a release candidate of a new version of this major LN node implementation that adds BIP39 mnemonic seed phrases as the new backup method, improvements to xpay, the askrene-bias-node RPC command to favor or disfavor all channels of a peer, the networkevents subsystem to access information about peers, and experimental-lsps-client and experimental-lsps2-service options for experimental JIT channels support.

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 #33872 removes the previously deprecated -maxorphantx startup option (see Newsletter #364). Using it results in a startup failure.

  • ● Bitcoin Core #33629 completes the cluster mempool implementation by partitioning the mempool into clusters that are limited to 101 kvB and 64 transactions each by default. Each cluster is linearized into fee-ordered chunks (sub-cluster feerate-sorted groupings), so that higher-feerate chunks are selected first for inclusion in a block template, and the lowest-feerate chunks are evicted first when the mempool is full. This PR removes the CPFP carve out rule and the ancestor/descendant limits, and updates transaction relay to prioritize higher-feerate chunks. Finally, it updates the RBF rules by removing the restriction that replacements can’t introduce new unconfirmed inputs, changes the feerate rule to require that the overall cluster feerate diagram improves, and replaces the direct conflicts limit with a directly conflicting clusters limit.

  • ● Core Lightning #8677 improves the performance of large nodes considerably by limiting the number of RPC and plugin commands processed at once, reducing unnecessary database transactions for read-only commands, and restructuring database queries to handle millions of chainmoves/channelmoves events more efficiently. The PR also introduces a filters option to rpc_command or custommsg hooks, enabling plugins like xpay, commando, and chanbackup to register for specific invocations only.

  • ● Core Lightning #8546 adds a withhold option (default false) to fundchannel_complete that delays the broadcast of a channel funding transaction until sendpsbt is called or the channel is closed. This allows LSPs to postpone opening a channel until a user provides sufficient funds to cover the network fees. This is necessary to enable the client-trusts-lsp mode in JIT channels.

  • ● Core Lightning #8682 updates the way blinded paths are built by requiring peers to have the option_onion_messages feature enabled, in addition to the option_route_blinding, even if the specification doesn’t require the former. This resolves an issue in which an LND node without the feature enabled would fail to forward a BOLT12 payment.

  • ● LDK #4197 caches the two most recently revoked commitment points in ChannelManager to respond to a peer’s channel_reestablish message after a reconnection. This avoids fetching the points from a potentially-remote signer and pausing the state machine when the counterparty is at most one commitment height prior. If a peer presents a different state, the signer validates the commitment point, and LDK either crashes if the state is valid or force-closes the channel if it’s invalid. For previous LDK updates to channel_reestablish, see Newsletters #335, #371, and #374.

  • ● LDK #4234 adds the funding redeem script to ChannelDetails and the ChannelPending event, enabling LDK’s on-chain wallet to reconstruct the TxOut of a channel and accurately estimate the feerate when building a splice-in transaction.

  • ● LDK #4148 adds support for testnet4 by updating the rust-bitcoin dependency to version 0.32.4 (See Newsletter #324) and requiring that as the minimum supported version for the lightning and lightning-invoice crates.

  • ● BDK #2027 adds a list_ordered_canonical_txs method to TxGraph, which returns canonical transactions in topological order, where parent transactions always appear before their children. The existing list_canonical_txs and try_list_canonical_txs methods are deprecated in favor of the new ordered variant. See Newsletters #335, #346 and #374 for previous canonicalization work on BDK.

Want more?

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