pull down to refresh
I think people are misinterpreting that table.
The "in" column is what you receive (leech/download).
The "out" column is what you send (seed/upload/share).
In other words, you are syncing /downloading from 17 peers and giving to 10 peers.
reply
trying to read second part again and again, trying read @DarthCoin comments and I am still confuse
my node serve these services
bitcoin-cli getnetworkinfo"localservicesnames": [ "NETWORK", "WITNESS", "COMPACT_FILTERS", "NETWORK_LIMITED", "P2P_V2" ]I think that NETWORK_LIMITED is there because I have
maxuploadtarget=512MNETWORK : This indicates your node is a full node participating in the Bitcoin P2P network. It serves and relays the full blockchain data and transactions to other peers. Other nodes connect to it to download blocks and transactions. This is the baseline service that makes a node a full validating node on the network.
bitcoin-cli -netinfoshow this tableipv4 onion npr total block in 0 0 17 17 out 2 8 0 10 2 total 2 8 17 27I dont know why but all 17 incoming connection over TOR are listed in column npr. But I want to show that I have incoming connection and believe those nodes can download from my node blocks (well max 512M for day), yes only TOR nodes can connect to my node. And you can see that my node connected to 2 clearnet nodes and believe those can also download blocks from my node.
I think that doesnt matter if connection is inbound or outbound, your node is relaying / sharing blocks.
reading
https://bitnodes.io/what-is-a-bitcoin-node/#reachable-vs-unreachable-nodes
"... node is considered as a reachable node if it accepts incoming connections from its peers..." I think any incoming connection, whether via clearnet, tor, or i2p, counts.
also : While the Bitcoin peer-to-peer network requires reachable nodes to allow new nodes to bootstrap themselves, unreachable nodes do not negate their importance as they still form part of the Bitcoin peer-to-peer network and enforce the same consensus rules through their outgoing connections.