So the block explorer served one purpose above all others, showing what information is actually being stored.
What if I want to make it harder to trace transactions back to me, by design? Mind you, I have nothing to hide. But that doesn't mean I don't *want* to stay stealthy, and it should be our option to do so, if only for the heck of it
Ok, enough politics, not for the technical side of things; Transactions can be traced to addresses, sort of. It's hard to know which part in a transaction is a transfer, which part is change, and new addresses are always being created, but consider this:
- A sends 100 coins to B
- B sends 10 coins to C
- C sends 1 coin to A
looking at the block explorer, and assuming the wallet address that receives each transfer is the same that sends to the next hop (possible, as values are lower at each hop, thus unless there's a better match at the user's wallet, that one will be used, right?), A can see that the address used to send to B is the same C used to send to A, thus establishing a connection between B and C. That and a little googling may disclose the identities of the people involved, not to mention inbound address for C that B is using, thus (assuming C doesn't provide a different address to B each time) recurrent payments from B to C are now traceable.
And if you know that C gave you that address to pay for something morally opposable, like lawyer's fees, you will then be able to know how many coins C is receiving for such a service.
I know this scenario is kinda lame, sorry about that, but how can one avoid that without needing to do anything hard or complex?
Someone had a service for hiding transfers by proxying, delaying them and shuffling values. I think this is the answer, if we take it to the next level. A stealth proxy for bitcoin that would work close to this:
- A uses the proxy API to say "I want to send X to B".
- A receives an address Y
- A sends some value to Y, could be more, could be less multiple times
- Once enough is transfered, proxy sends to one or two new addresses internally, breaking the value in pieces with a little randomization along the way
- proxy sends X to B
- proxy sends change to A
--- and the tricky part
- after enough confirmations on both to A and to B transfers are received, proxy deletes the addresses from the wallet
If you add a 48h log rotation to /dev/null (the 48h are there to debug any real issue) and this should be completely untraceable. Another option to prevent tweaking the bitcoin client in to deleting addresses is to use a new wallet for each transaction and killing it afterwards. The hard part here is keeping a block db available to 100 bitcoin clients, but I'm sure we can think of something.
Am I forgetting anything?