Quote from: YarkoL on June 10, 2015, 09:00:21 PM

Ok, I see it now. I think that (using Q X e as an encryption key) would work in principle,
but you'd have to test it in practice. Probably there's some hitch or two, otherwise
this would have superseded Diffie-Hellman already in computing stealth keys. Maybe
it comes down to the fact that this requires an additional layer of encryption, whereas the
original method works just as well and very elegantly too.

ECDH is still used in my second scenario to calculate the shared secret. It's not really an improvement on stealth payments, it's just an alternate way to do it. I was trying to think of a way to do it without having to generate a new ephem keypair for each stealth payment. In my second scenario the ephem keypair is not generated on the fly, the payer will just use the keypair associated with the address they are withdrawing coins from. The resulting Q' is still unique each time because the second shared secret is a randomly generated value. Doing it that way means the payer doesn't need to include their public key as metadata because it can be derived from the signature, and the only metadata we need to store is the encrypted random shared secret. That may be a better approach for Cryptonite because the tx message field is limited in size.