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
projects.

Action items

None this week.

News

• ● 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
Descriptors. 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.

• ● What are “leaf versions” in Taproot?
  Michael Folkson and Pieter Wuille explain that each leaf node of a
  taproot tree commits to both a leaf version and a script.
  This leaf version can be used for upgradability and designates the script
  semantics that apply just to that leaf.

• ● What are the different upgradability features in the BIP-Taproot (BIP341) proposal?
  Michael Folkson answers a question from Twitter regarding the different ways
  in which taproot can enable upgradability including leaf versions for script
  semantics, repurposing opcodes for future functionality, pubkey types, and the
  annex for new fields.

• ● Is there an active list of BIPs currently open?
  Pieter Wuille describes various methods that have previously been used to
  activate soft forks and notes that, while there are currently no unactivated
  soft forks in Bitcoin Core, there is a discussion about the activation method
  for taproot. Pieter also answers a similar question about mining signaling support.

• ● Could we skip the Taproot soft fork and instead use Simplicity to write the equivalent of Taproot scripts?
  Michael Folkson, quoting Pieter Wuille, outlines the current state of
  Simplicity and also notes that integrating Simplicity in
  taproot as a leaf version would be preferable.

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
  newsletter’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
(BIPs), 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
  transaction.

  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
     network 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
     2020.

  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—