consider adding musig2 and adaptor signatures to the bitcoin::schnorr module

[conduition]

One of the most useful properties of the TapRoot upgrade - and the support for Schnorr signatures which came along with it - is the fact that we can now use simple trustless key aggregation protocols like MuSig, and powerful scriptless contract primitives like Adaptor Signatures (AKA verifiably encrypted signatures).

I don't see any mention of MuSig or Adaptor Signatures in the code, issues, or PRs in this repo. I'd like to propose we add these tools, as they are very important building blocks for modern bitcoin devs.

As for the best road to this goal, I'd be happy to shamelessly shill my own MuSig implementation, for which I recently finished a draft PR adding adaptor signatures. It's fully compatible with the current draft of BIP327, and doesn't pull in any significant new dependencies (it uses the secp256k1 crate for curve math).

We could also use @LLFourn's schnorr_fun crate, although this would necessitate switching to secp256kfun for curve math.

[LLFourn]

Thanks for sharing your implementation @conduition. I'd expect the approach here would be to use the libsecp256k1 implementation via ffi when it's available. I can't recall whether the libsecp256k1-zkp implementation was going to move into libsecp256k1 proper though. Until then isn't it easy enough to just produce the signatures with your library and put them where they need to go?

[conduition]

I'd expect the approach here would be to use the libsecp256k1 implementation via ffi when it's available.

Once that's an option, i would definitely agree. Seems like it will probably take a while to become available though. There is ongoing discussion in this bitcoin core issue about adding musig to bitcoin core. Until that is resolved and a plan is resolved, upstream libsecp256k1 will probably not merge anything as they don't wanna jump the gun. More background reading.

Until then isn't it easy enough to just produce the signatures with your library and put them where they need to go?

I suppose so, yes, as long as you know what you're doing and read the docs. Keeping it separate from the rust-bitcoin crate is tidy, and works as long as your use-case is simple.

I suspect there are real-world use cases which would benefit from an integrated approach within rust-bitcoin. Here are a few examples of APIs which would be possible if rust-bitcoin integrated MuSig.

• An AggXpub type, representing an xpub composed of many pubkeys. Child keys can be derived either for individual signers (to verify partial sigs), or aggregated children to verify for the whole group. There is some related discussion here.
• Helper methods for constructing and spending m-of-n multisig tapscript outputs.
• First-class support for MuSig fields in PSBTs

This is off-topic somewhat, but on the matter of "put them where they need to go", there should really be an explicit method on Witness to push a taproot key-spend signature. I know it's as simple as witness.push(sig.serialize()), but unless you already know how taproot works, that's not obvious at all. I might have a go at that later. I'll follow up in #1470

[apoelstra]

Thanks for the issue! Will keep it open until we bring MuSig support in, but as @LLFourn says, we want to implement this via libsecp, even though that will take a while. We already have a dependency on libsecp and its maintainers, many rust-bitcoin maintainers have personal relationships with many libsecp maintainers, and libsecp gets very heavy review on account of being included in Bitcoin Core.

We simply don't have the bandwidth to bring a new crypto dependency online, especially for something as heavy as MuSig, which took multiple years of iteration for us to define a correct protocol with a safe API. (Though for noninteractive crypto I'd be much more open to the idea, see #1691.)

[conduition]

That's fair 👌 Thanks for the attention!