dnsseed.bitcoin.dashjr.org temporarily
#29149
Rationale:
Only this seeder is giving different results that include older versions: #29145#pullrequestreview-1797445282
Warnings on luke.dashjr.org reduces the confidence to use this as DNS seed in bitcoin core: https://pastebin.com/raw/Cwk2a1xr
He is not following DNS seed policy rule 0 and 1
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process. A summary of reviews will appear here.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
This PR is just trolling and should be closed/deleted.
So you are not willing to answer questions about your DNS seed and think its hardcoded forever?
BTW I am working on a project to monitor DNS seeds for different things. Last time I enquired about DNS seeds, they asked me to use seednode.
This time Peter Todd told me there are some trade-offs. So 60% nodes are working on those trade-offs.
Maybe the real reason is power you feel by seeding all the bitcoin network or misleading them with seed in your case.
I don’t think a removal is warranted, just fix (or explain if there is a legit reason) the issue with only returinng old nodes.
There is the monitoring site at https://www.21.ninja/dns-seeds/ run by @virtu - maybe having some additional statistics about the diversity of results could have caught this issue?
I don’t think a removal is warranted, just fix (or explain if there is a legit reason) the issue with only returinng old nodes.
There is the monitoring site at https://www.21.ninja/dns-seeds/ run by @virtu - maybe having some additional statistics about the diversity of results could have caught this issue?
It just covers “count” and “share”. There are lot of things you monitor for DNS seeds. You know better than me.
I don’t think a removal is warranted, just fix (or explain if there is a legit reason) the issue with only returinng old nodes.
Removal is warranted as explained in PR description or we need to change policy doc for Luke Dasshjr. Further, he is not ready to answer to explain.
You have asked no questions, only posted false accusations.
Why seeder returns IP address of nodes with user agent that look like old nodes?
If warnings on your server are true, why should we trust your domain will resolve to “honest” bitcoin nodes?
Are you sure that server used for DNS seed is secure?
What is the probability that US government agencies wont work with you and affect this last point? Then you spread something on social media about your biased opinion with 0.1 % hashrate?
By downloading anything from my personal web directory here, you assume responsibility for ensuring the copy is in compliance with the laws of your jurisdiction, my jurisdiction (Florida, USA), and my server’s jurisdiction (New York, USA). If you do not agree to these terms, you are not authorized to access this website. Accessing this website implies you have accepted this agreement as a binding contract.
just fix (or explain if there is a legit reason) the issue with only returinng old nodes.
They weren’t old nodes when that change was made - they were the latest, intentionally excluding old nodes which didn’t enforce Taproot.
I already updated it last night after you brought it to my attention.
However, it should be noted that the nodes returned were perfectly fine, and there wasn’t actually a real issue.
Removal is warranted as explained in PR description or we need to change policy doc for Luke Dasshjr.
The PR description is pure lies. You are just outing yourself as a bad actor.
However, it should be noted that the nodes returned were perfectly fine, and there wasn’t actually a real issue.
They were missing a few important bug fixes
The PR description is pure lies. You are just outing yourself as a bad actor.
You wanted questions in #29149 (comment) which I shared in #29149 (comment) and are not answered yet
Keep in mind that when a node gets a list of IP addresses from a DNS seed, the first thing it will do upon connection is to ask more peers. While the seed returns about a dozen addresses per query, these initial peers typically return a thousand each. So if subsequent outbound connections are randomly drawn, the odds of connecting to one of the peers initially returned by the seed are quite small.
So it doesn’t matter that much what features these initial peers support, as long as they can give us more peers.
So it doesn’t matter that much what features these initial peers support, as long as they can give us more peers.
But this seeder was
intentionally excluding old nodes which didn’t enforce Taproot.
and did so in a manner that was static (used a filtering method at the time that wasn’t updated) and the DNS seed policy states …
…the results may be randomized but must not single-out any group of hosts to receive different results unless due to an urgent technical necessity and disclosed.
So in summary by self admission, this was:
undisclosed filtering ∧ not a technical necessity ∴ breaking DNS seed policy rules
He has not yet addressed the hacking/compromise concerns yet, either.
This PR is far from ‘pure lies’. It should not have been closed without justification. I appreciate that luke has corrected the old static rules, but there are remaining concerns that need addressed.
A DNS seed operating organization or person is expected to follow good host security practices The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operator’s understanding and capability.
Evidence: https://pastebin.com/raw/Cwk2a1xr
Maybe read descriptions and https://github.com/bitcoin/bitcoin/blob/master/doc/dnsseed-policy.md before close pull request
A DNS seed operating organization or person is expected to follow good host security practices The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network to the best of the operator’s understanding and capability.
Evidence: https://pastebin.com/raw/Cwk2a1xr
Maybe read descriptions and https://github.com/bitcoin/bitcoin/blob/master/doc/dnsseed-policy.md before close pull request
A server can be compromised while following security best practices. They are not foolproof, particularly to very targeted attacks. While it is concerning that the server was compromised in the past, there is no evidence that it continues to be compromised.
AFAIK Luke has maintained control over it, continues to follow security best practices, and has not transferred the seed to anyone else. The seeder continues to behave honestly - it returns random nodes, and the vast majority of them also appear in bitcoin.sipa.be/seeds.txt.gz so can be reasonably assumed to be okay.
…the results may be randomized but must not single-out any group of hosts to receive different results unless due to an urgent technical necessity and disclosed.
To be clear, this refers to giving different results to different requesters. It does not forbid selection of which peers to return as results to everyone, which is quite normal for DNS seeds.
To be clear
This pull request was closed without any answers and we know the politics involved in it with reasons.
There is the monitoring site at https://www.21.ninja/dns-seeds/ run by @virtu - maybe having some additional statistics about the diversity of results could have caught this issue?
Finally got around to this. I added two: