Bitcoin Forum
April 17, 2026, 02:43:34 PM *
News: Latest Bitcoin Core release: 30.2 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: What are these localhost addresses with weird user agents?  (Read 121 times)
takuma sato (OP)
Hero Member
*****
Offline Offline

Activity: 832
Merit: 739


View Profile
September 14, 2025, 04:47:36 PM
Merited by ABCbits (1)
 #1

I have a node using Bitcoin Knots 29 fully synced in Linux and in bitcoin-qt in the "Peers" section I've seen a number of 127.0.0.1 addresses with different ports as incoming connections when using Tor.

The one that always quickly shows up has a website on the user agent:

127.0.0.1:52706 - Type: "bank"
Permissions: bloomfilter
Direction/Type: Inbound
Transport: v2
Session ID: some string of characters
Network: Unroutable
Version: 70016
User agent: /dns.kastel.kit.edu/bitcoin:28.0.0/
Services: NETWORK, WITNESS, NETWORK_LIMITED, P2P_V2
Address Relay: Yes

I don't get it. How is some german website connecting to my node (because direction type it says Inbound) and im sending it data? I recieved 5kb and was sending some data, I was around 500kb sent.

I have seen this with different ports, for instance, after reopening, it's using port 40640, and Network says: Onion, the rest is the same.

Another one I've seen that connected like an hour later while the other was still connected was this:

127.0.0.1:46808 - Type: "bank"
Permissions: bloomfilter
Direction/Type: Inbound
Transport: v1
Session ID: some string of characters
Network: Onion
Version: 70016
User agent: /bitcoinj:0.16.2/Bitcoin Wallet:9.26/
Services: None
Address Relay: No

I had no wallet opened during this time at all. I do not have any bitcoin devices, nothing was plugged into the computer. This one was around 30kb set and 300 B received

Another one I've seen is this:

127.0.0.1:34298 - Type: "blank"
Permissions: bloomfilter
Direction/Type: Inbound
Transport: v1
Session ID: some string of characters
Network: Onion
Version: 70016
User agent: "blank"
Services: None
Address Relay: No

This one had 800 B sent and 600 B received.

So basically, I've got these 127.0.0.1:movingPortNumber with different user agents and sometimes no user agent.
The one that always show up is /dns.kastel.kit.edu/bitcoin:28.0.0/, and sometimes others may show up.

There are no other inbound connections, only these 127.0.0.1 ones and then I get the expected 10 outbound peers with .onion addresses. The node seems to be working fine, I get the onion address in localaddress with getnetworkinfo and it shows up in Bitnodes.

I would like to know what does this mean.

Im not sure if this is Tor related because when I want to connect with clearnet I always set listen=0

If it helps here is the bitcoin.conf being used:

proxy:127.0.0.1:9050
listen=1
listenonion=1
onlynet=onion
discover=0 (not sure what this mean, but I had set it up like this). Looks like something to do with peers. New peers show up if I delete the peers.dat file, so it does not seem to be blocking discovery of new peers. Anyway, if anyone knows let me know this too.

Would like to double check this and see if my node is wrongly setup somewhere.
achow101
Moderator
Legendary
*
Offline Offline

Activity: 3920
Merit: 7677


Just writing some code


View Profile WWW
September 14, 2025, 06:45:53 PM
Merited by EFS (6), LoyceV (6), ABCbits (5), nc50lc (1), PowerGlove (1)
 #2

That's normal. Inbound Tor connections will always come from 127.0.0.1 since the node only sees the local Tor service make the connection (Tor acts as a proxy), and Tor doesn't have a "from" address like other protocols do.

Node software can set their user agent to any string. The text you see is the string that the other node literally sends in their version message. There's no validation or reverse lookup to determine that. So the kit.edu guys have custom node software where they set the user agent to be the domain for their website. That's all, there's nothing weird about that.

Likewise, you're also getting connections from node software that probably uses the bitcoinj library since that will set a bitcoinj user agent. And you've also got someone who wrote node software that sends an empty string for the user agent.

BitcoinJ is a fairly easy to use library so people often use it to write software the interacts with the network. These might be people who are trying to use a light client. But many of those nodes are probably just spy nodes which are trying to observe, and maybe identify, behavior and nodes on the network. The kit.edu people are specifically academics who are interested in network behavior and monitoring for attacks and issues, so you'll often see their monitoring nodes. The rest are generally not well known. They could be actual alternative node software, they could be spies, they could be network crawlers like the ones DNS seeders use, etc.

takuma sato (OP)
Hero Member
*****
Offline Offline

Activity: 832
Merit: 739


View Profile
September 14, 2025, 07:51:33 PM
 #3

That's normal. Inbound Tor connections will always come from 127.0.0.1 since the node only sees the local Tor service make the connection (Tor acts as a proxy), and Tor doesn't have a "from" address like other protocols do.

Node software can set their user agent to any string. The text you see is the string that the other node literally sends in their version message. There's no validation or reverse lookup to determine that. So the kit.edu guys have custom node software where they set the user agent to be the domain for their website. That's all, there's nothing weird about that.

Likewise, you're also getting connections from node software that probably uses the bitcoinj library since that will set a bitcoinj user agent. And you've also got someone who wrote node software that sends an empty string for the user agent.

BitcoinJ is a fairly easy to use library so people often use it to write software the interacts with the network. These might be people who are trying to use a light client. But many of those nodes are probably just spy nodes which are trying to observe, and maybe identify, behavior and nodes on the network. The kit.edu people are specifically academics who are interested in network behavior and monitoring for attacks and issues, so you'll often see their monitoring nodes. The rest are generally not well known. They could be actual alternative node software, they could be spies, they could be network crawlers like the ones DNS seeders use, etc.

