847 Pull Requests, Zero Headlines: Inside Bitcoin Core 28

Bitcoin's price fell 45% and the entire financial media wrote about it. Bitcoin Core merged 847 pull requests in the past twelve months and almost nobody outside of the developer mailing list noticed.

This asymmetry defines the gap between Bitcoin as a financial asset and Bitcoin as a protocol. The price is a number on a screen that changes every second. The protocol is the system that makes the number meaningful. One gets all the attention. The other does all the work.

What Bitcoin Core 28 Actually Changed

Bitcoin Core 28, released in late 2025, was not a single dramatic upgrade. It was hundreds of incremental improvements across four critical areas: transaction relay, mempool management, peer-to-peer networking, and wallet functionality. None of these changes are visible to someone checking their portfolio on an exchange. All of them matter for the long-term viability of the network.

Transaction relay policy received the most consequential updates. The mempool — the waiting room where unconfirmed transactions sit before being included in a block — has historically been a source of friction. During fee spikes, the mempool swells to hundreds of thousands of transactions, and the rules governing which transactions get relayed, which get evicted, and which get prioritized directly affect every user's experience.

Core 28 introduced package relay — a mechanism that allows child transactions to pay for the confirmation of their parent transactions in a single atomic bundle. This sounds arcane. It is not. Package relay solves a problem that has plagued Lightning Network channel closures for years: when a channel force-closes during a fee spike, the closing transaction may have insufficient fees to confirm promptly. Without package relay, the user is stuck waiting — sometimes for days — while their funds are locked. With package relay, a second transaction can attach additional fees to the original, ensuring timely confirmation regardless of mempool conditions.

For Lightning Network users, this is the difference between a force-close resolving in an hour versus resolving in a week. For the 2 million daily Lightning transactions, it is infrastructure that makes the payment layer reliable under adversarial conditions.

The Mempool Got Smarter

The mempool eviction policy was overhauled to be more economically rational. Previously, when the mempool reached capacity, transactions were evicted based primarily on fee rate — lowest fee rate gets dropped first. This created perverse incentives. A low-fee transaction that was a parent of a high-fee child transaction would be evicted, orphaning the child and reducing total miner revenue.

The new policy considers transaction clusters — groups of related transactions that depend on each other — and evicts the cluster with the lowest aggregate fee contribution. This means the mempool retains the set of transactions that maximizes total fees, which aligns miner incentives with user experience.

The practical effect is fewer stuck transactions during congestion periods. A user who submits a transaction with a reasonable fee is less likely to see it dropped from the mempool during a spike, because the eviction algorithm now accounts for the transaction's role in the broader dependency graph.

P2P Network Hardening

The peer-to-peer layer — the gossip network through which nodes discover each other and propagate transactions and blocks — received significant security improvements.

Eclipse attack resistance was strengthened. An eclipse attack occurs when an adversary controls all of a node's connections, allowing them to feed the node false information about the state of the blockchain. Core 28 expanded the diversity requirements for outbound connections, ensuring that nodes connect to peers across multiple network ranges and autonomous systems. The practical barrier to executing an eclipse attack increased substantially.

Transaction origin privacy was improved through changes to how transactions are announced to peers. Previously, a sophisticated observer monitoring multiple nodes could correlate transaction announcements to identify the originating node — and by extension, the user who created the transaction. Core 28 introduced randomized announcement delays and batching that make origin identification significantly harder.

This is not theoretical. Chain analysis firms have used transaction propagation timing as one input to their deanonymization models. Every improvement to announcement privacy degrades the accuracy of those models.

CJDNS and I2P support was expanded, giving users more options for running nodes over privacy-preserving networks. While Tor has been the standard privacy overlay for Bitcoin nodes, Tor's reliability has degraded in recent years due to DDoS attacks against the network. CJDNS and I2P provide alternative transport layers with different trust and performance characteristics.

AssumeUTXO: Full Nodes in Minutes, Not Days

One of the most user-facing improvements is AssumeUTXO, which allows a new node to begin validating and relaying transactions within minutes of startup by loading a pre-computed snapshot of the UTXO set — the database of all unspent Bitcoin — rather than replaying the entire blockchain from the genesis block.

Previously, starting a new full node required downloading and verifying 600+ gigabytes of blockchain data, a process that takes 12-72 hours depending on hardware and bandwidth. This was a meaningful barrier to running a full node, which is the gold standard for trustless Bitcoin usage. If you do not run your own node, you are trusting someone else's node to tell you the truth about the state of the network.

With AssumeUTXO, the node becomes functional almost immediately while continuing to validate the full history in the background. The security model is unchanged — the node eventually verifies everything — but the usability improvement is dramatic. A user can set up a new node, begin receiving and validating transactions within ten minutes, and have full historical verification complete by the next morning.

This matters for Bitcoin's decentralization. The easier it is to run a full node, the more nodes exist. The more nodes exist, the harder it is for any entity — government, corporation, or mining pool — to manipulate the network. Decentralization is not a slogan. It is a direct function of how many independent participants validate the rules.

The Governance Nobody Understands

Bitcoin Core's development process is frequently misunderstood by people who come from traditional software development or corporate governance backgrounds. There is no CEO. There is no board of directors. There is no voting mechanism. There is no foundation with decision-making authority.

Changes to Bitcoin Core require rough consensus among a group of approximately 30-40 regular contributors, reviewed by a smaller set of maintainers who have commit access to the repository. Any contributor can propose a change. Any contributor can block a change by raising substantive technical objections. The process is deliberately slow, deliberately conservative, and deliberately resistant to pressure from any single entity.

This is often criticized as inefficient. It is inefficient — by design. Bitcoin secures over $1 trillion in value. The cost of a bug or a malicious change is measured in billions of dollars. The development process prioritizes correctness over speed, and security over features. A proposed change that is "probably fine" does not get merged. A change must be demonstrably safe, thoroughly tested, and widely reviewed.

The result is that Bitcoin changes slowly. But when it does change, the changes are solid. There are no "move fast and break things" moments in Bitcoin Core development. The protocol's 15-year track record of zero unscheduled downtime is the evidence.

Why This Matters More Than the Price

The market will decide what Bitcoin is worth tomorrow. It will be some number higher or lower than today's number, and people will write articles explaining why the number moved.

None of that matters if the protocol does not work. The question that determines Bitcoin's value over decades — not days — is whether the system can scale to serve billions of users, resist state-level attacks, maintain decentralization under commercial pressure, and preserve the properties that make it valuable in the first place.

Package relay makes Lightning more reliable. Mempool improvements make transactions more predictable. P2P hardening makes the network more resistant to surveillance and attack. AssumeUTXO makes running a full node accessible to normal people. These are the changes that determine whether Bitcoin in 2036 is a functioning global monetary network or a historical curiosity.

The developers shipping these changes are not on CNBC. They are not posting predictions on X. They are writing C++ in public repositories, reviewing each other's code, arguing about edge cases in mailing list threads that nobody reads.

They are building the thing that everyone else is just trading.