[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Bitcoin over Tor isnât a good idea (Alex Biryukov / Ivan Pustogarov story)
...and this is precisely why I asked! The documentation on setting up a
bitcoin node is very....sparse, so I had to guess.
This is my current bitcoin configuration:
Since it has been indicated that this doesn't work, I am adding this:
The documentation indicated that tor= was the right answer, but mebbie not.
Nothing has indicated I am unable to run a node that listens on tor as well
as the public internet. I am not abundantly concerned about the anonymnity
of the bitcoin node which is why I'll run as all three.
Also I've noticed that tor is most certainly the... alpha partner in
iptables OUTPUT chain, zeroed at the same time:
pkts bytes target prot opt in out source
1187M 1371G TOR tcp -- * * 0.0.0.0/0
0.0.0.0/0 owner UID match 103 /* 100-v4 tor outgoing traffic */
8643K 7662M ACCEPT tcp -- * * 0.0.0.0/0
0.0.0.0/0 owner UID match 109 /* 101-v4 bitcoin outgoing traffic
It looks like I'll have to tinker with the onion stuff a bit. A twenty
dollar/month dedicated server lets me do a lot of tinkering and some
On Tue, Oct 28, 2014 at 9:30 PM, s7r <s7r@xxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> One question: how did you configure your Bitcoin node to be functional
> on v4,v6 and .onion at the same time?
> For example, the Tor hidden service node needs to have the following
> setting in bitcoin.conf:
> This will teach the daemon the .onion IP address it needs to advertise
> to other peers. It has no other way to learn this address except if
> you manually copy/paste it in bitcoin.conf
> I don't know how this affects the v4 and v6 interfaces, do you have
> multiple externalip= arguments in bitcoin.conf (in order to advertise
> the public v4 and v6 addresses too)? Is it possible this way?
> Can you please remove the sensitive data and copy/paste your
> bitcoin.conf? I am interested only in Listen=, Bind=, proxy= and
> externalip= as well as other connectivity entries.
> I don't run Tor hidden bitcoin nodes and clearnet nodes at the same
> time on the same instance (or even on the same server). I run bridge
> Bitcoin nodes in parallel. The bridge Bitcoin nodes help broadcast the
> information received from other Tor hidden peers to clearnet peers
> (since we do not want an island or a separate network - the clearnet
> and Tor hidden services network need to be glued together as a whole
> A bridge Bitcoin node is configured as a regular clearnet Bitcoin
> node. Additionally, you install Tor, and simply add in bitcoin.conf:
> Where 127.0.0.1:9050 is the Tor socks5 listener. Substitute the port
> if different. This setting tells the bitcoin daemon about the channel
> to reach .onion peers. For the rest of the clearnet peers it will use
> as default, its own public IP. Now this node exchanges information
> with .onion peers and clearnet peers simultaneous just fine,
> broadcasting the information from Tor hidden peers to clearnet peers.
> On 10/28/2014 7:18 PM, eric gisse wrote:
> > To that end, I setup a bitcoin node that listens on the v4/v6
> > internet as well as tor.
> > The hidden service address is dsyadrvivtt34s26.onion
> > Could some folks please test this for me and make sure it works for
> > others? I can see it is quite happily running on v4/v6 (and getting
> > traffic) but its' less obvious that it is working over tor.
> > On Mon, Oct 27, 2014 at 3:03 PM, Thomas White
> > <thomaswhite@xxxxxxxxxx> wrote:
> > I didn't realise my nodes didn't allow the bitcoin port. I'll get
> > right on it.
> > Also, if anyone in the Tor community has spare capacity, you can
> > also setup a full bitcoin node on the same server you use as an
> > exit/relay/bridge and it doesn't take up a great deal of resources
> > other than disk space (16Gb I think right now and growing slowly).
> > On my series of exits there is also full bitcoin nodes accessible
> > exclusively over hidden services and others which are accessible
> > over regular clearnet.
> > -T
> > On 27/10/2014 19:58, grarpamp wrote:
> >>>> On Thu, Oct 23, 2014 at 7:35 PM, Erik de Castro Lopo
> >>>> <mle+tools@xxxxxxxxxxxxx> wrote:
> >>>> http://arxiv.org/pdf/1410.6079v1.pdf
> >>>>> Could this situation be improved if people ran limited exit
> >>>>> nodes that only alloed the bitcoin p2p protocol to exit? I
> >>>>> for one don't have enough
> >>>> There are about ten exit nodes that do only this today. [One
> >>>> of which is run by Mike Hearn who has advocated building in
> >>>> censorship capabilities to Tor, and blocking (historically)
> >>>> tainted coins (such as you have now or might receive through
> >>>> otherwise completely innocent transactions with you, or from
> >>>> your own trans/mixing with others).]
> >>>> Then there is question if your client will select such 'only
> >>>> *coin' nodes versus those with high bandwidth and open exit
> >>>> policies.
> >>>> There are also a fair number of hidden services in
> >>>> Tor/I2P/CJDNS that act as bitcoin nodes.
> >>>> As related tangent, yes, the bitcoin protocol needs to be
> >>>> encrypted on the wire, at least bitcoin node to bitcoin node
> >>>> with TLS, obviously and urgently so, particularly if you wish
> >>>> to guard your trans from wire listeners.
> >>>> You might be best to in fact run bitcoin always and entirely
> >>>> over Tor, especially while transacting. But then also
> >>>> routinely compare that received blockchain to one you receive
> >>>> via alternate/trusted sources, such as clearnet or signed
> >>>> bittorrent checkpoints.
> >> -- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To
> >> unsubscribe or change other settings go to
> >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
> -----END PGP SIGNATURE-----
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change other settings go to
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to