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
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
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:
- 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.
- 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
● C-Lightning 0.9.0rc3 is a release candidate for
an upcoming major release. It adds support for the updated
command and new
keysendRPC 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
● Bitcoin Core #18044 adds support for witness txid (wtxid)
transaction inventory announcements (
inv) and requests (
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:
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.
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.
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).
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
networkactiveas 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
setnetworkactiveRPC 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
● 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_publishflag to the
which can be used to delay transaction broadcast until the very last channel
in the batch.