Right I'm aware of that but how do we implement that where GPG supports signing and verifying using an secp256k1 key
Discussion
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