tl;dr: the signer must negate the key if it is odd, before doing ECDSA signatures or PGP ECDH key derivation (pgp uses ECDSA ECDH as part of the message header secrets for encrypting the actual message secret of the message)
Discussion
My concern is that requires a fork of GPG. I don't like forking gnu apps XD or convincing the gray beards that it's desired to play nicely with our sandbox when they are never going to trust schnorr sigs. I'm over convincing legacy institutions.
that's why i'm saying, assume the 2 prefix, and the signer should negate the secret to sign with ecdsa/derive ecdh, that is the smallest change set required
strictly speaking, a key generator for BIP-340 is supposed to negate the secret if it has a 3 - but it doesn't have to for nostr so many nsecs make odd ecdsa Y coordinates
Right I'm aware of that but how do we implement that where GPG supports signing and verifying using an secp256k1 key
oh, going the other way?
i've mentioned this before but not actually put it to a proposal
needs a new tag, i think "s" makes sense, and it would be formatted thus:
`["s","
or something like that
the PGP can't really sign correctly for nostr authentication though, that's a whole other can of worms
i've talked about this idea before, but the thing is that verifiers have to support the signature verification so it really needs to be added to a NIP if you want to enable it to replace the BIP-340 signatures outright
i'm pretty sure adding a new signature algorithm isn't that hard to do for gpg... but i don't know what's involved exactly
i would think it shouldn't be that much harder than creating helpers for git
but anyway, you are the C expert, this is part of the reason why i never got into C programming... it is a very brittle and hard to extend language
having said that, it would be trivial to enable a relay to accept ecdsa signatures if there was a conventional signal that was the case... maybe better to just do "S" tag with a signature identifier - `curve-signature` i wouldn't bother messing with the hash function though, there's nothing wrong with SHA256
that brings up the other point too... the event has to be canonical form, the array with the positional fields, and zero first value, i think you can make pgp use SHA256, but that's the event ID source so that is how it has to be presented to pgp
to be perfectly honest, i think it would be simpler to simply make a standard C language pgp-like program that has the json hash generation, BIP340 signatures/ecdh and simply make it a drop-in for all the required args so you can literally just give it the secret key in the same form as would be for ECDSA but it recognises the json, rearranges that, hashes it and then signs on that hash and then generates the wire format output