This week’s newsletter summarizes an idea to use cluster mempool to detect block template feerate increases and shares an update on channel jamming mitigation simulation results. Also included are our regular sections describing recent changes to services and client software, announcing new releases and release candidates, and summarizing notable changes to popular Bitcoin infrastructure software.

News

  • ● Detecting block template feerate increases using cluster mempool: Abubakar Sadiq Ismail recently posted to Delving Bitcoin about the possibility of tracking the potential fee increase from each mempool update to provide a new block template to miners only when the fee rate improvement justifies it. This approach would reduce the number of redundant block template builds, which can delay transaction processing and relay to peers. The proposal leverages cluster mempool to assess whether a potential fee rate improvement is available without a rebuild of the block template.

    When a new transaction enters the mempool, it connects to zero or more existing clusters triggering re-linearization (see Newsletter #312 for more information about linearization) of affected clusters to produce old (pre-update) and new (post-update) feerate diagrams. The old diagram identifies potential chunks for eviction from the block template, while the new diagram identifies high-feerate chunks for potential addition. The system then follows a 4-step process to simulate the impact:

    1. Eviction: Remove matching chunks from a template copy, updating modified fees and sizes.

    2. Naive Merge: Greedily add candidate chunks while respecting block weight limits to estimate potential fee gains (ΔF).

    3. Iterative Merge: If the naive estimate is inconclusive, use a more detailed simulation to refine ΔF.

    4. Decision: Compare ΔF to a threshold; if it exceeds the threshold, rebuild the block template and send it to miners. Otherwise, skip to avoid unnecessary computation.

    The current proposal is still in the discussion phase, with no prototype available.

  • ● Channel jamming mitigation simulation results and updates: Carla Kirk-Cohen, in collaboration with Clara Shikhelman and elnosh, posted to Delving Bitcoin about their simulation results and updates with the reputation algorithm for their channel jamming mitigation proposal. Some notable changes are that reputation is tracked for outgoing channels, and resources are limited on incoming channels. Bitcoin Optech has previously covered lightning channel jamming attacks and an earlier Delving Bitcoin post from Carla. Read those posts to gain a baseline understanding of lightning channel jamming.

    In this latest update, they used their simulator to run both the resource and sink attacks. They found that with the new updates, protection against resource attacks remains intact, and with sink attacks, attacking nodes will be quickly cut off when they misbehave. It is noted that if an attacker builds a reputation and then targets a chain of nodes, only the last node is compensated. But there is a significant cost to an attacker to target multiple nodes.

    The write-up concludes that channel jamming attack mitigation has reached a point where it is good enough and encourages readers to try their simulator to test out attacks.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

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 25.09.1 is a maintenance release for the current major version of this popular LN node that includes several bug fixes.

  • ● Bitcoin Core 28.3 is a maintenance release for the previous release series of the predominant full node implementation. It contains multiple bug fixes, and also includes the new defaults for blockmintxfee, incrementalrelayfee, and minrelaytxfee.

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 #33157 optimizes the memory usage in cluster mempool by introducing a SingletonClusterImpl type for single-transaction clusters and by compacting several TxGraph internals. This PR also adds a GetMainMemoryUsage() function to estimate TxGraph’s memory usage.

  • ● Bitcoin Core #29675 introduces support for receiving and spending taproot outputs controlled by MuSig2 aggregate keys on wallets with imported musig(0) descriptors. See Newsletter #366 for the earlier enabling work.

  • ● Bitcoin Core #33517 and Bitcoin Core #33518 reduce the CPU consumption of multiprocess logging by adding log levels and categories, which avoids serializing discarded inter-process communication (IPC) log messages. The author found that before this PR, logging accounted for 50% of his Stratum v2 client application’s CPU time and 10% of the Bitcoin node’s processes. It has now dropped to near zero percent. See Newsletters #323 and #369 for additional context.

  • ● Eclair #2792 adds a new MPP splitting strategy, max-expected-amount, which allocates parts across routes by factoring in each route’s capacity and success probability. A new mpp.splitting-strategy configuration option is added with three options: max-expected-amount, full-capacity, which considers only a route’s capacity, and randomize (default), which randomizes the splitting. The latter two are already accessible through the boolean config randomize-route-selection. This PR adds enforcement of HTLC maximum limits on remote channels.

  • ● LDK #4122 enables queuing a splice request while the peer is offline, starting negotiation upon reconnection. For zero-conf splices, LDK now sends a splice_locked message to the peer immediately after tx_signatures are exchanged. LDK will also now queue a splice during a concurrent splice and attempt it as soon as the other one locks.

  • ● LND #9868 defines an OnionMessage type and adds two new RPC endpoints: SendOnionMessage, which sends an onion message to a specific peer, and SubscribeOnionMessages, which subscribes to a stream of incoming onion messages. These are the first steps required to support BOLT12 offers.

  • ● LND #10273 fixes an issue where LND would crash when the legacy sweeper, utxonursery, attempted to sweep an HTLC with a locktime (height hint) of 0. Now, LND successfully sweeps those HTLCs by deriving the height hint from the channel’s close height.

Want more?

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