From: Isidor Zeuner <cryptocurrencies@quidecco•de>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
Date: Mon, 1 Dec 2014 11:42:58 +0100 (CET) [thread overview]
Message-ID: <20141201104258.9E56EE170B7@quidecco.de> (raw)
In-Reply-To: <CAAS2fgRSxBmyDg5R7WgisB-XmhrpGVKHXQpchtL-Ow0xDQAziA@mail.gmail.com>
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
next prev parent reply other threads:[~2014-12-01 10:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-26 7:47 Jean-Paul Kogelman
2014-11-26 13:51 ` Jeff Garzik
2014-11-26 17:13 ` odinn
2014-11-27 2:09 ` Isidor Zeuner
2014-11-27 2:22 ` Gregory Maxwell
2014-11-27 11:06 ` Mike Hearn
2014-11-27 11:27 ` Wladimir
2014-12-08 16:15 ` Isidor Zeuner
2014-12-08 16:59 ` Mike Hearn
2015-01-22 0:44 ` Isidor Zeuner
2015-01-22 13:20 ` Mike Hearn
2014-12-15 13:25 ` Isidor Zeuner
2014-12-01 10:42 ` Isidor Zeuner [this message]
2014-11-27 17:44 Mistr Bigs
2014-11-27 20:30 ` Gregory Maxwell
2014-11-28 0:45 Mistr Bigs
2014-11-28 5:30 ` Gregory Maxwell
2014-12-11 11:51 ` Isidor Zeuner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141201104258.9E56EE170B7@quidecco.de \
--to=cryptocurrencies@quidecco$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox