Bitcoin Optech Newsletter #130 Bitcoin Optech

This week’s newsletter describes a proposed update to BIP322 generic
message signing and links to a specification for LN trampoline routing.
Also included are our regular sections with announcements of releases,
release candidates, and notable changes to popular Bitcoin
infrastructure software.

News

  • Proposed updates to generic signmessage: Andrew Poelstra
    posted a partial rewrite of the BIP322
    generic message signing proposal. The rewrite mainly clarifies the
    signing and verification procedures, but it now also allows wallets
    that don’t implement a complete set of checks to return an
    “inconclusive” state for signatures that use scripts they don’t
    understand. For example, a developer who wants to quickly implement
    generic signmessage may choose to only implement signature verification for
    P2PKH, P2WPKH, and P2SH-P2WPKH scripts, which covers a large
    percentage of all current and historic outputs. For anything else,
    the wallet can return “inconclusive” and maybe direct the user to a
    more comprehensive verification tool.

  • Trampoline routing: Bastien Teinturier posted
    to the Lightning-Dev mailing list a new specification
    for trampoline routing that allows a
    spender to pay a receiver without calculating a route between their
    nodes. Instead, the spender routes their money to a nearby trampoline
    node that calculates the next part of the route—getting the money
    either to the receiver or to the next trampoline node. This is useful
    for spenders with lightweight LN clients that are often offline or
    otherwise unable to keep track of network gossip in order to calculate
    routes themselves.

    Teinturier notes that ACINQ has been running a single-bounce trampoline node for users of their Phoenix wallet. This provides the route-finding benefit but, as described in a blog post, it means ACINQ can see the destination of all its users’ payments. The solution to this problem is allowing routing nodes to advertise the ability to accept onion-wrapped trampoline routes where spender Alice sends her money first to one trampoline (e.g. ACINQ’s node), then possibly to other trampolines, and finally to the receiver node. This prevents any individual trampoline from learning the node identifier for both the spender and receiver. The proposed specification would provide a standardized way to achieve this.

    It’s Teinturier opinion that “the code changes are very reasonable as it reuses a lot of components that are already part of every lightning implementation and doesn’t introduce new assumptions.”

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.

  • Eclair 0.5.0 is a new major version that adds support for a
    scalable cluster mode (see Newsletter #128), block
    chain watchdogs (Newsletter #123), and additional plugin
    hooks, among many other features and bug fixes.

  • Bitcoin Core 0.21.0rc5 is a release candidate
    for the next major version of this full node implementation and its
    associated wallet and other software. This latest RC has not yet been
    uploaded as of this writing, but we hope it will be available shortly
    after publication.

  • LND 0.12.0-beta.rc3 is the latest release candidate
    for the next major version of this LN node. It makes anchor
    outputs
    the default for commitment transactions
    and adds support for them in its watchtower
    implementation, reducing costs and increasing safety. The release also adds generic
    support for creating and signing PSBTs and includes
    several bug fixes.

Notable code and documentation changes

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

  • Bitcoin Core #19137 adds dump and createfromdump commands to wallet-tool, allowing users to write wallet records to a dump file and subsequently
    restore a wallet from that dump file. These commands are useful not only
    for testing but as part of the migration away from legacy wallets.

  • Bitcoin Core #20365 updates the bitcoin-wallet tool’s create
    command with a -descriptors flag for creating sqlite-backed
    descriptor wallets
    , similar to the daemon’s
    createwallet RPC.

  • Bitcoin Core #20599 updates the message handling code to process
    sendheaders and sendcmpct messages received before the peer has sent its
    verack message. The BIPs for sendheaders (BIP130) and sendcmpct
    (BIP152) do not specify that those messages must be sent after the verack
    message, and the original implementations (Bitcoin Core #7129 and
    Bitcoin Core #8068) allowed the messages to be received and processed
    before the verack message. A later PR (Bitcoin Core #9720) prevented
    Bitcoin Core from processing those messages if they were received before the
    verack. This PR restores the original behavior.

  • Bitcoin Core #18772 updates the getblock RPC when used with the
    verbosity=2 parameter to return a new fee field containing the
    total fee for each transaction in the block. This depends on
    additional block undo data that nodes store in order to handle block
    chain reorganizations. Undo data is stored separately from other
    block transaction data and nodes with pruning enabled may delete undo
    data before deleting other data, so it’s possible for pruned nodes to
    sometimes return results without a fee field.

  • Bitcoin Core GUI #162 adds a new sortable Network column to the GUI Peers
    window and a new Network row to the peer details area. In both, the GUI
    displays to the user the type of network the peer is connected through: IPv4,
    IPv6, or Onion, with the ability to display two potential future additions,
    I2P and CJDNS. The PR also renames the NodeId and Node/Service column headers
    to Peer Id and Address.

  • C-Lightning #4207 adds extensive new documentation about backing up your node data.

  • Eclair #1639 enables BOLT3 option_static_remotekey by
    default, allowing Eclair to honor the request from a channel peer to
    always send payments to the same public key. This makes it easy for
    the remote peer to locate and spend those payments onchain even if it
    loses some channel state. The PR description indicates Eclair developers are
    enabling this option now because the 0.12.0-beta release of LND will
    make it mandatory.

  • Rust Bitcoin #499 adds support for two global PSBT fields
    specified after BIP174’s original publication:

    1. The extended public key field which enables change detection for signing wallets (see Newsletter #55)

    2. The version number field which helps identify backwards-incompatible changes to the PSBT spec (see Newsletter #72)

    This is one of the last changes in a larger effort detailed in #473 to bring Rust Bitcoin’s PSBT implementation up-to-date with current
    specifications.

—Source link—

What do you think?

How to earn token airdrops Bankless

Futureswap Announces V2 Beta DeFi Rate