Quote from: urian on June 29, 2013, 08:26:59 AM

Hello,
here is a proposal for a slight protocol modification, which could solve the follwing two issues related to anonymity:

1. In order make an anonymous transaction the receiver of the money must generate a new public/private key pair.
This can get cumbersome if the receiver is, for instance, a web shop merchant. Here it would be preferable if the merchant could post a fixed public key on his web site.
But on the other hand, neither the merchant nor the buyer wants that everybody can see all transactions to the web shop.

2. It is a good idea to keep the secret keys in a secure, tamper-resistant wallet (e.g. a smart card). But it is unfortunate to store many secret keys on a resource limited device.
One solution would be to derive all private keys from a master secret. But than you have to maintain a database associating your private keys with their derivation data.

The solution to both issues stems from the following simple oberservation:
An ECC public(P)/private(s) key pair is related by the formula
P = G*s, where G is the fixed generator point of the curve.
The generator point G has been choosen by the curve constructor(CERTICOM). This point is only a random point on the curve. Any other point on the curve would be an equally well generator point.
If we multiply G and P by the same random number r, we get
P' = P*r
G' = G*r
and it follows that
P' = G'*s
With this trick we get a new public key P' an a new generator G' to the same secret key s.

Therefore we redefine a public key by the pair of points (G, P).
(i.e. the generator of the curve is no longer fixed but part of the public key)

Due to the Decicional-Diffie-Hellman assumption, two public keys (G,P) and (G',P') for the same private key s cannot be associated.
(i.e. we get untraceability)

The basic protocol flow would be as follows:
1. The receiver posts some randomly choosen public key (G,P) for his fixed secret key s on his web page.
2. The sender blinds the public key by multiplying it with a random number r and calculates (G',P')= (G*r, P*r)
3. The sender generates a transcript. (The hash of the public key must now consist of two points G', P')
4. The sender sends the transcript and the blinded public key (G', P') to the receiver.

I suppose the modifications to the bitcoin protocol would be moderate.
I can also see any security and performance impact.

I don't see how this would increase anonymity
This would require OP_CONCATENATE which is deactivated
Also, https://bitcointalk.org/index.php?topic=232787.0