Bitcoin Core's Quiet February Upgrades: Better Indexes, Stronger Privacy, Eclipse Resistance Built In | Bitcoin Index

The most important Bitcoin upgrades happen quietly. No fanfare, no price pumps, just careful code review and merges that won’t make headlines until years later when you realize the whole ecosystem depends on them.

Between February 19-20, 2026, three infrastructure improvements landed in Bitcoin Core master, all targeting version 31.0. None of them touch consensus. None of them will trend on social media. But they matter: better Lightning tooling, built-in eclipse attack resistance, and privacy features you can actually control.

Here’s what shipped.

Four years for a Lightning index

PR #24539 opened in March 2022. It merged on February 20, 2026. That’s nearly four years for what sounds simple: track which transaction spent each output.

The new -txospenderindex flag gives Lightning nodes (and any Layer 2 protocol) a clean way to ask: “Has output X been spent? If so, by which transaction?”

Before this, Lightning implementations had three bad options:

Run an Electrum server (centralized, privacy leak)
Enable -txindex (expensive, indexes everything whether you need it or not)
Use watch-only wallets (doesn’t scale when you’re tracking thousands of outputs)

Now you run Bitcoin Core with -txospenderindex and the gettxspendingprevout RPC tells you:

The spending transaction ID
The block hash where it confirmed
Optionally, the full spending transaction itself

This is critical for watchtowers monitoring revoked commitment broadcasts, LSPs checking funding confirmations for mobile users, and anyone running Lightning infrastructure without relying on external services.

Four years. Why so long?

Not controversy. Careful design. The PR author, sstone from ACINQ (the Eclair Lightning team), worked with reviewers to get the index structure right. The final version uses a composite key design that keeps storage overhead minimal: average key size of just 15 bytes.

Bitcoin Core doesn’t rush infrastructure. The code that ships is code that will run on thousands of nodes for the next decade. Four years starts to feel reasonable when you think about it that way.

Eclipse resistance without the file hassle

PR #28792 completed a three-part series to embed ASMap data directly into the Bitcoin Core binary. This one’s about security most users don’t think about.

An eclipse attack isolates your node from all honest peers. You only connect to attacker-controlled nodes. The consequences are ugly:

They feed you a fake chain
They censor your transactions
They control what you see
They know exactly which transactions you broadcast

Bitcoin Core mitigates this by connecting to a diverse set of peers. Historically, diversity meant different IP prefixes. But an attacker controlling multiple IP blocks could still surround you.

ASMap improves this by mapping IPs to Autonomous System Numbers (ASNs). That’s the network operators (ISPs, hosting providers) that control those addresses. Bitcoin Core then ensures it connects to peers across different ASNs, making it much harder for one entity to control all your connections.

The problem? Enabling ASMap used to require:

Obtaining an ip_asn.map file (generate it yourself or download from somewhere)
Placing it in the correct directory
Passing -asmap=PATH to Bitcoin Core

Most users never bothered.

Now the ASMap data lives in the Bitcoin Core repository at src/node/data/ip_asn.dat. It compiles directly into the binary. You just run Bitcoin Core with -asmap (no path needed).

One flag away instead of a multi-step treasure hunt.

Important caveat: it’s still opt-in. You have to pass -asmap to enable it. The default remains off to avoid surprising existing nodes. But the barrier dropped from “manually manage external files” to “add one flag.” That’s a real UX improvement for a real security feature.

Private broadcast gets visibility

PR #34329 adds two RPC commands for managing private transaction broadcasts: getprivatebroadcastinfo and abortprivatebroadcast.

Context: PR #29415 (merged mid-February) introduced the ability to broadcast transactions via short-lived Tor or I2P connections instead of your regular peers. This prevents network observers from linking a transaction to your IP address.

The privacy benefit is real. The problem is you had no way to:

See what was in the private broadcast queue
Know which peers were selected
Cancel a transaction that was taking too long
Debug when things weren’t working

Now you can query the status of your private broadcasts, see exactly which Tor/I2P peers were chosen, and cancel if needed.

This is a power-user feature. Most people running Bitcoin Core aren’t configuring Tor/I2P and worrying about transaction origin privacy. But for those who are, having visibility and control matters.

I keep coming back to this: privacy features that require manual setup and technical knowledge aren’t privacy for the masses. They’re privacy for the people who already know they need it. That’s fine. Not every feature has to be for everyone. But it’s worth being honest about who this serves.

Why infrastructure work takes time

Looking at the merge dates and PR lifespans:

PR #24539 (tx spender index): ~4 years
PR #28792 (embedded ASMap): ~15 months
PR #34329 (private broadcast RPCs): ~1 month

The variance tells you something. The transaction spender index required careful design iteration and review from multiple developers. Embedded ASMap was the final piece of a three-part series that laid groundwork over months. Private broadcast RPCs built on freshly merged functionality. They add visibility to something that just shipped.

None of this is consensus code. No one’s wallet breaks if these features have bugs. But they still get reviewed like they matter, because they do. Lightning nodes will depend on that index. Privacy-conscious users will trust that private broadcast actually works. Nodes enabling ASMap will assume it’s actually helping.

Bitcoin Core’s review culture is slow by startup standards. It’s fast by “infrastructure that has to work for a decade” standards.

What this means for version 31.0

All three PRs are assigned to milestone 31.0. No release date set. Bitcoin Core typically ships major versions every six months or so, but that’s not a hard rule.

What’s coming in 31.0 isn’t a single headline feature. It’s incremental improvements to Lightning tooling, network security, and privacy infrastructure. The kind of work that gets appreciated in hindsight.

Five years from now, when Lightning adoption is higher and privacy matters more to more people, someone will look back and say “oh, that’s when Core laid the groundwork.”

That’s how Bitcoin development works. Not flashy announcements, just steady improvement. The upgrades that matter most are the ones you don’t notice until you realize you’re depending on them.

Sources

Last updated: March 2, 2026