Destination Address Anonymization in Bitcoin

[Sergio_Demian_Lerner]

This is one of the ideas of APPECoin that can be directly applied to Bitcoin.

When you send a payment to the public address of a merchant, hackers can detect that one of your coins are being sent to that merchant. This is because Bitcoin is not truly anonymous (please do not discuss this fact here, as it has been already debated many times!). For example, your IP can be traced to your one of your Bitcoin addresses, and payments can also be traced with some confidence.

But if you want to cryptographically hide this information then you can do one of the following things:

1 - Contact the merchant privately, ask for a new public address specially generated for you, and send the payment to that address.
(a previous private contact is needed, and the communication must be authenticated or an active attacker may steal your coins, in a man-in-the-middle attack)

2 - Generate a new key pair, send the coins to the public address generated, send the keypair privately to the merchant, wait for the merchant to re-transfer the coins to a new private address.  (two transactions are needed, and the communication must be authenticated or a passive attacker may steal your coins)

There are different ways of doing that, with a method I called Destination Address Anonymization (DAA):

3- Take the merchant public key and "encrypt" it using a special encryption method. Send the coins to that encrypted public address. Send the encryption key privately to the merchant (no authentication is needed, since a passive attacker may only trace you but NOT steal your coins)

4- The merchant has, apart from the signing keys, an keypair suitable for encryption (ECIES or ElGamal), and publishes the encryption public key.  The method is similar to 3 but instead of sending the key in a private communication, you encrypt it using the encryption public key and put it in the script as a message to ignore ("<message> OP_DROP"). The merchant must scan all transactions for the ones that go to himself, trying to decrypt each message.

As previously said, both new methods require an EC public key "encryption", and this is very simple. Suppose the merchant has a key pair suitable for elliptic curve cryptography, consisting of a private key dA and a public key QA (where QA = dA * G). Then for a randomly selected integer in k the interval [1, n-1]). A new keypair can be generated by multiplying both keys by k (k*QA is the public key of the private key k*dA). k is the anonymization key.

So the main different between DAA method 3 and method 1 is that DAA m3 requires user-merchant communication after the payment without authentication, and method 1 requires authenticated communication before the payment is done.

DAA method 4 requires no private communication, but requires a bit more computations in the receiver application.

Best regards,
 Sergio.

[1715034506]

1715034506

[1715034506]

1715034506

[1715034506]

1715034506

[1715034506]

1715034506

[1715034506]

1715034506

[Sergio_Demian_Lerner]

(copied from another thread)

A standard merchant practice is to give each client an unique address to track transactions and provide anonymity. With Destination Address Anonymization you don't need to. You can give each client an unique number k. This has the additional benefit that your address is always the same and the user can save it in his address book, as normal. (the client application automatically must multiply the pubkey with k while building the tx).

Another advantage is that merchants just need to securely backup one private key (k values can be stored with much less security)

[TangibleCryptography]

As a merchant I don't really see those as useful advantages for the increased complexity.

You say "you don't have to give unique addresses" .... "you just need to give out unique k".  Well that still requires matching address/k against user/profiles/orders.  Unique addresses work with all clients (even psuedo clients like exchange accounts).  The idea of employing a system that even in the future would only work on <100% of clients/customers doesn't have much appeal and I really don't see an advantage.   The issue of backing up single key vs multiple keys is equally a non-issue.  10,000 keypairs is <2 MB. 

So a giant coin vs academic advantages.

[Sergio_Demian_Lerner]

As a merchant I don't really see those as useful advantages for the increased complexity.
The idea of employing a system that even in the future would only work on <100% of clients/customers doesn't have much appeal

I understand your point. DAA can only be really useful if it's implemented in all clients. But it brings no backward-compatibility problems so it can be implemented now, and begin to be used in 6 months, when more than 80% of the network will be using the new version.

Also you can provide both methods, so users using the DAA-enabled versions will benefit from a single address per merchant in the address book.

Best regards TangibleCryptography and thank you for opinion!