Issue 20: December 10, 2025

DNS seed operator removal, concern about Bitprojects, and Bitcoin mining pool December stats

Dec 10, 2025

Good morning,

Last Thursday, Bitcoin Core developers discussed updates from the Kernel, Benchmarking, Silent Payments, and Cluster Mempool working groups (WGs).

Developers also addressed—and acted on—the removal of Ocean Mining CTO and Bitcoin Improvement Proposal (BIP) Editor Luke Dashjr from Bitcoin’s DNS seed operator list. I break down what the DNS seed system is and why maintainers decided it was necessary to remove Luke from the rotation.

Also in today’s issue: a look at Bitprojects, the Bitcoin node hosting service whose large-scale infrastructure has raised concerns about node peering, plus the latest data on Bitcoin mining pool distributions and what it indicates about the Bitcoin mining industry at large.

Thanks for joining me this morning for another edition of BTC Before Light. Let’s get into it.

Yours truly,

Christine D. Kim

⏱️Core Release Schedule

(For background on the Bitcoin software development process, refer to the Bitcoin Governance 101 document in the BTC Toolkit.)

First, a quick overview of Bitcoin Core’s software release schedule and the status of the next major release:

Latest Stable Major Release: Bitcoin Core  30.0

Release Date: October 13, 2025

Latest Stable Minor Release: Bitcoin Core 28.3

Release Date: October 17, 2025

Upcoming Major Release: Bitcoin Core 31.0

Target Release Date: April 10, 2026
Open issues: 12
Closed issues: 17
Milestone progress: 58%

The previous week’s issue showed 11 open issues, 14 closed, and a milestone progress of 56%.

🗒️Meeting Minutes

(Quotes featured in this section and the next may be edited slightly for grammar and clarity. For more information on the people involved in Bitcoin development, refer to the Bitcoin Project Contributor Directory in the BTC Toolkit.)

Kernel WG: The Kernel WG aims to modularize Bitcoin Core by isolating consensus-critical logic from wallet code, user interfaces, and other non-consensus-critical components.

“sedited” noted there are several pull requests (PRs) on the Kernel project board that are ready for review.

Benchmarking WG: Efforts to measure and improve the performance of Bitcoin Core software through benchmarking, that is, analyzing how long certain processes take.

“L0rinc” reported that work is ongoing for PR #31132 (validation: fetch block inputs on parallel threads >40% faster Initial Block Download).

Silent Payments WG: Implementation of BIP 352, a way to improve on-chain privacy by enabling users to create a single reusable address that can automatically generate one-time addresses for incoming payments that only the recipient can identify.

“stickies-v” proposed archiving this working group until a champion can be identified who can share regular updates on the group’s progress.

Cluster Mempool WG: An initiative to build a graph-based mempool that would enable nodes to reason about the relationship between unconfirmed transactions and bundle related ones together for improved transaction fee estimation, prioritization, and storage.

“sipa” is reviewing PR #32545 (Replace cluster linearization algorithm with SFL).

Secp256k1 Library Update: Secp256k1 is the mathematical curve used by the Bitcoin protocol to create and verify digital signatures. Developers maintain a version of this curve for use in Bitcoin.

“abubakarsadiq” requested review for PR #1765 (Add “silentpayments” module implementing BIP352).

Bitcoin Core v31 Update: The next major software version release for the Bitcoin Core client.

“instagibbs” proposed including PR #33892 (policy: Remove individual transaction <minrelay restriction) and PR #33616 (policy: don’t CheckEphemeralSpends on reorg) in the v31 release.

Net Split WG: An initiative to separate Bitcoin’s networking layer from its peer-processing layer for improved networking upgradeability and testability.

“cfields” said they received good feedback on the meta PR for this WG, but not much progress to report this week on the project.

BIP 54, Consensus Cleanup: A soft fork proposal that would introduce several consensus-level safeguards for making the Bitcoin protocol’s transaction validation rules more predictable and resistant to denial-of-service (DoS) attacks.

“darosior” said an implementation of BIP 54 is ready for review on the Bitcoin Inquisition testnet.
Developers discussed whether it is due process to review BIP 54 as an implementation on Bitcoin Inquisition, rather than as a formal PR to Bitcoin Core.

DNS Seed Removal: A DNS seed is a service that helps new Bitcoin nodes discover other online nodes when they first connect to the peer-to-peer network. It is run by a group of about eight trusted operators that use automated crawlers to scan for and return a random set of publicly reachable Bitcoin nodes.

