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 1XK5uf-00022M-MR for bitcoin-development@lists.sourceforge.net; Wed, 20 Aug 2014 13:26:53 +0000 X-ACL-Warn: Received: from quidecco.de ([81.169.136.15]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1XK5ue-0005Sh-2q for bitcoin-development@lists.sourceforge.net; Wed, 20 Aug 2014 13:26:53 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id CB71CE043A5; Wed, 20 Aug 2014 14:59:01 +0200 (CEST) To: From: Isidor Zeuner Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format=flowed In-Reply-To: <20140818164543.GB31175@localhost.localdomain> Message-Id: <20140820125901.CB71CE043A5@quidecco.de> Date: Wed, 20 Aug 2014 14:59:01 +0200 (CEST) X-Spam-Score: -0.7 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1XK5ue-0005Sh-2q Cc: Ivan Pustogarov Subject: [Bitcoin-development] Proposal: PoW-based throttling of addresses (was: 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: Wed, 20 Aug 2014 13:26:53 -0000 Hi there, quote: [...] > 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. Using the same set of nodes for posting transactions using unrelated inputs kind of limits the privacy improvement that can be gained from using unrelated inputs in the first place. Similar to how Tor uses different circuits for different hosts to connect to, it may make more sense to only use the same set of nodes for posting a subsequent transaction when the input addresses are also the same. [...] > Some details are here: https://www.cryptolux.org/index.php/Bitcoin > I also find the topic of banning Tor exit nodes interesting. I wonder if it makes more sense not to ban IP addresses completely, but instead to throttle them using a PoW-based access control scheme. Misbehaving addresses can have their connecting difficulty scaled up, which should make it uneconomic to try to DoS the usage of Tor exit nodes for connecting to Bitcoin. It may also help nodes behind a NAT router if they share their global IP with misconfigured nodes. Best regards, Isidor