Quote from: bitfreak! on June 11, 2015, 09:14:30 AM

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.

I read some more on this, and it appears that a scenario where you do not generate ephem keys on the fly
belongs under the category of static (non-ephemeral) DH key exchange, which is not considered as secure,
since if the keypair of the payee gets compromised, the payer(s) get exposed as well.

http://security.stackexchange.com/questions/33233/ecdh-and-forward-secrecy

I think the original idea of transmitting a random number would therefore
work better. In fact, in the MillenniumCoin (script-based anonymity) you initiate
transactions by doing an off-chain exchange of a random nonce between the nodes,
so I was deprived of about one hour of much-needed sleep last night as my mind
started to mull over the possibilities Wink