Signing support for P2TR outputs

[GambolingPangolin]

I would like to contribute P2TR signing functionality to the ecosystem. Ultimately this relies on algorithms that are part of libsecp256k1 master, but behind a flag. Most Linux distributions ship a version of libsecp256k1 without those algorithms. (The version in nixpkgs-unstable does ship BIP340 signing support.)

There are three options as I see it.

• Add BIP340 signature bindings to haskell-secp256k1 and taproot signing support to haskoin-core. We would need to make sure that users are not surprised at link time if their version of libsecp256k1 does not support BIP 34x. This means creating a flag in each package, so the user has to opt into BIP 34x.
• Create a special package for BIP34x. Users of this package will need to ensure that their project links against a suitable version of libsecp256k1.
• Vendor libsecp256k1. This would give us complete control over what C routines are available to our Haskell code. IIUC haskell-secp256k1 used to do this, but it was difficult and fragile in practice.

I think the second option is the simplest and best. Once BIP340 support becomes widely available in libsecp256k1 in OS repositories, we can move the code into haskell-secp256k1 and haskoin-core.

[GambolingPangolin]

@jprupp @wraithm what do you think?

[wraithm]

What would the special package look like? I don't quite see the full vision for the second option. Could you flesh that out for me?

[jprupp]

I was thinking of the same question. How would that package work?

Is it possible to hide the P2TR code behind a compile-time flag? As long as a shell script is provided that will run the tests with and without flags, using the appropriate Nix package, without extra hassle, such that anyone can run it.

[GambolingPangolin]

Special package

The special package would require a version of libsecp256k1 with the BIP340 stuff enabled. It would have bindings to the signing and verification logic under secp256k1_schnorrsig.h. This entails duplicating some of the non-public code in haskell-secp256k1, but I think that's ok. It would also expose an API for creating TxSignature values for inclusion in P2TR witnesses and support for key-path and basic script path spends (CHECKSIG and CHECKMULTISIG).

Use flags

I think we can hide entire modules behind package flags. So if we were to go that route, we could have a flag --bip340 that would

• Make an additional module Haskoin.Transaction.Taproot.Sign available
• Set a similar flag on haskell-secp256k1 exposing the secp256k1_schnorrsig.h bindings

I think the best testing strategy would be to have one test script that runs all the tests against the Nix package. Since we are talking about adding bindings under a flag, testing with the flag indeed tests the base set of exports without the flag.

[GambolingPangolin]

I made a PoC sidecar package. It currently does not work, but should give you an idea of what the package would include. You can see it at https://github.com/GambolingPangolin/bitcoin-taproot .

[NCrashed]

As an active user of the library (ergvein wallet) I consider the flag option optimal. Also, if there would be any tasks that I can help with, I am in. We want to add taproot support to the wallet.

[GambolingPangolin]

@NCrashed good to hear your thoughts. I'll go ahead and create some branches that put the signing code behind flags, so everyone can have a look at that.

[wraithm]

I also agree that the flag option is the most intuitive and straightforward one for the user.

…

On Tue, Nov 16, 2021, 07:21 Ian Shipman ***@***.***> wrote: @NCrashed <https://github.com/NCrashed> good to hear your thoughts. I'll go ahead and create some branches that put the signing code behind flags, so everyone can have a look at that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#405 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALRLUODBO6BX5XT2BM5PL3UMJZHJANCNFSM5H3KJGVQ> .