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.

ghost 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.

luke-jr commented at 1:34 am on November 4, 2025: member

Regarding DNS seed policies, my seed is fully compliant.

It has always intentionally lagged introducing new versions, in case of unexpected issues, and this has never been brought up as a potential “breach” previously (indeed, other seeds also select for specific versions). Nor does it in any way contradict any explicit or implied purpose of DNS seeding. Part of the intent in this lagging is to increase diversity of results compared to other DNS seeds.

For the record, the current range of accepted versions is 0.21.1-28.*. If you are observing other versions, it is most likely because the node operator recently upgraded since the last crawl. There are currently 3567 “good” nodes being chosen from for results, which seems more than sufficient for now. (While this doesn’t break the policy in any way, maybe it would be about time to expand the scope since 28.x is no longer maintained.)

As for trust within the Bitcoin community, generally it seems I am much more trusted than some of the other DNS seed operators. Indeed, it probably makes sense to intentionally continue to include my seed in case the others go rogue. While I no longer support the Bitcoin Core project, I think it is better for the network if Core continues to use my seed, so I do not object to it.

Regarding security practices, there has never been a rational basis to question mine.

I have maintained top-notch security practices for many years, generally stricter than many other Core developers and maintainers, and the compromise 3 years ago (where the attackers took months to accomplish anything) was despite those practices, not due to a lack of them.

My personal website continues to display a warning out of an abundance of caution, and to encourage others to practice good security by verifying downloads - not because it remains compromised. There is no evidence even high-profile downloads were modified by the attacker at any time. Regardless, this has no impact on the DNS seed.

delta1 commented at 4:29 am on November 4, 2025: none

@luke-jr since you consider Core v30 to be “malware”, does that mean your seeder will never support returning v30 nodes?

Sjors commented at 8:40 am on November 4, 2025: member

maybe it would be about time to expand the scope since 28.x is no longer maintained.

Yes. Staying one major version behind seems acceptable to me. @gmaxwell wrote:

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.

Do you still believe that after his comment above?

pinheadmz commented at 1:48 pm on November 4, 2025: member

While I no longer support the Bitcoin Core project @luke-jr I think you should open a PR to remove your seed for this reason. It would be much more reasonable than someone else opening the PR on your behalf.

luke-jr commented at 1:53 pm on November 4, 2025: member

Don’t twist my quote out of context. Removing my DNS seed would be no harm to me, but it still shouldn’t be done and would reflect poorly on Bitcoin Core if you do it anyway.

Sjors commented at 2:17 pm on November 4, 2025: member

Note that there’s other seeds run by people who are not active contributors. That shouldn’t be a reason to remove a seed, unless we’re consistent about that.

Active hostility is a different matter. I don’t read that in “no longer support the Bitcoin Core project”, I do see it in social media. The question is whether that’s sufficient grounds for removing a seed, or whether something additional should happen.

gmaxwell commented at 2:58 pm on November 4, 2025: contributor

@luke-jr Can you point out where your filtering of recent versions was discussed in public in advance of implementation (per the policy, e.g. “Behavior outside of these expectations may be reasonable in some situations but should be discussed in public in advance”)? It’s both surprising to me and not consistent with what I knew. Filtering out sufficiently old versions is not news to me, at least to the extent it was filtering out things that actually might not work right (that it goes as recent as 21+ is somewhat surprising to me).

Also can you remove the remarks claiming that your security measures were state of the art and superior to other developers? You’ve left me in an awkward position where I feel I have to rebut a point you’ve made at the expense of information you shared with me in confidence… but the point is largely irrelevant over and above a simple assurance that you believe it is currently secure and the warning is out of an abundance of caution.

yancyribbens commented at 1:27 pm on November 5, 2025: contributor

Forgive my interjection, although isn’t there practice in place to routinely audit DNS seed nodes? IE a chron job that checks what versions are being named and the validity of the content? If such an audit system is in place, run on publicly verifiable infrastructure, then there’s indisputable reason to remove a node that names invalid content. If there is a high bar for auditing DNS seed nodes, I see no reason why more people can’t run these nodes, not less.

Also, it would be reasonable to have a ranking of seeds, preferring those that serve the latest versions. As well as some public visibility as to what versions are served by what seeds.

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

An idea (for the ML) would be something like Web of Trust. In fact, if you download this software, you could you not already replace the DNS seed nodes with nodes run by people you might trust more? Although, one should implicitly trust the maintainers who are also maintain these seeds since they also maintain the code being run.

laisial commented at 4:02 pm on November 5, 2025: none

DNS seeds still pose a small amount of risk for the network. As such, DNS seeds must be run by entities which have some minimum level of trust within the Bitcoin community. (DNS policy)

this discussion is inherently personal with the question being how much ‘some minimum level of trust’ is.

Luke: as for trust within the Bitcoin community, generally it seems I am much more trusted than some of the other DNS seed operators. Indeed, it probably makes sense to intentionally continue to include my seed in case the others go rogue.

one could argue that the Core community has lost trust in Luke, while his trust has increased in the Knots community. whether he still reaches a ‘minimum level of trust’ is not up to me to argue.

a DNS seed operator judging their own level of trust seems irrelevant, but his comment also includes a judgement on the trust of other DNS seed operators. I would like to hear from Luke if any DNS seed operators breach(ed) the minimum level of trust or the seed policy itself.

especially with the added comment of Luke about them potentially going “rogue”. it sounds like this should be taken seriously and investigated.

though, the same standard should then be applied to Luke whether it is possible that he goes rogue at some point.

Luke: I no longer support the Bitcoin Core project

