Topic: [PROPOSAL] Untrackable addresses (Read 2519 times)

That's very neat, thanks. I suggest we write this up on the wiki somewhere so it isn't lost.

I want to see this developed further.

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.

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.

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.

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.

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.

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.

Yes, each user should have two different keypairs. And so a pubkey specifically published for encryption.

Couldn't you then decrypt this by testing all known public keys against each message?

The proposed method seems stronger to me.

Destination Address Randomization (DAR) solves this problem.

See http://bitslog.wordpress.com/2012/08/06/destination-address-anonymization-in-bitcoin/

The simple idea is to send the money to a multiple of the public key, and send the factor privately.

You can also send the factor encrypted with the recipient public key, embedded in the input script. This way it works exactly like your proposal.

I agree that for some cases, like anonymous donations, where you don't want any out-of-band communication to occur a scheme such as this would be nice.

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.