en | ja | es | cs | hi | zh | de | fr

Bitcoin Optech Newsletter #248

Apr 26, 2023

This week’s newsletter relays a request for feedback about a proposal to remove support for the BIP35 mempool P2P protocol message from Bitcoin Core and includes 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

● Proposed removal of BIP35 mempool P2P message: Will Clark posted to the Bitcoin-Dev mailing list about a PR he’s opened to remove support for the P2P mempool message originally specified in BIP35. In its original implementation, a node receiving a mempool message would respond to the requesting peer with an inv message containing the txids of all the transactions in its mempool. The requesting peer could then send a regular getdata message containing the txids of any transactions it wanted to receive. The BIP describes three motivations for this message: network diagnostics, allowing lightweight clients to poll for unconfirmed transactions, and allowing miners who recently restarted to learn about unconfirmed transactions (at the time, Bitcoin Core did not save its mempool to persistent storage on shutdown).

However, various privacy-reducing techniques were later developed that made it easier to determine which node first broadcast a transaction by abusing either the mempool message or the ability to use getdata to request any mempool transaction. To improve transaction origin privacy, Bitcoin Core later removed the ability to request unannounced transactions from other nodes and restricted the mempool message to being used with transaction bloom filters (as specified in BIP37) for lightweight clients. Even later, Bitcoin Core disabled bloom filter support by default (see Newsletter #56), only allowing it to be used with peers configured with the -whitelist option (see Newsletter #60); this effectively makes BIP35 mempool also disabled by default.

Clark’s Bitcoin Core PR received support from within the project, although some supporters think BIP37 bloom filters should be removed first. On the mailing list, the only reply as of this writing noted that lightweight clients that connect to their own trusted node can currently use BIP35 and BIP37 to learn about unconfirmed transactions in a much more bandwidth-efficient manner than any other method that’s currently easily available through Bitcoin Core. The respondent suggested that Bitcoin Core provide an alternative mechanism before removing the current interface.

Additional feedback is requested from anyone using the BIP35 mempool message for any purpose. You can reply to either the mailing list post or the PR linked previously.

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.

● How many sigops are in the invalid block 783426? Vojtěch Strnad provided a script that iterates through all transactions in a block and counts the sigops and notes that there were 80,003 sigops in the block, making it invalid.
● How would an adversary increase the required fee to replace a transaction by up to 500 times? In referencing a draft BIP for ephemeral anchors, Michael Folkson asks how the referenced 500 times increase in required fees for a transaction replacement could occur. Antoine Poinsot gives an example of how an attacker could use the Replace-By-Fee (RBF) fee bumping rules to require additional replacement transactions to pay significantly higher fees.
● Best Practices with Multiple CPFPs & CPFP + RBF? Sdaftuar explains considerations around using RBF and Child Pays For Parent (CPFP) fee bumping techniques in the scenario that an initial CPFP fee bumping attempt failed to offer a sufficient feerate to get the initial transaction confirmed.

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.

● LDK 0.0.115 is a release of this library for building LN-enabled wallets and applications. It includes several new features and bug fixes, including more support for the experimental offers protocol and improved security and privacy.
● LND v0.16.1-beta is a minor release of this LN implementation that includes several bug fixes and other improvements. Its release notes note that its default CLTV delta has been increased from 40 blocks to 80 blocks (see Newsletter #40 where we covered a previous change in LND’s default CLTV delta).
● Core Lightning 23.05rc1 is a release candidate for the next version of this LN implementation.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, and Bitcoin Inquisition.

● LND #7564 now allows users of a backend that provides access to the mempool to monitor for unconfirmed transactions containing preimages for the HTLCs in the node’s channels. This allows the node to resolve the HTLCs faster than waiting for those transactions to confirm.
● LND #6903 updates the openchannel RPC with a new fundmax option that will allocate all channel funds towards a new channel, with the exception of any amount that needs to be kept onchain for adding fees to channels using anchor outputs.
● LDK #2198 increases the amount of time LDK waits before sending a gossip message announcing that a channel is down (e.g. because the remote peer is unavailable). Previously, LDK announced a channel was down after about a minute. Other LN nodes wait longer and a proposal for updating the LN gossip protocol suggests replacing timestamp fields with block heights instead of Unix epoch time, which would only allow updating a gossip message once per block (approximately every 10 minutes on average). Although the PR notes that sending slower updates involves tradeoffs, it updates LDK to wait about 10 minutes before broadcasting a channel disabled message.
● Bitcoin Inquisition #23 adds part of the support for ephemeral anchors. It doesn’t include support for v3 transaction relay, which ephemeral anchors depends on to stop transaction pinning attacks.