Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xz2HH-0000pA-AE for bitcoin-development@lists.sourceforge.net; Thu, 11 Dec 2014 11:51:27 +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 1Xz2HF-00006A-P7 for bitcoin-development@lists.sourceforge.net; Thu, 11 Dec 2014 11:51:27 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id C2587E22B8D; Thu, 11 Dec 2014 12:51:18 +0100 (CET) From: Isidor Zeuner To: Gregory Maxwell Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; format=flowed References: In-Reply-To: Message-Id: <20141211115118.C2587E22B8D@quidecco.de> Date: Thu, 11 Dec 2014 12:51:18 +0100 (CET) X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1Xz2HF-00006A-P7 Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper 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: Thu, 11 Dec 2014 11:51:27 -0000 [...] > And, on the flip side if the host is persistently behind tor, even > with some watermarkable behaviour, their privacy is protected. So > making sure that hosts can continually use tor (or similar systems) > should be the higher priority. (And, of course, not reimplementing > tor leverages the millions of dollars of investment and dozens of > subject matter experts working on that system). > Reimplementing Tor would not only mean to lose all the investment that ran into Tor, but also to lose a large user base. We can see this with TorCoin. Still, the fact that Bitcoin is a use case for Tor which measurably shows some limits where it is not fully clear if Tor or Bitcoin is to be blamed does not only mean that both projects may have to evolve in order to properly solve the issue, but also that the means of interfacing between both projects may have to be extended. Ideally, in a way which does not require to run a separate Tor and/or Bitcoin network in order to work, but which will be generic enough to satisfy both sides' need to still work in a standalone manner. But I do see huge merit in exploring better ways of synergy between the projects. For example, Tor's hardcoded circuit length may be considered as a hack which was only necessary due to the lack of a suitable resource compensation mechanism. Which is something that is available with Bitcoin. Best regards, Isidor