Well, d is an EC point hashed to an integer. So it can be implemented this way:

d=hash(A*c)=hash(C*a)
E=B+G*d
e=b+d

Here, hash is any hash function, and G is the base point.
Alternatively, a different key derivation function can be used:

E=B*d
e=b*d

I hope it's clearer now.

To compute d an attacker would need to know either a or c. None of them is public.
I define d=A*c=C*a. The fact that it's hard to compute d from A and C is the basis of Diffie–Hellman key agreement protocol.

Not exactly. Everyone would be able to see that something is embedded in the input script. In my proposal, nothing reveals that the transaction is in any way different from an ordinary pay-to-address transaction.

That's the whole point. A person who wants to receive donations doesn't have to set up a server for out-of-band communication. He only needs to publish an address. This also means that it won't be necessary to keep multiple keys in a wallet. One key would be enough.

My proposal doesn't require sending anything privately. All the necessary information is contained in the transaction itself. At the same time, the transaction looks exactly like the ordinary send-to-address transaction.

If everyone uses this scheme, then it would appear that each address ever received at most one transaction. Every transactions would have a unique address. However, if someone sends money twice from the same normal address to the same proposed address, then destination normal address will also be the same. But these coins are tied to each other anyway.

Currently, if someone publishes his Bitcoin address (to receive donations, for example), anyone can see how much money he got. I propose a protocol which can be used to receive donations without revealing all payments to everyone. A person who wishes to receive money would generate 3 keys:
1. Public key can be used to send money to the person, but not to see when others send money to him.
2. Semi-private key can be used to see all incoming transactions, but not spend them.
3. Private key is necessary to spend the money.
It is expected that the user will publish his public key, keep hist semi-private key on his online computer, and keep his private key offline.

Implementation
I will use lower case letters to denote ECDSA private keys and corresponding upper case letters to denote corresponding public keys.
Creating an address: to create an address, a user generates to pairs of ECDSA keys. Let's call them (a, A) and (b, B). Then, (A, B) is a public key, (a, B) is a semi-private key, and (a, b) is a private key.
Sending money: suppose that someone wants to send money to key (A, B), and some of it is currently owned by key C. He performs Diffie–Hellman key exchange between keys A and C to generate a shared secret d=A*c. Then he uses a type 2 key derivation function (used in type 2 deterministic wallets) to generate a new public key E from B and d. He than sends money to an address generated from E. Note that C must appear in one of the inputs.
Receiving money: on the receiving side, the user scans all transactions to see if they match his semi-private key (a, B). To do so, he iterates over all inputs that match send-to-address template. Let C be a key that appears in one of such inputs. He computes d=C*a and E. If E matches the address the money was sent to, then this money was sent to him.
Spending money: to generate private key e, the user generates d as before and derives e from b and d.

Why this is useful?
It would be able to publish an address such that no one would be able to see how much money was received.
If someone wants to send money owned by multiple keys, he can send it in multiple transactions that can't be linked to each other.
Finally, users won't need to have many addresses. They can send change to themselves using the same procedure.

The protocol proposed there has several shortcomings. Firstly, it assumes that merchant's web server would not be compromised. Mike Hearn said that the server needs to have access to SSL private key, so if it is compromised, the game is over. However, this is not true: SSL termination can be performed on a machine different from the one running the web server. Even if it is done on the same machine, web applications are typically run with limited permissions, so they can't access SSL private key.

However, in the proposed payment protocol, an application running on the server needs access to private key to be able to sign PaymentRequests. If this application is compromised, so is the key.

Secondly, this protocol can't be used securely with offline wallet because Payment structure is not signed so it can be modified by compromised customer's online computer. Modifications to refund_to attribute seem the most dangerous. Also, a merchant can reject the payment but still broadcast the transactions (possibly after some delay).

As far as I understand, thanke's proposal has none of these shortcomings.

Also, it doesn't depend on traditional PKI. Merchants may sign their master keys with SSL certificates, GPG certificates, or even both. So a normal customer can verify merchant's key using SSL certificate, but a paranoid customer, who doesn't trust governments and CAs but trusts GPG WOT, can verify the merchant's key using GPG.

Does anyone read this thread?

Hi. I am delighted to see how Bitcoin makes many things possible, such as bitcointip bot on reddit or just the ability to receive money from anyone without setting up merchant account.

Ещё это дурацкое ограничение на 1 пост в 6 минут...

Кстати, а это всех после поста перенаправляет в список тем? Надо бы пофиксить.

Ну да, вместо спама есть ветки вроде "Introduce yourself" на сотни страниц и прочий оффтоп.

Напомнило http://ithappens.ru/story/2671.