Keys are 64 bytes, right? So why does the golang implementation of secp256k1 want a 65 byte public key?
https://github.com/decred/dcrd/blob/master/dcrec/secp256k1/pubkey.go
Discussion
1 byte for good luck?
64 bytes is raw, 65 includes a prefix to say what kind of key it is apparently
no, 64 bytes only, it's from BIP-340
that extra byte is not going to be correct
also, no, an uncompressed ECDSA key is 64 bytes, a compressed key has only the sign of the second coordinate, only two are really needed, which is 33 bytes
65 bytes is not the length, that is a typical signature, i could be wrong, maybe there is a type byte for uncompressed ones, i never deal in uncompressed signatures as they aren't used in bitcoin, lightning or nostr
anyhow, point is if it's uncompressed pubkey then it's redundant to include any more than the 257th bit, the sign bit from the second coordinate
*uncompressed keys
that's not the one you use
and see, the abomination...
decred
here is the proper version, i cleaned all of that up from btcd:
you need to use the functions in the "schnorr" folder, in my code it is used many times so you can also see there: https://github.com/Hubmakerlabs/replicatr - in the pkg/nostr folder is all the nostr things including event handling, in the event folder is shown the correct method to make and verify BIP-340 signatures and pubkeys
the readme is slightly incorrect also
this version of it DOES fully pass all of the BIP-340 tests, there was an extra 4 that involve variable length messages and it passes them too, i tried to get this fixed in the original in btcd/btcutil but roasbeef said "it wasn't necessary to complete" the changes were simple anyhow, and my library is fully compliant to BIP340, even if you are only ever gonna use it on 32 byte hashes
btw, don't depend on replicatr's pkg/nostr folder yet, it's not stablised, for example just now i refactored the inconsistently ordered compute shared secret function in nip4, as in my library and in most ways of discussing ECDH you say My Secret Key, Your Public Key and the nip4 fiatjaf fiasco has it backwards, there's a lot of other little subtle things i change like in my ec library you can use the more logical and easier to shorten "secret key" instead of "private key" versus "public key" that pattern doesn't leave you an option for shortening it, sk/pk is more logical which derives from secret/public
i have yet to clean up that nip44 encryption/message formatting scheme yet, it's horribly written, as the audit points out it does no bounds checking on the keys derived out of the hex, not even checking the hex is the right length (which would be sufficient and make more sense to check before doing the work of decoding the hex)
i just am directing you to look at it because it will show you how to do the BIP340 nostr style signatures correctly
my work is not finished yet but it has been a while since i've made more than two small changes in that pkg/nostr folder in a week, so i think once i hit my current milestone target for an MVP relay i'll be pushing it out into its own package on my git hosting
another thing you need to know as a go programmer, if you are writing an app, and developing a general purpose library or ten at the same time, don't separate them until the libraries are unchanging for a substantial amount of time because it's a huge pain to keep the go modules synced up
the keys are 33 bytes for standard ECDSA public keys and 32 bytes for BIP340 compliant pubkeys, they have the extra bit (it's an extra byte just for 1 bit) as it uses a funny scheme which essentially shaves one bit of security for a much neater format, the way it works is that if it comes out odd (the first, least significant bit) then it inverts (bitwise NOT) and then it can omit that bit and it's a neat 32 bytes, or equal to 4x64 bit words
the schnorr signatures are 64 bytes long, and ecdsa signatures can be anywhere between 62 and 67, iirc, but they are not a consistent length unlike Schnorr, and usually they are 65 bytes, but not always
the reason for the change is that computing it and splicing together protocol messages is easier if you don't have to overflow into another 8 bit word... iirc, the actual modular arithmetic done for schnorr signatures and public keys is done on 4x64bit words, you can see this if you follow the computations into the back end, inside the key is a pair of ModNScalar i forget exactly, i haven't honestly gone that deep into it except to know that you can do some neat things other than just signatures and pubkeys with them, like the scheme bitcoin uses that recovers the key instead of checking a key matches a signature - this was done to save space - and it tests the same because you compare your pubkey with the key it generates, it generates a key either way but it has to match the one you want - but never mind that, that's ancient, NIST/NSA ECDSA bullcrap because they were too cheap to buy out schnorr for his far more efficient algorithm patent