HD wallets and address reuse

Question

HD wallets create a series of addresses, and then when one address has received an input it will give you a new address that hasn't received inputs yet

So in the idea of you sending yourself bitcoin from an exchange, and having different addresses all the time on the exchange, and different addresses in your wallets, then an observer wouldn't be able to track the sum of all your funds.

But isn't this all undermined when you move a large amount of bitcoin and the transaction combines bitcoin from all of the addresses in that wallet?

How is that part avoided while retaining the ability to realistically send funds quickly and conveniently? I understand that it is possible to form a transaction to only use a certain address for sending, but ultimately there is still a third party with one address that I want to send bitcoin to. So I will have to use several of my addresses to get the appropriate balance.

This seems to completely undo my privacy. Not necessarily from blockchain analysis but by having records of a single address (such as from the exchange).

For instance, lets say an exchange gave over the user names to a government. The government then looks at all the addresses that user sent bitcoin to from the exchange. Then they simply look in the blockchain for that address and look to see where it was used again to combine bitcoin with other addresses, as this reveals that one person had the private keys to all those addresses used. Privacy undermined.

Solution? I can imagine a scenario where I could do one transaction at a time back to a different exchange, generating new addresses in my exchange wallet. Cumbersome. But for something like a bitpay payment, I don't see how this is practical, unless third parties also let me choose how many addresses they would generate for me.

Answer 1

As mentioned, I don't believe HD Wallets are relevant to this problem. Even with simple wallets combining inputs from multiple addresses proves that a single person owned all the addresses included. I'm not sure if this would meet your specific privacy needs, but it is at least a straightforward way of avoiding that problem:

Assume you have 4 addresses, A, B, C, and D. You want to send a transaction that requires funds from all 4 without proving that they were owned by the same person. You could generate a 4th address E and over the course of several days combine all the address values at a new address.

While the blockchain would show that the funds in E came from A-D, there wouldn't be any proof that A-D were owned by the same person, as they were never in a single transaction together, and it is feasible that 4 different people all transferred value to E, instead of the same person transferring value to E.

It seems feasible to write a client that follows that policy of never combining inputs from multiple addresses in a single transaction, which would at least allow plausible deniability. The user would be able to manage timeframes depending on their needs, so that the combination could occur over the period of an hour or a year, depending how soon they need the transaction. You could also add some intermediary steps to split things up a bit more and pass through a few extra addresses to make it slightly harder to follow.

Since it is a public ledger it really isn't a very anonymous system, and achieving anonymity is difficult without a mixer, but the biggest compromise to anonymity is connecting multiple addresses in a single input, so simply avoiding doing that will be helpful, but at the expense of convenience.

Answer 2

Privacy is one of the most common myths about Bitcoin. By default, it does not provide anonymity, for many reasons, including the ones you have mentioned. Applying graph theory on the transactions can reveal a lot of information, connect seemingly independent addresses and thus compromise them. Bitcoin was never meant to provide anonymity out-of-the-box, so it's hard to blame it.

However, this does not mean the anonymity is impossible to achieve. There are many 3rd party services specializing at this, mixing your coins with other people's coins, for example bitmixer.io. You can find more such services and use them in chain for even better anonymity, just search the Internet for bitcoin mixer or bitcoin laundry.

Note: the problem of connecting addresses to the same owner is not specific to HD wallets, but concerns also simple wallets that generate all the addresses randomly. For the outside observer, there's no way to tell if you're using one or another, but this information is not necessary to connect the addresses once you've made a transaction combining their inputs.

Answer 3

Whatever the answer is today, it probably won't matter in the not-too-distant future. The blockchain is a public and permanent record of everyone's transactions.

Besides the fact that one would have to be 100% anonymous for each and every transaction, 100% of the time to remain anonymous (whatever that solution is)... There's that permanent public record of every one of your transactions. If somebody wants to they will eventually connect the dots from enough public and private databases. Not to mention quantum computing or other future advancements.

If I were a tax collector and wanted to prevent cheating, I would create a foolproof system to maintain a permanent record of every transaction. Then we could make it easy, troll the blockchain and submit monthly tax invoices to my minions. Don't pay it? Your transactions will not confirm. Can't spend. Kinda hard to refute then.

Answer 4

I'll fill in the technical aspects where I can later today, but in principle what's happening is a private key is being altered in such a way so that HD public keys can be created and traced up the family tree, that we both know.

But here's a few thing to consider:

1. Can a pubkey be isolated as being your key? Most likely not, but assuming so, it's still only the hash160 shared publicly. What's to say you haven't changed wallet seeds, for example?

2. Assuming 1 to be true, reversing the SHA256 AND ripemd160 for your public key x/y coordinates is ~impossible ie

   pubkey <==A==> hash <=====B===== 0x04 X + Y

         A = base58,     B = SHA256/RIPEMD160
   

   .

3. The only probably way a link between the public key and the private key can be found is by having at minimum the private key, and ideally for an attacker, a set of privatekeys