This week’s newsletter summarizes a discussion about adding expiration dates to silent payment addresses and provides an overview of a draft BIP for serverless payjoin. A contributed field report describes the implementation and deployment of a MuSig2-based wallet for scriptless multisignatures. Also included are our regular sections with announcements of new releases and release candidates and descriptions of notable changes to popular Bitcoin infrastructure projects.

News

• ● Adding expiration metadata to silent payment addresses: Peter Todd posted to the Bitcoin-Dev mailing list a recommendation to add a user-chosen expiration date to addresses for silent payments. Unlike regular Bitcoin addresses that result in output linking if used to receive multiple payments, addresses for silent payments result in a unique output script every time they are properly used. This can significantly improve privacy when it’s impossible or inconvenient for receivers to provide spenders with a different regular address for each separate payment.

  Peter Todd notes that it would be desirable for all addresses to expire: at some point, most users are going to stop using a wallet. The expected one-time use of regular addresses makes expiry less of a concern, but the expected repeated use of silent payments makes it more important that they include an expiry time. He suggests the inclusion of either a two-byte expiry time in addresses that would support expiry dates up 180 years from now or a three-byte time that would support expiry dates up to about 45,000 years from now.

  The recommendation received a moderate amount of discussion on the mailing list, with no clear resolution as of this writing.

