1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
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 <pete@petertodd.org>) id 1V4EhI-0006yd-Hm
for bitcoin-development@lists.sourceforge.net;
Tue, 30 Jul 2013 18:31:00 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.110 as permitted sender)
client-ip=62.13.148.110; envelope-from=pete@petertodd.org;
helo=outmail148110.authsmtp.com;
Received: from outmail148110.authsmtp.com ([62.13.148.110])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1V4EhG-0005rN-HY for bitcoin-development@lists.sourceforge.net;
Tue, 30 Jul 2013 18:31:00 +0000
Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233])
by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id
r6UIUof8056688; Tue, 30 Jul 2013 19:30:50 +0100 (BST)
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r6UIUhxw092066
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 30 Jul 2013 19:30:45 +0100 (BST)
Date: Tue, 30 Jul 2013 14:30:43 -0400
From: Peter Todd <pete@petertodd.org>
To: Bazyli Zygan <b@grabhive.com>
Message-ID: <20130730183043.GA32398@petertodd.org>
References: <FB36762E8B574F7AAB7D25618841CF01@grabhive.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="xHFwDpU9dbj6ez1V"
Content-Disposition: inline
In-Reply-To: <FB36762E8B574F7AAB7D25618841CF01@grabhive.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 2678b90c-f946-11e2-a49c-0025907707a1
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdQIUEkAYAgsB AmUbWl1eU117XWU7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQxpk f3tGGl5yfgdGfng+ ZEJnWHIVXkJ9fRR0
Qh1JQ2QCY3phaTUd TRFcflBJcANIexZF bVd/UyIMLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDIjkm DxkEEX0FHFEOQCQ1 RwAA
X-Authentic-SMTP: 61633532353630.1021:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1V4EhG-0005rN-HY
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Tor and Bitcoin
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2013 18:31:00 -0000
--xHFwDpU9dbj6ez1V
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 c=
ome 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 thu=
mb 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.
>=20
> While the scenario outlined seems unlikely, it's best to be prepared... W=
hat 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 bi=
tcoind, 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.
--=20
'peter'[:-1]@petertodd.org
00000000000000321cb1ef9de9c4a6c470c7f88c4b85bcee3a63121e31096fef
--xHFwDpU9dbj6ez1V
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlH4BlMACgkQpEFN739thoyvlgCghiXIyAtAYjsZr2nVJh+9mUDF
UUUAnRH8Czs3aaIyh9Q67Bqx7GJKGjQX
=46kp
-----END PGP SIGNATURE-----
--xHFwDpU9dbj6ez1V--
|
