Which list? The official DNS seeds or my page? It will take time to show up on the page, and the seeds may not list you for a very long time. Don't forget the --externalip setting. That's what this thread is all about.
It might take awhile! I noticed it took around an hour for me to show up on @chappjc's site. Also keep an eye out in your dcrd logs for "inbound" peers. That's how you'll know it's working.
Your page. And I did restart with --externalip, though this does suggest I'm going to have to reset dcrd any time I have to reboot my router. I may need to look into a DNS subscription.
Good suggestion. Something like this should show up: 04:14:14 2016-03-25 [INF] BMGR: New valid peer 115.66.31.xxx:55417 (inbound) (/dcrwire:0.0.1/dcrd:0.0.6) @ClokworkGremlin Just checking. Yeah, unfortunately, a dynamic DNS service may be necessary if your IPS doesn't at least give you a persistent or static IP.
I am testing out a dynamic DNS address right now, but I'm not expecting it to work on the network I'm currently on. I'll let it run and see if I get any inbound peers... but my hopes are not high. I'll do a "real" test when I'm at home on a more typical NAT network.
You can test the port forwarding with online services like this one: http://www.yougetsignal.com/tools/open-ports/ Of course, that won't verify that dcrd is advertising correctly.
After about 20 days, roughly 700 MB transmitted from dcrd. However, the VPS wasn't listed by the official seeds for most of that time. Once that happens, it goes up. There's a good chance I will close shop depending on traffic.
That's a good question. "Bandwidth" and "data used" are are two very different things. You are paying for the amount of data used, and not the speed that data moves. Right now, the size of the blockchain is about 100 MB. As time goes on, this will increase. The amount of data your node will use is mainly dependent on your inbound connections, but you also have to keep in mind the constant block up dates you're receiving from the rest of the network through your outbound connections, which occurs either way, public node or not. If you run a public node and have 8 peers connect to you that just launched dcrd for the first time, they're going to need a full copy of the blockchain. They may use your node and other nodes to download the blocks, but in theory you could be serving 800+ MB to get these new guys up and running. The odds of you serving 8 brand new nodes singlehandedly are probably very low, but it's not impossible.
This kind of reminds me of the six degrees of seperation. It probably isnt related but did come to mind in my head lol. Thanks for the tip though, i updated my dcrd for the community 10:19:17 2016-03-27 [INF] BMGR: New valid peer 92.x.x.x:52832 (inbound)
That's a solid amount of bandwidth and it will definitely benefit the network! 100GB is more than enough.. I wouldn't expect to see more than 3-4 GB of data used per month, and even that is probably overkill as @chappjc said his only used about 700MB in 20 days. Thank you!
Yes, that is effectively exactly the underlying reasoning! In math terms, you can figure that for every outbound node you are connected to (8 of them), they are also connected outbound to 8 others (you're an inbound to them, so they are connected out to 8 others), so the result is that you can reach any other node with a maximum of ceil(log8(total_nodes)) hops. This doesn't even take into account the fact that some of these nodes have inbound connections which are notified as well. For a concrete example, assume that at some point in the future there are a million nodes on the network. You would be able to reach any given node on the network with a maximum of ceil(log8(1000000)) = 7 hops. In practice, it works out to be even less than that on average because there are inbound nodes too which are notified and thus the net effect is that it raises the base of the logarithm which of course in turn reduces the hops.
I'm running a full node on a DigitalOcean VPS located in New York. I've always seen the "New valid peer: xxxx" message in my dcrd logs, but I am unable to locate my IP on this site. I SSH'd into my machine and ran Code: ifconfig | grep inet which returned the IP address I expected it to, and afterwards ran Code: wget -qO- http://ipecho.net/plain ; echo which verified this IP address to be the correct public address. I have iptables configured to allow tcp port 9108, verified by running iptables -S and returning Code: -A INPUT -p tcp -m tcp --dport 9108 -j ACCEPT So my question is, why is it that my IP address is not listed on the site? I'm very interested in running a public node, or even multiple in different locations in the future. Any insight would be greatly appreciated. EDIT: Just to verify that my node is indeed publicly accessible, I went ahead and launched an instance of dcrd on my local machine with addpeer=my_node_ip and was able to connect successfully, reflected in both dcrd logfiles.
I'm not sure how the code decides to advertise new addresses. Maybe @chappjc or somebody more familiar with the code can elaborate.
@Dyrk posted his getpeerinfo output on the dcrstats chat and I was able to find my node there. I'm modifying my config to allow more peers and I will post the output of getpeerinfo on my node when it generates.
If a node was advertising the wrong IP (running without the --external IP when it was needed), that host would end up in the ban list. Banned hosts should be rechecked at some point, but I don't know the time frame. There are roughly 4600 IPs on the list, so perhaps it's time to wipe the ban list and rescan the entire Decred network. I'll do that in about 30 min from now.
Your peers aren't necessarily all public nodes, so I don't think that's an informative query in this context. But perhaps I misunderstand this command. Anyway, your host is evidently working fine.
Our reference to the term "public node" is simply a node that accepts inbound connections. Public nodes are tracked by the official DNS seeders and also @chappjc's seeder. In order to become a public node, your node must be "aware" of it's public IP on the internet. If it's not aware, it will still be a node (with outbound connections only), but it has no way of telling other nodes where on the internet it's reachable.
Not with getpeerinfo, at least not for certain. getpeerinfo has 2 pieces of useful information regarding the type of node. If "inbound" is false, that means you connected to that node (outbound). But true doesn't preclude the possibility that you can't connect to them; it just means they connected to you. (And if you have incoming peers on your LAN, that doesn't guarantee your address is routable.) A syncnode on the internet is necessarily public, and outbound. From rpcserverhelp.go: Code: "getpeerinforesult-inbound": "Whether or not the peer is an inbound connection",
The page should be updated shortly with a FULL scan of the network shortly. I had to force it to pester the nodes for new peers as it only does it once a week by default. There are a handful of new nodes at the bottom of the list. It eats up bandwidth, but I'll make it more frequent given the rate at which people are adjusting their configurations.