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.
How Merchants can use DAA
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). But DAA can only be really useful if it’s implemented in all clients. As it brings no backward-compatibility problems 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 merchant can provide both methods, so users using the DAA-enabled versions will benefit from a single address per merchant in the address book.
Using DAA for Escrow without third parties
One of the uses of DAA (Destination Address Anonymization) is to create an p2p escrow without the need for third parties.
Suppose A wants to send X coins to B, and B in return must send Y virtual goods of some kind. B public address is Bpub
First A commits to sending X coins by choosing a random k and sending the money to the address Q=k*Bpub.
Then A creates a simple ZNP (zero knowledge proof) that Q is indeed the encryption of Bpub under a known k.
This can be done with the cut-and-choose method and the Fiat-Shamir heuristic to create a non-interactive proof.
(if you want more information of this method please ask me, it’s very simple and a standard practice)
Then B knows that A has committed to the payment (A cannot get the money back and B cannot take it, so the money is blocked).
B sends the virtual goods to A. A releases the money by sending the value k to B.
I know this is not the only way to do an escrow in Bitcoin (and maybe not the best way), but is a new useful way.
Best regards!
Bitslog 