Bitcoin Optech Newsletter #108

This week’s newsletter describes a proposal to allow upgrading LN
channel commitment transaction formats without opening new channels and includes
a field report from River Financial about building wallet software using PSBTs
and descriptors. Also included are our regular sections with selected questions and
answers from the Bitcoin StackExchange, recent releases and release
candidates, and notable changes to popular Bitcoin infrastructure

Action items

None this week.


  • Upgrading channel commitment formats: Olaoluwa Osuntokun
    posted to the Lightning-Dev mailing list this
    week with a suggested extension to the LN specification that will
    allow two peers with an existing channel to negotiate a
    new commitment transaction using a different format. Commitment
    transactions are used to allow LN nodes to publish the current channel
    state on chain, but the existing protocol only allows nodes to upgrade
    to new commitment formats by opening new channels. Osuntokun’s
    proposal would allow a node to signal to its peer that it wants to
    switch formats. If the peer agrees, the two nodes would port their
    existing channel state over to the new format and then use the new
    format going forward.

    All discussion participants seemed to support the basic idea. Bastien Teinturier suggested that it would be simplest to only allow switching commitment formats when channels had no pending payments (HTLCs)—implying nodes would need to pause sending or relaying payments in a particular channel in order to upgrade it.

    ZmnSCPxj noted that the same basic idea could be used to essentially update the funding transaction offchain, such as the case where taproot and SIGHASH_ANYPREVOUT are implemented, allowing Eltoo-based channel commitments to be used. In ZmnSCPxj’s proposal, the output of the existing funding transaction would be paid to a new funding transaction that is kept offchain. If the channel terminates with a mutual close, the original funding transaction output is paid to the final channel balances; otherwise, the offchain secondary funding transaction can be published onchain and the channel can be resolved using the appropriate unilateral close protocol.

Field report: Using Descriptors and PSBT at River

by Philip Glazman, Engineer at River Financial

River Financial​ is a challenger financial institution specializing in Bitcoin
financial services. River Financial’s flagship product, a Bitcoin brokerage,
provides retail investors with a high-touch platform to buy and sell Bitcoin.

River Financial leverages two technologies in its wallet software: Partially
Signed Bitcoin Transactions (PSBTs)
and Output Script
. The decision to incorporate these standards has
introduced greater flexibility and interoperability in River’s wallet operations.

The decision to bring PSBTs into the wallet stack was influenced by the concept
of treating key signers as interfaces. PSBT is a format for signers described in
BIP174 authored by Andrew Chow. Before this standard, there had been no
standardized format to describe an unsigned transaction. As a consequence, each
signer used vendor-specific formats which could not interoperate. By conforming
to the PSBT standard, the wallet infrastructure can avoid vendor lock-in, reduce
the attack surface in the signer logic, and have better guarantees about the
transaction being created by the wallet. The standard has also made
multisignature scripts safer to use, therefore significantly improving security
without a notable increase in operational expense.

The decision to implement Output Script Descriptors in the wallet software has
greatly reduced the complexity in wallet operations and has improved flexibility
in the feature set. Descriptors is a language for describing scripts that was
authored by Pieter Wuille and used in Bitcoin Core. In River’s wallet software,
the descriptor language is leveraged in several places from wallet creation to
address generation. Before descriptors, there had been no interoperable way for
wallets to import useful information about the scripts they used. By using
script descriptors, River’s wallet is able to reduce the necessary information
needed to start watching a script, address, or set of keys. Each wallet within
the wallet software has an associated descriptor with which scripts can be
created. This has two immediate benefits:

  1. The wallet software is able to watch cold wallets using descriptors and
    subsequently derive new addresses.
    In our flagship brokerage product, River
    clients can create fresh deposit addresses to deposit Bitcoin directly to a
    secure cold multisignature wallet.
  2. Creating and importing new wallets is easy because the descriptor language
    is able to define desired scripts.
    River is able to maintain many wallets
    with different scripts and as a result have separate security models for each
    wallet. A P2WSH multi-signature descriptor is used for the cold wallet and a
    P2WPKH descriptor for the hot (client withdrawal) wallet. Separate wallets
    allow River to keep the absolute minimum Bitcoin in the hot wallet (to
    minimize risk) and better manage the UTXO pool to service withdrawals.

The decision to use both descriptors and the PSBT standard has so far been
rewarding because of the flexibility and interoperability. This foundation will
help River Financial scale its wallet infrastructure.

Selected Q&A from Bitcoin StackExchange

