This week’s newsletter describes a new proposed Bitcoin P2P protocol message, a BIP for the bech32 modified address format, and an idea for preventing UTXO probing in proposed dual-funded LN channels. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, a list of releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

  • ● Proposed disabletx message: in 2012, BIP37 was published, giving lightweight clients the ability to request that peers not relay to the client any unconfirmed transactions until the client had loaded a bloom filter. Bitcoin Core later reused this mechanism for its bandwidth-saving -blocksonly mode where a node requests that its peers don’t send it any unconfirmed transactions at all. Last year, Bitcoin Core with default settings began opening a few block-relay-only connections as an efficient way to improve eclipse attack resistance without significantly increasing bandwidth or reducing privacy (see Newsletter #63). However, the BIP37 mechanism being used to suppress transaction relay allows the initiating node to request full transaction relay at any time. Transaction relay consumes node resources such as memory and bandwidth, so nodes need to set their connection limits with the assumption that each BIP37-based low-bandwidth blocks-relay-only connection could suddenly become a full transaction relay connection.

    This week, Suhas Daftuar posted to the Bitcoin-Dev mailing list a new proposed BIP for a disabletx message that could be sent during connection negotiation. A peer that understands the message and which implements all of the BIP’s recommendations won’t send the node requesting disabletx any transaction announcements and won’t request any transactions from the node. It also won’t send some other gossip messages such as addr messages used for IP address announcements. The disabletx negotiation persists for the lifetime of the connection, allowing peers to use different limits for disabled relay connections, such as accepting additional connections beyond the current 125 connection maximum.

  • ● Bech32m Pieter Wuille posted to the Bitcoin-Dev mailing list a draft BIP for a modified version of the bech32 address encoding that increases the chance that the accidental addition or removal of characters in one of these bech32m addresses will be detected. If no problems are found with the proposal, it is expected that bech32m addresses will be used for taproot addresses and possibly future new script upgrades. Wallets and services implementing support for paying bech32m addresses will automatically support paying all those future improvements (see Newsletter #45 for details).

  • ● LN dual funding anti UTXO probing: a long-term goal for LN has been dual funding, the ability to open a new channel with funds from both the node initiating the channel and the peer receiving their request. This will allow payments to travel in either direction in the channel from the moment it’s fully opened. Before the initiator can sign the dual funding transaction, they need the identities (outpoints) of all of the UTXOs the other party wants to add to the transaction. This creates a risk that an abuser will attempt to initiate dual-funded channels with many different users, learn their UTXOs, and then refuse to sign the funding transaction—harming those users’ privacy at no cost to the abuser.

    This week, Lloyd Fournier posted to the Lightning-Dev mailing list an evaluation of two previous proposals to deal with this problem, one using Proofs of Discrete Log Equivalency (PoDLEs, see Newsletter #83) and the other using dual funding transactions half-signed with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY. Fournier extended the previous half-signed proposal and then provided his own proposal that was equivalently effective but simpler. The new proposal has the initiator create and sign (but not broadcast) a transaction that spends their UTXO back to themselves. They give this to the other party as a proof of good faith—if the initiator later fails to sign the actual funding transaction, the respondent can broadcast the good-faith transaction, forcing the initiator to pay an onchain fee. Fournier concludes his post with a summary of the tradeoffs between the different approaches.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Add unit testing of node eviction logic is a PR (#20477) by pseudonymous contributor practicalswift to improve test coverage of Bitcoin Core’s peer eviction logic when a node’s inbound connection slots are full. Care must be taken to avoid exposing the node to attacker-triggered network partitioning with this logic.

Most of the discussion focused on understanding Bitcoin Core’s peer eviction logic.

  • Inbound or outbound peer selection: which one is our primary defense against eclipse attacks?

    Outbound peer selection, as attackers have less influence over what outbound peers we select than the inbound connections we accept. Inbound peer eviction is a second-order protection—and not all nodes permit incoming connections. ➚

  • Why does Bitcoin Core evict inbound connections?

    To make inbound slots available for honest peers in the network so that new nodes can establish good outbound connections to them. Otherwise, dishonest nodes could more easily attack new nodes by being available for their outbound connections and by occupying as many inbound slots as possible. ➚

  • When it needs to free up a slot, how does Bitcoin Core decide which inbound peer to evict?

    Up to 28 peers are protected from eviction based on criteria that are difficult to forge, such as low latency, network group, providing novel valid transactions and blocks, and a few others. The longest-connected remaining half are protected, including some onion peers. Of those that remain, the youngest member of the network group with the most connections is selected for disconnection. An attacker would have to be simultaneously better than honest peers at all of these characteristics to partition a node. ➚

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.

  • ● Bitcoin Core 0.21.0rc5 is a Release Candidate (RC) for the next major version of this full node implementation and its associated wallet and other software. Jarol Rodriguez has written an RC testing guide that describes the major changes in the release and suggests how you can help test them.

  • ● LND 0.12.0-beta.rc5 is the latest release candidate for the next major version of this LN node. It makes anchor outputs the default for commitment transactions and adds support for them in its watchtower implementation, reducing costs and increasing safety. The release also adds generic support for creating and signing PSBTs and includes several bug fixes.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, Rust-Lightning, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Bitcoin Core #18077 introduces support for a common automatic port forwarding protocol, NAT-PMP (Network Address Translation Port Mapping Protocol). A listening Bitcoin client started with the -natpmp configuration parameter will automatically open the listening port on NAT-PMP-enabled routers. NAT-PMP support is added in parallel to the existing UPnP (Universal Plug and Play) support which had been disabled by default in Bitcoin Core 0.11.1 after multiple security issues. In contrast to UPnP, NAT-PMP uses fixed-size UDP packets instead of XML parsing and is therefore considered less risky. This change also transitively adds support for PCP (Port Control Protocol), the backward-compatible successor to NAT-PMP.

  • ● Bitcoin Core #19055 adds the MuHash algorithm so that future PRs can use it for planned features. As covered in newsletter 123, MuHash is a rolling hash algorithm that can be used to calculate the hash digest of a set of objects and efficiently update it when items are added to or removed. This is a revival of the idea of using MuHash to calculate a digest of the complete UTXO set first suggested by Pieter Wuille in 2017 and implemented in Bitcoin Core #10434. For those interested in tracking the progress of creating an index for UTXO set statistics, making it easier to verify assumeUTXO archives, meta PR Bitcoin Core #18000 documents the project’s progress and future steps.

  • ● C-Lightning #4320 adds a cltv parameter to the invoice RPC so that users and plugins can set the resulting invoice’s min_final_cltv_expiry field.

  • ● C-Lightning #4303 updates hsmtool to take its passphrase on standard input (stdin) and begins ignoring any passphrase provided on the command line.