INVESTIGATION: Staging branch for experimental cryptography for the secp256k1 library?

[ChristopherA]

There is a need for a reasonable long-term "staging" ground branch for sep256k1 related crypto that might ultimately be brought into the bitcoin ecosystem, not just at the L1 level but also at L2.

The problem is that Bitcoin Core's secp256k1 library tends to not merge branches until they are extremely mature and are ready to use in an upcoming L1 release.

Until recently, Blockstream's Elements [secp256k1-zkp] has unofficially served this purpose, with early versions of Segwit, Schnorr, Taproot, etc. being first implemented there first and ultimately merged into the upstream master. Most recently, Musig 2 has been implemented in Elements -zkp branch and is under evaluation for merging upstream, and work toward quorum threshold FROST has started on Elements -zkp.

However, Blockstream and the Elements team are not sure that their Elements -zkp branch should be used this way, unless it is specifically for a Blockstream project. This causes problems as there are other important cryptographic functions that need tight integration with the secp256k1 library, but are not currently important to Blockstream, that ought to be supported by the larger community. Currently having to support multiple branches of the secp256k1 library is problematic.

I'm not sure if the right answer is to persuade Blockstream to broaden their support of other cryptographic code into Elements -zkp, or to try to build community support in the broader bitcoin-core community for an official long-term experimental staging branch hosted there, or if this is something that Blockchain Commons should try to offer the ecosystem. In the latter case, we don't have a sufficient level of cryptographic engineers to support a project like this, but we could possibly encourage some to commit to support a project like this hosted by Blockchain Commons.

• Discussion about this in [Bitcoin Core issues](https://github.com/bitcoin-core/secp256k1/issues/997#issuecomment-949463114]
• Discussion about this topic at Elements issues
• Related:
  • Adapter Signatures for Schnorr
  • VRF for secp256k1

/cc @kanzure @jesseposner @maaku @wolfmcnally @kanzure

[maaku]

I think your suggested scope is too small, if this is to become a Blockchain Commons project. There is a need for a library which handles all the sorts of things that are generally useful to do with secp256k1 curves. This potentially includes more than just things which might be of useful to bitcoin in the future.

…

On May 7, 2022, at 6:24 PM, Christopher Allen ***@***.***> wrote:  There is a need for a reasonable long-term "staging" ground branch for sep256k1 related crypto that might ultimately be brought into the bitcoin ecosystem, not just at the L1 level but also at L2. The problem is that Bitcoin Core's secp256k1 library tends to not merge branches until they are extremely mature and are ready to use in an upcoming L1 release. Until recently, Blockstream's Elements [secp256k1-zkp] has unofficially served this purpose, with early versions of Segwit, Schnorr, Taproot, etc. being first implemented there first and ultimately merged into the upstream master. Most recently, Musig 2 has been implemented in Elements -zkp branch and is under evaluation for merging upstream, and work toward quorum threshold FROST has started on Elements -zkp. However, Blockstream and the Elements team are not sure that their Elements -zkp branch should be used this way, unless it is specifically for a Blockstream project. This causes problems as there are other important cryptographic functions that need tight integration with the secp256k1 library, but are not currently important to Blockstream, that ought to be supported by the larger community. Currently having to support multiple branches of the secp256k1 library is problematic. I'm not sure if the right answer is to persuade Blockstream to broaden their support of other cryptographic code into Elements -zkp, or to try to build community support in the broader bitcoin-core community for an official long-term experimental staging branch hosted there, or if this is something that Blockchain Commons should try to offer the ecosystem. In the latter case, we don't have a sufficient level of cryptographic engineers to support a project like this, but we could possibly encourage some to commit to support a project like this hosted by Blockchain Commons. Discussion about this in [Bitcoin Core issues](bitcoin-core/secp256k1#997 (comment)] Discussion about this topic at Elements issues Related: Adapter Signatures for Schnorr [VRF for secp256k1](https://github.com/aergoio/secp256k1-vrf /cc @kanzure @jesseposner @maaku @wolfmcnally @kanzure — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.

[wolfmcnally]

If libsecp256k1-zkp is a fork of libsecp256k1, then it might make sense to have a well-maintained fork of libsecp256k1-zkp that can continue to pull from it as its upstream but also include a much wider variety of constructs contributed by the community. If any of the constructs prove more widely useful, they could be cherrypicked by upstream projects, but projects that need these less proven or more niche constructs could use this fork without giving up any of the advantages of the upstream repos.

[ChristopherA]

The problem with forking -zkp is that there is a lot of code specific to Blockstream Liquid or other Blockstream projects that we may not want to support.

[wolfmcnally]

If we fork libsecp256k1 directly then we'd have to cherry pick (and maintain) the parts of -zkp that we do want. If our fork is more about providing a wide range of functionality over providing support for a specific project like BitcoinCore or Elements, then I don't think we'd need to worry about bringing along the code that Blockstream uses; other people may find it useful too. I expect that maintaining it would basically involve pulling from -zkp upstream and making sure there are no regressions.