Quote from: abacabadabacaba on December 17, 2012, 04:56:02 PM

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 DiffieHellman 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.

Erm. What exactly is stopping an attacker from doing the same math between the pubkey of each input and the list of known public keys to recover all of the transactions?

A, B and C are all publicly known, which means that d is known, which means that E is known. The attacker still can't spend them because b is unknown, but he can sure see them.

P.S. Diffie-Hellman is an online protocol. It requires (bidirectional) active participation from both parties.