200 sats \ 1 reply \ @conduition OP 3 Jul 2023 \ parent \ on: A Dive Into the Math Behind Bitcoin Schnorr Signatures bitcoin
the nice thing about them is the key is embedded in them so you take the message hash, combine with the signature, and out comes the public key
You can also do that with Schnorr! (although not with Key-Prefixed Schnorr, which is used in Bitcoin)
In Bitcoin, e = H(R || D || m), but if you are free to design the protocol you could just as easily make this e = H(R || m) like with canonical Schnorr signatures.
If e = H(R || m), you can compute e without knowing the pubkey in advance. Then you can recover the public key which created the signature like so.
  s = r + e*d
s*G = R + e*D
e*D = s*G - R
  D = (s*G - R) / e
(Dividing by e is the same as multiplying by the multiplicative inverse of e)
oh yeah, btw, I borrowed a bit of the schnorr signature protocol to create a rolling fast private key generator, it uses two private keys, the base and the secondary key, which is scalar multiplied with the base to derive a new base for the next message key. The private keys used by senders with the public key of the receiver are changed for every single message, since the private key is not needed to decode it, the receiver's private key can do it.
Interesting, what's the purpose of such a scheme?
write
preview
0 sats \ 0 replies \ @l0k18 3 Jul 2023
So that recoverable pubkey can be hiding in the 64 bytes? ok I need to look at this because of the reduction in computation complexity.
The cloak is to make it impossible for anyone without the correct private key to acquire the ECDH secret of a message. They only have one half, the public key of the sender, which is a different key derived via scalar addition for each packet (and message, or onion, if you prefer).
The packet dispatch between peers is of uniform sized packets and in any given stream there can be millions of different looking cloaks (2^24) and the key changes are done far more frequently than this. Traffic between peers is a mass of these identical looking messages that you can't separate without knowing secrets.
The messages that are broken up into the packets also have these keys in the onion layers of encryption, again each one has a new secret key giving a different public key each time.
Really just obeying the rules of how to use EC. Never the same hash to be signed twice. Easy to guarantee it with a random 8 byte nonce in every message.
reply