Bitcoin Optech Newsletter #131 Bitcoin Optech

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


  • 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
    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

  • 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
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
    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
, 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

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

—Source link—

What do you think?

How to make bank with The Graph Bankless

The Castor release Synthetix Blog