This is not a thorough schooling on Tor and only shows how to configure it to work together with Bitcoin Core.
Bitcoin Core includes Tor integration
When Tor is correctly setup on your system, Bitcoin Core automatically identifies Tor and creates an anonymous service. Little configuration is required to be 'off the grid' and, just a tiny bit more to be ...
Jon Atack answered this on Twitter.
Configuration and setup
First install and start I2P (version 2.35 or above).
$ apt install i2pd
$ systemctl enable i2pd.service
$ systemctl start i2pd.service
In your bitcoin.conf file add (I will assume you run Bitcoin Core v22+ and want to use both Tor and I2P but remove debug=tor and onlynet=onion if not interested in ...
Generally if you read BOLT 07 you will see that lightning nodes and channels can either be private or public.
This is independent of the fact if they run on tor or not.
The node announcment message explicitly supports announcing that it runs on tor as written in the BOLT 07
The following address descriptor types are defined:
1: ipv4; data = [4:...
It probably doesn't give you more security, and in fact if the mixer service's coin volumes are low, which they likely are, and dependent on whatever their turn around time may be, and dependent on how many coins you are asking them to mix, it is very possible for you to get back some of the same coins you sent to them. Unless they were verifiably in a ...
The answer to your question is a clear NO, as two very different problems are being tackled but the onion routing in the TOR network and by the Onion Routing in BOLT 04.
The idea of the Tor network is to hide your IP address. If you run your lightning node on a tor onion you will have a tor address and not even your channel partners can know where your ...
Basically as fast as a regular payment. The encrypted onion is being transported from node to node and will most likely leave the TOR network pretty quickly as many connections in lightning happen with direct IP connections.
The path calculation is happening locally on your node and does not need communication with your peers at the time when the payment is ...
The onion routing in Lightning is based on the Sphinx Mix Format described in this paper. The situation is different from Tor
We don't have entry and exit nodes in Lightning as all nodes are inside the Network.
In Tor a new connection along the path is as easy as creating a TCP socket between the tor routing nodes. In Lightning a payment channel with ...
Armory (in online mode) uses a full node. Full nodes relay transactions for other programs on the Bitcoin network, so by running Armory on Tor, you help other people send their transactions with possibly-improved privacy.
Sending your own transactions through Tor with Armory can help prevent anyone from associating your IP address with your transaction, ...
The paper you link to when used as advice rather than a scholarly investigation into the tradeoffs of different choices is outright bad advice.
The attacks they give are largely generic and have little to do with tor itself, while use of tor provides non-trivial protection against many other vectors, and if used consistently and exclusively at least ...
Using Tor doesn't help to prevent someone from linking addresses and guessing that they might be owned by the same person.
It may help to keep someone from finding out who that owner actually is, where they live, etc.
Running lightning node over TOR is no different than running it over normal IP connection. Sending payment, fulfilling incoming payment, sending error messages etc. would happen in the exact same way in both cases. The only difference is that the above messages that you send to your peer will now happen over TOR network rather than a direct IP package.
Of the 18 outbound connections, one is to a peer which offers COMPACT_FILTERS BIP 158 service. (I got the name from a list of optional node services provided here in Dec. 2019.) And here it says that a node can provide BIP 157 service by setting peerblockfilters=1. How is BIP 158 service provided?
The separation between BIP158 and BIP157 is somewhat murky, ...
Bitcoin Core no longer contains any mining code, so it's definitely not mining. (If it were, you'd see 100% CPU usage.) Mining has nothing to do with the behavior you are seeing.
You're downloading the entire block chain (150+ GB) and checking it for validity, which explains the CPU usage. The UpdateTip message simply records that you've received a new ...
Low-latency transmissions over Tor can be defeated with a timing attack if you're connected to several of the attacker's nodes and the attacker is watching your transmissions at your ISP.
The attacker can relay only blocks that he/she creates, putting you on a Bitcoin fork (separate from the main chain). After that you would be open to double-spending ...
Your settings look correct for the versions you would have been using, I do not know about bitseed.conf however.
For a more up to date guide for setting up Bitcoin Core to run over Tor, you can try this question. Bitcoin Core now supports automatically configuring an ephemeral Tor service, for example.
Using a mixer helps preserve your financial privacy. The question is: who are you protecting your privacy from?
Bitcoin transactions are public record, so anybody can view any historical transaction at their leisure. So when considering your privacy, there are a few different situations worth exploring, for example:
An unrelated third party is looking at ...
The node side of Bitcoin Core treats wallet transactions as any other transaction. They aren't treated any differently from transactions received over the network. So once the transaction is added to the node's mempool, it will be broadcast to connected nodes in the same way that any other transaction would be relayed.
All you can do is to ...
My suggestion: Don't use windows AT ALL. Easiest way to get hacked.
also here's the answers you are looking for https://en.bitcoin.it/wiki/Tor
specifically this line:
"(after starting tor) Run bitcoind with -proxy=127.0.0.1:9050"
Unfortunately there is a library used in MultiBit/ bitcoinj for networking (called netty) that does not support SOCKS proxies. Thus currently you cannot set up MultiBit to use Tor.
It is something we want to support so there are plans afoot to refactor the code and use a different networking library that does support SOCKS proxies.
Almost all of the drawbacks of using bitcoin over Tor revolve around the fact that your node can't trust that it isn't segmented from the network and thus can't truly verify the state of the network it sees is real. So if you ran two bitcoin nodes (both with the same privkey), one on the clearnet just to have an accurate view of the network and the other ...
No, it's a bad idea to run bitcoin over tor if your striving for anonymity. Here is a paper detailing the vulnerability.
While Bitcoin provides some level of anonymity (or rather pseudonymity) by encouraging the users to have any number of random-looking Bitcoin addresses, recent research shows that this level of anonymity is rather low. This encourages ...
Electrum v3.1.3 and earlier includes a setting to use Tor
When Tor is correctly setup on your system, it is possible to directly configure Electrum to connect via Tor for all connections, both to Electrum servers and, to third-party services.
Using these steps you can be anonymous in only five minutes.
Setting up Electrum and Tor
These instructions work ...
The RPC interface is not exposed over Tor. The only thing that goes over Tor is the P2P connection. To access the RPC server, you need to connect directly to the node's IP address, not connect to it over Tor. Note that the RPC interface and the P2P interface are two different things; the RPC interface is private facing while the P2P interface is public ...
bitcoind will cache the private key used. It is located at in the onion_private_key file in your bitcoind data directory (default will be ~/.bitcoin/onion_private_key). Delete that file and you should get a new onion private key and thus a new onion URL.
Yes. The channels are announced with the node ID. If the ip Address changes we get a new node announcement message so it takes some time until the information is through the gossip protocol. But moving a node to a new server is no problem
The guide you linked is a good start.
The next step is to broadcast these IPs using the externalip flag in the lnd.conf file. A sample lnd.conf file that enables connections (using default port 9735) via Tor, IPv4, and IPv6 should include the following:
(replace the 3 fake addresses with your own):
First of all, anonimity and privacy are two different things. Bitcoin is designed to be pseudonimous - which is close to anonimity, but instead of being completely anonimous, you're linked to your bitcoin address, or pseudonym.
You cannot make a private transaction on the Bitcoin network, but you can try to be as anonymous as possible.
It is possible to run ...
Turns out my node had auto-banned localhost (127.0.0.1) at some point. As a result bitcoind was rejecting all incoming connections from the tor service, including my friend's attempts. I removed the ban and he is able to connect.
Is it possible the problem for that to be related to TOR, considering that I can connect to and open channels with public nodes just fine?
No, that's very unlikely. (and contradictory)
Are the channels you created announced ?
Are your two nodes connected to the network ? For a node to find a route it needs to be connected to the peer-to-peer network to ...