Bitcoin Optech: BIPs And Standards

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter describes a set of BIPs for output script descriptors, summarizes a proposal to create a set of standards documents for LN protocol extensions and application interoperability, and discusses standardizing support for pre-trusted zero-conf channel opens. Also included are our regular sections describing how to prepare for taproot, releases and release candidates, and notable changes to popular Bitcoin infrastructure projects.

News

BIPs for output script descriptors: Andrew Chow posted to the Bitcoin-Dev mailing list a proposed set of BIPs to standardize output script descriptors. A core BIP provides the general semantics and primary elements used by descriptors. Six additional BIPs describe expansion functions such as pkh(), wpkh(), and tr() that use their arguments to fill in a script template. The multiple BIPs allow developers to choose which descriptor features they want to implement, e.g. newer wallets may never implement the legacy pkh() descriptor.
Descriptors were originally implemented for Bitcoin Core and have seen increased adoption over the past year by other projects. They’re poised to see a significant increase in use as wallets begin to explore the flexibility enabled by taproot and the ability to simplify access to the flexible scripts through tools like miniscript.
BLIPs: Ryan Gentry posted to the Lightning-Dev mailing list a proposal for a collection of Bitcoin Lightning Improvement Proposals (BLIPs), documents that describe extensions and applications of LN that will benefit from interoperability standards. René Pickhardt linked to an almost identical proposal he made in 2018.
In discussion, the idea seemed to have broad support, although concerns were raised that it doesn’t actually solve the barrier to getting those standards incorporated in the base BOLTs documents—that barrier being experienced developers lacking enough time to review the many community proposals. If BLIPs are merged without significant review, that increases the chance that they’ll contain bugs or that they’ll fail to achieve broad support from multiple stakeholders, leading to fragmentation as different projects adopt competing standards. Still, non-mainline protocols are already being created and most discussion participants seemed to believe providing a well-known archive where documentation about those protocols could be published would be primarily beneficial.
Zero-conf channel opens: Rusty Russell started a discussion on the Lightning-Dev mailing list about standardizing the handling of zero-conf channels, also known under the name turbo channels. These are new single-funded channels where the funder gives some or all of their initial funds to the acceptor. Those funds are not secure until the channel open transaction receives a sufficient number of confirmations, so there’s no risk to the acceptor spending some of those funds back through the funder using the standard LN protocol.
For example, Alice has several BTC in an account at Bob’s custodial exchange. Alice asks Bob to open a new channel paying her 1.0 BTC. Because Bob trusts himself not to double-spend the channel he just opened, he can allow Alice to send 0.1 BTC through his node to third-party Carol even before the channel open transaction has received a single confirmation.

Some LN implementations already support the idea in a non-standardized way and all discussion participants seemed to favor standardizing it. The exact details to use were still being discussed at the time of writing.

Preparing for taproot #3: taproot descriptors

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

Output script descriptors provide a generic way for wallets to store the information needed to create addresses, efficiently scan for outputs paying those addresses, and later spend from those addresses. In addition, descriptors are reasonably compact and contain a basic checksum, making them convenient for backing up address information, copying it between different wallets, or sharing it between wallets that are cooperating to provide multiple signatures.

Although descriptors are currently only used by a few projects, they and the related miniscript project have the potential to significantly improve interoperability between different wallets and tools. This will become increasingly important as more users take advantage of the benefits of taproot to improve their security through multisignatures and their resiliency through backup spending conditions.

Before that can happen, descriptors need to be updated to work with taproot. That was the subject of the recently merged Bitcoin Core #22051 pull request. The syntax has been designed to allow a single descriptor template to provide all the information necessary to use both P2TR keypath spends and script path spends. For simple single-sig, the following descriptor is sufficient:

tr(<key>)

The same syntax may also be used for multisignatures and threshold signatures. For example, Alice, Bob, and Carol aggregate their keys using MuSig and then pay to tr(<combined_key>).

Unintuitively, the key specified by tr(<key>) won’t be the key encoded in the address. The tr() descriptor follows a safety recommendation from BIP341 to use an internal key that commits to an unspendable script tree. This eliminates an attack against users of naive key aggregation schemes (more advanced schemes such as MuSig and MuSig2 are not affected).

For scriptpath spending, a new syntax is added that allows specifying the contents of a binary tree. For example, { {B,C} , {D,E} } specifies the following tree:

A tree can be specified as an optional second parameter to the descriptor template we used before. For example if Alice wants to be able to spend via keypath, but she also wants to allow Bob, Carol, Dan, and Edmond spend via a scriptpath that generates an audit trail for her (but not for third-party chain surveillance), Alice can use the following descriptor:

tr( <a_key> , { {pk(<b_key>),pk(<c_key>)} , {pk(<d_key>),pk(<e_key>)} )

The above features are all that’s required to use descriptors for taproot, but PR #22051 notes that there are still some things missing that could be added to make descriptors better at completely describing expected policies:

Voided keypaths: some users may want to prevent usage of keypath spending in order to force scriptpath spending. That can be done now by using an unspendable key as the first parameter to tr(), but it’d be nice to allow wallets to store this preference in the descriptor itself and have it compute a privacy-preserving unspendable keypath.
Tapscript multisig: for legacy and v0 segwit, the multi() and sortedmulti() descriptors support the OP_CHECKMULTISIG opcode. To allow batch verification in taproot, script-based multisig is handled a bit differently in tapscript, so tr() descriptors currently need to specify any necessary multisig opcodes via a raw() script. Updated versions of multi() andsortedmulti() for tapscripts would be nice to have.
MuSig-based multisignatures: earlier in this article, we described Alice, Bob, and Carol manually aggregating their keys in order to use a tr() descriptor. Ideally, there would be a function that allows them to specify something like tr(musig(<a_key>, <b_key>, <c_key>)) so that they could retain all the original key information and use it to populate fields in the PSBTs they use to coordinate signing.
Timelocks, hashlocks, and pointlocks: these powerful constructions used in LN, DLCs, coinswaps, and many other protocols can currently only be described via the raw() function. Adding support for them directly to descriptors is possible, but it may be the case that support will be added instead through descriptor’s sibling project, miniscript. Integration of miniscript into Bitcoin Core is still an ongoing project, but we expect its innovations to spread to other wallets in the same way that tools like PSBTs and descriptors already have.

Wallets don’t need to implement descriptors in order to start using taproot, but those that do will give themselves a better foundation for using more advanced taproot features later.

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.

LND 0.13.1-beta.rc1 is a maintenance release with minor improvements and bug fixes for features introduced in 0.13.0-beta.

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, BTCPay Server, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

Bitcoin Core #19651 allows the wallet key manager to update existing descriptors. This allows wallet users to edit labels, extend descriptor ranges, reactivate inactive descriptors, and make other updates using the importdescriptors wallet RPC.
C-Lightning #4610 adds an –experimental-accept-extra-tlv-types command-line option which allows users to specify a list of even-numbered TLV types that lightningd should pass through for plugins to handle. Previously, lightningd considered all unknown evenly-typed TLV messages to be invalid. This change allows for plugins to define and handle their own custom TLV types unknown to lightningd.
Eclair #1854 adds support for decoding and logging of warning messages sent from peers like C-Lightning that have recently implemented warning message types.
BIPs #1137 adds BIP86, which suggests a key derivation scheme for single key P2TR outputs. The BIP was summarized in last week’s newsletter.
BIPs #1134 updates BIP155 to indicate that the sendaddr2 P2P feature negotiation message should be sent any time a software program understands version 2 addr messages, including in cases where the program doesn’t necessarily want to receive addr messages.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.