From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XJRQn-0003xI-Gd for bitcoin-development@lists.sourceforge.net; Mon, 18 Aug 2014 18:13:21 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.181 as permitted sender) client-ip=209.85.220.181; envelope-from=gmaxwell@gmail.com; helo=mail-vc0-f181.google.com; Received: from mail-vc0-f181.google.com ([209.85.220.181]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XJRQm-00032o-HK for bitcoin-development@lists.sourceforge.net; Mon, 18 Aug 2014 18:13:21 +0000 Received: by mail-vc0-f181.google.com with SMTP id lf12so6239050vcb.12 for ; Mon, 18 Aug 2014 11:13:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.228.67 with SMTP id sg3mr7398211vdc.6.1408385594995; Mon, 18 Aug 2014 11:13:14 -0700 (PDT) Received: by 10.52.187.132 with HTTP; Mon, 18 Aug 2014 11:13:14 -0700 (PDT) In-Reply-To: References: <20140818164543.GB31175@localhost.localdomain> Date: Mon, 18 Aug 2014 11:13:14 -0700 Message-ID: From: Gregory Maxwell To: Bitcoin Development Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XJRQm-00032o-HK Subject: [Bitcoin-development] Fwd: Outbound connections rotation X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 18:13:21 -0000 On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille 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 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.