From: Mike Hearn <mike@plan99•net>
To: Brooks Boyd <boydb@midnightdesign•ws>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Tor / SPV
Date: Thu, 16 Jan 2014 11:25:18 +0100 [thread overview]
Message-ID: <CANEZrP3ZmahH8tY4zyLK5wCUVsj2e+w8wfCHz5Z4_w5GXTiqPA@mail.gmail.com> (raw)
In-Reply-To: <CANg-TZAyr8LyRQ5e4DpQA8fXEbGq6kxv=peB9oYB+bU_xA98ww@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2005 bytes --]
Yes correct, using hidden services just as a kind of more complicated, out
of process/sandboxable SSL.
> would the overall transactions/second the Bitcoin network could handle go
> down?
>
If all nodes talked to each other all the time over Tor, probably yes
because Bitcoin is quite sensitive to latency. But what I'm proposing here
is less ambitious. It's just about protecting (parts of)
end-user-to-network communication, which is a much less risky sort of
change. P2P nodes would still talk to each other in the clear.
SSL for everything is still an idea I like, but it's true that increasing
bitcoind attack surface area is not something to take lightly.
Considering that the clearnet sybil protection also relies on scaling
> up the resource requirements for an attacker, why not require hidden
> service addresses following a certain pattern, like a fixed prefix?
I'm sure we can come up with all kinds of neat anti-sybil techniques, but
IMHO they are separate projects. I'm trying to find an upgrade that's small
enough to be easily switched on by default for lots of users, today, that
is low risk for the network overall. Later on we can add elaborations.
The SPV node could connect to the IP using Tor. It would preserve the
> privacy of the SPV node - hard to see it's running Bitcoin. It also
> reduces the ability of an attacker to MITM because the routing varies
> with each exit node.
Right so the key question is, to what extent does Tor open you up to MITM
attacks? I don't have a good feel for this. I read about exit nodes
routinely doing very naughty things, but I don't know how widespread that
is. Probably you're right that with random selection of exits you're not
excessively likely to get MITMd.
How does Tor itself manage anti-sybil? I know they have the directory
consensus and they measure nodes to ensure they're delivering the resources
they claim to have. Punting anti-sybil up to the Tor people and letting
them worry about it is quite an attractive idea.
[-- Attachment #2: Type: text/html, Size: 3264 bytes --]
next prev parent reply other threads:[~2014-01-16 10:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-15 22:51 Mike Hearn
2014-01-15 23:07 ` Brooks Boyd
2014-01-15 23:32 ` Mike Hearn
2014-01-16 2:26 ` Brooks Boyd
2014-01-16 4:30 ` Miron
2014-01-16 10:25 ` Mike Hearn [this message]
2014-01-16 3:54 ` Isidor Zeuner
2014-01-15 23:37 ` Robert McKay
2014-01-16 4:29 ` Miron
2014-01-16 4:40 ` Miron
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=CANEZrP3ZmahH8tY4zyLK5wCUVsj2e+w8wfCHz5Z4_w5GXTiqPA@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=boydb@midnightdesign$(echo .)ws \
/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