[As an aside I agree that there are lots of thin= gs to improve here,
but the fact that users can in theory be forced off of tor via DOS
attacks is not immediately concerning to me because its a conscious
choice users would make to abandon their privacy

Bitcoin already has a large population of users who have little or no= technical skill, it wouldn't surprise me at all if it was found to be = the clear majority by now. Assuming success and growth in future, very few = users will make any decisions at all about their privacy, they will just ac= cept the defaults. In such a world no consumer wallet is going to directly = expose Tor to end users - if used at all it'll just be used behind the = scenes. So automated fallback or control over exits would be a concern for = such wallets.

My gut feeling about this stuff has = changed over time. I don't think it'd be a great idea to tie Bitcoi= n to Tor too deeply, convenient though its infrastructure is. Most apps don= 't need a whole lot of onion routing - a small amount built in to the p= 2p layer would be sufficient. Tor is huge, complicated and could be a liabi= lity in future.

--f46d041825bc97c0340508d522ec-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XtxEb-00017a-Hc for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 11:27:41 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.180 as permitted sender) client-ip=209.85.223.180; envelope-from=laanwj@gmail.com; helo=mail-ie0-f180.google.com; Received: from mail-ie0-f180.google.com ([209.85.223.180]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XtxEZ-0002j5-Ov for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 11:27:41 +0000 Received: by mail-ie0-f180.google.com with SMTP id rp18so4219545iec.25 for ; Thu, 27 Nov 2014 03:27:34 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.42.130.7 with SMTP id t7mr20599293ics.25.1417087654477; Thu, 27 Nov 2014 03:27:34 -0800 (PST) Received: by 10.64.195.164 with HTTP; Thu, 27 Nov 2014 03:27:34 -0800 (PST) In-Reply-To: References: <54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> Date: Thu, 27 Nov 2014 11:27:34 +0000 Message-ID: From: Wladimir To: Gregory Maxwell 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 (laanwj[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: 1XtxEZ-0002j5-Ov 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, 27 Nov 2014 11:27:41 -0000 On Thu, Nov 27, 2014 at 2:22 AM, Gregory Maxwell wrote: >> Since this attack vector has been discussed, I started making some >> measurements on how effective it is to connect to Bitcoin using Tor, >> and I found that the number of connections dropping to near-zero is >> a situation which occurs rather frequently, which suggests that there >> is still room to improve on the DoS handling. > > I'm confused by this, I run quite a few nodes exclusively on tor and > chart their connectivity and have seen no such connection dropping > behaviour. In my experience the problem has always been getting bootstrapped. Most nodes hardly give any hidden service nodes in their getaddr. (this has been improved in master by including a set of hidden service seed nodes) But this assumes -onlynet=tor. Tor with exit nodes should be less problematic, unless someone managed to DoSban all the exit nodes as described in the paper (but I've never seen such an attack myself). > Can you tell me more about how you measured this? > > [As an aside I agree that there are lots of things to improve here, > but the fact that users can in theory be forced off of tor via DOS > attacks is not immediately concerning to me because its a conscious > choice users would make to abandon their privacy (and the behaviour of > the system here is known and intentional). There are other mechanisms > available for people to relay their transactions than connecting > directly to the bitcoin network; so their choice isn't just abandon > privacy or don't use bitcoin at all.] Right, there's something to be said for splitting your own transaction submission from normal P2P networking and transaction relay. (esp for non-SPV wallets which don't inherently leak any information about their addresses) There was a pull request about this for Bitcoin Core one, maybe I closed it unfairly https://github.com/bitcoin/bitcoin/issues/4564 . Wladimir From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xu37i-0003fl-HQ for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 17:44:58 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.193 as permitted sender) client-ip=209.85.217.193; envelope-from=misterbg6@gmail.com; helo=mail-lb0-f193.google.com; Received: from mail-lb0-f193.google.com ([209.85.217.193]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xu37h-00042v-Ff for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 17:44:58 +0000 Received: by mail-lb0-f193.google.com with SMTP id w7so720627lbi.0 for ; Thu, 27 Nov 2014 09:44:51 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.27.73 with SMTP id r9mr37705004lag.33.1417110291121; Thu, 27 Nov 2014 09:44:51 -0800 (PST) Received: by 10.25.30.13 with HTTP; Thu, 27 Nov 2014 09:44:51 -0800 (PST) Date: Thu, 27 Nov 2014 18:44:51 +0100 Message-ID: From: Mistr Bigs To: Bitcoin Development Content-Type: multipart/alternative; boundary=089e0160c274828d0e0508dab327 X-Spam-Score: -0.3 (/) 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 (misterbg6[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (misterbg6[at]gmail.com) 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1Xu37h-00042v-Ff 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, 27 Nov 2014 17:44:58 -0000 --089e0160c274828d0e0508dab327 Content-Type: text/plain; charset=UTF-8 I might be mistaken, but it seems to me this paper discusses unintended ways of obtaining the IP addresses of clients involved in transactions on the core Bitcoin network. Tor was mentioned only insofar as it might be one's first thought of how to mitigate this risk, yet Bitcoin over Tor has its own problems that prevent this from being effective. But the primary "issues" mentioned in the paper are regarding a Bitcoin node in default operation, no? "In their new study, researchers at the Laboratory of Algorithmics, Cryptology and Security of the University of Luxembourg have shown that Bitcoin does not protect user's IP address and that it can be linked to the user's transactions in real-time." "The basic idea behind these findings is that Bitcoin entry nodes, to which the user's computer connects in order to make a transaction, form a unique identifier for the duration of user's session. This unique pattern can be linked to a user's IP address. Moreover, transactions made during one session, even those made via unrelated pseudonyms, can be linked together. With this method, hackers can reveal up to 60 percent of the IP addresses behind the transactions made over the Bitcoin network." "'This Bitcoin network analysis combined with previous research on transaction flows shows that the level of anonymity in the Bitcoin network is quite low,' explains Dr. Alex Biryukov." M --089e0160c274828d0e0508dab327 Content-Type: text/html; charset=UTF-8

I might be mistaken, but it seems to me this paper discusses unintended ways of obtaining the IP addresses of clients involved in transactions on the core Bitcoin network.
Tor was mentioned only insofar as it might be one's first thought of how to mitigate this risk, yet Bitcoin over Tor has its own problems that prevent this from being effective.
But the primary "issues" mentioned in the paper are regarding a Bitcoin node in default operation, no?

"In their new study, researchers at the Laboratory of Algorithmics, Cryptology and Security of the University of Luxembourg have shown that Bitcoin does not protect user's IP address and that it can be linked to the user's transactions in real-time."

"The basic idea behind these findings is that Bitcoin entry nodes, to which the user's computer connects in order to make a transaction, form a unique identifier for the duration of user's session. This unique pattern can be linked to a user's IP address. Moreover, transactions made during one session, even those made via unrelated pseudonyms, can be linked together. With this method, hackers can reveal up to 60 percent of the IP addresses behind the transactions made over the Bitcoin network."

"'This Bitcoin network analysis combined with previous research on transaction flows shows that the level of anonymity in the Bitcoin network is quite low,' explains Dr. Alex Biryukov."

M

--089e0160c274828d0e0508dab327-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xu5hm-0002SE-5T for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 20:30:22 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.169 as permitted sender) client-ip=209.85.223.169; envelope-from=gmaxwell@gmail.com; helo=mail-ie0-f169.google.com; Received: from mail-ie0-f169.google.com ([209.85.223.169]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xu5hl-0006iH-Bj for bitcoin-development@lists.sourceforge.net; Thu, 27 Nov 2014 20:30:22 +0000 Received: by mail-ie0-f169.google.com with SMTP id y20so5091150ier.0 for ; Thu, 27 Nov 2014 12:30:16 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.50.228 with SMTP id f4mr29590622igo.49.1417120216106; Thu, 27 Nov 2014 12:30:16 -0800 (PST) Received: by 10.107.18.65 with HTTP; Thu, 27 Nov 2014 12:30:16 -0800 (PST) In-Reply-To: References: Date: Thu, 27 Nov 2014 20:30:16 +0000 Message-ID: From: Gregory Maxwell To: Mistr Bigs 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: 1Xu5hl-0006iH-Bj 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, 27 Nov 2014 20:30:22 -0000 On Thu, Nov 27, 2014 at 5:44 PM, Mistr Bigs wrote: > I might be mistaken, but it seems to me this paper discusses unintended ways > of obtaining the IP addresses of clients involved in transactions on the > core Bitcoin network. You're mistaken. :) If a node is used exclusively via tor it effectively doesn't have a IP address. (short of bugs of a class that aren't discussed here) The paper is about fingerprinting approaches that probabilistically connect transactions to hosts that you can already identify their IPs. 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 1Xu9gl-0002w5-D9 for bitcoin-development@lists.sourceforge.net; Fri, 28 Nov 2014 00:45:35 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.65 as permitted sender) client-ip=209.85.215.65; envelope-from=misterbg6@gmail.com; helo=mail-la0-f65.google.com; Received: from mail-la0-f65.google.com ([209.85.215.65]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xu9gk-0002Lz-Iw for bitcoin-development@lists.sourceforge.net; Fri, 28 Nov 2014 00:45:35 +0000 Received: by mail-la0-f65.google.com with SMTP id hs14so33304lab.0 for ; Thu, 27 Nov 2014 16:45:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.189.10 with SMTP id ge10mr40749845lbc.23.1417135528230; Thu, 27 Nov 2014 16:45:28 -0800 (PST) Received: by 10.25.30.13 with HTTP; Thu, 27 Nov 2014 16:45:28 -0800 (PST) Date: Fri, 28 Nov 2014 01:45:28 +0100 Message-ID: From: Mistr Bigs To: Bitcoin Development Content-Type: multipart/alternative; boundary=001a11c37016c244f50508e0933d X-Spam-Score: -0.3 (/) 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 (misterbg6[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (misterbg6[at]gmail.com) 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1Xu9gk-0002Lz-Iw 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: Fri, 28 Nov 2014 00:45:35 -0000 --001a11c37016c244f50508e0933d Content-Type: text/plain; charset=UTF-8 That's what I was trying to say... The researchers are deanonymizing transactions from non-Tor connected hosts. So why are we talking about Tor limitations in response to this? Shouldn't we be discussing how to address the issues in Bitcoin proper? M On 11/27/2014 9:30 PM, Gregory Maxwell wrote: On Thu, Nov 27, 2014 at 5:44 PM, wrote: I might be mistaken, but it seems to me this paper discusses unintended ways of obtaining the IP addresses of clients involved in transactions on the core Bitcoin network. You're mistaken. :) If a node is used exclusively via tor it effectively doesn't have a IP address. (short of bugs of a class that aren't discussed here) The paper is about fingerprinting approaches that probabilistically connect transactions to hosts that you can already identify their IPs. --001a11c37016c244f50508e0933d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That's what I was trying to say... The researcher= s are deanonymizing transactions from non-Tor connected hosts. So why are w= e talking about Tor limitations in response to this? Shouldn't we be di= scussing how to address the issues in Bitcoin proper?

