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

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.

I implemented what is effectively 'split routing' for Bitcoin Core some time ago (just a switch that makes it not relay transaction; so an additional utility can getrawtransaction and handle it some other way).  But it's not currently compatible with the conflicted detection in Bitcoin core because the transaction says out of the mempool until its heard over the network and erroneously shows as conflicted, so I've been waiting for that to change.   If someone is interested in working on this in Bitcoin Core, feel free to lemme know and I can point out what needs to be done.  Primary difficulty is just in writing test harnesses and test cases, because this area of the software is under-tested currently so we're not comfortable taking changes without accompanying tests.

It would be straight-forward on top of that to provide a small sidecar daemon that handled your broadcasting for you (including by using fancy things like a high latency mix network).

http://sourceforge.net/p/bitcoin/mailman/message/33607215/

I didn't because doing so seemed redundant... it's dependent on Bitcoin Core for all if its networking needs, so if Bitcoin Core gained split routing, Armory would "inherit" it.


Completely agree, e.g. with MultiBit HD and/or other bitcoinj-based wallets if bitcoinj adds Tor & split routing support.


I think the situation isn't quite that bad. Mycelium uses a 'fully trust the server' model, and Electrum uses a 'query the server for an address' model (but Electrum does do SPV). Even with these two, Tor could help a little (although if they maintain long-term connections to the server, then they're leaking information related to addresses that are associated with one another, despite not leaking the actual IP addresses).

On the other hand, MultiBit (Classic and HD), Bitcoin Wallet for Android, and breadwallet are all pretty popular, and they're all "real" bloom-filter-using SPV clients.

Also to be fair, multisig wallets w/2FA trade privacy for security, and for some people that's a fair trade. E.g. GreenBits, even though it's a "real" bloom-filter-using SPV client, still needs to get the GreenAddress.it servers to sign their half of a 2-of-2 tx.

I would add Armory to that list as well.   Still I think split routing can even enhance the privacy of SPV nodes.  Download headers through public channel and send bloom filter requests and outgoing txns through the private channel (tor/i2p/vpn). 

The one thing I would agree with you is that users of these wallets tend to be 'prosumers' and thus are more interested in stuff like privacy and enhanced security.  It is my understanding that most lite clients today don't even use SPV model but instead use a proprietary 'trust the server' model or if the use SPV they don't use bloom filters.  The fact that users continue to use them would indicate they don't really care about privacy concerns.

Practically speaking, if some wallet were to implement D&T's split routing, it would probably be a wallet which currently takes privacy seriously. AFAIK, there are only three wallets which seem to fit into this category:

• Bitcoin Core
• MultiBit HD
• Darkwallet

These are the only wallets I could find which avoid address reuse, can be used relatively easily with Tor, and do not depend on any centralized service. (I don't think Darkwallet has implemented Tor/SOCKS yet, but it's on their roadmap.)

So if anyone were serious about this, that's where they should probably be looking.

Also worth noting that the latter two aren't yet considered stable enough for general use by their devs, so I'd guess (it's just a guess) that a new feature request such as split routing probably wouldn't be very high on their priority list....

Edited to add: It looks like bitcoinj might consider adding support for this one day...

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.

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.

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))

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.

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.

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.

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.

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.

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

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

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.

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://bitcointalksearch.org/topic/m.10772130

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.

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