chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us #33723

pull SatsAndSports wants to merge 1 commits into bitcoin:master from SatsAndSports:patch-1 changing 2 files +1 −3
  1. SatsAndSports commented at 3:53 pm on October 28, 2025: none

    The DNS seed dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us. is not returning a representative sample of bitcoin nodes. It currently returns nothing later than 28.1.0, breaching the policy.

    This PR removes that seed from the list of DNS seeds

    Rationale

    The policy for seeds includes this:

    The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network

    A number of comments below, in response to this PR, include apparent breaches of this policy: 1 2, 3, in particular the first linked comment (1) comparing the distribution at this seed to other seeds. This seed is not including anything later than 28.2.0, breaching this policy.

    To ensure the policy is followed, and the seeds include a representative sample of Bitcoin nodes, this PR removes this seed from the list

    Data

    I ran this:

    0# Get some ip address from that seed:
1# Repeated multiple times, to get many different IPs:
2dig +short dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us >> dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us
3# For each distinct ip gathered from the seed, get basic info about the node, including it's User Agent string:
4cat dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us | sort -u | while read ip; do echo ===; echo $ip; nmap -p 8333 --script bitcoin-info "$ip"; done > seed_versions.txt

    and then summarized the agents with egrep 'User Agent' seed_versions.txt | sort | uniq -c and got:

    0      1   User Agent: /Satoshi:22.0.0/