On 11/27/2014 9:30 PM, Gregory Maxwell wrote:

On Thu, Nov 27, 2014 at 5:44 PM, <misterbg6@gmail.com> wrote:

I might be mistaken, but it seems to me th=
is paper discusses unintended ways
of obtaining the IP addresses of clients involved in transactions on the
core Bitcoin network.

You're mistaken. :)

If a node is used exclusively via tor it effectively doesn't have a IP =
address.

(short of bugs of a class that aren't discussed here)

The paper is about fingerprinting approaches that probabilistically
connect transactions to hosts that you can already identify their IPs.

--001a11c37016c244f50508e0933d-- 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 1XuE8f-00040Q-Vd for bitcoin-development@lists.sourceforge.net; Fri, 28 Nov 2014 05:30:42 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.171 as permitted sender) client-ip=209.85.213.171; envelope-from=gmaxwell@gmail.com; helo=mail-ig0-f171.google.com; Received: from mail-ig0-f171.google.com ([209.85.213.171]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XuE8c-0001US-7G for bitcoin-development@lists.sourceforge.net; Fri, 28 Nov 2014 05:30:41 +0000 Received: by mail-ig0-f171.google.com with SMTP id z20so5370400igj.10 for ; Thu, 27 Nov 2014 21:30:33 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr31189623igt.8.1417152632957; Thu, 27 Nov 2014 21:30:32 -0800 (PST) Received: by 10.107.18.65 with HTTP; Thu, 27 Nov 2014 21:30:32 -0800 (PST) In-Reply-To: References: Date: Fri, 28 Nov 2014 05:30:32 +0000 Message-ID: From: Gregory Maxwell To: Mistr Bigs 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: 1XuE8c-0001US-7G 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: Fri, 28 Nov 2014 05:30:42 -0000 On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs wrote: > That's what I was trying to say... The researchers are deanonymizing > transactions from non-Tor connected hosts. So why are we talking about Tor > limitations in response to this? Shouldn't we be discussing how to address > the issues in Bitcoin proper? Because if the user does not use tor or an analogous infrastructure (e.g. something else reimplementing tor's functionality) the user can be deanonymized in many different ways. At the end of the day, if I'm listening widely to the network, and your host is regularly the first to hand me your transactions then I can draw reasonably reliable conclusions... and this is true even if there is a complete absence of identifiable characteristics otherwise. 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). From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XvORf-0002Cl-AZ for bitcoin-development@lists.sourceforge.net; Mon, 01 Dec 2014 10:43:07 +0000 X-ACL-Warn: Received: from quidecco.de ([81.169.136.15]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1XvORd-0005Wk-IJ for bitcoin-development@lists.sourceforge.net; Mon, 01 Dec 2014 10:43:07 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id 9E56EE170B7; Mon, 1 Dec 2014 11:42:58 +0100 (CET) From: Isidor Zeuner To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8; format=flowed References:

<54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> In-Reply-To: Message-Id: <20141201104258.9E56EE170B7@quidecco.de> Date: Mon, 1 Dec 2014 11:42:58 +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: 1XvORd-0005Wk-IJ 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: Mon, 01 Dec 2014 10:43:07 -0000 Hi Gregory, response below quote: > > Since this attack vector has been discussed, I started making some > > measurements on how effective it is to connect to Bitcoin using Tor, > > and I found that the number of connections dropping to near-zero is > > a situation which occurs rather frequently, which suggests that there > > is still room to improve on the DoS handling. > > I'm confused by this, I run quite a few nodes exclusively on tor and > chart their connectivity and have seen no such connection dropping > behaviour. > > Can you tell me more about how you measured this? > When you say "running exclusively on Tor", what do you mean exactly? Do you also connect or allow connections through hidden services? I made outbound connections through Tor exit points the only way to connect to Bitcoin, and increased the number of allowed outbound connection in order to get more meaningful values. Lately, I could see unusual behaviour at: * 2014-11-28 13:14 UTC * 2014-11-25 07:32 UTC * 2014-11-24 13:06 UTC Anything I should look into? > [As an aside I agree that there are lots of things to improve here, > but the fact that users can in theory be forced off of tor via DOS > attacks is not immediately concerning to me because its a conscious > choice users would make to abandon their privacy (and the behaviour of > the system here is known and intentional). There are other mechanisms > available for people to relay their transactions than connecting > directly to the bitcoin network; so their choice isn't just abandon > privacy or don't use bitcoin at all.] > I think this issue is more important than it seems. Firstly, when running Tor-only, there are still attack vectors which make use of the DoS protection deficiencies. Secondly, if we tell people not to connect directly if they want privacy, how do we ensure that these indirect methods will not come with implications for their privacy? Best regards, Isidor 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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xy1Sr-0004kb-Jp for bitcoin-development@lists.sourceforge.net; Mon, 08 Dec 2014 16:47:13 +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 1Xy1Sq-0007wh-1C for bitcoin-development@lists.sourceforge.net; Mon, 08 Dec 2014 16:47:13 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id 6C492E1B59B; Mon, 8 Dec 2014 17:15:14 +0100 (CET) To: Mike Hearn From: Isidor Zeuner Content-Type: text/plain; charset=UTF-8; format=flowed References:

<54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> In-Reply-To: Message-Id: <20141208161514.6C492E1B59B@quidecco.de> Date: Mon, 8 Dec 2014 17:15:14 +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: 1Xy1Sq-0007wh-1C 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: Mon, 08 Dec 2014 16:47:13 -0000 > > > > [As an aside I agree that there are lots of things to improve here, > > but the fact that users can in theory be forced off of tor via DOS > > attacks is not immediately concerning to me because its a conscious > > choice users would make to abandon their privacy > > > Bitcoin already has a large population of users who have little or no > technical skill, it wouldn't surprise me at all if it was found to be the > clear majority by now. Assuming success and growth in future, very few > users will make any decisions at all about their privacy, they will just > accept the defaults. In such a world no consumer wallet is going to > directly expose Tor to end users - if used at all it'll just be used behind > the scenes. So automated fallback or control over exits would be a concern > for such wallets. > In order to get more synergy between Bitcoin users of varying skill levels, my suggestion would be a cleaner separation between technical mechanisms and policies (possibly suitable for users without technical skills). Core development would mean providing suitable mechanisms by which it is possible to run Bitcoin on different constraints. This may include ways to handle attacks specific to the Tor/Bitcoin combination. People who like to research what is possible with the protocol can then experiment on how these mechanisms can be used in order to mitigate these attacks. Finally, distributors of consumer wallets can use this research in order to distribute their wallet with policies which may be less prone to Tor-specific attacks. Or leave this out altogether if their audience has different expectations for connecting to Bitcoin. The tricky part is probably to figure out what is the greatest common denominator of what keeps Bitcoin stable and running while still leaving room for customized policies. But I think that separating concerns like this is better than letting a debate about how to mitigate certain Tor-related attacks evolve towards a debate about Tor or not Tor. > My gut feeling about this stuff has changed over time. I don't think it'd > be a great idea to tie Bitcoin to Tor too deeply, convenient though its > infrastructure is. Most apps don't need a whole lot of onion routing - a > small amount built in to the p2p layer would be sufficient. Tor is huge, > complicated and could be a liability in future. > I think it would be very interesting to explore alternatives for Tor. But at this point, completely abandoning Tor would mean that users either have to agree to have their transactions correlated to their IP address, or to trust their transactions to a third party where they are not subject to the security guarantees Bitcoin's logic can provide anymore. In my opinion, it's a rather huge sacrifice. What I find interesting, however, is that a lot of suggestions I see with respect to attacks related to Tor/Bitcoin (including my own) involve some kind of extra effort required for Tor users on Bitcoin in order to protect themselves against these attacks. So, it may be interesting to explore if it is viable to think of Tor's privacy guarantees as coming for free. Going from there, if it cannot be guaranteed to work completely for free, the question would be to what extent the required extra effort should be a shared effort of the network, and to what extent users requiring the improved privacy should use their own resources in order to make it possible. Best regards, Isidor From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xy1eU-0007CK-5o for bitcoin-development@lists.sourceforge.net; Mon, 08 Dec 2014 16:59:14 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.179 as permitted sender) client-ip=209.85.212.179; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f179.google.com; Received: from mail-wi0-f179.google.com ([209.85.212.179]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xy1eS-00053N-PW for bitcoin-development@lists.sourceforge.net; Mon, 08 Dec 2014 16:59:14 +0000 Received: by mail-wi0-f179.google.com with SMTP id ex7so5419134wid.6 for ; Mon, 08 Dec 2014 08:59:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.76.239 with SMTP id n15mr18338522wiw.66.1418057946735; Mon, 08 Dec 2014 08:59:06 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.9 with HTTP; Mon, 8 Dec 2014 08:59:06 -0800 (PST) In-Reply-To: <20141208161514.6C492E1B59B@quidecco.de> References: <54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> <20141208161514.6C492E1B59B@quidecco.de> Date: Mon, 8 Dec 2014 17:59:06 +0100 X-Google-Sender-Auth: bMlElvLdJH88xR6T6o4gpx2uc08 Message-ID: From: Mike Hearn To: Isidor Zeuner Content-Type: multipart/alternative; boundary=f46d043749b32faa800509b7586e X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1Xy1eS-00053N-PW 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: Mon, 08 Dec 2014 16:59:14 -0000 --f46d043749b32faa800509b7586e Content-Type: text/plain; charset=UTF-8 > > Finally, distributors of consumer wallets can use this research in > order to distribute their wallet with policies which may be less prone > to Tor-specific attacks. Or leave this out altogether if their > audience has different expectations for connecting to Bitcoin. > Sure. I guess there will be wallets for all kinds of people in future, sharing a common core that they can customise (this is certainly the vision and general direction for bitcoinj, and it's working out OK). To clarify, my comments above were for mainstream granny-focused wallets. Wallets designed for crypto geeks can and should expose all the knobs to let people run wild. One possible direction to go is to use Tor for writing to the network and use general link encryption and better Bloom filtering for reading it. Thus new transactions would pop out of Tor exits, but there isn't much they can do that's malicious there except mutate them or block them entirely. If you insert the same transaction into the P2P network via say 10 randomly chosen exits, the worst a malicious mutator can do is race the real transaction and that's no different to a malicious P2P node. Even in a world where an attacker has DoS-banned a lot of nodes and now controls your TX submission path entirely, it's hard to see how it helps them. The nice thing about the above approach is that it solves the latency problems. Startup speed is really an issue for reading from the network: just syncing the block chain is already enough of a speed hit without adding consensus sync as well. But if you're syncing the block chain via the clearnet you can connect to Tor in parallel so that by the time the user has scanned a QR code, verified the details on the screen and then pressed the Pay button, you have a warm connection and can upload the TX through that. It reduces the level of startup time optimisation needed, although Tor consensus download is still too slow even to race a QR code scan at the moment. I think tuning the consensus caching process and switching to a fresh one on the fly might be the way to go. When BIP70 is in use, you wouldn't write the tx to the network yourself but you could download the PaymentRequest and upload the Payment message via an SSLd Tor connection to the merchant. Then malicious exits can only DoS you but not do anything else so there's no need for multiple exit paths simultaneously. --f46d043749b32faa800509b7586e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Finally, distributors of consumer wallets can us= e this research in
order to distribute their wallet with policies which may be less prone
to Tor-specific attacks. Or leave this out altogether if their
audience has different expectations for connecting to Bitcoin.

Sure. I guess there will be wallets for all kinds o= f people in future, sharing a common core that they can customise (this is = certainly the vision and general direction for bitcoinj, and it's worki= ng out OK).

To clarify, my comments above were for= mainstream granny-focused wallets. Wallets designed for crypto geeks can a= nd should expose all the knobs to let people run wild.

=C2=A0

One possible direction to go is to use Tor for writing to the networ= k and use general link encryption and better Bloom filtering for reading it= . Thus new transactions would pop out of Tor exits, but there isn't muc= h they can do that's malicious there except mutate them or block them e= ntirely. If you insert the same transaction into the P2P network via say 10= randomly chosen exits, the worst a malicious mutator can do is race the re= al transaction and that's no different to a malicious P2P node. Even in= a world where an attacker has DoS-banned a lot of nodes and now controls y= our TX submission path entirely, it's hard to see how it helps them.

The nice thing about the above approach is that it s= olves the latency problems. Startup speed is really an issue for reading fr= om the network: just syncing the block chain is already enough of a speed h= it without adding consensus sync as well. But if you're syncing the blo= ck chain via the clearnet you can connect to Tor in parallel so that by the= time the user has scanned a QR code, verified the details on the screen an= d then pressed the Pay button, you have a warm connection and can upload th= e TX through that. It reduces the level of startup time optimisation needed= , although Tor consensus download is still too slow even to race a QR code = scan at the moment. I think tuning the consensus caching process and switch= ing to a fresh one on the fly might be the way to go.

<= div>When BIP70 is in use, you wouldn't write the tx to the network your= self but you could download the PaymentRequest and upload the Payment messa= ge via an SSLd Tor connection to the merchant. Then malicious exits can onl= y DoS you but not do anything else so there's no need for multiple exit= paths simultaneously.

--f46d043749b32faa800509b7586e-- 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-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 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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y0VeN-0002Vy-GD for bitcoin-development@lists.sourceforge.net; Mon, 15 Dec 2014 13:25:23 +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 1Y0VeL-0006kl-Jl for bitcoin-development@lists.sourceforge.net; Mon, 15 Dec 2014 13:25:23 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id BCC88E2353B; Mon, 15 Dec 2014 14:25:14 +0100 (CET) To: Wladimir Content-Type: text/plain; charset=UTF-8; format=flowed From: Isidor Zeuner References:

<54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> In-Reply-To: Message-Id: <20141215132514.BCC88E2353B@quidecco.de> Date: Mon, 15 Dec 2014 14:25:14 +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: 1Y0VeL-0006kl-Jl 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: Mon, 15 Dec 2014 13:25:23 -0000 [...] > > I'm confused by this, I run quite a few nodes exclusively on tor and > > chart their connectivity and have seen no such connection dropping > > behaviour. > > In my experience the problem has always been getting bootstrapped. > Most nodes hardly give any hidden service nodes in their getaddr. > (this has been improved in master by including a set of hidden service > seed nodes) > But this assumes -onlynet=tor. Tor with exit nodes should be less > problematic, unless someone managed to DoSban all the exit nodes as > described in the paper (but I've never seen such an attack myself). > When refering to "getting bootstrapped", do you only mean collecting node addresses, or also syncing blocks? If you're saying the drops in connection counts are likely to be not caused by a DoSban attack on the exit nodes, what could be other reasons to look into? > > Can you tell me more about how you measured this? > > > > [As an aside I agree that there are lots of things to improve here, > > but the fact that users can in theory be forced off of tor via DOS > > attacks is not immediately concerning to me because its a conscious > > choice users would make to abandon their privacy (and the behaviour of > > the system here is known and intentional). There are other mechanisms > > available for people to relay their transactions than connecting > > directly to the bitcoin network; so their choice isn't just abandon > > privacy or don't use bitcoin at all.] > > Right, there's something to be said for splitting your own transaction > submission from normal P2P networking and transaction relay. > (esp for non-SPV wallets which don't inherently leak any information > about their addresses) > > There was a pull request about this for Bitcoin Core one, maybe I > closed it unfairly https://github.com/bitcoin/bitcoin/issues/4564 . > Great! I find it very interesting to research options for splitting communication between Tor and non-Tor as long as the introduced information leakage between both connection methods can be proved to be nonexistent or negligible. In the case of Bitcoin, this makes me wonder about an attack that could look approximately like this: * Node A connects to Bitcoin using Tor (for submitting transactions) and IPv4 (for all other communication). * Node B strives for direct IPv4 connections with node A * Node B uses the direct IPv4 connections in order to supply Node A with additional peer addresses not supplied to any other nodes * Node B observes these additional peer addresses For transactions submitted to the additional peer addresses supplied by node B, how to prevent that the probability of these originating from node A is higher than for originating from other nodes? For handling block propagation using non-Tor connections, it's probably harder to create information leaks, as the logic for handling disagreement about blocks is pretty well-researched, meaning that it's less important where the blocks come from. Best regards, Isidor From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YE6Em-0000ZT-QB for bitcoin-development@lists.sourceforge.net; Thu, 22 Jan 2015 01:07:08 +0000 X-ACL-Warn: Received: from quidecco.de ([81.169.136.15]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YE6El-0002W9-6a for bitcoin-development@lists.sourceforge.net; Thu, 22 Jan 2015 01:07:08 +0000 Received: from localhost (localhost [127.0.0.1]) by quidecco.de (Postfix) with SMTP id 93EFDE27748; Thu, 22 Jan 2015 01:44:16 +0100 (CET) From: Isidor Zeuner To: Mike Hearn Content-Type: text/plain; charset=UTF-8; format=flowed References:

<54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> <20141208161514.6C492E1B59B@quidecco.de> In-Reply-To: Message-Id: <20150122004416.93EFDE27748@quidecco.de> Date: Thu, 22 Jan 2015 01:44:16 +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: 1YE6El-0002W9-6a 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, 22 Jan 2015 01:07:08 -0000 Hi there, some thoughts in-line: > > > > Finally, distributors of consumer wallets can use this research in > > order to distribute their wallet with policies which may be less prone > > to Tor-specific attacks. Or leave this out altogether if their > > audience has different expectations for connecting to Bitcoin. > > > > Sure. I guess there will be wallets for all kinds of people in future, > sharing a common core that they can customise (this is certainly the vision > and general direction for bitcoinj, and it's working out OK). > > To clarify, my comments above were for mainstream granny-focused wallets. > Wallets designed for crypto geeks can and should expose all the knobs to > let people run wild. > I hear that. But I don't see why mainstream wallets and wallets designed for crypto research should not share a common core. Nor do I understand why having a common core for different types of wallets should be reserved for BitcoinJ. When Bitcoin was pretty new, having a less customizable core did probably have more of a merit in order to achieve network stability through monoculture. But as of today, Bitcoin has proven itself as being capable of allowing a variety of client application to run on the network, so why should the reference implementation not reflect this kind of diversity? The policy the mainstream distribution imposes upon the core can still be rather restrictive. > One possible direction to go is to use Tor for writing to the network and > use general link encryption and better Bloom filtering for reading it. Thus > new transactions would pop out of Tor exits, but there isn't much they can > do that's malicious there except mutate them or block them entirely. If you > insert the same transaction into the P2P network via say 10 randomly chosen > exits, the worst a malicious mutator can do is race the real transaction > and that's no different to a malicious P2P node. Even in a world where an > attacker has DoS-banned a lot of nodes and now controls your TX submission > path entirely, it's hard to see how it helps them. > It might deserve some research in order to determine how Tor's privacy guarantees might be impacted if we allow attackers to mess around with exit node choices in a rather predictable and low-cost manner. Unfortunately, I can't think of another (non-Bitcoin) application which puts Tor to a similar test. > The nice thing about the above approach is that it solves the latency > problems. Startup speed is really an issue for reading from the network: > just syncing the block chain is already enough of a speed hit without > adding consensus sync as well. But if you're syncing the block chain via > the clearnet you can connect to Tor in parallel so that by the time the > user has scanned a QR code, verified the details on the screen and then > pressed the Pay button, you have a warm connection and can upload the TX > through that. It reduces the level of startup time optimisation needed, > although Tor consensus download is still too slow even to race a QR code > scan at the moment. I think tuning the consensus caching process and > switching to a fresh one on the fly might be the way to go. > I do agree that hybrid clearnet/Tor approaches come with interesting performance properties. > When BIP70 is in use, you wouldn't write the tx to the network yourself but > you could download the PaymentRequest and upload the Payment message via an > SSLd Tor connection to the merchant. Then malicious exits can only DoS you > but not do anything else so there's no need for multiple exit paths > simultaneously. > BIP70 is interesting, indeed, although I still fail to understand why (according to the specs I saw) the PaymentRequest message is signed, but not the Payment message. But in context of the discussed protocol issues, I think it just moves the issue from the payer to the payee, so it may or may not partially relieve network-related issues, depending on the usage scenario. Best regards, Isidor From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YEHga-0004tU-8U for bitcoin-development@lists.sourceforge.net; Thu, 22 Jan 2015 13:20:36 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.170 as permitted sender) client-ip=209.85.212.170; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f170.google.com; Received: from mail-wi0-f170.google.com ([209.85.212.170]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YEHgZ-0006CX-3o for bitcoin-development@lists.sourceforge.net; Thu, 22 Jan 2015 13:20:36 +0000 Received: by mail-wi0-f170.google.com with SMTP id em10so21582403wid.1 for ; Thu, 22 Jan 2015 05:20:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.126.99 with SMTP id mx3mr5250399wib.66.1421932829110; Thu, 22 Jan 2015 05:20:29 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.194.188.9 with HTTP; Thu, 22 Jan 2015 05:20:29 -0800 (PST) In-Reply-To: <20150122004416.93EFDE27748@quidecco.de> References: <54760A50.201@riseup.net> <20141127020947.A13D2E19A09@quidecco.de> <20141208161514.6C492E1B59B@quidecco.de> <20150122004416.93EFDE27748@quidecco.de> Date: Thu, 22 Jan 2015 14:20:29 +0100 X-Google-Sender-Auth: ECu5DAIxO6DEgBkWe-wSgnvsbNw Message-ID: From: Mike Hearn To: Isidor Zeuner Content-Type: multipart/alternative; boundary=e89a8f8389d12c78f5050d3d894a X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1YEHgZ-0006CX-3o 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, 22 Jan 2015 13:20:36 -0000 --e89a8f8389d12c78f5050d3d894a Content-Type: text/plain; charset=UTF-8 > > I hear that. But I don't see why mainstream wallets and wallets > designed for crypto research should not share a common core. > I think there was some misunderstanding. I was saying they *could and should* share common cores, so we are in agreement without realising it :) I also didn't mean to imply there was anything special about bitcoinj, just that it's an example of a wallet engine that's already in use. > BIP70 is interesting, indeed, although I still fail to understand why > (according to the specs I saw) the PaymentRequest message is signed, > but not the Payment message. > Because it's intended to be submitted via HTTPS. But what would you sign the message with? Some arbitrary key bound to the transaction? --e89a8f8389d12c78f5050d3d894a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I hear that. But I don't see why mainstream = wallets and wallets
designed for crypto research should not share a common core.

I think there was some misun= derstanding. I was saying they could and should=C2=A0share common co= res, so we are in agreement without realising it :) I also didn't mean = to imply there was anything special about bitcoinj, just that it's an e= xample of a wallet engine that's already in use.

=C2=A0

BIP70 is interesting, indeed, although I sti= ll fail to understand why
(according to the specs I saw) the PaymentRequest message is signed,
but not the Payment message.

Because it= 's intended to be submitted via HTTPS. But what would you sign the mess= age with? Some arbitrary key bound to the transaction?

--e89a8f8389d12c78f5050d3d894a--