The recent sybil attack on the network by Chainalysis got me thinking about identity being leaked by the high correlation between the first relayed IP address and the original creator. IP can be a very powerful piece of identity information. It alone can be useful but then combined with other measured can be used to build a real world identity and link transactions to it. Granted the first relayed node may not be the sender but with enough nodes and some heuristics and multiple datapoints it becomes possible to start seeing the information from the noise.
Glad to see this discussion. Cross posting something that may be helpful:
https://bitcointalk.org/index.php?topic=1083961.msg11561739#msg11561739(...) So I guess we can be thankful that Chainalysis did such a horribly bad job out of the gate that they brought attention to the issue before someone competent tries. Hiding the creator's IP address alone does not provide perfect privacy but it is a start.
1) Nodes should support split routing
TOR, I2P, and VPN proxy are options to decouple your IP address from your transactions but bitcoin generates a lot of traffic when only a tiny portion of that is privacy related. Routing all of it through privacy protecting services is inefficient. Split routing would allow the client to be configured to relay some of its traffic (like locally created transactions) to one network and the rest of the traffic (like relayed blocks) to another network. By routing only a node's outbound txns the bandwidth requirements over the secure network can be reduced significantly. It may be more secure to randomly pick a small portion of the received transaction to relay over the secure network and then add locally created transactions to that stream. This makes exit node analysis more difficult in the event the exit node is compromised. Still it should be possible to reduce the TOR bandwidth requirements by 99% or more. Likewise users of VPN proxy services could take advantage of split routing to reduce cost as their bandwidth requirements will be low.
It sounds like you are saying that if I am using both Tor and a VPN for example, that bitcoin protocol could be configured to support some of the traffic going off along Tor and some of it going off along my VPN.
(...)
3) Wallet developers should consider making it possible for a user to create a signed transaction without broadcasting and to import a signed transaction.
Armory already makes it easy to sign a transaction without broadcasting in offline mode (cold storage) but this could be useful feature for an online wallet as well and also implemented in Bitcoin core. User creates a transaction in the wallet, checks an option to not broadcast and when signed receives the hex encoded raw transaction which he can send directly to the receiver. Merchants and other service providers will likely use automated system to accept and process this transactions but end users may not. Clients should make it easy to 'import' a signed transaction for validation and relaying.
If the user would be creating a signed transaction (or indicate preferences for the wallet to create a transaction that would be broadcast at a later time when a certain threshold is met) without broadcasting immediately and could specify that the basic conditions as to where and when the broadcasts should occur and let the wallet handle the rest, this sounds good, so long as the recipient does not have trouble receiving what is being sent.
