Pages:
Author

Topic: Thinking about ways to make it more difficult to link IP address to txn creator. - page 3. (Read 7831 times)

full member
Activity: 196
Merit: 103
Plenty of transactions from around the world were connected to my node IP address. Which I am not happy with.

This is perhaps a risk it should be warned against? Could users possibly "incriminate" themselves?

I'm no expert in how transactions are relayed, but let's say Joe Student runs bitcoin-core on his dorm computer and leave it runnnig. Then some other bitcoin user running node software is connected to his node and issues a tx.

Afaik, it's possible to limit the bitcoin-code connections to 1, and also to set up which node to connect to. I'm unsure whether the "orginating IP" shown will be the node sending the tx, or the relay-node. But if it's the relay-node, then it's very easy for someone to just connect to someone random and send their "nasty payments" through them.

That tx then enters the network with an orginating IP of Joe Student. This other user bought some nasty stuff on some black market, and was the "victim" of a honeypot operation by law enforcement. These law enforcement officers might as well look up the transaction on blockchain.info, or with some other tool, and seeing this is their only "lead", they go for a raid..

We have an unconfirmed story of this happening already. I've also been told by someone I used to know how police took all his electronics without even talking to him or asking him about anything, all because of a mistake, much like the one above, with a false lead.

As for how accurate law enforcement is.. Old story, but still relevant:

Quote
Earlier this week, the FBI seized several servers at a hosting facility in Reston, VA. The servers were used by DigitalOne, a Web hosting company based in Switzerland. According the New York Times, the FBI was interested in just one of DigitalOne's clients, but took equipment used to host several other sites, including those run by Curbed Network, Pinboard, and Instapaper.

According to the New York Times, Sergej Ostroumo, DigitalOne's chief executive, said that the FBI took entire server racks, instead of just machines linked to a specific IP addresses:

DigitalOne provided all necessary information to pinpoint the servers for a specific I.P. address, Mr. Ostroumow said. However, the agents took entire server racks, perhaps because they mistakenly thought that "one enclosure is = to one server," he said in an e-mail.

So it's no wonder that someone's electronic equipment can be taken if they run a full node at home, and they pop up in a "suspicious transaction list". Of course, if the officers in question had proper knowledge about technology.. However they do as they please, it seldom gets them in trouble, so why not break down the door and take all the computers? What fun is it to ask nicely?
legendary
Activity: 2170
Merit: 1427
I always use a VPS for sending coins, so that's at least 1 problem for me that I don't have to deal with.

But that's not the same story for my full node that I used to run on my home pc.

Plenty of transactions from around the world were connected to my node IP address. Which I am not happy with.

Now I run the full node on another VPS to avoid all this connecting.
donator
Activity: 1617
Merit: 1012

Or use a mixer.

How does this help if the mixed coins and the original coins can be associated back to the same IP address? At the very least you would need to use the mixed coins from a different node.
legendary
Activity: 4522
Merit: 3426
2) Merchants and payment service providers should directly accept signed transactions.
3) Wallet developers should consider making it easier for a user to receive a signed transaction and to import a signed transaction.

POS terminals accepting signed transactions over NFC, wifi, and bluetooth will help here. It would be great if some enterprising POS terminal manufacturer would develop a transaction-signing protocol and write up a BIP that mobile bitcoin wallet developers could easily implement.
legendary
Activity: 2142
Merit: 1010
Newbie
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.

You seem to assume that noone else did this in the past. What this assumption is based on?
donator
Activity: 1218
Merit: 1080
Gerald Davis
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.

The good news is that Chainanlysis created non-responding nodes and used a sequential range of IP addresses from a given subnet.  So it was both suspicious and did not appear as normal nodes to other nodes on the network.  A smarter attacker however would use a few high capacity nodes hidden behind a larger number geo diverse IP addresses acting as transparent proxies.  It would be possible to aggregate the same information without appearing any differently than other bitcoin nodes.  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.

2) Merchants and payment service providers should directly accept signed transactions.
The person you are paying already knows 'you' are paying.  How much of you they know depends on the circumstances it may be a little or it may be a lot but there is some element of trust with any counterparty.  If I buy a gold coin from an online dealer who accepts bitcoins they already know at a minimum my name, address, and probably my IP address unless I used privacy protecting service.  It would leak less information to provide the signed transaction directly to the recipient rather than to an anonymous peer who may be malicious.

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.
Pages:
Jump to: