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

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.

—Source link—