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.