Add rotation of outbound connections

ivanpustogarov commented at 4:29 pm on August 18, 2014: contributor

Every 2-5 minutes choose a random outbound connection with probability proportionally to its connected time and disconnect the corresponding peer. This periodically rotates outbound connections and prevents a Bitcoin client from being fingerprinted (the set of outbound connections uniquely identifies a client). This is to initiate a discussion.

Add rotation of outbound connections every 2-5 min

Every 2-5 minutes choose a random outbound connection with probability
proportionally to its connected time and disconnect the corresponding
peer. This periodically rotates outbound connections and prevents a
bitcoin client to be fingerprinted (the set of outbound connections
uniquely identifies a client).

ff7e3dac66

sipa commented at 5:07 pm on August 18, 2014: member

I have done some investigation a long time ago about this behavior. My purpose was making sure that the average eventual connection durations are approximately exponentially distributed: causing a few connection slots to rotate frequently, but also maintain longer connrction times with some. I believe that using a disconnection chance proportional to connected_time ^ 0.8 worked relatively well in simulations, but I doubt I have the numbers still. You would also want to have some additional scoring mechanism to prevent disconnrcting the peer that is always fastest in given you new blocks.

sipa commented at 5:07 pm on August 18, 2014: member

Sorry, connection_time ^ -0.8

BitcoinPullTester commented at 10:03 pm on August 18, 2014: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4723_ff7e3dac66eeaa09eefbe9f21e8622188b9eff70/ for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

gmaxwell commented at 11:41 pm on August 18, 2014: contributor

I’m not super happy about continuing to disconnect peers when it takes a long time connect. I’d rather it did not attempt a disconnection unless the outbound connections are at the maximum.

In addition to not disconnecting when connect is used— it should not disconnect any nodes which were addnode, and it should not disconnect whitelisted peers.

You would also want to have some additional scoring mechanism to

The simplest heuristic would be to track for each peer when we last accepted a block from it. Then the rotation process could protect the peer with the most recent block accepted time.

I’m also concerned about partitioning attacks, keeping up long term connections means no late coming partition attack can be successful (without first dos attacking off the rest of the network). So I think we should at a minimum protect our three oldest “working” outbound connections, and not just bias the selection against them. (Three because anything smaller is guaranteed to give a degenerate topology assuming our other connections are sybils)

Does someone have a simulation of the deanonymization attacks so we can estimate how much connection persistence can be tolerated before rotation is ineffective?

gmaxwell commented at 11:51 pm on August 18, 2014: contributor

It was pointed out to me that my concern wrt partitioning is unclear. Imagine an attacker starts up a moderate number of sybil nodes. He also connects to every other available listening peer and fills up their inbound capacity (this is a fairly cheap attack).

In the current network this kind of activity would only disrupt newly joining peers, but nodes which were still online would remain connected to each other. With excessive rotation the entire network could become connected exclusively via the sybils.

In particular, if an attacker is able to partition a large miner they can eliminate their hash-power from competition or even use it to perform double spending attacks against partitioned merchants; so there is an economic motivation for these sorts of attacks.

laanwj commented at 8:29 am on August 19, 2014: member

I don’t think it makes sense to discuss this here and on the mailing list in parallel.

laanwj added the label Brainstorming on Aug 19, 2014

dgenr8 commented at 4:52 pm on August 30, 2014: contributor

In addition to protecting against fingerprinting, rotation would help a successfully sybiled node not stay that way.

gmaxwell commented at 5:49 pm on August 30, 2014: contributor

@dgenr8 Or, not handled well, it would allow a not sybiled node to become that way. This was discussed upthread previously.

dgenr8 commented at 7:34 pm on August 30, 2014: contributor

@gmaxwell: yes, I am offering the counterpoint. Today, a sybil attacker can know pretty well when she owns a node’s world (introduce a test tx on an uncontrolled node and see if owned node relays it). So she knows a fresh attack (via whatever vector) is needed when she gets disconnected. If disconnects happen more commonly, this gets more expensive.

rebroad commented at 0:29 am on September 6, 2014: contributor

@dgenr8 Not sure I understand how this test would prove a node is owned. What’s the outcome for when the node is owned?

rebroad commented at 0:32 am on September 6, 2014: contributor

Yes, this merge is currently too simple. It needs to only start disconnecting when max connections reached, and it shouldn’t disconnect addnoded nodes, and the disconnected node should be replaced by an outbound connected node if the disconnected node was an outbound connected node (code may already enforce this, not checked).

dgenr8 commented at 1:28 am on September 6, 2014: contributor

@rebroad If I have say 8 connections to node, and send a new tx to some other place on the network, does node relay it to me? If not, it has no good connections. Although, it could have other sorts of bad ones.

laanwj added this to the milestone 0.11.0 on Dec 3, 2014

laanwj added the label P2P on Jan 8, 2015

laanwj commented at 11:15 am on March 20, 2015: member

Needs rebase (and comments addressed).

laanwj removed this from the milestone 0.11.0 on May 18, 2015

laanwj commented at 7:45 am on May 18, 2015: member

Ping: Still needs rebase (and comments addressed).

ivanpustogarov commented at 9:40 pm on May 19, 2015: contributor

Sorry for being silent. I was busy with other stuff. It looks like this change might solve one problem but create others (e.g. as gmaxwell mentioned the partitioning attack if there are no long term connections). So I think more research should be done in this direction. Unfortunately I don’t have enough time now to work on this.

jgarzik commented at 6:06 pm on July 23, 2015: contributor

Closing based on the above comments. Can re-open once mailing list discussion and more concrete solution appear.

jgarzik closed this on Jul 23, 2015

MarcoFalke locked this on Sep 8, 2021

Add rotation of outbound connections #4723