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
disabletxmessage: 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
-blocksonlymode 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
disabletxmessage 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
disabletxany transaction announcements and won’t request any transactions from the node. It also won’t send some other gossip messages such as
addrmessages used for IP address announcements. The
disabletxnegotiation 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
● 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
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
● 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
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
cltvparameter to the
invoiceRPC so that
users and plugins can set the resulting invoice’s
● C-Lightning #4303 updates
hsmtoolto take its passphrase on
standard input (stdin) and begins ignoring any passphrase provided on
the command line.