Bitcoin Optech #160: Preparing For Taproot And More

This week’s Bitcoin Optech newsletter details how to prepare for Taproot, releases and changes to Bitcoin infrastructure projects.

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 includes our regular sections describing how you can prepare for taproot, summarizing the latest releases and release candidates, and listing notable changes to popular Bitcoin infrastructure projects.

News

No significant news this week.

Preparing for taproot #7: multisignatures

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

In the 1,000 blocks received prior to this writing, 11% of all transaction inputs contained a multisig opcode. Two of the largest and most immediate benefits of taproot will manifest if many of the users and services creating those transactions switch from multisig opcodes to scriptless multisignatures.

The first major benefit will be a reduction in transaction size. Script-based multisigs increase in size as more keys and signatures are required, but multisignatures are a constant small size. The smallest effective multisig policy (1-of-2) requires more space than a multisignature policy that can involve thousands of signers. The decrease in size leads to direct reduction in fees for the multisignature users and an indirect reduction in fees for all users as the same amount of demand for confirmed transactions can be fulfilled using a smaller amount of block space.

The second major benefit is improved privacy. Each use of multisigs is distinctively recorded to the block chain where surveillants can use them to make informed guesses about the wallet history and current balance of individual users. For example, looking at block 692,039, we can distinguish not just the multisig spends from the single-sig spends but also distinguish between different set sizes and thresholds for the multisigs.

By comparison, a third party looking only at block chain data can’t tell that a spender used a multisignature. When a multisignature is used for a keypath spend, it is indistinguishable from single-sig spends. If all single-sig and multisigs in the block above were switched to P2TR keypath spends, only a few exotic spends would be distinguishable by their scripts (and even those could use keypath spends in the best case).

Using multisignatures

We’re aware of three schnorr-based multisignature schemes designed specifically for Bitcoin, all members of the MuSig family:

• MuSig (also called MuSig1), which should be simple to implement but which requires three rounds of communication during the signing process.
• MuSig2, also simple to implement. It eliminates one round of communication and allows another round to be combined with key exchange. That allows using a somewhat similar signing process to what we use today with script-based multisig. This does require storing extra data and ensuring your signing software or hardware can’t be tricked into unknowingly repeating part of the signing session.
• MuSig-DN (Deterministic Nonce), significantly more complex to implement. Its communication between participants can’t be combined with key exchange, but it has the advantage that it’s not vulnerable to the repeated session attack.

All signers have to agree on the protocol to use, so there may be a network effect where many implementations choose to use the same protocol. The authors of the MuSig proposals suggest that will be MuSig2 due to its relative simplicity and high utility.

There’s an open and actively-developed PR to the libsecp256k1-zkp project to add MuSig2 support. We expect the basic multisignature workflow will look something like the following:

1. The wallet for each participant generates a BIP32 xpub that is shared with all the other participants through an output script descriptor or another method (the same as is commonly done now for multisigs).
2. The wallet also generates a set of nonces that are also shared with the other participants. The wallet can generate these nonces using BIP32 hardened derivation. Nonces are 32 bytes and you need two of them per signature. For infrequently used wallets, all the nonces needed for the entire wallet lifetime can be shared up front. For more frequently used wallets (e.g. LN routing nodes), each wallet can send its signature for the current transaction along with its nonces for the next transaction.
3. Any of the wallets can then generate an aggregated public key by combining its pubkey at a certain BIP32 depth with pubkeys at the same depth from all other wallets in the multisignature association. The aggregated public key can be used to receive P2TR payments.
4. When one of the wallets wants to spend the funds, it uses a PSBT-based workflow similar to what it would use with script-based multisig. Unlike multisig, the wallet uses its next nonces and the next nonces of all the other participants to create a shared nonce according to the MuSig2 algorithm; it then creates a partial signature over that nonce and the transaction.
5. When the other wallets receive the PSBT, they use the same procedure. The partial signatures are then combined to create the final signature and the transaction is broadcast.

Threshold signing

By themselves, the MuSig family of multisignature schemes only give you n-of-n signing—every party who contributes a key towards the aggregated public key must also contribute a partial signature to the final signature. That works perfectly well as a direct replacement for some uses of script-based multisig today, such as spending 2-of-2 LN funding outputs, but it’s a departure from other popular policies such as the 2-of-3 multisig script used by many exchanges.

Several developers are working threshold signature schemes that will bring the same efficiency and privacy benefits of multisignatures to k-of-n scenarios, but there’s a simple trick that can be used until those schemes are available.

In many threshold cases, it’s known in advance which participants are most likely to sign. For example, in a 2-of-3 situation, it might be known that normally Alice and Bob will co-sign, while Carol only signs if one of the others is unavailable. For this set of circumstances, the primary keys can use a multisignature for the taproot keypath spend (e.g. between Alice and Bob) and the additional outcomes (Alice and Carol, or Bob and Carol) can use multisignatures with the OP_CHECKSIG opcode in separate branches in a tree of tapscripts.

In the normal case, the above has exactly as much efficiency and privacy as a single-sig or multisignature transaction. In the abnormal case, spending still works as expected and remains more efficient and private than publishing your multisig parameters onchain.

Although users wanting minimal fees and maximal privacy may eventually switch to pure threshold signature schemes, the above scheme may also continue to remain in use because it provides onchain proof to an auditor (if they know all of the participants’ public keys) about which corresponding private keys were used to sign.

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.10.1rc2 is a release candidate for an upgrade that contains a number of new features, several bug fixes, and a few updates to developing protocols (including dual funding and offers).

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 #22006 adds documentation for User-Space, Statically Defined Tracing (USDT) and the first three tracepoints – build support and macros for which were added in Bitcoin Core #19866. Users that build Bitcoin Core with eBPF tracing enabled can hook into the tracepoints with the provided example scripts or write their own tracing scripts for greater observability into the node when a new block is connected, inbound P2P messages are received, and outbound P2P messages are sent. The documentation also includes usage examples and guidelines for the addition of new tracepoints.
• Eclair #1893 allows separate configuration of feerates for unannounced channels, announced channels, and trampoline relay minimums. This PR also sets different default relay feerates for unannounced channels (0.01%) in contrast to announced channels (0.02%).
• Rust-Lightning #967 adds support for making keysend-style spontaneous payments via thesend_spontaneous_payment function call. With this change, all four LN implementations we cover will have support for keysend.
  The author has also submitted corresponding documentation (yet unmerged) on keysend payments as a BLIP (Bitcoin Lightning Improvement Proposals), a proposed way to document features and best practices which do not belong as part of the LN BOLTs specification

Find the original post here.

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