[Bitcoin-development] Outbound connections rotation
Hi there, I'd like to start a discussion on periodic rotation of outbound connections. E.g. every 2-10 minutes an outbound connections is dropped and replaced by a new one. Motivation: Each bitcoin non-UPnP client behind NAT has 8 outbound connections which change only rarely (due to occasional remote side disconnections). A subset of these 8 entry nodes uniquely identifies a user. An attacker can listen for transactions in Bitcoin network and for each transaction record the first 8 peers which forwarded the transaction. If two distinct transactions (with unrelated bitcoin addresses) come from the same set of 8 peers, the attacker can conclude that they originated from the same user. This gives another method (in addition to transaction graph analysis) for an attacker to link different BC addresses of the same user. Also note that by default bitcoin clients advertise their public IP addresses. The attacker can link the advertised IP's to corresponding 8 entry nodes and use it to deanonymise Bitcoin clients. If a bitcoin client periodically rotates his set of outbound connections, his 8-peers fingerprint is blurred over time. Corresponding pull request is #4723. Some details are here: https://www.cryptolux.org/index.php/Bitcoin -- Ivan -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Outbound connections rotation
Simply by observing timing from sufficiently geo-graphically and network-ly dispersed nodes, you may deduce the original broadcaster of a transaction. Rotating peers doesn't help. That said, periodic rotation can be helpful. Every 2-10 minutes is excessive. On Mon, Aug 18, 2014 at 12:46 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: Hi there, I'd like to start a discussion on periodic rotation of outbound connections. E.g. every 2-10 minutes an outbound connections is dropped and replaced by a new one. Motivation: Each bitcoin non-UPnP client behind NAT has 8 outbound connections which change only rarely (due to occasional remote side disconnections). A subset of these 8 entry nodes uniquely identifies a user. An attacker can listen for transactions in Bitcoin network and for each transaction record the first 8 peers which forwarded the transaction. If two distinct transactions (with unrelated bitcoin addresses) come from the same set of 8 peers, the attacker can conclude that they originated from the same user. This gives another method (in addition to transaction graph analysis) for an attacker to link different BC addresses of the same user. Also note that by default bitcoin clients advertise their public IP addresses. The attacker can link the advertised IP's to corresponding 8 entry nodes and use it to deanonymise Bitcoin clients. If a bitcoin client periodically rotates his set of outbound connections, his 8-peers fingerprint is blurred over time. Corresponding pull request is #4723. Some details are here: https://www.cryptolux.org/index.php/Bitcoin -- Ivan -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Outbound connections rotation
On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: Hi there, I'd like to start a discussion on periodic rotation of outbound connections. E.g. every 2-10 minutes an outbound connections is dropped and replaced by a new one. Connection rotation would be fine for improving a node's knoweldge about available peers and making the network stronger against partitioning. I haven't implemented this because I think your motivation is _precisely_ opposite the behavior. If you keep a constant set of outbound peers only those peers learn the origin of your transactions, and so it is unlikely that any particular attacker will gain strong evidence. If you rotate where you send out your transactions then with very high probability a sybil pretending to be many nodes will observe you transmitting directly. Ultimately, since the traffic is clear text, if you expect to have any privacy at all in your broadcasts you should be broadcasting over tor or i2p. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Outbound connections rotation
Connection rotation would be fine for improving a node's knoweldge about available peers and making the network stronger against partitioning. It's also the first/next step towards decentralising the DNS seeds (for SPV clients), as it'd allow each node to explore the network and return better quality results in getaddr. If you rotate where you send out your transactions then with very high probability a sybil pretending to be many nodes will observe you transmitting directly. This is sort of what Tor is going through with their guard nodes and how often to rotate them. I think the attack Ivan is talking about does not require sybil attacks to work though, just listening to lots of peers. Raising the bar to require the attacker to receive lots of connections seems like a win. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Outbound connections rotation
Yes, I believe peer rotation is useful, but not for privacy - just for improving the network's internal knowledge. I haven't looked at the implementation yet, but how I imagined it would be every X minutes you attempt a new outgoing connection, even if you're already at the outbound limit. Then, if a connection attempt succeeds, another connection (according to some scoring system) is replaced by it. Given such a mechanism, plus reasonable assurances that better connections survive for a longer time, I have no problem with rotating every few minutes. On Aug 18, 2014 7:23 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: Hi there, I'd like to start a discussion on periodic rotation of outbound connections. E.g. every 2-10 minutes an outbound connections is dropped and replaced by a new one. Connection rotation would be fine for improving a node's knoweldge about available peers and making the network stronger against partitioning. I haven't implemented this because I think your motivation is _precisely_ opposite the behavior. If you keep a constant set of outbound peers only those peers learn the origin of your transactions, and so it is unlikely that any particular attacker will gain strong evidence. If you rotate where you send out your transactions then with very high probability a sybil pretending to be many nodes will observe you transmitting directly. Ultimately, since the traffic is clear text, if you expect to have any privacy at all in your broadcasts you should be broadcasting over tor or i2p. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fwd: Outbound connections rotation
On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille pieter.wui...@gmail.com wrote: Yes, I believe peer rotation is useful, but not for privacy - just for improving the network's internal knowledge. I haven't looked at the implementation yet, but how I imagined it would be every X minutes you attempt a new outgoing connection, even if you're already at the outbound limit. Then, if a connection attempt succeeds, another connection (according to some scoring system) is replaced by it. Given such a mechanism, plus reasonable assurances that better connections survive for a longer time, I have no problem with rotating every few minutes. Previously when you and I had discussed this I'd proposed that some number (say) four of the most long lived connections which had proven themselves useful (e.g. by relaying blocks) be pinned up and not be eligible for dropping. By protecting some subset of peers you guarantee that an attacker which simply introduces a lot of nodes cannot partition the network which existed prior to when the attack started. On Mon, Aug 18, 2014 at 10:27 AM, Mike Hearn m...@plan99.net wrote: I think the attack Ivan is talking about does not require sybil attacks to work though, just listening to lots of peers I may not be understanding you. Might be a definitions thing, I'm using the definition: A sybil attack is when a party takes on many identities (nodes) in the network. What ivan highlights is a bit of a tradeoff between concealing identities and linkages. Relaying transactions through only a single peer ever (until that one is no longer on the network) is the best strategy for concealing your identity (ignoring tor and what not), as only that peer learns anything about your identity. But it may reveal a lot about how different transactions are linked, since people observing that peer will observe that your transactions are correlated. The optimal strategy for avoiding linkages (ignoring tor, again), is to randomly pick a different peer for each transaction and relay the transaction only to that peer. This can (and probably should) be distinct from your normal network connectivity. Probably for anti-linkage I'd suggest that a facility for that kind of announcement should be done. If used over tor it would also protect your identity. Then the regular topology of the network can be optimized for learning and partition resistance. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Outbound connections rotation
On Mon, Aug 18, 2014 at 11:37 AM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: the same for a long time, an attacker which does not have any peers at all but just listens the Bitcoin network can link together differed BC addresses and learn the IP of the client. I don't understand what you're talking about here; if you have no peer at all you will learn nothing about the Bitcoin network. Can you clarify? The 8 entry peers are unique per client so if two users share the same IP, they can be distinguished. What mechanism are you referring to specifically? Outbound connections are still rotated from time to time due to remote side disconnections. Plus outbound connections do not survive BC client restarts (unlike Tor Guard nodes). On our initial connections we do have a preference for nodes we knew were up recently. This could be made further. That the current behavior isn't great isn't an argument for making it worse on that dimension. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Outbound connections rotation
On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: The attack I'm trying to address is described here: https://www.cryptolux.org/index.php/Bitcoin It was discussed here: https://bitcointalk.org/index.php?topic=632124.0 It uses the following observation. Each NATed client connects to the Bitcoin network through 8 entry peers; he also advertises his public IP address to these peers which allows an attacker to make the mapping 8-entry-peers, client-IP-address. I'm afraid I'm losing you here. The node advertises himself to everyone he is connected to and in/or out, those nodes pass along those advertisements. When I receive an advertisement from a node I do not know how far away the advertised peers is, presumably I can accurately exclude it from being 0-hops— itself—) 1 or more should be indistinguishable. Is there a reason that they're distinguishable that I'm missing? Can you explain to me how you propose to produce this mapping? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Outbound connections rotation
For each neighbour, a Bitcoin peer keeps the history of addresses that it forwarded to the neighbour. If an address was already forwarded to a neighbour it is not retransmitted again. An attacker can make a list of potential IP addresses of clients (say an IP range of an ISP, or listen for addresses in the Bitcoin network before the attack). Then she periodically spams the network with this list and updates the address-forward history at each Bitcoin peer. After each spam round, the attacker reconnects her connections to Bitcoin peers and thus clears the retransmission history for her connections only. As the result, when a NAT client connects to the network and advertises its address, the addresses will propagate to the attacker's connections only. On Mon, Aug 18, 2014 at 01:43:44PM -0700, Gregory Maxwell wrote: On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: The attack I'm trying to address is described here: https://www.cryptolux.org/index.php/Bitcoin It was discussed here: https://bitcointalk.org/index.php?topic=632124.0 It uses the following observation. Each NATed client connects to the Bitcoin network through 8 entry peers; he also advertises his public IP address to these peers which allows an attacker to make the mapping 8-entry-peers, client-IP-address. I'm afraid I'm losing you here. The node advertises himself to everyone he is connected to and in/or out, those nodes pass along those advertisements. When I receive an advertisement from a node I do not know how far away the advertised peers is, presumably I can accurately exclude it from being 0-hops— itself—) 1 or more should be indistinguishable. Is there a reason that they're distinguishable that I'm missing? Can you explain to me how you propose to produce this mapping? -- Ivan -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Outbound connections rotation
On Mon, Aug 18, 2014 at 2:02 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote: For each neighbour, a Bitcoin peer keeps the history of addresses that it forwarded to the neighbour. If an address was already forwarded to a neighbour it is not retransmitted again. Okay, sorry, I thought you were saying something else. I understand. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
