maaku
commented
2 years ago 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](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](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
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.
/cc @kanzure @jesseposner @maaku @wolfmcnally @kanzure