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.


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

    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.

  • lists Bitcoin software marked as malicious by antivirus products:
    The 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
    (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
, 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
    , 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—

What do you think?

Executive Vote: Increase ETH Debt Ceiling to 420 Million The Maker Blog

Terra Money – The Case for LUNA [Subscribers Only] Token Tuesdays