Core (v30) is now labelled by Luke as “malware"1, “malicious"2, “dead"3, “bad actors"4, “lunatics"5, “compromised"6.

while I think both sides have fair arguments in the data storage debate, it has surpassed the ‘agree to disagree’ phase. it has come down to an ‘all or nothing’, ‘win or lose’, Core or Knots, soft fork/hard fork fight.

Luke: At this point, the only option is to make Core obsolete and rebuild the development side of things without the bad actors.7 How do we go about starting that rebuilding process? Luke: It’s already begun as more devs have started focusing on Knots in recent months.8

Luke seems to want Core gone and devs to leave Core behind and switch over to Knots, a fork of Core that he started and is primarily maintaining.

at the same time Luke’s X bio still says ‘#Bitcoin Core developer’ and his pinned tweet states the same with a request for financing his development efforts9.

all these aspects hit on trust.

while I can believe that Luke has, in his own perspective, Bitcoin in his best interests, and while I make no opinion on Knots, he does not have Core in his best interests (anymore).

everyone is entitled to their opinion, but the questions remains if there is a lack of trust and if the risk has become too great for Luke to stay on as DNS seed operator.

1 https://x.com/LukeDashjr/status/1977371638845861955 https://x.com/LukeDashjr/status/1973130522256875925 https://x.com/LukeDashjr/status/1969662551350002160

2 https://x.com/LukeDashjr/status/1980293369768427681 https://x.com/LukeDashjr/status/1976727228487798878 https://x.com/LukeDashjr/status/1974457701561442435

3 https://x.com/LukeDashjr/status/1985194136824353041 https://x.com/LukeDashjr/status/1984701828211114033 https://x.com/LukeDashjr/status/1973935409442025586

4 https://x.com/LukeDashjr/status/1983320986369044894

5 https://x.com/LukeDashjr/status/1976806111635554695

6 https://x.com/LukeDashjr/status/1980708228406325660 https://x.com/LukeDashjr/status/1968965263363076422

7 https://x.com/LukeDashjr/status/1984994433314476477

8 https://x.com/LukeDashjr/status/1985084445901176905

9 https://x.com/LukeDashjr/status/1311028816429670401

l0rinc commented at 7:17 pm on November 5, 2025: contributor

Would we add Luke as a DNS seed operator now, if that was the discussion instead?

ArmchairCryptologist commented at 7:47 am on November 8, 2025: none

For the record, the current range of accepted versions is 0.21.1-28.*. If you are observing other versions, it is most likely because the node operator recently upgraded since the last crawl. There are currently 3567 “good” nodes being chosen from for results, which seems more than sufficient for now. (While this doesn’t break the policy in any way, maybe it would be about time to expand the scope since 28.x is no longer maintained.)

It seems to me that intentionally configuring your DNS seed to specifically only return nodes running EOL versions of the software, and thus actively discouraging the use of up-to-date versions that fix known security vulnerabilities, may not be a technical violation of the DNS seed policy, but it is certainly unfortunate. Though it should be questioned whether this is does, in fact, qualify as fairly selected and functioning Bitcoin nodes.

willcl-ark commented at 5:17 pm on November 11, 2025: member

We opened this issue to give Luke a chance to respond to the concerns in the OP. He has replied but IMO has not addressed the concerns around version filtering.

As documented in this thread, dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us is currently not returning any v29 or v30 nodes, which violates point 1 of our DNS seed policy: “The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network.” Multiple independent tests have confirmed this filtering behavior.

Using my own DNS seed (>1 year uptime) I see that out of 7,000 nodes marked “good”, 2,360 are running v29 or 30. Luke may be filtering as many as 33% of the “good” nodes, according to my view of the network. This represents a significant portion of the healthy network that new users should be connecting to.

This seems to ~ tally with Luke’s own numbers:

There are currently 3567 “good” nodes being chosen from for results, which seems more than sufficient for now

IMO if Luke can’t commit to having his DNS seed return currently maintained versions of Bitcoin Core then we would be negligent in our collective duty of maintaining the seed infrastructure to allow it to remain part of this project.

Point 0 of our DNS seed policy requires that “DNS seeds must be run by entities which have some minimum level of trust within the Bitcoin community.” Luke has publicly stated that he “no longer supports the Bitcoin Core project” and has repeatedly characterized current Bitcoin Core releases as “malware” (and its developers and maintainers as malicious) on social media platforms. These statements clearly undermine the trust relationship required for DNS seed operation (and with the project as a whole).

Having someone who actively opposes the project be part of its seed infra is inappropriate. The projects’ seed infrastructure should be operated by entities that support the project’s success and are committed to serving a fair representation of the current, maintained versions of the software to new users.

For those reasons I too think that Luke’s seed should be removed from this project.

It seems to me this issue has performed its function, and we can probably close it and return to reviewing #33723?

kanzure commented at 5:43 pm on November 11, 2025: contributor

I strongly object to using or appealing to policy to decide on outcomes for this issue. It’s the same reason why you should never enter into a street fight: anybody dumb enough to enter a street fight with you is going to be much crazier than you, more heavily armed, less to lose, etc. It’s the same thing with policy, you’ll just be inviting endless policy argumentation from governancepilled people when in reality our actual goal was to building Bitcoin Core and developing bitcoin, not policy or process….

Having someone who actively opposes the project be part of its seed infra is inappropriate.

This is a common sense point, rather than a policy point. And It’s significantly better than policy.

fanquake commented at 2:11 pm on November 12, 2025: member

Closing for now.

fanquake closed this on Nov 12, 2025

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