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 can allow using a somewhat similar signing process to what we use today with script-based multisig. This does require storing extra data and being very careful about ensuring your signing software or hardware can’t be tricked into unknowingly repeating part of the signing session. We’ll examine the tradeoffs in more detail in next week’s preparing for taproot column.

• 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 for most software 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. 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.

3. 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, but now two rounds of communication between signers are required. In the first round, the proposer creates the unsigned transaction and includes a pair of randomly-generated nonces. It’s absolutely essential that the nonces not be derived in an entirely deterministic way that could lead to the same nonce being used again for a different signature. The proposer sends the PSBT with the nonces to the other wallets.

4. The other wallets receive the PSBT and send a further updated PSBT with their own pair of random nonces to the other wallets, or to a coordinator who works trustlessly on behalf of the wallets.

5. When all the wallets have all the nonce pairs, they combine them into a single nonce. The coordinator may also do this for them. The wallets then all update their versions of the PSBT with their partial signatures, sending the PSBTs to the other wallets or the coordinator. 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 on 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.

Edit: some of the text above about MuSig2 was updated to clarify that extra care is required when pre-sharing nonces, so most normal wallets using MuSig2 are expected to generate new random nonces at the moment they’re needed. We thank members of the #secp256k1 IRC room for sharing their concerns.

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 the send_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.