Bitcoin Optech Newsletter #111 Bitcoin Optech

This week’s newsletter describes a possible update to the BIP340
specification of schnorr signatures and a new proposed BIP that
specifies how Bitcoin nodes should handle P2P protocol feature
negotiation in a forward compatible way. Also included are our
regular sections with notable changes to services and client software,
releases and release candidates, and changes to popular Bitcoin
infrastructure software.

Action items

None this week.

News

• ● Proposed uniform tiebreaker in schnorr signatures: the elliptic
  curve cryptography used in Bitcoin requires identifying points on
  Elliptic Curves (ECs). This can be done unambiguously using a 32-byte X
  coordinate and a 32-byte Y coordinate. However, if you know a point’s
  X coordinate, then you can calculate the two possible locations
  for its Y coordinate. This small ambiguity can be resolved either by
  providing a single bit of extra data to indicate which of the two
  coordinates to use or by using a type of method known as a
  tiebreaker to automatically choose one Y coordinate or the other for
  each X coordinate.

  The BIP340 specification of schnorr signatures for Bitcoin currently uses a tiebreaker method to minimize the amount of data needed to identify EC points in public keys and signatures. Earlier, BIP340 used a tiebreaker algorithm based on the squaredness of the Y coordinates for both the point in public keys and the point in signatures. This was recently changed so that public keys used a different algorithm based on the evenness of the coordinates, which was believed to be easier to implement for existing software that created public keys (see Newsletters #83 and #96).

  This week, Pieter Wuille posted to the Bitcoin-Dev mailing list a tentative proposal to update BIP340 again so that both public keys and signatures would use the evenness algorithm. It was previously thought that the squared version would be faster to compute during signature verification and so would help speed up full nodes, but a recent PR to libsecp256k1 by Peter Dettman with a significant performance improvement caused developers to question this belief and revealed that an earlier benchmark that favored the squared version wasn’t actually providing a fair comparison between the two tiebreaking methods. It now seems that both methods should be about equal in performance.

  Several respondents replied that, even though they already implemented code using both tiebreaker methods, they’d prefer to see the specification changed to use just the evenness method. Anyone else with an opinion is encouraged to respond to the mailing list thread.

• ● Proposed BIP for P2P protocol feature negotiation: Suhas Daftuar
  posted a suggestion to create a separate
  BIP for the P2P feature negotiation method that
  became a part of BIP339 (see Newsletter #87). The protocol change is simple: when a node receives a
  P2P version message from a newly connected peer, the node should
  ignore any messages it doesn’t understand until a verack message has
  been received from that peer. Those messages, like the new BIP339
  wtxidrelay message, may signal what features the remote peer
  supports.

  This behavior is already implemented in an unreleased development version of Bitcoin Core. If the maintainers of other implementations, or anyone else, opposes this change, please respond to the mailing list thread.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin
wallets and services.

• ● Crypto Garage announces P2P Derivatives beta application on Bitcoin:
  In a blog post, Crypto Garage outlines a beta
  application for conducting P2P DLC-based derivatives on Bitcoin regtest
  and testnet. The application allows the specification of a financial
  agreement and creation of a corresponding locking transaction of funds between
  the two parties of that agreement. Upon contract maturity, a price oracle
  provides a signature for the closing transaction spending the amounts
  corresponding to agreement.

• ● Specter Desktop adds batching:
  Specter Desktop, a hardware wallet multisig-focused GUI
  for Bitcoin Core, added the ability to send transactions to multiple receivers.

• ● Lightning Labs releases Lightning Terminal:
  Lightning Terminal is a visual, browser-based tool
  for LN channel management, initially focusing on Lightning Loop.

• ● Wasabi adds support for PayJoin:
  Wasabi 1.1.12 adds support for the BIP78 PayJoin specification that
  also works over Tor.

• ● BlueWallet for Desktop alpha announced:
  BlueWallet announced an alpha desktop version for macOS
  of their Lightning and Bitcoin wallet supporting bech32, hardware wallets, PSBTs,
  watch-only addresses, and more.

• ● BitcoinIsSafe.com lists Bitcoin software marked as malicious by antivirus products:
  The bitcoinissafe.com website tracks the detection rate of Bitcoin software
  including Bitcoin Core, Electrum, and Wasabi within popular antivirus
  products. The website also provides contact information for notifying
  antivirus vendors about potential false positives.

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.

• ● LND 0.11.0-beta.rc4 is a release candidate for the
  next major version of this project. It allows accepting large
  channels (by default, this is off) and contains
  numerous improvements to its backend features that may be of interest
  to advanced users (see the release notes).

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 #19658 modifies the getnodeaddresses RPC to allow returning
  all known addresses when 0 is specified as the number of addresses to retrieve.
  Previously, there was a limit on the maximum number of addresses returned,
  mostly due to an internal implementation quirk.

• ● Bitcoin Core #18654 adds a new psbtbumpfee RPC that takes the
  txid of a transaction currently in the local node’s mempool and
  creates a PSBT that increases its feerate (either by an
  automatic amount or by an amount specified via a parameter). Other
  RPCs or external tools can then sign and finalize the PSBT.

  The existing bumpfee RPC previously created PSBT fee bumps for watch-only wallets (see Newsletter #80). This behavior is now deprecated and a message will be printed to tell those users to use psbtbumpfee. Use of bumpfee with regular key-containing wallets still creates, signs, and broadcasts the fee bump. This change helps make bumpfee more consistent since its previous behavior for watch-only wallets of creating PSBTs couldn’t include the signing or broadcast steps.

• ● Bitcoin Core #19070 allows Bitcoin Core to advertise its support
  for compact block filters when the
  peerblockfilters and blockfilterindex configuration options have been enabled (default:
  disabled). This will allow services such as DNS seeders to tell
  lightweight clients the IP addresses of nodes that serve filters.
  This PR is the last in a series of patches that enable BIP157 and
  BIP158 support in Bitcoin Core.

• ● Bitcoin Core #15937 updates the createwallet, loadwallet, and
  unloadwallet RPCs to provide a load_on_startup option that will
  add the wallet’s name to the list of wallets automatically loaded on
  start up (or, if the option is set to false, remove the wallet’s name
  from that list). It’s expected that a future PR will allow the GUI to
  add or remove wallet names from the same list.

• ● C-Lightning #3830 adds experimental support for using anchor
  outputs, which can both reduce onchain
  transaction fees in normal cases and increase fees when necessary for
  security. This initial implementation is only available if
  C-Lightning is compiled with experimental features enabled.

• ● LND #4521 updates the method it uses for adding
  routing hints to invoices. The previous method didn’t consider
  multipath payments and so wouldn’t include
  routing hints if you tried to generate an invoice larger than any of
  your current channels. The new method includes more hints and also
  randomizes the order of the hints so that there’s less chance of a
  single channel running out of liquidity.

—Source link—