This week’s newsletter includes our regular sections summarizing updates to services and client software, announcing new releases 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.

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.

  • ● LND v0.19.2-beta is the release of a maintenance version of this popular LN node. It “contains important bug fixes and performance improvements.”

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 #32604 rate-limits unconditional logging to disk such as for LogPrintf, LogInfo, LogWarning and LogError to mitigate disk-filling attacks by giving each source location a 1 MB per hour quota. All log lines are prefixed with an asterisk (*) when any source location is suppressed. Console output, logs with an explicit category argument, and UpdateTip Initial Block Download (IBD) messages are exempt from rate limits. When the quota resets, Core prints the number of bytes that were dropped.

  • ● Bitcoin Core #32618 removes the include_watchonly option and its variants, as well as the iswatchonly field from all wallet RPCs because descriptor wallets don’t support mixing watch-only and spendable descriptors. Previously, users could import a watch-only address or script into a legacy spending wallet. However, legacy wallets have now been removed.

  • ● Bitcoin Core #31553 adds block reorg handling to the cluster mempool project by introducing the TxGraph::Trim() function. When a reorg reintroduces previously confirmed transactions to the mempool and the resulting combined cluster exceeds cluster count or weight policy limits, Trim() builds a feerate-ordered, dependency‑respecting, rudimentary linearization. If adding a transaction would breach a limit, that transaction and all its descendants are dropped.

  • ● Core Lightning #7725 adds a lightweight JavaScript log viewer that loads CLN log files in a browser and allows users to filter messages by daemon, type, channel, or regex. This tool adds minimal repository maintenance overhead while improving the debugging experience for developers and node runners.

  • ● Eclair #2716 implements a local peer-reputation system for HTLC endorsement that tracks the routing fees earned by each incoming peer versus the fees that should have been earned based on the liquidity and HTLC slots used. Successful payments result in a perfect score, failed payments lower it, and HTLCs that remain pending past the configured threshold are heavily penalized. When forwarding, the node includes its current peer score in the update_add_htlc endorsement TLV (see Newsletter #315). Operators can adjust the reputation decay (half-life), the stuck payment threshold (max-relay-duration), the penalty weight for stuck HTLCs (pending-multiplier), or simply disable the reputation system entirely in the configuration. This PR primarily collects data to improve channel jamming attack research and does not yet implement penalties.

  • ● LDK #3628 implements the server-side logic for async payments, allowing an LSP node to provide BOLT12 static invoices on behalf of an often-offline recipient. The LSP node can accept ServeStaticInvoice messages from the recipient, store the provided static invoices, and respond to payer invoice requests by searching for and returning the cached invoice via blinded paths.

  • ● LDK #3890 changes the way it scores routes in its pathfinding algorithm by considering total cost divided by channel amount limit (cost per sat of usable capacity) instead of considering only the raw total cost. This biases the selection toward higher-capacity routes and reduces excessive MPP sharding, resulting in a higher payment success rate. Although the change overly penalizes small channels, this tradeoff is preferable to previous excessive sharding.

  • ● LND #10001 enables the quiescence protocol in production (see Newsletter #332) and adds a new configuration value --htlcswitch.quiescencetimeout, which specifies the maximum duration for which a channel can be quiescent. The value ensures that dependent protocols, such as dynamic commitments, finish within the timeout period. The default value is 60 seconds, and the minimum value is 30 seconds.

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 July 22. The discussion is also recorded and will be available from our podcasts page.