Bitcoin Optech Newsletter #106

This week’s newsletter describes a proposed update to the draft BIP118
SIGHASH_NOINPUT and summarizes notable changes to popular Bitcoin
infrastructure projects.

Action items

None this week.

News

• ● BIP118 update: Anthony Towns posted to the
  Bitcoin-Dev mailing list a link to a PR that proposes to replace the
  existing text of the BIP118 draft of SIGHASH_NOINPUT with the draft specification for
  SIGHASH_ANYPREVOUT and SIGHASH_ANYPREVOUTANYSCRIPT. Both
  proposals describe optional signature hash (sighash) flags that do not
  commit to the particular UTXOs (inputs/previous outputs) being spent
  in a transaction, making it possible to create a signature for a
  transaction without knowing which UTXO it will spend. That feature can
  be used by the proposed eltoo settlement layer to allow
  creating a series of transactions where any later transaction can
  spend the value from any earlier transaction, allowing an offchain
  contract to be settled in its latest state even if earlier states are
  confirmed onchain.

  The main difference between the noinput and anyprevout proposals is that noinput would require its own new version of segwit but anyprevout uses one of the upgrade features from the proposed BIP342 specification of tapscript. Additional differences between the proposals are described in the revised text itself.

Notable code and documentation changes

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

• ● Bitcoin Core #19219 clarifies the distinction between manual peer banning
  and automated peer discouragement, and it reduces worst-case resource usage
  by placing the IP addresses of misbehaving peers into a non-persisted rolling bloom filter to
  prevent them from abusing Bitcoin Core’s limited connection slots. Such peers are now
  logged as discouraged rather than banned to reflect the changes made in
  #14929 (see Newsletter #32).
  By contrast, incoming connections are never accepted
  from manually banned peers, and their addresses and subnets are persisted to
  banlist.dat on shutdown and reloaded on startup. Banning can be used to
  prevent connections with spy nodes or other griefers—although neither banning nor discouragement protects
  against DoS attacks, as it is trivial for an attacker to reconnect using
  different IP addresses.

  This PR marks the beginning of a series of current and future changes to peer
  management. In related merges this week, #19464 removes the
  -banscore configuration option, and #19469 updates the
  getpeerinfo RPC to deprecate the banscore field. Further improvements to
  resource usage, inbound connection optimization
  and user interfaces related to peer management are currently in development.

• ● Bitcoin Core #19328 updates the gettxoutsetinfo RPC with a new
  hash_type parameter that allows specifying how to generate a
  checksum of the current UTXO set. Currently the only two options are
  hash_serialized_2, which produces the checksum that has been the
  default since Bitcoin Core 0.15 (September 2017), or none, which
  returns no checksum. It’s planned to later
  allow a muhash-based checksum along with an index that will allow
  returning the checksum much more quickly than is now possible (in less
  than two seconds, per early testing by an Optech contributor). For
  now, requesting the none result allows the gettxoutsetinfo RPC to
  run much more quickly, which is useful for anyone running it after
  each block (e.g. to audit the number of spendable bitcoins). For
  historical context on fast UTXO set checksums, see this 2017
  post by Pieter Wuille.

• ● Bitcoin Core #19191 updates the -whitebind and -whitelist
  configuration settings with a new download permission. When this
  permission is applied to a peer, it will be allowed to continue
  downloading from the local node even if the node has reached its
  -maxuploadtarget maximum upload limit. This makes it easy for a
  node to restrict how much data it offers to the public network
  without restricting how much it offers to local peers on the same
  private network. The existing noban permission also gives peers
  with that permission an unlimited download capability, but that may be
  changed in a future release.

• ● LND #971 adds support for controlling the maximum pending value in
  outstanding HTLCs (which are at risk of being locked up) with openchannel’s
  new remote_max_value_in_flight_msat flag. This new flag will be available to
  LND users via both the RPC interface and the command line.

• ● LND #4281 adds an --external-hosts command line flag that accepts
  a list of one or more domain names. LND will periodically poll DNS
  for each domain’s IP address and advertise that LND is listening for
  connections on that address. This makes it easy for users of dynamic
  DNS services to automatically update their node’s advertised IP
  address.

—Source link—