public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Bazyli Zygan <b@grabhive.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Tor and Bitcoin
Date: Tue, 30 Jul 2013 14:30:43 -0400	[thread overview]
Message-ID: <20130730183043.GA32398@petertodd.org> (raw)
In-Reply-To: <FB36762E8B574F7AAB7D25618841CF01@grabhive.com>

[-- Attachment #1: Type: text/plain, Size: 3825 bytes --]

On Tue, Jul 30, 2013 at 02:01:39PM +0200, Bazyli Zygan wrote:
> > I think to support Tor really well [in bitcoinj], we'd need not only to make SOCKS work, but also add a way to use hidden peers and then try and come up with an anti-sybil heuristic. Unfortunately it's unclear what such a heuristic would look like. Bitcoin-Qt uses different /16s as a rule of thumb when on the clearnet, but no such technique is usable on Tor because by definition you aren't supposed to know anything about the hidden peers.
> 
> While the scenario outlined seems unlikely, it's best to be prepared... What do you all think? How can this be done properly?

There was a good reply to those concerns last time the issue came up:

    Tor does not act as a particularly effective man in the middle for nodes
    that support connections to hidden services because while your
    connections to standard Bitcoin nodes go through your exit node, the
    routing path for each hidden service peer is independent. Having said
    that we should offer modes that send your self-generated transactions
    out via Tor, while still maintaining non-Tor connections.

    Anyway Sybil attacks aren't all that interesting if you are the one
    sending the funds, and receivers are reasonably well protected simply
    because generating false confirmations is extremely expensive and very
    difficult to do quickly. After all, you always make the assumption that
    nearly all hashing power in existence is honest when you talk about
    replace-by-fee among other things, and that assumption naturally leads
    to the conclusion that generating false confirmations with a sybil
    attack would take more than long enough that the user would be
    suspicious that something was wrong long before being defrauded.

    I'd be surprised if anyone has ever bothered with a false confirmation
    sybil attack. I wouldn't be the slightest bit surprised if the NSA is
    recording all the Bitcoin traffic they can for future analysis to find
    true transaction origins. Which reminds me, again, we need node-to-node
    connections to be encrypted to at least protect against network-wide
    passive sniffiing.

    Regarding usage I would be interested to hear from those running Bitcoin
    nodes advertising themselves as hidden services.
    -http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02438.html

tl;dr: Users should be using Tor to preserve their privacy and the MITM
risks are minimal to anyone using Bitcoin correctly. (don't trust
zero-conf transactions, they are not secure!)

> Gregory Maxwell is the person who wrote the hidden service support for bitcoind, right? It might be interesting to get his comments here.

Yeah, he had the idea of adding .onion addresses of seed nodes
along-side the DNS seeds table; that would give an end-to-end MITM-proof
channel to a trusted seed who can in turn give an honest view of the
network.

Ideally those .onion addresses would be of nodes run by the same people
as running the existing seeds so that it was clear who was being trusted
- I'll write a patch to do this soon with a .onion testnet seed first.
(I run one of the testnet DNSSEED seeds and have a small grant from the
foundation to do so)

Bitcoin relays .onion addresses over the P2P network, so once you are
connected you can gain additional peers with addresses that are MITM
resistant. Currently there isn't any equivalent to the (weak) anti-sybil
properties of IP address range diversity for .onion's, but in the future
we'll eventually add node identities and some way to make creating lots
of fake identities for a sybil attack expensive.

-- 
'peter'[:-1]@petertodd.org
00000000000000321cb1ef9de9c4a6c470c7f88c4b85bcee3a63121e31096fef

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  parent reply	other threads:[~2013-07-30 18:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-30 12:01 [Bitcoin-development] Tor and Bitcoin Bazyli Zygan
2013-07-30 12:41 ` Mike Hearn
2013-07-30 14:01   ` Jeff Garzik
2013-07-30 17:02     ` Wendell
2013-07-30 17:20       ` Bazyli Zygan
2013-07-30 18:30 ` Peter Todd [this message]
2013-07-30 19:36   ` Wendell
2013-07-30 20:11     ` Peter Todd
2013-07-30 20:12       ` Peter Todd

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=20130730183043.GA32398@petertodd.org \
    --to=pete@petertodd.org \
    --cc=b@grabhive.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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