Adding Schnorr to Electron Cash

gistfile1.md

Thankfully, the hard work has been done by ABC and Calin Culianu, who ported the entire library into Electron Cash. Now the question is how to actually implement?

Adding Schnorr to Electron Cash

Currently, the sign() function in lib/transaction.py creates a signature using ECDSA-related objects like MySigningKey class from bitcoin.py, and sign_digest_deterministic, which I believe operates on a private key object returned from the ecdsa library.

Instead of this, the sign() function should directly call into secp256k1/src/modules/schnorr/secp256k1_schnorr_sign using the message and private key.

The has_secp variable should be already set from init and we can check that to handle errors based on the missing module. Although not sure if something special is required for wrong versions of libsec (linux users).

This is envisioned as an optional setting (to use Schnorr instead of ECDSA) either on the send tab or in the preferences.

You may want to clarify in this gist:

• There are two extant variants of libsecp256k1 -- the core one (which is the one you get off the libsecp256k1 repo from sipa/Peter Wiulle), and the Bitcoin-ABC variant.
• The core one USED to have schnorr but they took it out.
• The bitcoin ABC one has schnorr, tested, working.

EC needs to distinguish which lib it's using.

Also, I would not directly call into libsecp256k1. We want the call to be abstracted out. Probably a class should be provided in bitcoin.py or wherever that says "SchnorrSign(tx, input)" or something like that -- and it handles dispatching the call down further.

Potentially there would be 3 implementations we would provide:

• libsecp256k1 from BitcoinABC (preferred)
• OpenSSl 1.0 based Schnorr (if ths lib is found on the system) -- this is native and still fast
• Native Python (not sure how to do this but Mark Lundeberg said he could probably implement someting in Python). <--- this last one perhaps is optional for us now.

note to self:

https://hastebin.com/ahatubucog.rb