mimblewimble team mailing list archive

[Ignotus Peverell <igno.peverell@xxxxxxxxxxxxxx>]

Hi all,

Most of our transaction schemes, whether scriptless scripts for lightning [1], multisig [2] or more robust 2-party transactions [3] all rely on Schnorr signatures. So it would seem reasonable to drop standard ECDSA in favor of Schnorr as default.

However on the implementation side, things are less clear cut. I can count 4 different versions of libsecp256k1 (one on bitcoin-core, one under Blockstream Elements, one under Andrew's Rust binding and one in the Grin repo), 3 of which have some Schnorr support. I _think_ the Schnorr implementation there is enough to support most of what we have in mind, but we may need to expose a few more utility functions (similarly to what I had to do for Pedersen Commitments).

So I can see 2 strategies:
- Stick with ECDSA for now until Schnorr is brought back in the Bitcoin Core repo (which seems the best supported), then add Schnorr support.
- Clean up our version of secp256k1 to make it a bona-fide vendor branch, add what we need there (eventually merging back upstream if desired) and standardize on Schnorr. I'm not sure the Schnorr impl is still compatible with the latest Bitcoin Core secp256k1 tree though.

I have a slight preference on 2 as it seems it'd be a better starting base but it's a little more hazardous and I'd love others' opinions. If Andrew or Peter could chime in on what would work best with the libsecp256k1(-zkp or not) plan it'd be really helpful as well.

- Igno

[1] https://lists.launchpad.net/mimblewimble/msg00086.html
[2] https://lists.launchpad.net/mimblewimble/msg00047.html
[3] https://lists.launchpad.net/mimblewimble/msg00087.html