1      1   User Agent: /Satoshi:22.1.0/
2      5   User Agent: /Satoshi:24.0.1/
3      1   User Agent: /Satoshi:25.1.0/
4     30  User Agent: /Satoshi:27.0.0/
5      1   User Agent: /Satoshi:27.1.0/
6      1   User Agent: /Satoshi:27.1.0/Knots:20240801/
7      1   User Agent: /Satoshi:28.0.0/
8      7   User Agent: /Satoshi:28.1.0/
9      2   User Agent: /Satoshi:28.1.0/Knots:20250305/
  2. DrahtBot commented at 3:54 pm on October 28, 2025: contributor

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Code Coverage & Benchmarks

    For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33723.

    Reviews

    See the guideline for information on the review process.

    Type Reviewers
    ACK l0rinc, delta1, dergoegge, stickies-v, Crypt-iQ
    Concept NACK wizkid057, 00w1
    Concept ACK achow101, waketraindev, Symphonic3, jlopp, polespinasa, niteshbalusu11, frodrik-froggo, onyxcoyote, jaonoctus
    Stale ACK reardencode, hsjoberg, gmaxwell, john-moffett, davidgumberg

    If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

    LLM Linter (✨ experimental)

    Possible typos and grammar issues:

    • DNS seed -> DNS seeds [pluralize because two different providers (sipa and achow101) are listed, so “DNS seed” should be plural to be grammatical]

    drahtbot_id_5_m

  3. dergoegge commented at 4:20 pm on October 28, 2025: member

    ACK 9c3291ff9bd713e1a92dae2c388a83e4a107bf7e

    Don’t think a lot of damage can be done by controlling just one of the seeds but it’s just a matter of time before Luke pulls some random shenanigans.

  4. pinheadmz commented at 4:25 pm on October 28, 2025: member

    Don’t think a lot of damage can be done by controlling just one of the seeds but it’s just a matter of time before Luke pulls some random shenanigans.

    This is going to be a hard thread to moderate because personal attacks are forbidden, but this is one of the very few lines of code that literally point to a specific central entity.

    The PR author is also a first-time contributor to the project and I’m worried this PR is going to get brigaded by people susceptible to social media influence.

    We have a dns seed policy: https://github.com/bitcoin/bitcoin/blob/master/doc/dnsseed-policy.md

    In my opinion, any review of a PR like this MUST refer to the rules in this document

  5. stickies-v approved
  6. stickies-v commented at 4:26 pm on October 28, 2025: contributor

    ACK 9c3291ff9bd713e1a92dae2c388a83e4a107bf7e

    Operators of DNS seeds have a (limited) ability to be harmful to users, e.g. by filtering results or logging requests. Luke has shown multiple cases of hostile and unpredictable behaviour towards the Bitcoin Core project (e.g. his attempt at taking over the Transifex project), so removing this seed seems like the responsible thing to do, even if we can’t guarantee the reliability of other DNS seeds.

  7. pinheadmz commented at 4:29 pm on October 28, 2025: member
    I think it is far more mature to wait until the service becomes unreliable or violates a stated policy rule before removing. Otherwise the project is merely reacting preemptively to someone’s tweets.
  8. dergoegge commented at 4:33 pm on October 28, 2025: member

    “must be run by entities which have some minimum level of trust within the Bitcoin community”

    Can only speak for myself but that doesn’t reflect my current sentiment regarding Luke.

  9. glozow added the label P2P on Oct 28, 2025
  10. reardencode commented at 5:16 pm on October 28, 2025: none

    utACK 9c3291f

    Given recent developments, it seems that including Bitcoin Knots’ maintainer’s seed as a trusted bootstrap source for bitcoin core users is no longer advisable.

  11. delta1 commented at 5:17 pm on October 28, 2025: none

    utACK 9c3291ff9bd713e1a92dae2c388a83e4a107bf7e

    Luke considers Bitcoin Core v30 to be “malware”, so he probably doesn’t want to provide a DNS seed for Core nodes any longer.

  12. pinheadmz commented at 5:30 pm on October 28, 2025: member

    I just queried all the DNS seeds and compared responses with BitNodes API, using jq to isolate the user agent:

    https://gist.github.com/pinheadmz/ff6057f14aa6b9aa642db2c98f331a1a

    No real anomolies to speak of, except that seed.mainnet.achownodes.xyz returned the most knots nodes 🤷

    update: dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us is not returning v29 or v30 nodes, apparently

  13. waketraindev commented at 5:42 pm on October 28, 2025: none

    update: dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us is not returning v29 or v30 nodes, apparently

    I did 9 tries and had the same experience.

    Concept ACK

  14. achow101 commented at 5:46 pm on October 28, 2025: member

    Point 0 of the policy states:

    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.

    Given that Luke was hacked a couple years ago, arguably his DNS seed should have been removed at that time. Furthermore, his personal website still has the following disclaimer, even after 3 years:

    WARNING: In November and December 2022, this server was compromised twice. While known rootkits were promptly removed, it has not been entirely audited nor rebuilt yet. Be extra careful to verify OpenPGP signatures and not to trust anything you download.

    We also know that Luke has been in contact with the FBI regarding this hack, and has possibly given them access to machines under his control so that they can perform an investigation. While I expect that they would not still have access to machines currently used in production, it is still uncertain to me as to whether Luke has sole control over the seed, especially with the aforementioned disclaimer.

    Considering this, I think removing his DNS seed, even belatedly, is a reasonable measure.

    Concept ACK

  15. fanquake added the label Needs backport (28.x) on Oct 28, 2025
  16. fanquake added the label Needs backport (29.x) on Oct 28, 2025
  17. fanquake added the label Needs backport (30.x) on Oct 28, 2025
  18. fanquake commented at 5:53 pm on October 28, 2025: member
    If this does end up being merged, then it should be backported to all supported branches.
  19. mzumsande commented at 5:57 pm on October 28, 2025: contributor

    update: dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us is not returning v29 or v30 nodes, apparently

    I had 9 tries and had the same experience.

    this type of thing has happened before: See these links Maybe there is a manual process for adding newer versions.

  20. davidgumberg commented at 6:00 pm on October 28, 2025: contributor

    /contrib/seeds/README.md should also be updated:

    https://github.com/bitcoin/bitcoin/blob/5a58d4915e5ce53b922961b16840709686ce9996/contrib/seeds/README.md?plain=1#L13-L20

  21. jlopp commented at 6:08 pm on October 28, 2025: contributor

    Concept ACK

    It is well known that Luke has a lengthy history of poor security practices, a concern that is compounded by his insistence that he does NOT have poor security practices. As such, the reliability and integrity of this DNS seed is highly suspect, we should not expect it to improve, and evidence is already being presented that it is not responding quite as one would expect.

    Although the operational risk to the Bitcoin network is low, the standards for operating this part of Bitcoin’s infrastructure should be extremely high.

  22. Symphonic3 commented at 6:19 pm on October 28, 2025: none

    Concept ACK

    Have independently confirmed that dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us is not returning any Core v30 nodes.

  23. glozow commented at 6:33 pm on October 28, 2025: member

    We have removed seeds in the past when they weren’t functioning as expected (see #29911).

    1. The DNS seed results must consist exclusively of fairly selected and functioning Bitcoin nodes from the public network

    I think omitting Bitcoin Core v30 nodes definitely breaks this policy. Based on the operator’s behavior I assume it is intentional, but cc @luke-jr do you plan on fixing this? @SatsAndSports it would be helpful if you could update the PR description with some of the more specific motivations.

  24. polespinasa commented at 6:39 pm on October 28, 2025: member

    Concept ACK

    update: dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us is not returning v29 or v30 nodes, apparently

    I have also queried the seeder a few times and didn’t get a single v29 or v30 node. Other seeders do respond with v29 and v30 nodes.

    This violates point 1: “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.”

    this type of thing has happened before: See these links Maybe there is a manual process for adding newer versions.

    If that’s the case, then it’s fair to give @luke-jr the opportunity to explain and fix it. Although given the circumstances, I would assume it’s intentional.

    Point 0 is also violated as @achow101 argues.

    If this gets merged +1 to backport the change.

    Luke Seeder:

     0sliv3r@sliv3r-tuxedo:~$ for ip in $( dig dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us  +short); do curl -s https://bitnodes.io/api/v1/nodes/$ip-8333/ | jq .data[1]; done
 1"/Satoshi:25.1.0(FutureBit-Apollo-Node)/"
 2"/Satoshi:25.0.0/"
 3"/Satoshi:25.0.0/"
 4null
 5"/Satoshi:28.1.0/"
 6"/Satoshi:28.1.0/"
 7"/Satoshi:28.1.0/"
 8"/Satoshi:28.1.0/"
 9null
10"/Satoshi:28.1.0/Knots:20250305/"
11"/Satoshi:28.0.0/"
12"/Satoshi:28.1.0/"
13"/Satoshi:25.0.0/"
14"/Satoshi:28.1.0/"
15null
16"/Satoshi:28.1.0/"
17"/Satoshi:27.0.0/"
18"/Satoshi:27.0.0/"
19"/Satoshi:27.1.0/"
20"/Satoshi:28.1.0/Knots:20250305/"
21"/Satoshi:28.1.0/"
22"/Satoshi:25.0.0/"
23sliv3r@sliv3r-tuxedo:~$ for ip in $( dig dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us  +short); do curl -s https://bitnodes.io/api/v1/nodes/$ip-8333/ | jq .data[1]; done
24"/Satoshi:27.1.0/"
25"/Satoshi:28.1.0/"
26"/Satoshi:25.0.0/"
27"/Satoshi:28.1.0/Knots:20250305/"
28"/Satoshi:25.0.0/"
29"/Satoshi:25.1.0(FutureBit-Apollo-Node)/"
30"/Satoshi:25.0.0/"
31"/Satoshi:27.0.0/"
32"/Satoshi:28.1.0/"
33"/Satoshi:28.1.0/"
34"/Satoshi:28.0.0/"
35"/Satoshi:28.1.0/Knots:20250305/"
36"/Satoshi:27.0.0/"
37"/Satoshi:28.1.0/"
38null
39"/Satoshi:28.1.0/"
40null
41"/Satoshi:28.1.0/"
42"/Satoshi:28.1.0/"
43null
44"/Satoshi:28.1.0/"
45"/Satoshi:25.0.0/"
46sliv3r@sliv3r-tuxedo:~$ for ip in $( dig dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us  +short); do curl -s https://bitnodes.io/api/v1/nodes/$ip-8333/ | jq .data[1]; done
47"/Satoshi:25.0.0/"
48null
49"/Satoshi:27.1.0/"
50"/Satoshi:28.1.0/"
51"/Satoshi:28.1.0/"
52"/Satoshi:28.1.0/"
53"/Satoshi:27.0.0/"
54"/Satoshi:28.1.0/"
55"/Satoshi:28.1.0/Knots:20250305/"
56"/Satoshi:28.1.0/"
57"/Satoshi:25.1.0(FutureBit-Apollo-Node)/"
58"/Satoshi:25.0.0/"
59"/Satoshi:28.1.0/"
60null
61"/Satoshi:27.0.0/"
62"/Satoshi:28.1.0/"
63"/Satoshi:28.0.0/"
64null
65"/Satoshi:25.0.0/"
66"/Satoshi:28.1.0/Knots:20250305/"
67"/Satoshi:25.0.0/"
68"/Satoshi:28.1.0/"

    Other Seeders:

     0sliv3r@sliv3r-tuxedo:~$ for ip in $( dig dnsseed.bluematt.me  +short); do curl -s https://bitnodes.io/api/v1/nodes/$ip-8333/ | jq .data[1]; done
 1null
 2"/Satoshi:27.1.0/"
 3"/Satoshi:29.0.0/"
 4"/Satoshi:29.0.0/"
 5"/Satoshi:30.0.0/"
 6"/Satoshi:30.0.0/"
 7"/Satoshi:28.1.0/"
 8"/Satoshi:30.0.0/"
 9"/Satoshi:29.1.0/"
10null
11"/Satoshi:25.1.0(FutureBit-Apollo-Node)/"
12"/Satoshi:30.0.0/"
13"/Satoshi:27.0.0/"
14"/Satoshi:29.0.0/"
15"/Satoshi:30.0.0/"
16"/Satoshi:30.0.0/"
17"/Satoshi:24.0.1/"
18"/Satoshi:30.0.0/"
19null
20null
21null
22"/Satoshi:30.0.0/"
23sliv3r@sliv3r-tuxedo:~$ for ip in $( dig seed.bitcoin.sprovoost.nl  +short); do curl -s https://bitnodes.io/api/v1/nodes/$ip-8333/ | jq .data[1]; done
24null
25"/Satoshi:28.1.0/"
26"/Satoshi:30.0.0/"
27null
28null
29"/Satoshi:28.1.0/"
30null
31null
32null
33null
34null
35null
36null
37null
38null
39null
40null
41null
42null
43null
44null
45null
46null
  25. niteshbalusu11 commented at 6:54 pm on October 28, 2025: none

    Concept ACK

    Because it’s been verified that this happens.

    Have independently confirmed that dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us is not returning any Core v30 nodes.

    If @luke-jr is willing to change this then we don’t have to remove.

  26. hsjoberg commented at 6:57 pm on October 28, 2025: contributor

    utACK 9c3291ff9bd713e1a92dae2c388a83e4a107bf7e.

    Luke has repeatedly called “Bitcoin Core” bad actors in public. Given this hostility, it stands to reason that his DNS seed should not be in the software.

  27. DrahtBot requested review from achow101 on Oct 28, 2025
  28. DrahtBot requested review from polespinasa on Oct 28, 2025
  29. pinheadmz commented at 7:03 pm on October 28, 2025: member

    [!CAUTION] OK at this point there is NO LONGER A NEED for more comments about an individual’s trustworthiness.

    This PR is starting to get brigaded and comments that do not ADD ADDITIONAL INFORMATION or help the maintainers do their job will probably get hidden and may result in a ban

  30. john-moffett commented at 7:07 pm on October 28, 2025: contributor

    Concept ACK based on @achow101 ’s comment and the currently not “fairly selected” Bitcoin nodes.

    Here’s what I get with multiple runs:

    Seed 30.99.0 30.0.0 29.2.0 29.1.0 29.0.0 28.99.0 28.2.0 28.1.0 28.0.0 27.99.0 27.2.0 27.1.0 27.0.0 26.2.0 26.1.0 26.0.0 25.1.0 25.0.0 24.0.1 24.0.0 23.1.0 23.0.0 22.0.0 0.21.1 0.20.1 0.20.0 0.17.1 0.12.1
    dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us 2 41 8 6 42 2 26 21 4 1 9
    seed.bitcoin.sipa.be. 8 11 4 2 2 4 6 3 3 2 1
    dnsseed.bluematt.me. 34 4 16 12 14 2 2 8 4 2 2
    seed.bitcoin.jonasschnelli.ch. 4 55 2 6 15 2 1 30 10 1 4 2
    seed.btc.petertodd.net. 4 34 4 2 6 2 2 14 4 2 2 2
    seed.bitcoin.sprovoost.nl. 2 14 49 10 6 9 4 2 19 2 9 5 1
    dnsseed.emzy.de. 6 14 2 4 12 4 4
    seed.bitcoin.wiz.biz. 30 4 12 24 2 22 8 2 2 10 2 2 10 6 2
    seed.mainnet.achownodes.xyz. 2 6 28 11 11 15 1 4 1 13 3 4 2 4 2
  31. gmaxwell commented at 7:13 pm on October 28, 2025: contributor

    ACK 9c3291ff9bd713e1a92dae2c388a83e4a107bf7e

    This DNS seed is clearly violating policy– which was put into place to discourage abuse of seeds for attempting eclipse attacks and network surveillance. Removing it should be entirely uncontroversial. The change should also be backported.

  32. frodrik-froggo commented at 8:09 pm on October 28, 2025: none
    ACK
  33. SatsAndSports commented at 8:35 pm on October 28, 2025: none

    I’ve updated the description now, linking to some of the evidence provided by others in this thread, and mentioning the policy that you referenced. I’m not an expert at writing PRs, I hope my updated description is concise and helpful

    @SatsAndSports it would be helpful if you could update the PR description with some of the more specific motivations. @davidgumberg , thanks for pointing out the README change. I’ve updated it now too in this PR

  34. SatsAndSports force-pushed on Oct 28, 2025
  35. niteshbalusu11 commented at 8:48 pm on October 28, 2025: none

    I ran a test a few times, my results.

  36. onyxcoyote commented at 8:55 pm on October 28, 2025: none

    There is another important reason why I ACK this…

    Separation of duties, which is both a best practice, and even legally required in some industries (like banks).

    Any one individual should not cross over multiple checks and balances. For example, they should not be able to develop, test, review, and deploy code to production (or really any 2-3 of those things). It does not matter if they are a rockstar developer and 100% trusted, or even if it could offend them. In my previous life I removed production access from all of my best developers.

    The capability to cross so multiple boundaries should just not be there.

    In this case it is:

    1. being able to unilaterally develop, test, review, build and release code to 15-25% of the network.
    2. controlling which nodes new nodes connect to

    #1 alone breaks separation of duties, which makes mitigating #2 more important. So even if the DNS seed results are corrected, separation of duties says it should be removed.

  37. SatsAndSports commented at 9:06 pm on October 28, 2025: none

    Thanks @niteshbalusu11 and @john-moffett for your detailed breakdown of the versions. Can you share the code or system you used?

    I just updated the description of this PR with a small script I made, with dig and nmap, also showing that recent versions are not represented in this seed. But it would be great to have your code and data described, as mine data is very basic

    PS: I just noticed that @pinheadmz and @polespinasa (and maybe others) including data and a script. Thanks to all for the data

  38. niteshbalusu11 commented at 10:02 pm on October 28, 2025: none

    @SatsAndSports some basic python vibe coding. most of the code is to make it pretty looking, core logic is really small.

    https://gist.github.com/niteshbalusu11/582f450104a0493ed78a0d0edb54a928

  39. l0rinc commented at 10:16 pm on October 28, 2025: contributor

    ACK c18f9d1fd5d4e1fc255d83ed7f808e2571c4ed9f

    Please update the PR title now that the README was also updated. And I personally would suggest a different phrasing, we’re not removing this entry because it’s “unnecessary” but because of breach of trust.

  40. DrahtBot requested review from stickies-v on Oct 28, 2025
  41. DrahtBot requested review from dergoegge on Oct 28, 2025
  42. stickies-v commented at 10:34 pm on October 28, 2025: contributor
    re-ACK c18f9d1fd5d4e1fc255d83ed7f808e2571c4ed9f
  43. jlopp commented at 10:40 pm on October 28, 2025: contributor

    Please update the PR title now that the README was also updated.

    Since any given DNS seed is strictly unnecessary, I’d suggest changing “unnecessary” to “unreliable.”

  44. SatsAndSports renamed this:
    Remove unnecessary seed from chainparams.cpp
    Remove unreliable seed from chainparams.cpp, and the associated README
    on Oct 28, 2025
  45. 00w1 commented at 11:08 pm on October 28, 2025: none

    NACK

    1. This pull request is a desperate attempt to remove the DNS seed without clarifying anything with Luke.
    2. I do not see any policy that requires the inclusion of latest releases in the DNS seed results.

    Given that Luke was hacked a couple years ago, arguably his DNS seed should have been removed at that time. Furthermore, his personal website still has the following disclaimer, even after 3 years:

    We also know that Luke has been in contact with the FBI regarding this hack, and has possibly given them access to machines under his control so that they can perform an investigation. While I expect that they would not still have access to machines currently used in production, it is still uncertain to me as to whether Luke has sole control over the seed, especially with the aforementioned disclaimer.

    Considering this, I think removing his DNS seed, even belatedly, is a reasonable measure.

    Its interesting to note that @achow101’s comments contradict her previous comments about security: #29149 (comment)

  46. davidgumberg commented at 11:37 pm on October 28, 2025: contributor

    ACK https://github.com/bitcoin/bitcoin/commit/c18f9d1fd5d4e1fc255d83ed7f808e2571c4ed9f

    I think you should squash the two commits, and change the commit description to match the PR description. @00w1

    I do not see any policy that requires the inclusion of latest releases in the DNS seed results.

    /doc/dnsseed-policy.md

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

    Modifying the DNS seed results to exclude functioning Bitcoin nodes on the public network because of their version clearly violates this expectation, or do you have a different interpretation of the words “fairly selected and functioning Bitcoin nodes from the public network”?

    Edit: I was missing some context when I wrote this, and it does seem that recent versions of both Bitcoin Core and Knots are filtered by Luke’s seeder, see comments below.

    Its interesting to note that @achow101’s comments contradict her previous comments about security: #29149 (comment)

    Anyone that works full-time on an open-source project where all discussion takes place in public for years will end up “contradicting” themselves in public many, many times, just the same as people that don’t work in the open contradict themselves many, many times in private, and your remark seems to be a personal attack that does not add any information about whether or not this PR should be merged.

  47. john-moffett commented at 11:46 pm on October 28, 2025: contributor
    ACK c18f9d1fd5d4e1fc255d83ed7f808e2571c4ed9f @SatsAndSports I used a custom hacked-together script that switched VPNs to several different countries, re-ran, and de-duped the IPs. This is the code with the VPN related stuff removed.
  48. 00w1 commented at 11:57 pm on October 28, 2025: none

    Modifying the DNS seed results to exclude functioning Bitcoin nodes on the public network because of their version clearly violates this expectation, or do you have a different interpretation of the words “fairly selected and functioning Bitcoin nodes from the public network”?

    Version based filtering is done by other DNS seeds as well. It’s not a new practice or a violation of the policy. Older versions are functioning bitcoin nodes and selected from the public network to the best of the operator’s understanding.

    Luke’s clarification: https://x.com/LukeDashjr/status/1983320986369044894

  49. achow101 commented at 0:13 am on October 29, 2025: member

    Its interesting to note that @achow101’s comments contradict her previous comments about security: #29149 (comment)

    To clarify, there has been new information since that comment was made. In particular, we were notified of the FBI’s (continued) involvement in 2024. Additionally, it’s now been 3 years since the hack and the disclaimer is still on his website. This suggests that no further action has been done to ensure that there is no continuing compromise.

  50. Ademan commented at 0:25 am on October 29, 2025: none

    Modifying the DNS seed results to exclude functioning Bitcoin nodes on the public network because of their version clearly violates this expectation, or do you have a different interpretation of the words “fairly selected and functioning Bitcoin nodes from the public network”?

    Version based filtering is done by other DNS seeds as well. It’s not a new practice or a violation of the policy. Older versions are functioning bitcoin nodes and selected and from the public network to the best of the operator’s understanding.

    Luke’s clarification: https://x.com/LukeDashjr/status/1983320986369044894

    That tracks with information others have shared, however when I asked Luke when he intended to return v30 peers from his seed he refused to respond, hid my comment, and blocked me (while I was writing a follow up request for clarification).

    Someone (else) should ask for clarification, but I’m inclined to believe he does not intend to seed v30 peers according to his prior procedures (which would violate rule 1)

  51. mzumsande commented at 1:49 am on October 29, 2025: contributor

    In my opinion it doesn’t really matter whether a single DNS seeds returns nodes running the newest version or not. DNS seeds are important for the initial bootstrap, they are ideally are queried exactly once in the lifetime of a node. After that, nodes will automatically learn about thousands of other peers, so they will soon get a representative sample of nodes anyway. Besides, newer Knots versions based on 29.x aren’t returned either.

    I think the other issues brought up above are much more serious.

  53. shyrwall commented at 4:47 am on October 29, 2025: none

    I just queried all the DNS seeds and compared responses with BitNodes API, using jq to isolate the user agent:

    https://gist.github.com/pinheadmz/ff6057f14aa6b9aa642db2c98f331a1a

    No real anomolies to speak of, except that seed.mainnet.achownodes.xyz returned the most knots nodes 🤷

    update: dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us is not returning v29 or v30 nodes, apparently

    You can just check https://luke.dashjr.org/programs/bitcoin/files/charts/data/seeds.txt instead of DNS-queries. The ones marked as good are returned.

    I think it’s important to note that he’s also not returning any newer Knots nodes. So I don’t see how it’s violating the policy.

  54. Remove unreliable seed from chainparams.cpp, and the associated README b0c706795c
  55. SatsAndSports force-pushed on Oct 29, 2025
  56. SatsAndSports commented at 6:59 am on October 29, 2025: none
    I’ve squashed the two commits into one, and made the commit text more accurate, as suggested by @davidgumberg
  57. wizkid057 commented at 8:36 am on October 29, 2025: none

    NACK

    This is clearly a personal attack with zero technical merit, zero violation of any policy, and is overall just part of the continuing witch hunt of some vs Luke.

    Regardless, I’d highly suggest waiting until @luke-jr can comment and weigh in on this directly before even considering hastily merging this. Doing so without that minimum courtesy seems quite unnecessary for something that couldn’t possibly pose any risk whatsoever nor require such any haste.

    https://x.com/LukeDashjr/status/1983322751747412327

    At a minimum, address any deficiencies you may think his DNS seed has with him here.

    All of that said, unless there’s actual proof that some rule has been violated with regard to operating the DNS seed, this PR needs to just be closed. Making such a change backed solely by dogpiled personal attacks is just crazy.

  58. l0rinc commented at 8:39 am on October 29, 2025: contributor
    reACK b0c706795ce6a3a00bf068a81ee99fef2ee9bf7e
  59. DrahtBot requested review from davidgumberg on Oct 29, 2025
  61. dergoegge approved
  62. dergoegge commented at 9:35 am on October 29, 2025: member
    ACK b0c706795ce6a3a00bf068a81ee99fef2ee9bf7e
  63. laisial commented at 10:18 am on October 29, 2025: none

    I’d highly suggest waiting until @luke-jr can comment and weigh in on this directly before even considering hastily merging this. https://x.com/LukeDashjr/status/1983322751747412327

    he has commented in the post you shared. also, you did not provide any counterarguments. the policy is using an open standard, so any decision will be subjective and open to interpretation.

    luke did say that he “Obviously” plans to add new versions in the future: https://x.com/LukeDashjr/status/1983414007278288950.

  64. stickies-v approved
  65. stickies-v commented at 10:20 am on October 29, 2025: contributor
    re-ACK b0c706795ce6a3a00bf068a81ee99fef2ee9bf7e
  66. fanquake renamed this:
    Remove unreliable seed from chainparams.cpp, and the associated README
    chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us
    on Oct 29, 2025
  67. jlopp commented at 11:01 am on October 29, 2025: contributor

    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.

    This may be considered more of a meta comment, but the practice of a DNS seed dropping peers based upon their useragent is problematic in my view.

    A useragent by no means defines how a node operates; it’s trivial to set one’s node to advertise any arbitrary useragent. If a DNS seed only accepts specific “approved” useragents, that seems to violate the “fairly selected” clause in my opinion.

    One could dig into what it means to be a “functioning Bitcoin node” - given that there is no such thing as “proof of node” then I’d suggest that this just means the peer responds to any given p2p message in line with the protocol, and the DNS seed operator has the discretion to decide how exhaustively they wish to query a given peer to determine its level of functionality.

  68. Crypt-iQ commented at 12:33 pm on October 29, 2025: contributor
    crACK b0c706795ce6a3a00bf068a81ee99fef2ee9bf7e
  69. glozow commented at 12:56 pm on October 29, 2025: member

    I’d highly suggest waiting until @luke-jr can comment and weigh in on this directly before even considering hastily merging this.

    We have previously given operators time to respond when we noticed problems with their DNS seed. I’m not sure what is giving people the impression that we’re not doing the same here; Luke has been pinged both on this PR and directly through other platforms. @luke-jr please update us here instead of on twitter.

  70. jaonoctus commented at 1:48 pm on October 29, 2025: none
    Concept ACK, I agree with @achow101 and @niteshbalusu11
  71. wizkid057 commented at 1:49 pm on October 29, 2025: none

    I’m not sure what is giving people the impression that we’re not doing the same here

    The pitchfork carrying mob seems to be out in force here, complete with some maintainers, on this nothingburger PR with 50+ comments in < 24 hrs… while there’s other PRs (likely with actual merit) which don’t even have a single comment from a maintainer… that’s what’s giving the impression.

    Luke has been pinged both on this PR and directly through other platforms. @luke-jr please update us here instead of on twitter.

    In case you or others didn’t read the note I previously linked, in it Luke states that he can not currently respond on GitHub due to security practices while traveling. I don’t know his travel schedule, so I don’t know when he’ll be able to respond, but I’m certain he will the moment he is able to do so.

    In the meantime, seems likely the dogpile will continue unchecked, despite there being no non-political reasoning for doing so.

    Perhaps lock this thread for now pending his return?

  72. kanzure commented at 2:04 pm on October 29, 2025: contributor
    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.
  73. laisial commented at 2:18 pm on October 29, 2025: none

    personal attack with zero technical merit zero violation of any policy continuing witch hunt of some vs Luke. minimum courtesy change backed solely by dogpiled personal attacks is just crazy. The pitchfork carrying mob seems to be out in force this nothingburger PR the dogpile will continue no non-political reasoning lock this thread @wizkid057 you’re spamming off-topic with zero counterarguments on why the seed policy has not been violated. you’re only policing the tone and appealing to morality. with your final wish to censor the discussion.

    reading the level of discourse here is shocking.

  74. glozow commented at 2:21 pm on October 29, 2025: member

    Calm down.

    Historically, when a DNS seed was not operating properly, an issue was opened and we waited for the operator to respond.

    Potential actions we can take: (0) address the problems with the DNS seed, (1) decide there is no problem (though I think it’s clear that there are technical issues here and this is not just a “witch hunt”), or (2) remove the DNS seed. I agree that opening a PR to remove the seed straight out of the gate was not the best way to bring up the issue.

    I’ve opened the issue at #33734. This PR has already been reviewed for correctness, so this is ready for merge if chosen as the solution.

    I have contacted @luke-jr directly and expect a response on #33734 in a few days.

    This thread should be locked.

    If you have something new to add to the discussion about whether the DNS seed policy is being violated, put it on #33734. If you find a bug in the code here, wait until the thread is unlocked.

  75. bitcoin locked this on Oct 29, 2025
  76. DrahtBot requested review from jaonoctus on Oct 31, 2025


SatsAndSports DrahtBot dergoegge pinheadmz stickies-v reardencode delta1 waketraindev achow101 fanquake mzumsande davidgumberg jlopp Symphonic3 glozow polespinasa niteshbalusu11 hsjoberg john-moffett gmaxwell frodrik-froggo onyxcoyote l0rinc 00w1 Ademan shyrwall wizkid057 laisial Crypt-iQ jaonoctus kanzure


davidgumberg achow101 jaonoctus polespinasa

Labels
P2P Needs backport (28.x) Needs backport (29.x) Needs backport (30.x)

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2025-11-02 15:13 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me