makeseeds.py to handle IPv6 and onions, fix regular expression for recent Bitcoin Core versionsgenerate-seeds.py with regard to IPv6 parsingchainparamsseeds.hSource data: https://dev.visucore.com/bitcoin/seeds-20150624.txt.xz retrieved 2015-06-24 09:28:55 +0200 from http://bitcoin.sipa.be/seeds.txt
Needs backport to 0.11.
ACK.
I think we need to check the data that http://bitcoin.sipa.be/seeds.txt is keeping at some point. I have been consistently running a node at 68.34.102.231:8335 that doesn't show up in that list at all. I have verified that this node is open and accessible using https://getaddr.bitnodes.io/.
Also, my node at 68.34.102.231:8333 only shows 34% uptime for 30 days and I believe that I have had closer to ~60-70% uptime. Overall I don't believe that this hurts the overall intent of this PR, but something just seems a bit off.
Edit: Node in second paragraph was supposed to say port 8333
Well in any case, this needs a refresh. Someone (sorry, I don't remember who) said they went through the list a while ago and all but a few nodes were stale. This isn't surprising as last update was more than a year ago.
Note that only nodes on port 8333 are included in the built-in seeds. This is part of the regexp in makeseeds.py. Probably this was done with a reason, on the other hand there may be valid reasons to revise this e.g. ISPs blocking port 8333 as well as the DNS seeds. @sipa?
Hmm, I think the crawler prefers :8333 as that's the only port that's transferrable through DNS.
There is also a combine.pl script in https://github.com/sipa/bitcoin-seeder/ that can be used to first merge different crawlers's outputs together.
There are a few others with port 8335 in the original seeds.txt, just not @PRabahy's. @PRabahy is your node advertising itself properly, e.g. you don't have the wrong -externalip in your config file? (if any, without it it should autodiscover the right one)
I'll add port parsing logic to makeseeds.py.
- Moved all seed related scripts to contrib/seeds for consistency
- Updated `makeseeds.py` to handle IPv6 and onions, fix regular
expression for recent Bitcoin Core versions
- Fixed a bug in `generate-seeds.py` with regard to IPv6 parsing
Allow for non-8333 nodes to appear in the internal seeds. This will
allow bitcoind to bypas a filter on 8333. This also makes it possible to
use the same tool for e.g. testnet.
As hosts with multiple nodes per IP are likely abusive, add a filter to
remove these (the ASN check will take care of them for IPv4, but not
IPv6 or onion).
OK, new commits pushed
Allow for non-8333 nodes to appear in the internal seeds. This will
allow bitcoind to bypas a filter on 8333. This also makes it possible to
use the same tool for e.g. testnet.
As hosts with multiple nodes per IP are likely abusive, add a filter to
remove these (the ASN check will take care of them for IPv4, but not
IPv6 or onion).
There are a few hardcoded seeds with ≠8333 ports now.
@laanwj That could be the problem. Right now I haven't set -externalip for either node and they are both behind a NAT router. FYI, :8333 is running bitcoin-qt and :8335 is running btcd. Later today I try to figure out if they are advertising the correct IP.
Tested ACK.
Do we need a port number even when it is standard? It could save a bit...
Do we need a port number even when it is standard? It could save a bit...
But at least now it can be stored in a simple, network-agnostic table with fixed-sized records. We went from a separate table for IPv4 and IPv6+onion to a unified one, let's not split it up again (for - at most - 10% saving).
Cherry-picked (and squashed) to 0.11 as 41bbc85ec9f20ec9f5dc9c96476180d2c57ed041
I think I figured out what is going on with my nodes. I have both IP4 and IP6 setup on my machine and I have a publicly accessible IP6 address. When bitcoin starts up it appears to only autodetect IP6 addresses. The problem with this is that I never setup IP6 port forwarding on my router (IP4 is forwarded properly). I'm going to open the IP6 port and see if that changes the statistics at all.