<p>So I've found relatively few resources explaining the intricacies of the Bitcoin P2P network internal functionality. Right now, I'm writing a similar sort of peer-to-peer network, in another language however, but based on the same principles. I've gotten a pretty resillient P2P network implemented, however, obviously once I ran it on a server, and tried to connect locally, I ran into the problem of my peer being behind a NAT. I sketched out this diagram:</p>
<p><a href="https://i.sstatic.net/jBPVu.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/jBPVu.png" alt="enter image description here" /></a></p>
<p>So essentially the 'full nodes' (green) are the ones that have portforwarding on, and will help contribute to gossiping data around the network, and the private nodes (red) are the nodes that need the network state (i.e. still needs to listen into broadcast tx's etc.) but is behind a NAT (i.e. they can only do outbound connections to full nodes, and never to each other). So my question is: What is a good way to determine if a node is a 'private node' (behind a NAT) or a 'full node' (ports open, can accept any connection). The reason why I want to determine this, is so that private peers do not become part of the 'peer-exchange' protocol (so nodes don't get a bunch of peers that they can't connect to).</p>
<p>My gut-solution to this problem is simply to attempt to open a new socket connection to peers connecting to me and see if they refuse the connection the other way around (where they have an inbound connection from me), if they do, we can be fairly certain that is a private node behind a NAT, however this feels hacky, and I'm wondering how bitcoin tackles this issue of private nodes (nodes behind a NAT) and full nodes (nodes that help strengthen the network).</p>
<p>TL;DR: How does Bitcoin avoid NAT-guarded nodes are added to peoples peer list?</p>

CC BY-SA 4.0
2022-01-23T19:53:15.307Z
Just a note on terminology: usually the term "full node" refers to nodes that fully validate (sometimes also to whether they have the full blockchain), but this is independent of whether they are reachable from the public internet.
Pieter Wuille
CC BY-SA 4.0
2022-01-23T20:17:51.473Z
@PieterWuille That's what I initially thought as well, but looking at [this](https://bitcoin.org/en/full-node) it specifically mentions "[...] validating those transactions and blocks, and then relaying them to further full nodes". From the discussion I've seen around full nodes they're described as the one 'helping strengthen the network', so I assume it is the correct terminology for the nodes that publicly reachable.
John Doe
CC BY-SA 4.0
2022-01-23T20:36:43.413Z
Non-public full nodes also relay transactions and blocks to their peers.
Pieter Wuille
CC BY-SA 4.0
2022-01-23T20:39:31.247Z
@PieterWuille Makes sense. Thanks for clearing it up. :)
John Doe
<network><p2p>
Programmatically determining a full node in a peer-to-peer network
John Doe
# Programmatically determining a full node in a peer-to-peer network

(Asked by: username_0 on 2022-01-23)

So I've found relatively few resources explaining the intricacies of the Bitcoin P2P network internal functionality. Right now, I'm writing a similar sort of peer-to-peer network, in another language however, but based on the same principles. I've gotten a pretty resillient P2P network implemented, however, obviously once I ran it on a server, and tried to connect locally, I ran into the problem of my peer being behind a NAT. I sketched out this diagram:

[![enter image description here](https://i.sstatic.net/jBPVu.png)](https://i.sstatic.net/jBPVu.png)

So essentially the 'full nodes' (green) are the ones that have portforwarding on, and will help contribute to gossiping data around the network, and the private nodes (red) are the nodes that need the network state (i.e. still needs to listen into broadcast tx's etc.) but is behind a NAT (i.e. they can only do outbound connections to full nodes, and never to each other). So my question is: What is a good way to determine if a node is a 'private node' (behind a NAT) or a 'full node' (ports open, can accept any connection). The reason why I want to determine this, is so that private peers do not become part of the 'peer-exchange' protocol (so nodes don't get a bunch of peers that they can't connect to).

My gut-solution to this problem is simply to attempt to open a new socket connection to peers connecting to me and see if they refuse the connection the other way around (where they have an inbound connection from me), if they do, we can be fairly certain that is a private node behind a NAT, however this feels hacky, and I'm wondering how bitcoin tackles this issue of private nodes (nodes behind a NAT) and full nodes (nodes that help strengthen the network).

TL;DR: How does Bitcoin avoid NAT-guarded nodes are added to peoples peer list?

**Tags:** network, p2p

> **Comments:**
> **username_1**: Just a note on terminology: usually the term "full node" refers to nodes that fully validate (sometimes also to whether they have the full blockchain), but this is independent of whether they are reachable from the public internet.  
> **username_0**: @username_1 That's what I initially thought as well, but looking at [this](https://bitcoin.org/en/full-node) it specifically mentions "[...] validating those transactions and blocks, and then relaying them to further full nodes". From the discussion I've seen around full nodes they're described as the one 'helping strengthen the network', so I assume it is the correct terminology for the nodes that publicly reachable.  
> **username_1**: Non-public full nodes also relay transactions and blocks to their peers.  
> **username_0**: @username_1 Makes sense. Thanks for clearing it up. :)  

---

## 0 answers

