From: Isidor Zeuner <cryptocurrencies@quidecco•de>
To: Wladimir <laanwj@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
Date: Mon, 15 Dec 2014 14:25:14 +0100 (CET) [thread overview]
Message-ID: <20141215132514.BCC88E2353B@quidecco.de> (raw)
In-Reply-To: <CA+s+GJBsxmQJkrUYekFuUOgmEcD7qeL2e9Rf-d2nD1G1N7c_EQ@mail.gmail.com>
[...]
> > 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
next prev parent reply other threads:[~2014-12-15 13:25 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 [this message]
2014-12-01 10:42 ` Isidor Zeuner
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=20141215132514.BCC88E2353B@quidecco.de \
--to=cryptocurrencies@quidecco$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=laanwj@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