Bitcoin StackExchange is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments to help curious or confused users. In
this monthly feature, we highlight some of the top-voted questions and
answers posted since our last update.

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.

  • C-Lightning 0.9.0rc3 is a release candidate for
    an upcoming major release. It adds support for the updated pay
    command and new keysend RPC described in last week’s
    notable code changes section. It also
    includes several other notable changes and multiple bug fixes.

  • Bitcoin Core 0.20.1rc1 is a release candidate
    for an upcoming maintenance release. In addition to bug fixes and
    some RPC behavior changes resulting from those fixes, the planned
    release provides compatibility with recent versions of HWI and its support for hardware wallet firmware released for the
    fee overpayment attack.

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 #18044 adds support for witness txid (wtxid)
    transaction inventory announcements (inv) and requests (getdata)
    as described in BIP339 (see Newsletter #104). Prior
    to this merge, all Bitcoin nodes announced new unconfirmed
    transactions to their peers by the transaction’s txid. However, txids
    don’t commit to the witness data in segwit transactions, so a node that
    downloads an invalid or unwanted segwit transaction can’t safely
    assume that any transaction with that same txid is also invalid or
    unwanted. That means nodes may waste bandwidth by downloading the
    same bad transaction over and over from each peer announcing that

    So far this hasn’t been an issue—honest peers usually don’t announce transactions they wouldn’t accept themselves, so only a disruptive peer that wanted to waste its own upload bandwidth would advertise invalid or unwanted transactions. However, one type of unwanted transaction today are spends of v1 segwit UTXOs—the types of spends the BIP341 specification of taproot plans to use. If taproot activates, this means newer taproot-aware nodes will advertise taproot spends to older taproot-unaware nodes. Each time one those taproot-unaware nodes receives a taproot-spending transaction, it will download it, realize it uses v1 segwit, and throw it away. This could be very wasteful of network bandwidth, both for older taproot-unaware nodes and newer taproot-aware nodes. This same problem applies to other proposed changes to network relay policy.

    The solution implemented in this merged PR is to announce transactions by their wtxid—which includes a commitment to the witness data for segwit transactions. A taproot implementation in Bitcoin Core (see PR #17977) could then only relay transactions by their wtxid to prevent newer nodes from accidentally spamming older nodes.

    However, after this PR was merged into Bitcoin Core’s master development branch, it was discussed during the weekly Bitcoin Core Development Meeting whether taproot’s soft dependency on wtxid relay will make it more complicated to backport taproot to the current 0.20.x branch of Bitcoin Core. Four options were mentioned during the meeting and in subsequent discussions:

    1. Backport wtxid: both wtxid relay and taproot will be
      backported if there’s a 0.20.x taproot release. John Newbery has
      already created a wtxid relay backport.

    2. Don’t backport wtxid: only backport taproot and just accept that
      transaction announcements will use more bandwidth than usual
      until everyone has upgraded to wtxid-using nodes.

    3. Don’t relay taproot: only backport taproot but don’t enable
      relaying of taproot transactions on backported nodes. This
      prevents the immediate bandwidth waste but it may make it harder to
      get taproot-spending transactions to miners and will reduce the
      speed and efficiency of BIP152 compact blocks. Worse compact
      block performance may temporarily increase the number of stale
      blocks that miners create (especially since the public FIBRE
      has recently shut down).

    4. Don’t backport anything: don’t backport wtxid relay or
      taproot—let taproot wait until some time after the release of Bitcoin
      Core 0.21, roughly expected in December

    No clear conclusion on which of these options to follow has been reached.

  • Bitcoin Core #19473 adds support for networkactive as both a command line
    start-up and configuration file option. Setting this option enables or
    disables all P2P network activity. After the node has been started, network
    activity can be toggled using the existing setnetworkactive RPC or the network
    activity button in the GUI.

  • Eclair #1485 adds support for spontaneous payments using the same keysend protocol previously
    implemented by LND (see Newsletter #30) and
    C-Lightning (see Newsletters #94 and
    #107). This merged PR supports both receiving
    spontaneous payments (labeled as donations) and sending payments
    using the new sendWithPreimage method.

  • Eclair #1484 adds low-level support for the changes to commitment
    transactions for anchor outputs. Not yet
    added is higher-level support that will allow Eclair to negotiate
    the use of anchor outputs with peers, but this early step does pass
    all proposed test vectors.

  • LND #4455 enables safe PSBT-based batched channel opens. Previously, each
    successful channel negotiation in the batch would prematurely broadcast the
    whole transaction with all channel funding outputs. This meant
    subsequent channel negotiation failures could result in stuck funds.
    This merged PR introduces a --no_publish flag to the openchannel command,
    which can be used to delay transaction broadcast until the very last channel
    in the batch.

—Source link—

What do you think?

DerivaDEX Raises $2.7M For Decentralized Derivatives Exchange

Synthetix Dissolves Foundation in Favor of Community DAOs