Use bip39/44/84 for keys rather than Scnorr

[arcbtc]

Can we use more industry standard key generation/derivation standards for now as Schnorr support is very limited, and it will halt the development of a lot of Nostr clients/relays?
Once Scnorr is more of a standard for key crypto, and there are plenty of libraries, the Nostr network could move to support it

[Jeffrey-P-McAteer]

FYI I plan on writing a Nostr client and relay in Rust, which has this library for Schnorr: https://docs.rs/schnorrkel/
If Nostr wants to support different key mechanisms than it will need to add that metadata to all messaging so a client built with Schnorr can tell the user "Oops, we havent implemented support for X yet!" instead of "this is an invalid signature".

[fiatjaf]

Sorry, I forgot to answer this.

The idea is to have a single signature scheme, multiple things would be crazy and create unnecessary complexity and incompatibility madness.

At first I wrote my basic client and relays using ECDSA, but then I thought Schnorr would be simpler and better and specially that it would be good because it supports an easy way to aggregate signatures, such that one Nostr entity could be controlled by multiple people with different keys and they would all need to sign and all that stuff -- so we get "team accounts" for free without having to add special support for this kind of thing in the protocol. So that's it, the stupid reason I chose Schnorr.

Also using the specified Schnorr scheme keys and signatures are a little smaller than ECDSA.

So unless someone points out an obvious flaw and weakness in my choice of Schnorr we should stick to it and never change.

[fiatjaf]

@Jeffrey-P-McAteer I don't understand cryptography, but I think that library will not work since the specified scheme is the one defined in BIP340 and that one seems to be for a different elliptic curve with different specifics.

There is this library that does the signatures we need: https://docs.rs/schnorr_fun/ (although I'm trying to understand if and how we can give it the message hash directly instead of the full message, but I don't understand Rust very well.)

And this one should add a more general way of doing Schnorr/BIP340 signatures anytime soon: https://crates.io/crates/secp256k1 (because it is a wrapper over a C library which added the functions we need recently).

This one may also add support anytime soon: https://lib.rs/crates/libsecp256k1, and it's pure Rust.

If none of the above work we can implement the signing and verification in the most naïve way. It's a simple matter of porting this code using the curve operations from https://lib.rs/crates/libsecp256k1.

[fiatjaf]

Ok, I just heard from the the maintainer of https://crates.io/crates/secp256k1 that BIP340 signatures support will be released "in the next day or two".

[arcbtc]

I have seen the light