Lately, I've been trying to wrap my head around how the generic-seeder functions. I stumbled upon a few statements that really got me thinking.
I found some info on GitHub that seems relevant.
Besides having legit nodes (which should ideally make up most of the network), the quoted text, especially the underlined parts, got my attention. It implies there are certain factors that define a node as "reliable," but I’m not too sure what those might be.
From what I understand, block height might be an indicator of reliability. But then, I realized there are nodes that don’t retain all historical data, like prune nodes. I'm not convinced that should automatically make them less reliable... I could be wrong about that.
So I have a couple of questions:
1. Referring to the first quoted statement, what specific traits make a node reliable? What exactly do we mean when we call a node reliable?
2. The second quoted statement talks about connectable nodes. Are there nodes that can be connected to and others that can’t? If full nodes and prune nodes could be used as examples, that would be helpful.
I’m totally open to corrections since I still consider myself a newbie. Sorry for any mistakes I’ve made, and I’d love to hear your thoughts. Feel free to do your own research after reading this.
What makes a node reliable?
2 replies 172 views
gr3g.0rbitHero Member
Posts: 1025 · Reputation: 2646
#2Aug 4, 2024, 05:42 AM
The "Features" part of readme document may have a brief explanation of that: https://github.com/guapcrypto/DNS-Seeder/blob/main/README.md?plain=1#L27-L38
But to be precise, you'll have to audit their code to know exactly what they mean by those.
In a way, there are "not connectable" nodes which for example, those with listen=0 config which can connect to others, but others can't connect to.
But you're way overthinking that statement since the keyword is "list of the connectable nodes"
Since using the term "list of nodes" will just means 'all the nodes in the network' which is not the purpose of their app.
It's also worth to mention people usually would use term "accept incoming connection" and "doesn't accept incoming connection". And aside from listen=1, they may need to configure their router to enable port forwarding and check their ISP doesn't use CGNAT.
?Reply
Sign in to reply to this topic
Related topics
- Issues connecting Bitcoin Full Node 3
- Bitcoin Core displaying coins (UTXOs) in a new tab 13
- Are you in favor of BIP-110? Let's get a Bitcoin poll going. 0
- Erlay seems to have some issues here’s a better proposal for a bitcoin protocol without invites 3
- New Optional Hourglass Implementation is Live 3
- Ways to earn some sats by contributing to bitcoin core development 5