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
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://help.launchpad.net/ListHelp