“dergoegge” asked why PR #33723 (chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us) has not been merged. This PR removes BIP Editor Luke Dash Jr. as a trusted operator for the DNS seed.
“Murch[m]” said Dash Jr. is “actively attacking Bitcoin Core” and should be relied on as little as possible.
After some discussion, “fanquake” merged the PR during the meeting.

IRC Chair Triage Permissions: The IRC Chair is the individual who hosts the Thursday Bitcoin Core developers meetings over Internet Relay Chat (IRC). Since last month, developers have been rotating chair responsibilities between a few regular meeting participants.

“stickies-v” asked if IRC chairs should be granted triage permissions, which would allow these individuals to label issues, move them into milestones, and help with basic project organization on Github.
Developers agreed that IRC meeting chairs don’t currently need these permissions, but the idea can be reconsidered later if the responsibilities for chairing IRC meetings expand and require it.

Outbound Peers Selection: A Bitcoin infrastructure and consulting firm known as Bitprojects operates a node cluster of roughly 3,000 peers, representing about 30% of the public Bitcoin network. This has prompted concerns of eclipse attacks. Eclipse attacks refer to isolating nodes such that all outbound connections are attacker-controlled peer connections.

Darosior proposed a way to randomize outbound peer selection further, such that eclipse attacks are harder to pull off.
Developers debated how detrimental eclipse attacks are in practice to node operations and network security, given code changes like PR #19858 (Periodically make block-relay connections and sync headers) that already reduce the payoffs from eclipse attacks.
They also discussed potential second-order consequences of tweaking outbound peer selection, which could make it easier for a malicious entity to pull off eclipse attacks.
Developers agreed that more discussion and network simulations are needed on this topic. Darosior said they will open an issue on Github for continued conversation.

Meeting Highlights

Discussion: Bitprojects controls about 30% of publicly identifiable, IPv4-reachable, Bitcoin nodes on the internet. (This share is not of all active Bitcoin nodes contributing to protocol security and decentralization. Some Bitcoin nodes run behind privacy networks such as Tor, or behind firewalls, or are set up to be otherwise unreachable by public crawlers.)

According to the Bitprojects website, they operate thousands of Bitcoin nodes to provide “anycast hosting” services. Anycast is a networking technique in which multiple servers, or in this case, nodes, share the same IP address. In doing so, servers may be more resilient through load balancing and quicker to respond to global user requests, as multiple servers are reachable for requests and, presumably, from various locations around the world.

In September, Darosior wrote a blog post explaining how Bitprojects nodes masquerading on the network as one node resulted in initially confusing behavior that they suspected to be “spy nodes.”

Darosior wrote:

In late June 2025, Eric Voskuil reached out to me asking about a weird behaviour he had observed on the Bitcoin network. Libbitcoin had started dropping peers which advertised an excessively off timestamp in their version message and they found that while most peers were within seconds, a handful were off by small amounts and a large number was behind by up to 5100 minutes. What’s more, all those peers were Bitcoin Core v27.1 or v27.2.

Through further investigation, Darosior identified the root cause of the issue as a clock misconfiguration within Bitprojects’ nodes.

Darosior alerted Bitprojects to the problem, and Bitprojects has since addressed it. However, now that these nodes are back online and in greater numbers than before, developers are concerned about the downstream consequences of any entity with as much share as Bitprojects of publicly identifiable Bitcoin nodes.

Darosior said in the IRC meeting on Thursday:

When you spin up a new nodes nowadays it would most of the time have around 3 outbound connections to [Bitproject nodes]. We’ve had multiple reports of this happening. So all this to say my concern is not purely theoretical, there is an entity actively trying to demonstrate it, which is reasonably successful so far.

The concern is that Bitprojects could launch eclipse attacks on other nodes by commanding all outbound connections. This could then lead to Bitproject nodes purposefully withholding or delaying blocks from other nodes, or withholding transactions submitted from isolated nodes, or manipulating pending transaction information.

“Eugenesiegal” said during the meeting:

I think [Bitprojects] could cause some damage if he withheld blocks, even if only for 10 minutes...

Darosior proposed changing how nodes choose outbound connections by first requiring nodes to randomly select an internet netgroup, or cluster of IP addresses, before choosing a peer within that netgroup.

If we were to instead pick a random netgroup to connect to, and then pick a node from this netgroup, the probability for an attacker to control all of our outbound connections would be exponentially decreasing in the number of connections we make.

One concern raised by Sipa about this proposal is that it may allow attackers to more easily eclipse nodes’ connections by purposefully spinning up malicious nodes across obscure netgroups to increase the probability of peer connections.