Right, the way it looked is that people were connecting on my localhost which is weird and didn't make sense. What is the normal amount of inbound connections to have after like 30 minutes? I only ever get 1-2 at the same time, I think once I saw 3.

Btw I have discover=0, I've read what this does but it's not clear. Is it safe to put it to 1 to get more inbound connections to make the node more useful or is this going to compromise privacy in some way.

Also I don't have bind= enabled. This means default is already 127.0.0.1:9050 I think. Is it relevant to add this? The way I see it is that in Tor it's always going to be 127.0.0.1:9050 no matter what you type from what you explained above anyway so I don't have anything there.

Also when I enable server=1 because I want to use the .cookie to run bitcoin-cli commands, when using tor what are some recommended measures?
achow101
Moderator
Legendary
*
Offline Offline

Activity: 3920
Merit: 7677


Just writing some code


View Profile WWW
September 15, 2025, 02:38:08 AM
Merited by LoyceV (6), ABCbits (3)
 #4


What is the normal amount of inbound connections to have after like 30 minutes? I only ever get 1-2 at the same time, I think once I saw 3.
Single digits. 1 or 2 seems about normal. It takes time for your node's address to be determined as good enough to be propagated by your peers, and even more time for it to propagate through the network.


Btw I have discover=0, I've read what this does but it's not clear. Is it safe to put it to 1 to get more inbound connections to make the node more useful or is this going to compromise privacy in some way.
It is generally safe. All this option does is it does some validation of the address that peers claim is yours, and may announce those addresses as yours when connecting out to other peers. There have been situations in the past where a clearnet address was announced over privacy networks in a way that could allow someone to correlate your privacy network address with the clearnet address, but I believe that was fixed.

Also I don't have bind= enabled. This means default is already 127.0.0.1:9050 I think.
No. The bind default is 0.0.0.0:8333, which means it will listen for incoming connections to port 8333 on any interface and IP address on your machine.

127.0.0.1:9050 is the default Tor SOCKS proxy address (localhost port 9050). This is what is used to make outbound connections to Tor nodes.

There is an additional bind on 127.0.0.1:8334 for Tor inbound connections specifically. When Tor gets an inbound connection, it forwards the connection to this bind. This is a separate bind so that inbound Tor connections can be identified. Otherwise they look like any other connection coming from localhost.

Is it relevant to add this?
Generally no.

Also when I enable server=1 because I want to use the .cookie to run bitcoin-cli commands, when using tor what are some recommended measures?
The defaults are fine.

If you don't want to your clearnet IPs to possibly leak over Tor, you should use onlynet=onion.

takuma sato (OP)
Hero Member
*****
Offline Offline

Activity: 832
Merit: 739


View Profile
September 15, 2025, 05:24:42 PM
Last edit: September 15, 2025, 05:53:53 PM by takuma sato
 #5

So why does everyone always recommend "bind=127.0.0.1" whenever I look up for a "bitcoin core with tor" tutorial? Examples:

You're not using Tor. Bitcoin Core cannot connect to the Tor instance, are you running Tor at all?

You have to use -onlynet=onion and -bind=127.0.0.1 to force Bitcoin Core to only connect to onion nodes and for incoming connections to go through Tor. If done correctly, bitcoin-cli getnetworkinfo should return reachable for onion and have a network score.

Not sure how it works for inbound. probably best practice to disable all of it with nolisten as listen=1 may allow nodes to connect over clearnet in certain instances?
When a proxy is enabled, Core automatically sets listen=0 unless specified otherwise.

https://bitcointalk.org/index.php?topic=5298655.0
https://bitcoin.stackexchange.com/questions/70069/how-can-i-setup-bitcoin-to-be-anonymous-with-tor

https://markaicode.com/bitcoin-core-configuration-guide-security-2025/

Also when using server=1 for RCP, they also recommend "rcpbind=127.0.0.1" and not leaving defaults

Here "bind=127.0.0.1:8333" is commented as "Privacy"

https://blog.lopp.net/tor-only-bitcoin-lightning-guide/

But here they comment it and use 0.0.0.0 instead:

https://21ideas.org/en/practice-privacy/dojo-1/

Im just looking at the bitcoin.conf that people have and they usually use these.

Btw, why does getnodeaddresses give some ipv4 IP when im connected with tor?

Quote
[
  {
    "time": somenumberhere,
    "services": 3080,
    "address": "someiphere",
    "port": 18333,
    "network": "ipv4"
  }
]

In localaddresses in getnetworkinfo I do get the .onion address:

Quote
"localaddresses": [
    {
      "address": "somecharactershere.onion",
      "port": 18333,
      "score": 4
    }
achow101
Moderator
Legendary
*
Offline Offline

Activity: 3920
Merit: 7677


Just writing some code


View Profile WWW
September 15, 2025, 06:06:43 PM
 #6

So why does everyone always recommend "bind=127.0.0.1" whenever I look up for a "bitcoin core with tor" tutorial?
Probably to guarantee that it isn't binding to a public IP that is reachable. But it should also be unnecessary with onlynet=onion.

But here they comment it and use 0.0.0.0 instead:
I don't know why they do that.

Btw, why does getnodeaddresses give some ipv4 IP when im connected with tor?
That RPC does not return your node's addresses, it returns addresses of other nodes that it knows about. Clearnet addresses are still propagated when connected over Tor, so your node will know about IPv4 addresses even if it doesn't connect to them.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!