dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us appears to be violating DNS seed policy

glozow commented at 2:10 pm on October 29, 2025: member

Is there an existing issue for this?

I have searched the existing issues

Current behaviour

There are concerns about @luke-jr’s security practices and control over the server: #33723 (comment) @luke-jr was hacked and posted on his website that his server has been compromised. As of this morning, the warning is still there:

We also learned of an investigation following the hack and are unsure whether Luke has shared access to the server with investigators. It would be helpful if @luke-jr can clarify this point.

There are also concerns that @luke-jr is purposefully filtering nodes based on user agent, attempting to stop users from running or connecting to recent versions of Bitcoin Core. #33723 (comment) #33723 (comment) #33723 (comment) #33723#pullrequestreview-3390131426

Expected behaviour

The current behavior appears to violate the DNS seed policy.

A DNS seed operating organization or person is expected to follow good host security practices, maintain control of applicable infrastructure, and not sell or transfer control of the DNS seed. Any hosting services contracted by the operator are equally expected to uphold these expectations.

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.

Solutions

Typically when a DNS seed is not operating properly, an issue is opened and we wait for the operator to respond (for example, see #29911)

Ideally, the problems are addressed. If not, the DNS seed can be removed (see #33723).

Alternatively, we may determine that there is no violation. Discuss here.

glozow added the label P2P on Oct 29, 2025

pinheadmz commented at 2:27 pm on October 29, 2025: member

[!CAUTION] Personal attacks are not allowed and will result in a ban

Be extremely clear and concise when posting on this thread.
Every comment must relate directly to the topic described in the issue description
Be mature, respectful and sensible.

Rob1Ham commented at 2:29 pm on October 29, 2025: none

Calling out @kanzure’s comment in #33723 to ask the question on if there are advantages to having DNS seeds that are more conservative with their versioning.

In the event that this DNS seed server is removed from the configuration, it’s worth considering (or considering the effects of not) replacing it with another DNS seed node that implements a conservative strategy with regards to node versions. I also don’t know if anyone has analyzed whether this heuristic has a protective or beneficial effect, and if the number of such seed nodes changes the magnitude or quality of any of these effects.

kanzure commented at 3:06 pm on October 29, 2025: contributor

I also have a question as to whether user agent version filtering was previously discussed as a matter of DNS seed policy. If it was, then perhaps someone would be kind enough to give a link to that discussion. This however seems to me like a smaller issue compared to the other considerations that are necessary for resolving this ticket.

We also learned of an investigation following the hack and are unsure whether Luke has shared access to the server with investigators. It would be helpful if @luke-jr can clarify this point.

I think that the question of whether Luke has shared access to the server with investigators (or other attackers) is independently interesting separate from the question of any policy violation, and it’s also separate from the question of whether (for any reason at all) the contributors feel like removing that DNS seed node. That is, people might be interested to know if the answer that Luke gives is “yes”.

Typically when a DNS seed is not operating properly, an issue is opened and we wait for the operator to respond. Ideally, the problems are addressed. If not, the DNS seed can be removed. Alternatively, we may determine that there is no violation. Discuss here.

There is at least one more possible course of action not specified above: if the Bitcoin Core developers feel like removing this node, then they should go ahead and do so, for any reason whatsoever, stated or unstated, regardless of whether there is a “finding” of a “policy violation”.

gmaxwell commented at 3:37 pm on October 29, 2025: contributor

Luke-jr’s seed returns knots 29.2 nodes, and yet he claims knots 29.2 is based on the same code it currently won’t return. https://x.com/LukeDashjr/status/1977355254510256135 even though the issue is now known to luke-jr the behavior hasn’t been corrected.

I looked at my logs and see examples of discussions of luke-jr’s seed it returning just released versions. The only exclusions I see discussed are e.g. old versions that didn’t support node witness or have other known issues that make them unsuitable.

This is consistent with earlier analysis on delving: https://x.com/LukeDashjr/status/1977355254510256135

In light of these facts and luke-jr’s consistent claims that recent versions of Bitcoin core are “malware” rather than Bitcoin software (https://x.com/LukeDashjr/status/1977371638845861955) I do not believe luke-jr’s comments on twitter explaining the current behavior as a product of ordinarily excluding ’new’ versions is particularly credible.

It’s also worth considering what you might do if there was interest in removing a seed you were running– I dunno about you but other than just fixing any fixable thing my response would only be “ah, okay if that’s what you want! no skin off my back, and one less thing to worry about”. But someone who fights and throws accusations to keep their dnsseed in? (https://x.com/LukeDashjr/status/1983520476036276567) No one should be that interested, it suggests they are gaining a benefit from it that they should not be gaining. Aggression about being included has been a factor in prior removals.

Taking a step back– I would also say that there have always been more rules for dnsseeds than were bothered being written down. I would have never thought that the policy needed to say that a seed operator may not be an avowed enemy of the project or convinced that the project or its maintainers were compromised (https://x.com/LukeDashjr/status/1980708228406325660 https://x.com/LukeDashjr/status/1921571463343055003).

Although things are supposed to be robust to secretly malicious actors, that doesn’t mean that accepting sources of known particular risk is a responsible practice. DNSseeds are also more vulnerable since if someone (even a third party) DDOSes the fair seeds than the unfair seed will effectively be performing an eclipse attack, also because private information gathering could enable a wider network view (e.g. of non-listening nodes) and also enable targeted attacks (e.g. by someone who believes recent versions are “malware” and thus morally obligated to shut them down).

If I had ever thought it would have been needed I would have pushed for the policy to explicitly say that seed operators must have a good working relationship with the project and be supportive of its success. I don’t know how things got to a point where this is a thing that even needs to be said outright.

As Kanzure points out– contributors should feel free to associate or not associate with whomever they choose. But moreover, if you’re willing to selflessly subject yourself (and others) to someone’s abuse it ought to be for someone at least committed to the project’s success.

Accepting contributions from someone opposed to the project or someone acting on their behalf and trusting that the normal review process (which can’t work on dnsseed output) will protect against sabotage is not that dissimilar from continuing to use a hacked server with a little note reminding people to check the signatures on downloads from it. You can choose that, if you want, but .. uhh… it’s not something to do if you hope for others to choose to use the things you produce!

glozow commented at 4:09 pm on October 29, 2025: member

I looked at my logs and see examples of discussions of luke-jr’s seed it returning just released versions.

It is helpful to know that the claim of simply not returning recent versions is false, thank you for looking into this.

But someone who fights and throws accusations to keep their dnsseed in? Aggression about being included

seed operators must have a good working relationship with the project and be supportive of its success.

I certainly agree that these are points to consider and ultimately, the project has governance over the software we ship. Referencing the policy is not an attempt at playing lawyer on of a set of guidelines written many years ago; it’s a starting point for us to make a decision grounded in what’s best for the software. That being said, the PR’s comments mostly come from outside of the regular contributors and was an unproductive discussion.

This issue and the moderation actions are an attempt at a fair process to minimize the amount of abuse and brigading on this repo and elsewhere. I am sure it’s being screenshotted already.

I believe this is how we should react to a PR for removing sipa or achow’s DNS seed: moderate aggressive comments and personal attacks, open an issue if there are actually compelling reasons, and give the operators some time to respond.

if you’re willing to selflessly subject yourself (and others) to someone’s abuse it ought to be for someone at least committed to the project’s success.

I do not think it is fair to say that we are responsible for the online abuse that we have received, or that I do this for Luke’s benefit. I imagine that’s not what you meant.

00w1 commented at 6:00 pm on October 29, 2025: none

Luke-jr’s seed returns knots 29.2 nodes, and yet he claims knots 29.2 is based on the same code it currently won’t return. https://x.com/LukeDashjr/status/1977355254510256135 even though the issue is now known to luke-jr the behavior hasn’t been corrected.

I have been trying to resolve dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us since last 15 minutes but it did not return any knots v29.2 node IP address in the response. Others who reviewed #33723 did not get any v29.2 knots node IP address in results as well.

 0--------------------------------------------------------------------------------
 11. IP: 164.132.247.153
 2   User Agent: /Satoshi:27.0.0/
 3--------------------------------------------------------------------------------
 42. IP: 66.183.154.237
 5   User Agent: /Satoshi:0.21.1/
 6--------------------------------------------------------------------------------
 73. IP: 64.218.188.164
 8   User Agent: /Satoshi:25.1.0(FutureBit-Apollo-Node)/
 9--------------------------------------------------------------------------------
104. IP: 18.133.128.214
11   User Agent: /Satoshi:25.0.0/
12--------------------------------------------------------------------------------
135. IP: 95.217.241.15
14   User Agent: /Satoshi:25.1.0/
15--------------------------------------------------------------------------------
166. IP: 172.234.249.54
17   User Agent: /Satoshi:27.0.0/
18--------------------------------------------------------------------------------
197. IP: 35.195.170.141
20   User Agent: /Satoshi:25.1.0/
21--------------------------------------------------------------------------------
228. IP: 139.177.194.50
23   User Agent: /Satoshi:27.0.0/
24--------------------------------------------------------------------------------
259. IP: 172.232.180.212
26   User Agent: /Satoshi:27.0.0/
27--------------------------------------------------------------------------------
2810. IP: 34.96.170.247
29   User Agent: /Satoshi:25.1.0/
30--------------------------------------------------------------------------------
3111. IP: 172.104.136.235
32   User Agent: /Satoshi:27.0.0/
33--------------------------------------------------------------------------------
3412. IP: 172.105.15.206
35   User Agent: /Satoshi:27.0.0/
36--------------------------------------------------------------------------------
3713. IP: 173.27.87.24
38   User Agent: /Satoshi:25.1.0(FutureBit-Apollo-Node)/
39--------------------------------------------------------------------------------
4014. IP: 72.217.88.35
41   User Agent: /Satoshi:25.1.0(FutureBit-Apollo-Node)/
42--------------------------------------------------------------------------------
4315. IP: 70.20.231.250
44   User Agent: /Satoshi:25.1.0(FutureBit-Apollo-Node)/
45--------------------------------------------------------------------------------
4616. IP: 212.51.134.43
47   User Agent: /Satoshi:28.1.0/
48--------------------------------------------------------------------------------
4917. IP: 107.215.145.100
50   User Agent: /Satoshi:27.1.0/Knots:20240801/
51--------------------------------------------------------------------------------
5218. IP: 172.234.88.188
53   User Agent: /Satoshi:27.0.0/
54--------------------------------------------------------------------------------
5519. IP: 34.87.216.102
56   User Agent: /Satoshi:25.1.0/
57--------------------------------------------------------------------------------
5820. IP: 13.36.183.251
59   User Agent: /Satoshi:25.0.0/
60--------------------------------------------------------------------------------
6121. IP: 15.236.9.153
62   User Agent: /Satoshi:25.0.0/
63--------------------------------------------------------------------------------
6422. IP: 141.195.182.139
65   User Agent: /Satoshi:28.1.0/
66--------------------------------------------------------------------------------

gmaxwell commented at 6:34 pm on October 29, 2025: contributor

Odd. I connected to it in a loop and eventually got a “/Satoshi:29.2.0/Knots:20251010/” – also other knots versions and yet yours shows no knots at all?

Sjors commented at 6:55 pm on October 29, 2025: member

I share the concerns, but at the same time it will be a while before we ship a new release. So I prefer to just wait a few days / weeks to hear a clear answer from Luke himself, preferably here on Github and not some gated social media platform that I can’t read :-)

Psifour commented at 8:38 pm on October 29, 2025: none

A few notes that should not be taken as support/detraction for the question of removal (I am opposed to dns seeds in general, but there is not a better alternative currently that I am aware of).

Firstly, the seed in question appears to resolve to a server in Germany instead of the one pointed to by luke.dashjr.org (the one that was previously compromised and features a disclaimer about it’s safety). As such, I am less concerned by his deviations from standard security practice with that specific server except where it points to a potential habit of neglecting best-practices.

Secondly, I believe the current servers returned by the seed are mirrored on his personal site at seeds.txt. As of today the number of v30 nodes present has risen to expected levels based on network participation. This indicates to me that the issue in question may have already been resolved.

My personal opinion on the topic is that the inclusion of a dns seed by a party that has labeled the master branch of the project as ‘malware’ is a bit irresponsible and the seed should be removed regardless of any real or perceived malfeasance due to professed hostility/disagreement. If removal of a seed must be ‘for cause’ beyond direct public opposition, I believe the seed has already been brought in-line with expectations (assuming seeds.txt is in fact mirroring what is returned by the seed) and as such cause would be challenging/impossible to prove (regardless of actuality). If that is the criteria, the seed should be left in place. That decision falls to the maintainers.

Furthermore, as (primarily) an observer, I would love to see a discussion on the ML regarding any alternatives to DNS seeds that we could explore in the future to avoid the need for pseudo-trusted intermediaries when bootstrapping a new node. I say this as we have no means to verify that a dns seed is performing as expected and having such a trusted system seems undesirable.

dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us appears to be violating DNS seed policy #33734

Is there an existing issue for this?

Current behaviour

Expected behaviour

Solutions