New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clients leak IPs if they are recipients of a transaction #3828
Comments
This can be avoided by using Tor or another anonymity overlay network for transaction (re)broadcast. Not re-broadcasting to clients you have already spoken does not sound like a solution, as an attacker can easily have a lot of IPs available. Also when mempool expiration is implemented this will make it harder to rebroadcast transactions (at a certain point all the reliable nodes will be marked). |
I'm just saying I watched U Penn researchers talk very knowledgeably about exact nodes rebroadcasting repeatedly; they had very pretty graphs. I don't think most people expect that having the qt wallet turned on means they are broadcasting IP-Address linkages to the world. I'm not enough of an expert on Tor to comment as to whether repeatedly issuing the same packets out over and over breaks some assumptions Tor makes as to anonymity, but I am suspicious that it's not an ideal communication pattern even there. |
Well at least when using Tor none of your peers can see what your IP is. Sure, someone monitoring all the world's communication lines could make educated guesses based on timing correlations and such, but that's not the kind of threat scenario most people have to deal with. Or that we can even hope to protect against. For directly hiding your IP (for example from criminals), using Tor works well, and many people are using bitcoin behind Tor for that reason alone. From what I've heard, BitcoinJ is even going to make operating over Tor the default (then again, it's more urgent there as an SPV client gives away much more information to peers). |
I know there's a long list - o - bugs, just wanted to put this out there; it seemed surprising that you could induce a very long period of 'beaconing' from the qt client just by sending it an unlikely to be mined transaction in which it has an economic stake. |
@laanwj : I think outsourcing anonymity to Tor is very wrong for algorithmic reasons: |
But no matter what, as soon as a node is seen broadcasting a previously-seen transaction a second time (say, more than an hour later) you know he's either the original sender or recipient of the transaction. One way to avoid this would be to avoid rebroadcasting of transactions completely (after the initial flurry). The sender would have to make sure he's really well-connected the first time to avoid the transaction from getting lost. The receiver would never (re-)broadcast the transaction at all. If your transaction gets stuck, there's nothing that can be done about it. Another way to hide would be for nodes to randomly re-broadcast other people's transactions from the mempool. But I think this won't interact well with memory pool expiration. |
@laanwj : |
I explained why we ware doing that! Rebroadcasting your own transactions avoids them from getting stuck if your set of peers at the time was flaky. If you have another channel to send the transaction to your recipient (like the payment protocol) it becomes less important to broadcast it yourself, but we cannot assume that. As for mempool expiration, different peers receive the transaction at slightly different times, and thus expire them at different times. Let's say Node B received a transaction sooner than node A. B is just about the expire the transaction, and then Node A rebroadcasts it randomly. B will see it as a new transaction... and after A expired it, it may be that B rebroadcasts it again. Bouncing around it will be kept in the mempool forever. This is how it would go right now. You propose to persistently remember transaction expired from the mempool (for a certain duration) so that they don't reenter, but such functionaltiy doesn't exist at this point. I also don't think it would work. The point of expiring transactions is not to avoid them from being re-broadcasted, in the contrary, it's just to make sure transactions that the sender/receiver don't care about (by not re-broadcasting them) don't keep cluttering the mempool. |
@laanwj The general target for expiring a transaction from the mempool seems to be 2-3 days. If random transactions would be broadcasted for a significatnly shorter time, let's say half the expiration time, that seems to make it unlikely that another peer has already expired it when it's randomly rebroadcasted. |
@laanwj Lets discuss the two issues separately:
|
Addition to 2: The expiration time must of course be modified by a random bias before sharing it, otherwise it gives away too much information about how close to the origin of the transactions the sender is. |
I think it makes sense to move this to the mailing list. This bug tracker is intended for concrete issues specific to this implementation ("bitcoin core"). General protocol improvements should be discussed over there, with more visibility. |
Outsourcing to tor is a major problem, it creates an unexpected binding between the two. People are likely to be de-anonymized when they fire up bitcoind and tor isn't running or if the tor process ever dies while bitcoind is running or any number of other scenarios. |
As long as we don't have mempool reconciliation, I think there is no real solution to this problem. |
At least we now have an option to disable the default broadcast: The problem still exists so might as well keep open the issue as a reminder. |
I do appreciate the availability of this option but let's be honest:
I would please strongly ask to keep it open - storage of issues costs you nothing, but the value of resolving this someday is very high for the large amount of users who want privacy. |
Just randomly stumbled upon this issue. |
ref #21061 |
So, this paper http://ifca.ai/fc14/papers/fc14_submission_71.pdf got me thinking about the current rules for transaction rebroadcasting:
Once a transaction has been broadcast, you stop rebroadcasting. Unless you own txins or txouts in the transaction.
So, you use the paper's techniques. But you can be much more speculative than they are, and get a low-likelihood but possible IP match for an address, connect your client up, and issue a transaction paying yourself and a small amount to the address you're interested in, just over the dust amount.
The transaction should be constructed so it's unlikely to be mined.
The transaction traverses the network, then it stops being rebroadcast, except by the recipient and you. If your client is connected to the wallet that owns the address, it will see rebroadcasting for some time, providing a very strong link between the two.
This seems like a bad outcome.
I speculate that the 1Sochi transactions may have this motivation -- mapping addresses to determine IPs at large in Bitcoin.
It seems like the simplest thing would be to not re-re-broadcast to clients you've already spoken to, but I'll wait for smarter people than me to work out the right fix.
The text was updated successfully, but these errors were encountered: