Thinking about ways to make it more difficult to link IP address to txn creator.

[DeathAndTaxes]

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.

[1714488999]

1714488999

[1714488999]

1714488999

[1714488999]

1714488999

[Come-from-Beyond]

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?

[odolvlobo]

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.

[Soros Shorts]

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.

[1Referee]

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.

[Cryptowatch.com]

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:

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?

[Come-from-Beyond]

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

I won't be surprised if several people go to jail because of this. http://en.wikipedia.org/wiki/Money_transmitter

[spin]

Probably crap ideas:

1. Why not make the tx appear like a typical relayed tx in a special inv that's only revealed to one "selected" peer.  "selected" could be random or outbound only, or any other feature that could indicate some more trust in the node.  This should be private with the probability of 1-a/n where a=attacker nodes I'm connected to n=total nodes i'm connected to.  Doesn't help if a=n though.  This does help if the attacker is connected to every single node in the network as this would mean that they first see the tx from some other node unless you happen to pick one of their nodes.

This could then be redone in x minutes if the my client hasn't heard about this tx from other nodes.  I.e. the tx hasn't effectively been rebroadcast.

2. Another point is if I get an addr message for a node from every single node I'm connected to does that not indicate a node that is trying to connect to too many nodes.  Should I not trust such a node less?  I guess this might be difficult to determine an optimal point?  Plus the attacker would work round whatever heuristic get's used.

3. Nodes under 1. can be selected based on behaviour (am I receving useful info/tx/addresses).  Is it behaving like a regular node etc.  Attacker could probably work around this.

4. I suppose one could also "select" a new random node out there to connect to, just to broadcast this tx.  Then it depends on how good your selection process is.

[belcher]

I had an idea related to my project JoinMarket.


Regarding the Chainalysis deanonymizing sybil attacker.

CoinJoin doesn't directly deal with IP-address based attacks.

However, because CoinJoin has multiple people, the final fully-signed transaction could be broadcast by any of them. This passive-monitoring sybil does not know that the different IP addresses are co-operating to create a CoinJoin.

For JoinMarket right now, it is always the liquidity-taker who broadcasts the tx from their IP or through a blockchain explorer. This could be improved by having taker be able to send the fully-signed tx hex to one of the market-makers who will then broadcast it. The taker would choose to broadcast the txhex himself, or send it to one randomly chosen maker to broadcast. In this way the coinjoin tx could come from many IPs instead of just the taker's.
It could work quite well. The makers are already incentivized to allow their bitcoins to be coinjoined with, now they can be incentivized to allow their IP address to broadcast coinjoins. They don't earn their coinjoin fee unless they broadcast.

From https://bitcointalk.org/index.php?topic=919116.msg10772130#msg10772130

[belcher]

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.

For this kind of idea, we probably need to come up with a good format for serializing bitcoin transactions. The current hex string style does not include error detection or other desirable characteristics. Of course, wallets should accept the current hexstring style too.

I suggest a simple base64 encoded string with the first 4 bytes of double-sha256() appended as a checksum. Maybe the string BITCOIN TRANSACTION should appear there somewhere too.

[spin]

...
1) Nodes should support split routing
...

2) Merchants and payment service providers should directly accept signed transactions.
...
3) Wallet developers should consider making it possible for a user to create a signed transaction without broadcasting and to import a signed transaction.
...

2 and 3 have the added advantages.  Merchants can validate the tx, ensure sufficient fees and broadcast it widely, to reduce double spend probability.

[goregrind]

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.

Along the same line, we should be able to use pushtx services to broadcast transactions

[gmaxwell]

and broadcast it widely, to reduce double spend probability.

There is no form of additional "broadcast it widely" work beyond the ordinary operations of the network that meaningfully reduces the probability of a double-spend.

[belcher]

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.

Along the same line, we should be able to use pushtx services to broadcast transactions

The JoinMarket market-makers could be one of the things which do that. Push everyone's transactions instead of only their own coinjoins.

An important point often missed is that this privacy stuff should be automatic to the user. Very few users will be inclined to copypaste transactions around when they can just click "Send" and have the tx go from their own IP.

[DeathAndTaxes]

and broadcast it widely, to reduce double spend probability.

There is no form of additional "broadcast it widely" work beyond the ordinary operations of the network that meaningfully reduces the probability of a double-spend.

Agreed it provides no additional security against double spends but it could be useful to prevent "stuck" payments.  At least the merchant will gain immediate visibility of the payment which may not be the case if user is running a wallet which creates non-standard txns (primarily due to size, dust, or fee).  If parent pays child becomes more common a high capacity merchant may even be willing to accept such non-standard payments bundle them together with sufficient fees in child transaction and push to miners.  

From a merchant standpoint one downside is customer satisfaction.  When Bitcoin works it works great but when it doesn't (primarily due to issues created by the user) the merchant can't do anything.  Most merchants don't like to be in this position.    The ability to accept the txn directly at least gives them the ability to resolve user issues transparently and thus improve customer satisfaction and merchant reputation.

[DeathAndTaxes]

An important point often missed is that this privacy stuff should be automatic to the user. Very few users will be inclined to copypaste transactions around when they can just click "Send" and have the tx go from their own IP.

Agreed.  However as a first step the ability to do it 'at all' is a first step.  To make it more transparent and seamless, BIP70 could be extended to support a privacy enhancing 'direct to merchant' option which transmits the payment only to the merchant.



