This week’s newsletter summarizes a post about having full nodes ignore transactions that are relayed without being requested first. Also included are our regular sections with popular questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

News

• ● Ignoring unsolicited transactions: Antoine Riard posted to Bitcoin-Dev two draft BIPs that would allow a node to signal that it will no longer accept tx messages that it had not requested using an inv message, called unsolicited transactions. Riard previously proposed the general idea in 2021 (see Newsletter #136). The first proposed BIP adds a mechanism that allows nodes to signal their transaction relay capabilities and preferences; the second proposed BIP uses that signaling mechanism to indicate that the node will ignore unsolicited transactions.

  There are several small advantages to the proposal, as discussed in a Bitcoin Core pull request, but it conflicts with the design of some older lightweight clients and could prevent users of that software from being able to broadcast their transactions, so a careful deployment might be required. Although Riard had opened the aforementioned pull request, he later closed it after indicating that he planned to work on his own full node implementation based on libbitcoinkernel. He also indicated the proposal may help address some attacks he recently disclosed (see Newsletter #332).

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.

• ● What’s the rationale for how the loadtxsoutset RPC is set up? Pieter Wuille explains why assumeUTXO’s value for representing the UTXO set is hardcoded at a particular block height, ways of distributing assumeUTXO snapshots in the future, and the benefits of assumeUTXO compared with just copying Bitcoin Core’s internal data stores.

• ● Are there classes of pinning attacks that RBF rule #3 makes impossible? Murch points out that RBF rule #3 is not intended to prevent pinning attacks and touches on Bitcoin Core’s replacement policy.

• ● Unexpected locktime values User polespinasa lists the different reasons why Bitcoin Core sets specific nLockTime values: to block_height to avoid fee sniping, a random value less than the block height 10% of the time for privacy, or 0 if the blockchain is not current.

• ● Why is it necessary to reveal a bit in a script path spend and check that it matches the parity of the Y coordinate of Q? Pieter Wuille elaborates on BIP341’s rationale to keep the Y coordinate parity check during taproot script path spending to allow for the potential future addition of batch validation functionality.

• ● Why does Bitcoin Core use checkpoints and not the assumevalid block? Pieter Wuille details a history of checkpoints in Bitcoin Core and what purpose they served, and points to an open PR and discussion of removing checkpoints.

• ● How does Bitcoin Core handle long reorgs? Pieter Wuille outlines how Bitcoin Core handles blockchain reorgs, commenting that one difference in larger reorgs is that “re-adding transactions back to the mempool is not performed”.

• ● What is the definition of discard feerate? Murch defines discard feerate as the maximum feerate for discarding change and summarizes the code to calculate the discard feerate as “the 1000-block target feerate cropped to 3–10 ṩ/vB if it falls outside of that range”.

• ● Policy to miniscript compiler Brunoerg notes that the Liana wallet uses the policy language and points to both the sipa/miniscript and rust-miniscript libraries as examples of policy compilers.

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.02rc3 is a release candidate for the next major version of this popular LN node.

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.

• ● Core Lightning #8116 changes the handling of interrupted channel closing negotiations to retry the process even if it’s not needed. This fixes an issue where a node missing the CLOSING_SIGNED message from its peer gets an error when reconnecting and broadcasts a unilateral close transaction. Meanwhile, the peer, already in the CLOSINGD_COMPLETE state, has broadcast the mutual close transaction, potentially leading to a race between the two transactions. This fix allows renegotiation to continue until the mutual close transaction is confirmed.

• ● Core Lightning #8095 adds a transient flag to the setconfig command (see Newsletter #257), introducing dynamic configuration variables that are applied temporarily without modifying the configuration file. These changes are reverted upon restart.

• ● Core Lightning #7772 adds a commitment_revocation hook to the chanbackup plugin that updates the emergency.recover file (see Newsletter #324) whenever a new revocation secret is received. This enables users to broadcast a penalty transaction when sweeping funds using emergency.recover if the peer has published an outdated revoked state. This PR extends the static channel backup SCB format and updates the chanbackup plugin to serialize both the new and legacy formats.

• ● Core Lightning #8094 introduces a runtime-configurable xpay-slow-mode variable to the xpay plugin (see Newsletter #330), which delays the return of success or failure until all parts of a multipath payments (MPP) are resolved. Without this setting, a failure status could be returned even if some HTLCs are still pending. If a user retries and successfully pays the invoice from another node, an overpayment could occur if the pending HTLC is also settled.

• ● Eclair #2993 enables the recipient to pay for fees associated with the blinded portion of a payment path, while the sender covers fees for the non-blinded portion. Previously, the sender paid all fees, which could allow them to infer and potentially unblind the path.

• ● LND #9491 adds support for cooperative channel closures when there are active HTLCs using the lncli closechannel command. When initiated, LND will halt the channel to prevent the creation of new HTLCs and wait for all existing HTLCs to be resolved before starting the negotiation process. Users must set the no_wait parameter to enable this behavior; otherwise, an error message will prompt them to specify it. This PR also ensures that the max_fee_rate setting is enforced for both parties when a cooperative channel closure is initiated; previously, it was only applied to the remote party.

Want more?

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