Seeder see only nodes at config

[bitcandy]

Hello, thank you for your seeder and hard work!

I'm experiencing an issue where the seeder cannot independently find nodes; it only detects and validates nodes added to settings.conf. For instance, with seed_1-seed_7, it shows 2/7 (correctly identifying 2 out of the 7 nodes, but unable to find the others—I know at least 1 more is online). Before adding seed_7, it displayed 1/6...

All nodes are in sync (the 3 that I'm aware of). Could this be due to daemon incompatibility with your seeder?

Additionally, I have a suggestion regarding -prune mode nodes. Do you know if they can contribute to the network by providing access to download blocks they know and reporting known peers to the seeder?

Thanks again for your assistance!

[joeuhren]

Hi, it's difficult to say exactly what the problem is as there is unfortunately no real logging in the app to help figure these things out and its a very low priority for me since the seeder is working great for most coins. In case you are interested, I have started adding crowdfunding tasks to my website to help cover the cost of development for different features like this as I am not able to find the time to make everything work for everyone for free while balancing multiple different open source projects. I already added a task to add proper logging into the seeder app which will greatly help diagnose problems like the one you are having: https://exor.io/task/9/847becdcaee866d8fd34ca52ca2df4af151a7983/.

What coin are you testing this against? It is definitely possible you are using a coin that has changed the default bitcoin code enough that it is no longer compatible with the seeder, but so far I haven't seen that happen yet.

You mention about having 3 nodes that you are aware of which is a very tiny and unhealthy amount if that is all the nodes on the network. There are a number of reasons why a node may not be seen as "good" and its very possible that the 3rd node you are talking about is behind a firewall or has another reason why it is not being recognized as a good, stable node. For example, the seeder checks that the node is running on the correct port and is routable (ie. not behind a firewall), verifies the version matches what was entered in the config, the block height is within a few blocks before or after the value that was last picked up by the block explorer, the node has been reliably online for a high percentage of the time that the seeder has been running, etc. It's also possible the node has maxed out its peers list and is not accepting new connections which will also cause the seeder to reject it as a good node. Again, logging would greatly help with diagnosing this as there are lots of reasons for failure.

That's an excellent question about pruned nodes. My own coin does not support pruned nodes and therefore I've never really checked or tested it myself so I'm only guessing at this point. The generic seeder is largely based on the official bitcoin seeder which I believe was developed way before the idea of pruned nodes was added to bitcoin. My understanding of pruned nodes may be outdated, but last time I checked, pruned nodes in bitcoin were not identifiable to the network in any special way. The only way you could tell a pruned node from a full node is to request a certain block and if the pruned node does not respond with the block then it is thought to be pruned. As far as I am aware, pruned nodes function more-or-less identically to full nodes and can serve the blocks that they have in their internal database when requested and can also share their peer list with other nodes, including the seeder. Since I haven't tested pruned nodes myself against the generic-seeder, I cannot be 100% sure of the answer but I do not believe there is any restrictions in place for testing particular blocks to test if they are pruned or not which means that my best guess is that pruned nodes can most likely show up as "good" nodes in the seeder results at this moment, but again, it would need to be tested to be 100% sure.

[bitcandy]

Thank you for your quick and detailed response! I share the same perspective on pruned nodes. However, in my experience with the coin I'm currently supporting and testing generic-seeder against (Bitcoin Candy - CDY), which uses a relatively old Bitcoin (ABC) codebase from 2018, I've noticed that the pruned node I run consistently maintains a low number of connections, typically around 3-5. It seems like other nodes on the network might be hesitant to connect or may not prefer to follow it. In contrast, other full nodes on the network usually have a significantly higher number of connections. As of now, the pruned node has 3 connections, while a full node has 13.

About little amount of full nodes, CDY is small coin with too big blockchain to run full node by simple user. They almost always use light wallets, exchanges or in best scenario pruned nodes...

Regarding code differences with Bitcoin which I know about (as I'm not original developer of Candy): the block structure was changed. Can it be the reason? I'm sure no. But maybe seeder trying to download latest block and somehow verify? What kind of verification seeder do when it connect to the node port?

I will check other reasons mentioned in your post, but sure it's not firewall/block explorer/height at config/run time/banned/version/different port.... About "not accepting new connections", maybe I need to test this, thanks. Maybe really not enough "place" to initialize new connections as other pruned nodes on the network can use all possible "max connections" from this full nodes.

[joeuhren]

You can review the bitcoin.cpp code if you want to compare how the seeder connects to nodes and check how that may differ from your own coin. The TestNode() function runs a series of cmds to emulate how bitcoin nodes talk to each other. You have access to the full source code so feel free to add your own logging to see what is actually going on behind the scenes with your network.

[bitcandy]

Thanks, I will try to investigate it