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.


  • 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
    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
, 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
    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
    services to automatically update their node’s advertised IP

—Source link—

What do you think?

New York Blockchain Week: A Skyscraper Success

Exploring DeFi’s Ownership Economy