In order for Bitcoin to function pseudonymously it's essential for addresses to be used in such a way that they are difficult to correlate based on the transactions in the blockchain. From the very beginning, developers have recommended as a best practice that addresses should be treated as single-use payment codes and never be reused. This solves half the problem, and it's the part that users have direct control over using existing clients. The other condition needed to stop addresses from being correlated is to never include outputs from different addresses as inputs to the same transaction. This is something that clients that care about privacy generally try to accomplish, but it's not always possible to do this, for example the case where no collection of inputs from the same address is large enough for the desired payment.
If my wallet consists of a 2 BTC unspent output at address A and a 3 BTC unspent output at address B and I desire to make a 4 BTC payment to address C, the only way to accomplish this in a single transaction is to use the outputs at A and B as inputs, with a 4 BTC output going to address C and a 1 BTC output going to change address D. Unfortunately this correlates A, B, and D in such a way that someone observing the blockchain can conclude with a high degree of certainty that the same individual controls all three addresses. This represents a permanent loss of financial privacy.
The only way to retain privacy in this situation is to ask the recipient to give me two destination addresses. Then I can make two transactions and broadcast them into the network a few seconds apart. This leaks far less information about which addresses I control into the blockchain and allows me to retain a higher degree of privacy.
The problem with that approach is that it's more difficult from an accounting perspective and an ease of payment perspective. Without HD wallets, the recipient finds it difficult to correlate multiple addresses with a single transaction, and it's more difficult to transmit the payment addresses to the sender. The recipient must either pregenerate multiple payment addresses just in case and send them all, or else they need some kind of negotiation step where the sender tells the recipient how many addresses they need.
HD wallets and extended public keys can entirely solve these problems, if we simply as a best practice that recipients of bitcoin transactions give the sender a unique extended public key for each transaction instead of giving them a (single) unique address.
HD-aware wallet software can use the extended public key as the unique index for associating blockchain transactions with, for example, an web site order in the same way they normally use a single bitcoin address, but by giving the user the capability to generate as many public keys as they want now the user can choose to protect their privacy by sending their payment in multiple transactions without requiring any explicit coordination between the sender and the recipient.
Another advantage of allowing the sender to generate an arbitrary number of public keys is that services which hold bitcoins for their users, such as Mt Gox, could lock an account's withdrawal addresses to the tree created by an extended public key, and still send the bitcoins to a unique address for each withdrawal. There's nothing stopping services like Mt Gox from implementing locked withdrawal addresses now, but doing so without HD wallets means that the users must sacrifice financial privacy in order to gain the security of knowing that a hacker who compromises their account can't withdraw their bitcoins to an arbitrary address. With HD wallets no compromise is necessary.
What needs to happen:Besides implementing BIP32 wallets in the clients, we need to extend the Bitcoin URI scheme to support extended public keys instead of single addresses. We also need a standard way of representing an extended public key in text form.
Once this is complete bitcoin-accepting businesses and payment processors need to implement support for extended public keys in their accounting and order processing systems, both to track provide buyers with extended public keys instead of single addresses and to add the ability to associate multiple payments to unique bitcoin addresses to the same business transaction.
Finally, clients need to have a privacy protecting mode where they will refuse to include outputs from different addresses as inputs to the same transaction, at the cost of incurring additional transaction fees. BIP32-aware clients should by default expect to store an extended public key with an address book entry, and automatically use unique receiving addresses when sending Bitcoins to a known entity. The use of bare addresses should be deprecated.
What you can do to help:
- Explain to the developers of your favorite Bitcoin client software how important your financial privacy is to you, and how properly-implemented BIP32 support can help you achieve it.
- Encourage the major bitcoin payment processors like BitPay, Coinbase, and BIPS to start including this capability into their systems.
- Once HD wallets become available in your bitcoin client of choice, protect your financial privacy by always giving out extended public keys instead of bitcoin addresses to the people who are sending you Bitcoins. Never reuse bitcoin addresses and ask every service you use to implement best practices for protecting financial privacy.