To this, “Lightlike” suggested a mixed strategy in which half of all outbound node connections are determined by netgroup sampling and the others by regular peer sampling.

Developers agreed to continue the discussion on mitigations for eclipse attacks on Github.

Takeaway: Ideally, all 10 outbound peer connections created by a Bitcoin node are to other nodes, each operated by a different entity from a different geographic location. This ensures maximum resiliency and reliability in node operations. However, due to the scale of Bitproject’s operations, there are now instances of nodes where three to four of the node’s ten outbound connections are commanded by the same entity. While this is still not the majority of connections, it raises concerns about the outsized influence Bitproject operations may have on the Bitcoin network, whether through unintentional clock misconfigurations or intentional ones.

📧 You’ve Got Mail! (& Other News)

(For a comprehensive overview of all major Bitcoin development meetings and discussion forums, refer to this post in the BTC Toolkit.)

An overview of other notable discussions and news that happened over the past two weeks, sourced from the Bitcoin Development Mailing List and other public forums:

One denial-of-service and two theft-of-funds vulnerabilities were fixed in the Lightning Network Daemon (LND) client. Users should immediately upgrade to LND 0.19.0 or later to protect their funds. (Delving Bitcoin)
Firmware engineer at Ledger, Salvatore Ingala, unveils Vanadium, a new and experimental approach to building hardware wallets that allows developers to write and test firmware as regular Rust programs that run on a RISC-V Virtual Machine within a secure enclave environment. (Delving Bitcoin)
Founder of Satsbridge Ilya Evdokimov proposes the design for a new protocol that lets Bitcoin Lightning wallets act as secure remote signers for Ethereum smart contract wallets. In other words, a user could log in to Ethereum apps and approve Ethereum transactions using a Lightning wallet, rather than an Ethereum wallet. (Delving Bitcoin)
BitcoinTalk user “NotBlox1” shares an overview of Bitcoin mining pool market share as of December 2025. Among the pools, Foundry USA has the highest share, building over 1/5 of all Bitcoin blocks. (Bitcoin Talk)

Discussion Spotlight

Subject line: Bitcoin Mining Pool distribution monthly reports

Date(s): July 21, 2025 - December 9, 2025

Discussion: On Tuesday, NotBlox1 updated the Bitcoin Talk thread on Bitcoin mining pool distribution with a new snapshot of data from Bitcoin blockchain explorer mempool.space.

The following chart shows mining pool distribution over the past 24 hours:

Source: mempool.space. Data as of December 9, 2025.

Since 2022, Foundry has been the top pool for Bitcoin mining reward payouts.

Earlier this year, in January, Foundry was responsible for building over one-third of all Bitcoin blocks. However, over the past 12 months, their share has declined to 20%-25% of all Bitcoin blocks.

Behind Foundry, the long-established pools Antpool and F2Pool continue to rank as the second and third-largest miners by share. These two pools once dominated Bitcoin mining during the 2010s and early 2020s. However, their market share declined due to regulatory changes in China that forced pool operators to relocate and rebuild infrastructure across jurisdictions such as Kazakhstan, the U.S., and parts of Europe.

Takeaway: Foundry’s multi-year run as the top Bitcoin mining pool underscores how decisively the center of gravity in Bitcoin mining has shifted to the United States, where miners and pool operators benefit from deep capital markets, strong rule of law, and access to large-scale industrial energy infrastructure.

Earlier this year, Foundry’s share briefly exceeded one-third of all blocks mined, prompting concerns about pool centralization. Foundry’s current 20–25% range remains notable, but is less concerning than the >33% threshold Bitcoin stakeholders were watching in January.

It’s important to remember that pool-level concentration does not map to miner concentration. Many small or mid-sized operators direct their hash rate to the same pool for more stable payouts, and miners can switch pools quickly, meaning pool dominance is rarely “sticky.”

Moreover, pools do not control miners’ hardware—they coordinate block templates and payouts. Still, because block templates determine transaction selection and ordering, there are ongoing efforts through a project called Stratum v2 to decentralize block construction by shifting template creation from pools to miners themselves.

Even with its caveats, pool concentration offers one lens through which stakeholders can track trends in the Bitcoin mining industry and assess potential centralization pressures impacting the Bitcoin protocol.

🟠 You are now officially caught up on the state of Bitcoin Core development and governance.

🙏 Thank you for reading this issue of BTC Before Light. If you like what you read, consider sharing it with a friend who might also enjoy the content.

💥If today’s post sparked any thoughts, opinions, or questions, I’d love to hear them. Please share your feedback on today’s newsletter by leaving a comment.

Discussion about this post

Ready for more?