• ● Serverless payjoin: Dan Gould posted to the Bitcoin-Dev mailing list a draft BIP for serverless payjoin (see Newsletter #236). By itself, payjoin as specified in BIP78 expects the receiver to operate a server for securely accepting PSBTs from spenders. Gould proposes an asynchronous relay model that would start with a receiver using a BIP21 URI to declare the relay server and symmetric encryption key they wanted to use for receiving payjoin payments. The spender would encrypt a PSBT of their transaction and submit it to the receiver’s desired relay. The receiver would download the PSBT, decrypt it, add a signed input to it, encrypt it, and submit it back to the relay. The spender downloads the revised PSBT, decrypts it, ensures that it is correct, signs it, and broadcasts it to the Bitcoin network.

  In a reply, Adam Gibson warned about the danger of including the encryption key in the BIP21 URI and the risk to privacy of the relay being able to correlate the receiver’s and spender’s IP addresses with the set of the transactions broadcast within a window of time near when they completed their session. Gould has since revised the proposal in an attempt to address Gibson’s concern about the encryption key.

  We expect to see continued discussion about the protocol.

Field Report: Implementing MuSig2

The first MuSig paper was published in 2018, and the potential of MuSig on Bitcoin was one of the selling points used to gain support for the taproot soft fork. Work on MuSig continued with the publication of MuSig-DN and MuSig2 in 2020. When taproot neared activation on Bitcoin’s mainnet in 2021, excitement about bringing MuSig signing to Bitcoin users was palpable. At BitGo, we were hoping to launch a MuSig taproot wallet concurrent with taproot activation; but the spec, test vectors, and reference implementation were incomplete. Instead, BitGo launched the first tapscript multisig wallet and made the first tapscript multisig transaction on mainnet. Nearly two years later, MuSig2 is specified in BIP327, and we launched the first MuSig taproot multisig wallet.

Why MuSig2?

Compared to Script Multisig

There are two main benefits of MuSig compared to script multisig. The first and most obvious benefit is a reduced transaction size and miner fee. Onchain signatures are 64-73 bytes, 16-18.25 virtual bytes (vB), and MuSig can combine two (or more) signatures into one. In BitGo’s 2-of-3 case, a MuSig key path input costs 57.5vB, compared to a native SegWit input at 104.5vB or depth 1 tapscript at 107.5vB. The second benefit of MuSig is an improvement in privacy. With a MuSig key path on a collaboratively held output, a cooperative spend cannot be distinguished by a third party blockchain observer from a single signature taproot spend.

Naturally, there are some drawbacks to MuSig2. Two important ones revolve around nonces. Unlike signers for plain ECDSA (elliptic curve digital signature algorithm) or schnorr signatures, MuSig2 signers cannot consistently use deterministic nonces. This inability makes it more difficult to ensure high-quality nonces and to ensure against nonce reuse. MuSig2 requires two rounds of communication in most cases. First nonce exchange, and then signing. In some cases, the first round can be precomputed, but this must be undertaken cautiously.

Compared to Other MPC protocols

MPC (multi-party compute) signing protocols are growing in popularity due to the aforementioned fee and privacy benefits. MuSig is a simple multi-signature (n-of-n) protocol, made possible by schnorr signatures’ linearity. MuSig2 can be explained in a 30-minute presentation, and the complete reference implementation is 461 lines of code in Python. Threshold signature (t-of-n) protocols, such as FROST, are significantly more complex, and even 2-party multi-signatures based on ECDSA rely on Paillier encryption and other techniques.

Choice of Scripts

Even before taproot, choosing a specific script for a multi-signature (t-of-n) wallet was difficult. Taproot, with its multiple spending paths further complicates the matter, and MuSig layers in even more options. Here are some of the considerations that went into the design of BitGo’s taproot MuSig2 wallet:

• We use fixed key order, not lexicographic sorting. Each signing key has a specific role stored with the key, so using those keys in the same order each time is simple and predictable.
• Our MuSig key path includes only the most common signing quorum, “user” / “bitgo”. Including the “backup” signing key in the key path would significantly reduce how often it could be used.
• We do not include the “user”, “bitgo” signing pair in the Taptree. As this is our second taproot script type and the first is a three tapscript design, users requiring script signing can use the first type.
• For tapscripts, we do not use MuSig keys. Our wallets include a “backup” key which is potentially difficult to access or signs with software outside of our control, so expecting to be able to sign MuSig for the “backup” key is not realistic.
• For tapscripts, we choose OP_CHECKSIG / OP_CHECKSIGVERIFY scripts over OP_CHECKSIGADD. We know which keys will sign when we construct transactions, and 2-of-2 depth 1 scripts are slightly cheaper than 2-of-3 depth 0.

The final structure looks like this:

Nonces (deterministic and random)

Elliptic curve digital signatures are produced with the help of an ephemeral secret value known as a nonce (number used once). By sharing the public nonce (public nonce is to secret nonce as public key is to secret key) in the signature, verifiers can confirm the validity of the signature equation without revealing the long-lived secret key. To protect the long-lived secret key, a nonce must never be reused with the same (or related) secret key and message. For single signatures, the most commonly recommended way to protect against nonce reuse is RFC6979 deterministic nonce generation. A uniformly random value can also be used safely if it is immediately discarded after use. Neither of these techniques can be applied directly to multi-signature protocols.

To use deterministic nonces safely in MuSig, a technique like MuSig-DN is necessary to prove that all participants correctly generate their deterministic nonces. Without this proof, a rogue signer can initiate two signing sessions for the same message but provide different nonces. Another signer who generates their nonce deterministically will generate two partial signatures for the same nonce with different effective messages, thus revealing their secret key to the rogue signer.

During the development of the MuSig2 specification, Dawid and I realized that the last signer to contribute a nonce could generate their nonce deterministically. I discussed this with Jonas Nick, who formalized it into the specification. For BitGo’s MuSig2 implementation, this deterministic signing mode is used with our HSMs (Hardware Security Modules) to enable them to execute MuSig2 signing statelessly.

When using random nonces with multi-round signing protocols, signers must consider how the secret nonces are stored between rounds. In single signatures, the secret nonce can be deleted in the same execution as it is created. If an attacker could clone a signer immediately after nonce creation but before providing nonces from the other signers, the signer could be tricked into producing multiple signatures for the same nonce but different effective messages. For this reason, it is recommended that signers carefully consider how their internal states can be accessed and exactly when secret nonces are deleted. When BitGo users sign with MuSig2 using the BitGo SDK, secret nonces are held within the MuSig-JS library, where they are deleted on access for signing.

The Specification Process

Our experience with implementing MuSig2 at BitGo shows that companies and individuals working in the Bitcoin space should take the time to review and contribute to the development of specifications that they intend to (or even hope to) implement. When we first reviewed the draft MuSig2 specification and started studying how best to integrate it into our signing systems, we considered various difficult methods to introduce stateful signing on our HSMs.

Fortunately, as I described the challenges to Dawid, he was confident that there was a way to use a deterministic nonce, and we eventually settled on the rough idea that one signer could be deterministic. When I later raised that idea to Jonas and explained the specific use case we were trying to enable, he recognized the value and formalized it into the specification.

Now other MuSig2 implementers can also take advantage of the flexibility offered by allowing one of their signers not to manage state. By reviewing (and implementing) the draft specification during its development, we were able to contribute to the specification and be ready to launch MuSig2 signing soon after the specification was formally published as BIP327.

MuSig and PSBTs

The PSBT (Partially Signed Bitcoin Transaction) format is intended to carry all information needed to sign a transaction between the parties (e.g., coordinator and signers in a simple case). The more information is needed for signing, the more valuable the format becomes. We examined the costs and benefits of expanding our existing API format with additional fields to facilitate MuSig2 signing vs. converting to PSBT. We settled on converting to PSBT format for transaction data interchange, and it’s been a huge success. It’s not widely known yet, but BitGo wallets (except those using MuSig2, see the next paragraph) can now integrate with hardware signing devices that support PSBTs.

There are not yet published PSBT fields for use in MuSig2 signing. For our implementation, we used proprietary fields that were based on a draft shared with us by Sanket. This is one of the little talked about benefits of the PSBT format - the ability to include whatever additional data might be needed for your custom transaction building or signing protocol in the same binary data format; with global, per-input, and per-output sections already defined. The PSBT specification separates the unsigned transaction from the scripts, signatures, and other data needed to eventually form a complete transaction. This separation can enable more efficient communication during the signing process. For example, our HSM can respond with a minimal PSBT including only its nonces or signatures, and they can be combined into the pre-signing PSBT easily.

Acknowledgements

Thanks to Jonas Nick and Sanket Kanjalkar at Blockstream; Dawid Ciężarkiewicz at Fedi; and Saravanan Mani, David Kaplan, and the rest of the team at BitGo.

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.

• ● Core Lightning 23.08rc2 is a release candidate for the next major version of this popular LN node implementation.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, and Bitcoin Inquisition.

• ● Bitcoin Core #27213 helps Bitcoin Core make and maintain connections to peers on a more diverse set of networks, reducing the risk of eclipse attacks in some situations. An eclipse attack occurs when a node is unable to connect to even a single honest peer, leaving it with dishonest peers who can give it a different set of blocks than the rest of the network. That can be used to persuade the node that certain transactions have been confirmed even though the rest of the network disagrees, potentially tricking the node operator into accepting bitcoins that they’ll never be able to spend. Increasing the diversity of connections can also help prevent accidental network partitions where peers on a small network become isolated from the main network and so fail to receive the latest blocks.

  The merged PR attempts to open a connection to at least one peer on each reachable network and will prevent the sole peer on any network from being automatically evicted.

• ● Bitcoin Core #28008 adds the encryption and decryption routines planned to be used for the implementation of the v2 transport protocol as specified in BIP324. Quoting from the pull request, the following ciphers and classes are added:

  • “The ChaCha20Poly1305 AEAD from RFC8439 section 2.8”

  • “The [Forward Secrecy] FSChaCha20 stream cipher as specified in BIP324, a rekeying wrapper around ChaCha20”

  • “The FSChaCha20Poly1305 AEAD as specified in BIP324, a rekeying wrapper around ChaCha20Poly1305”

  • “A BIP324Cipher class that encapsulates key agreement, key derivation, and stream ciphers and AEADs for BIP324 packet encoding”

• ● LDK #2308 allows a spender to include custom Tag-Length-Value (TLV) records in their payments which receivers using LDK or a compatible implementation can now extract from the payment. This can make it easy to send custom data and metadata with a payment.