This shows standard BIP protocol sequence.  Notice in the second to last step the payer's wallet broadcasts the txn to the network.  However the protocol could be extended to optionally remove this step.  If the 'payment request' sent by merchant (step 2) had a 'direct to merchant only' flag which indicated the merchant would relay the txn and the user's wallet was both aware of this flag and the user elected 'direct to merchant' payments then the wallet would not broadcast the txns.  Instead the merchant would and the user would see the txns when his wallet received it from the network.  This would provide a way to enhance privacy in a transparent manner.  An existing BIP70 wallet (which is unaware of 'direct to merchant' flag) would fall back to normal txn broadcast and acting on the flag could be a user defined option (default to enable?) so even newer wallets could still fallback to the existing mode.

[DeathAndTaxes]

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.

For this kind of idea, we probably need to come up with a good format for serializing bitcoin transactions. The current hex string style does not include error detection or other desirable characteristics. Of course, wallets should accept the current hexstring style too.

I suggest a simple base64 encoded string with the first 4 bytes of double-sha256() appended as a checksum. Maybe the string BITCOIN TRANSACTION should appear there somewhere too.

That probably is not a requirement although it can't hurt (more compact in terms of symbols than hex).   Bitcoin transactions are signed.  Changing bytes either intentionally or accidentally in any part of the txn except the ScriptSig will simply result in an invalid txns.  The ScriptSig is malleable (the txn malleability issue) however even a change here will either result in an invalid txn or a valid txn with a new txn id.  It is very likely the later would happen due to accident so it is no different than any other transaction in this respect.

I would recommend using base58checked instead of base64.   The non-alpha symbols in base64 make copying and pasting a pain.

[onemorexmr]

Hi DnD

i like your recommendation to develop a standard for payments directly with a signed TX.
that would also allow offline devices to do payments (if they have the UTXO set of the current user)

regarding your point that a salesman can do nothing when a payment is stuck: i though it was planned / supported that if a merchant immediately spends this new transaction with a higher fee it has a higher probability to get included?

and i expect bigger merchants to make agreements with pools too (like mtgox and eligius did a long long time ago (AFAIK at the the time of the gox scam this wasnt the case anymore))

[DeathAndTaxes]

regarding your point that a salesman can do nothing when a payment is stuck: i though it was planned / supported that if a merchant immediately spends this new transaction with a higher fee it has a higher probability to get included?

That is true but most txns that are 'stuck' become so because they do not fully propagate the network.  As an example say you are using a poorly coded wallet which allows you to create an output below the dust threshold.  Most nodes will not relay that txn.  From your end it looks like you 'paid' the merchant but most nodes are just dropping the transaction and refusing to relay because it failed the IsStandard() check.

Even if one of your immediate peers does relay it unless there is an unbroken line of peers between you and the merchant it will be dropped at some point along the way.  In a situation like that the merchant simply doesn't see your txn.  Even if you give them the txId their local bitcoind will say the txn doesn't exist.  Now if you paid a 'normalish' fee and some node relayed it to a pool which mines non-standard txn it may get included in a block at which point the merchant would see you 'paid' when the block publishes which may be hours or even days later.   However if you also decided to be cheap and make it both non-standard and free it may never be included in a block.

If the merchant can't 'see' the txn they have no ability to fix your problems even if they want to.  By transmitting directly to the merchant the at least be guaranteed they will get a copy of the txn.  Now if it is some massive bloated spammy garbage that some unknown wallet allowed you to create they may not want to fix your problems using 'child pays parent' but they at least have the option (especially as you indicate if the merchant has an existing agreement with one or more pool).

It isn't a perfect analogy but think about how CC works.  In theory CC could operate on a model that when you want to pay your smartphone contacts the CC network directly including all the routing and payment details.  The merchant would then see the txn when they are notified by the processor.  It doesn't work that way however.  You provide the payment to the merchant directly via POS terminal who then pushes that to the network and both you are the merchant are notified.  The merchant has a very vested interest in making sure the payment goes through so it makes sense for them to handle the transmission of the payment.

[DeathAndTaxes]

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.

True the network itself doesn't track originator IP addresses and couldn't in any provable manner.  You are right the 'relay IP address' is just the IP address the snooping node first saw the txn from.  The idea is that if there are say 8,000 full nodes and you create 2,000 full nodes and the average user has 8 connections the odds are you will connect to at least one snooping node.  When all the nodes share information on the backend there is a high probability that 'relay IP address' is the originator's IP address at least for default behavior of most wallets if the user is not using some privacy enhancement.  Using TOR, I2P, or VPN proxy today would defeat these types of attempts (unless exit nodes are poisoned).  The reality is most users will not go beyond the default configuration so the thread was looking for ways to make privacy easier for the average user.

Your single connection scenario doesn't work as well as you might think.  In case it isn't understood having only a single connection to the network is very dangerous.  It can allow you to be isolated and fed false information by a malicious node.  That could lead to a loss of funds if you are tricked into thinking a txn is on the main chain when it is not.  The foundation of blockchain security is that your node will connect to at least one honest peer and thus can determine the longest valid chain. If you are connecting to 8 or 20, or 80 peers the probability that they will all be the attacker is low but if you connect to a single node especially at random the odds are much greater.  I am not saying there aren't niche uses but the node you connect to should be trusted and you should understand the risks.

Connecting to a single random node means there is a good chance you will connect to one of the 'snooping node' and thus you haven't accomplished anything.   The other thing to consider is that any snooping like this is pretty much useless for a single transaction it would use heuristic algorithms.  While sometime you may not connect to a snooping node, sometimes you will and each txn provides another piece to the puzzle.  By doing blockchain analysis looking for probable change address and correlating those to IP addresses the privacy can be eroded.   Sure it won't be 100% of the txn 100% of the time but that isn't really the goal.