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

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.