Quote from: caedes on October 30, 2014, 08:43:37 PM

vout_priv = sha256((scan_pubkey + prev_hash + vout + index).decode('hex'))

maybe you want scan_privkey instead of pubkey there otherwise the secret is public...

Code:

address_point = ECaddition(ECaddition(spend_pubkey, shared_secret_pub), vout_pub)

spend_pubkey = public
shared_secret_pub = private
vout_pub = public

Since the shared_secret_pub is already private (as it is the scan_privkey x Ephem_pubkey (or vice versa)) there is no need to have the vout_pub be secret.

The vout_pub only serves the purpose of removing the possibility of address reuse when sending multiple outputs to the same stealth address.

Not to mention that if you used scan_privkey, the sender would not be able to calculate the address's point.

Back to OT, I have been working on this sporadically, and a lot of security concerns arise from allowing private keys to stay in memory for longer than necessary...

I was thinking of other solutions... one of which would involve using the k value (the one used to generate the r value of the signature) with the scan pubkey to generate the shared secret... this way the receiver would multiply his scan privkey with the r value to get the shared secret... the problem with this is that it would mess with the deterministic signatures of Electrum. (you need the final tx to be signed in order to be a truly deterministic signature... I think that replacing the output script with the hex representation of the stealth address for the k generation, and this should be sufficient... but the security implications of such tomfoolery is beyond my scope of studies)

I guess the best way to deal with it is:
1. Move to create a new standard script template that can accommodate stealth in one output.
2. Just hope everyone uses stealth to lower the standing out of OP_RETURN stealth on the blockchain.

Maybe I'm just over-thinking things...