Transparency Report 003

  • Post date March 18, 2026
Transparency Report 003

This is our third Transparency Report. These reports offer us an opportunity to detail some of the recent activity our organization has engaged in. We hope to surface interesting materials and inspire others to dig deeper into our focus areas and the work which surrounds it.

This report covers activity from August 1st 2025 through December 31st 2025. It is non-exhaustive. 

Highlight: 

  • From August 18th to November 21st we were joined by our first Visiting Scholar, Pol Espinasa. Some of his work will be included in this report. Many thanks to Lightspark and Tyler Levine for supporting his visit.

Events and Education

Conferences and Meetups

The late summer and fall are particularly busy times for the Bitcoin community. As summer vacation winds down, work picks up and the fall conference circuit goes into full throttle. 

In October, Localhost Research sponsored and organized the Socratic Village at TABConf 7. In the Socratic Village, our team was involved in four events:

  • Justin, Murch, and David led the “Project Updates and Cherry Picked PRs from Bitcoin Core” Socratic Session and covered some exciting areas of the codebase.
  • Justin moderated the “Mempool Policy and Payload Politics” Socratic Panel, alongside panelists Murch, Ava, and Matthew Zipkin. This panel was an opportunity for community members to explore issues surrounding the recent relaxation of Bitcoin Core’s OP_RETURN network policy limit. 
    • Topics covered: Bitcoin Core’s moderation policy, the history and boundaries for useful standardness rules, compact block reconstruction rates, private mempool providers, metaprotocol design patterns, and an exploratory steelman of the pro-filter camp’s position.  
  • Justin was both a moderator and panelist in the Techniques for Diffusing Mining Centralization Pressures Socratic panel, alongside Bob McElrath, average-gary, and vnprc. Justin presented on FIBRE and MEVPool, Bob on Braidpool, average-gary on SV2 and vnprc on Hashpools.
    • The discussion started with a review of the Antpool and Friends template provider cartel and the associated subject of FPPS and variance reduction. 
    • We explored questions related to each project:
      • We raised concerns around code quality and barriers to adoption of Sv2
      • On Hashpool, we contemplated who might make markets for these hash shares, as well as how the project was being developed in relation to the upstream Sv2 codebase
      • During the Braidpool discussion, we covered local resource requirements as well as scaling limitations of a Braidpool
    • We closed out the panel with a brief investigation into novel coinbase payout schemes utilizing Coinpool/Joinpool-style protocols (e.g. Ark).  

After the conference, Justin hosted Hardcore Trivia. Congrats to team Ringer Signature for winning!

Beyond the village, Murch joined the Pleb Undeground stream for a chat. The team also attended a number of workshops and fielded questions at the Bitcoin Core “table.” David and Pol were particularly excited about Warnet, so much so that David even made a minor upstream contribution to improve his workflow.

Many thanks to the conference organizers for another excellent TABConf! We look forward to this year’s event.

Right after TABConf, the entire team attended CoreDev in Frankfurt, the twice-yearly event designed to bring together regular Bitcoin Core contributors. These events present contributors with the opportunity to collaborate, push forward important discussions, and assess project direction. Justin and Patricia helped organize the event alongside Mike Schmidt and Emily Kee of Brink. Transcripts from the event can be found here. 

In early November, Bitcoin Research Week was hosted at Chaincode Labs. Ava, David, and Pol attended and participated in a number of the sessions, including SwiftSync, ARK, PeerObserver, WalletFingerprint, BitVM, among others.

In October, Murch presented on Working in Open Source at the Laurier Bitcoin Club. In December, he gave a similar presentation at the Bitcoin Builders meetup in Palo Alto: Onboarding to Bitcoin Development. 

Pol lead discussion on the OP_RETURN and filter drama at the third BitDevs Lima Socratic Seminar and a BitDevs Latino event.

Throughout the summer and fall, Justin regularly co-hosted SF BitDevs, and guest co-hosted BitDevs NYC in September. 

Recurring Education and Media Contributions

On Bitcoin Stack Exchange, Murch continued his moderation efforts and answered a number of questions, two notable ones of which can be found below:

Murch also co-hosted 17 episodes of the Bitcoin Optech Newsletter Recap Podcast. He contributed to the Optech Year in Review newsletter as well as the special 4.5-hour Year In Review podcast.

Ava hosted her regular Monday Twitch streams 14 times, including one stream dedicated to a thought experiment: what would it take to stop arbitrary data? Notes from the stream can be found here.

For the last 4 years, Ava has been the primary meeting chair for the weekly #bitcoin-core-dev IRC meetings (and for 2 years prior to this she led the wallet meetings). In October, she suggested to the group that rotating chairs would lower the burden on any individual chair and avoid a tragedy of the commons where no one steps up to act as chair. The group has agreed to a rotation, and a set of new contributors have assumed the role. Thanks to Ava for your many years of leadership in the meetings!

Murch spent dozens of hours on X educating the community about the OP_RETURN debate and published a number of useful threads:

One-off Media and Educational Contributions

Murch was a guest on a number of podcasts:

…he also contributed to a Blocktrainer article (in German) about the OP_RETURN debate. With Murch’s help, Pol authored “A technical overview and opinion about mempool filters”

Murch advised Matthew Zipkin on how to structure the Coin Selection challenge during the most recent BOSS program. 

David was a guest on Presidio Bitcoin’s 21 in 21 where he details his journey through the Chaincode ₿OSS Challenge and his time at Localhost.

Bitcoin Improvement Proposals (BIPs)

Over the last year, activity in the BIPs repository has noticeably increased. Murch, as an active BIP editor, has shouldered a considerable amount of the required review work. From August through December, Murch left 343 review comments across 73 pull requests, closed (either via close or merge) 34 pull requests, and participated in BIP discussions on the Mailing List and Delving Bitcoin. 

Some notable BIPs that he reviewed: 

Outside of his day-to-day review work, he also pushed forward BIP 3, his proposal to update the BIP Process. In November, he sent out a Motion to Activate BIP 3 to the bitcoin-dev mailing list, seeking feedback on whether or not BIP 3 had yet reached a state of rough consensus. In response, he received additional feedback on the proposal, some of which was adopted into the BIP.

Bitcoin Core

Releases and Build Processes

Each “major” release of Bitcoin Core has a “release captain.” This individual is responsible for ensuring that all steps of the release process are followed. They are not required to complete all the steps themselves, but they must ensure the project as a whole has satisfied the requirements. This individual also assumes the role of release captain for any subsequent minor releases (Bitcoin Core always maintains the latest three major versions, ensuring bugfixes and other important updates are available to users). 

As captain of the v28 series of Bitcoin Core, Ava oversaw the packaging and release of v28.3 in October. The most notable backport included was the lowering of the default minimum feerate, a network policy rule that had become the source of significantly degraded performance of Compact Block Relay.  

In October, v30 of Bitcoin Core was released. Our team contributed to it in a variety of areas, many of which you will find in the sections below. Some of these PRs are included in the v30 “milestone.” PRs and issues with a milestone tag are items that the project agreed must be merged before a release can be “cut.” As blockers to a release, they can consume review bandwidth in the weeks and months leading up to a release. Our team, Ava especially, contributed to review of many of these milestone PRs. 

Wallet

Across the Bitcoin Core wallet, our team authored and reviewed a number of interesting PRs. 

In March of 2024, Ava opened a PR that enabled Bitcoin Core to receive and spend inputs involving MuSig2 aggregate keys. The PR received hundreds of review comments. In October of last year, it was merged. Ava reviewed and merged a number of other PRs related to this work. w0xlt also authored a PR that adds explicit tests for Bitcoin Core’s MuSig2 interface. Congrats to Ava and the whole project for enabling support for MuSig2!

Fellow contributor ishaanam opened a PR to support v3 transactions in the Bitcoin Core wallet. v3 transactions are an important primitive for Lightning and other L2 protocols, in that they help mitigate vectors for transaction “pinning.” Ava, w0xlt, and Murch provided valuable review to this pull request. In addition to this, Ava reviewed a PR authored by glozow that improves the wallet’s handling of the new v3 policy limits. 

P2A and ephemeral dust are also important tools for ensuring timely transaction confirmation in time-sensitive L2 protocols. In August, Ava opened a PR that ensures the Bitcoin Core wallet correctly identifies and handles these now-standard 0-value outputs. 

Work continues on Ava’s PR to better support airgap users in the wallet with an exportwatchonlywallet RPC. Pol and w0xlt both contributed reviews to this PR. 

Similarly, Murch further refined his work on an optimized BnB exploration coinselection algorithm based on feedback from Ava, w0xlt and a number of other contributors. 

The team contributed to a number of PRs related to descriptors. Notably, Ava introduced a new unused(KEY) descriptor that allows a wallet to hold HD keys which can sign but aren’t initially associated with any scripts. This is useful for scenarios like setting up a multisig. The PR also adds an addhdkey RPC that either generates a new HD key or imports a provided private key into the wallet via this descriptor, making key management and descriptor rotation more convenient. 

Pol, inspired by discussions amongst contributors and his own experience, has been working towards migrating Bitcoin Core away from representing fees in BTC/kvB to sat/vB. The wider Bitcoin ecosystem has long-since adopted sats/vB as the standard units to represent fees, so Core’s divergence is a source of confusion for users.  His earliest work in this area began with an effort to replace the settxfee RPC (which accepted fee rates in BTC/kvB) with a new settxfeerate function that would use sat/vB instead. However, static fee rate settings are a footgun: in a dynamic fee environment, they lead to overpaying when the mempool is empty or underpaying during congestion. Last year, rather than introducing a sat/vB replacement, Pol authored a PR that deprecated settxfee and paytxfee entirely, steering users toward per-transaction fee rate specification or the built-in fee estimation. He then followed up by removing both settings, a PR he worked on during his time at Localhost. Simultaneously, he opened an issue to discuss and track the migration across RPC and startup options. In June he began work on a refactor that directly enables the user-facing unit migration. Murch, David, and Ava reviewed this PR, with Ava merging it. In October, he opened a proof-of-concept PR that adds optional sats/vB fee rate outputs to five RPCs.

Follow-ups to the removal of the legacy wallet continue. One example is #32523, a targeted cleanup PR authored by Ava which further simplifies the wallet codebase. Our entire team reviewed it. Similarly, #32977 by w0xlt offered additional legacy wallet-related cleanups. Ava reviewed and merged this PR. Other PRs that our team contributed to in this area include #33082, #33161, and #33186.

Networking

Currently, Bitcoin Core supports behavior that is under-specified in the Compact Block Relay BIP: a node which is not one of your “High Bandwidth” peers can send you an “unsolicited” CMPCTBLOCK. Besides being unexpected, it’s possible for a malicious peer to leverage this behavior to fingerprint mempools. David opened up a PR to disallow this behavior and has been actively engaging with reviewers on the subject.

David’s work on Compact Block prefills continues. He further elaborated on his prefill strategy in the ongoing Delving Bitcoin thread and has made headway on the implementation. He continues to collect data from nodes running this branch and is working toward opening a pull request to Bitcoin Core.

Relatedly, our office spent quite a bit of time discussing compact block reconstruction rates and various selfish mining strategies. One afternoon, we theorized about what transactions were most often being requested during reconstructions. Pol wrote a small patch to Bitcoin Core to track these requests and shared the results on Delving. 

In August, ajtowns opened a PR that addressed a performance regression in the reconstruction of compact blocks. This is especially important because any inefficiencies in reconstruction cause blocks to propagate slower across the network. David, Pol, and Ava provided review to this PR. 

In response to diverging mempool policy rules around standardness, ajtowns opened a PR to relax checks around consensus and standardness validity in relay, simplifying this code path and reducing the risk of significantly divergent mempools across the network. Ava reviewed and merged this PR. 

For each peer, Bitcoin Core maintains an “inventory queue.” This queue limits the number of transaction announcements that a node will accept from a given peer. When the limit is hit, INV messages are dropped. The primary bounding metric is the block size; beyond maintaining a small buffer, Bitcoin Core does not allow more transactions per second to be announced to your node by a peer than can possibly fit in a block. However, when transaction sizes decrease, the network can handle more than the current limit (7 tx/s). Ajtowns’s PR to increase tx relay rate by a factor of 2 was reviewed by Ava. 

For some time, Bitcoin Core has worked towards support for privacy-enhanced transaction broadcast. In February of 2024, vasild opened a PR that changes the behavior of the sendrawtransaction RPC to broadcast locally submitted transactions over short-lived Tor or I2P connections, making it more difficult for chain analytics firms to associate transactions with specific nodes. w0xlt reviewed this PR. 

Ava additionally reviewed and merged #32180 from mzumsande which fixes a bug where, during Initial Block Download, the node’s internal tracking of which blocks it shares with a peer could become stale after connecting many blocks at once, causing it to wastefully re-scan already-downloaded blocks and falsely flag peers as stalling. The fix updates this tracking earlier in the download process so the request window is calculated correctly and peers aren’t unnecessarily disconnected.

Consensus / Validation

The latter half of 2025 proved to be an exciting time to be working on the kernel. PR #30595 is the foundational PR for the entire libbitcoinkernel public API. Merged in November, it introduced the initial C header that external applications can utilize to call into Bitcoin Core’s validation logic. A project Pol and w0xlt worked on (described below) consumed this API which led to them providing useful feedback about additional endpoints that the API could support. 

Based on his experience with the kernel, w0xlt authored #33796 which introduces context-free consensus checks on a transaction structure. Similarly, w0xlt’s #33908 enables context-free validation of a block’s structure. Both of these PRs are still actively being reviewed and iterated on. 

stickies-v authored a PR that, by modifying underlying ownership semantics, exposes block data to external consumers with low overhead. Ava and w0xlt reviewed this PR, with Ava merging it. 

The team also reviewed PRs related to IBD, chainstate reindexing, and dbcache. 

Notably, Ava reviewed+merged andrewtoth’s #32414 and l0rinc’s #33602, the first of which fixed a gap where periodic saves of cache progress to disk were not actually happening during a reindex-chainstate, meaning a crash mid-reindex could cause progress to be lost; the latter eliminated redundant work on a code path that runs billions of times during sync. Additionally, Ava and w0xlt reviewed a PR that introduces a startup warning to those who configure a dbcache size larger than their available memory. 

Miscellaneous

w0xlt has been an active contributor to the secp256k1 repository, participating in review of the Silent Payments module as well as some smaller PRs, one of which he inspired.

Late last year, Ava made two important changes to her dnseedrs project. In September, she introduced support for BIP 324, enabling the crawler to complete a v2 handshake with peers advertising NODE_P2P_V2. In December, she added optional support for ASMap. When enabled, the seeder uses ASN-based diversity when selecting addresses to return to clients. 

Over the last six months, David and Justin have been working together to design and build an IBD benchmarking platform. Together, they have curated a collection of hardware that will be orchestrated by a CI-like tool. With one-click, a proposed change to the Bitcoin Core codebase will be deployed to a cluster of on-premise devices representing every major CPU architecture. David has forked benchkit to support this use-case. Stay tuned for a detailed blog post on this project. 

Throughout the latter half of 2025, Justin and jeezman designed and built a PR tracking tool for individual contributors. With no authentication to a GitHub account required, the tool leverages GitHub’s public search API and a set of simple heuristics to automatically populate a Trello board with a target user’s authored and reviewed pull requests, triaged into priority-driven lists. This tool offers an alternative mechanism by which contributors can track their work, as opposed to relying on GitHub notifications and other ephemeral signals that are often missed in the noise of a busy repository. This tool is currently in private beta.

Mining

MEVPool

While in-office, Pol primarily focused his attention on MEVPool. 

Under the guidance of Justin and Matt, Pol (with extensive help from w0xlt) tasked himself with building a proof-of-concept version of the MACT (marketplace-aware custom templater) block builder. Described in the MEVPool paper, the MACT constructs a block from two sources: the miner’s public mempool in combination with transactions encrypted in the miner’s enclave-protected private mempool.

This architecture poses some unique challenges. Amassing enough context to start working on this project required significant ramp-up, as Pol had to familiarize himself with MEVPool, the complexities of block building, and the engineering constraints in-built to various enclave architectures.

After some experimentation and discussion with members of the kernel team, Pol and w0xlt settled on working with Intel TDX, as SGX puts expansive constraints on what device-level resources an enclave app can access. These restrictions are incompatible with the current capabilities of the kernel. 

Ultimately, Pol and w0xlt shipped their proof of concept MACT. Along the way, they were able to contribute upstream to Bitcoin Core’s kernel project. The proof of concept has many limitations, but it remains a solid foundation on which further research can be done. Pol intends to author a formal paper on MEVPool and continue pushing this work forward alongside Justin, Matt, and w0xlt.

FIBRE

w0xlt and Justin made progress towards the release of FIBRE throughout the second half of 2025. w0xlt completed a rebase against v30 and added various metrics and USDT tracepoints to the project. Justin prepared the FAQ for the FIBRE website. The project is now live. Further detail will be available in future transparency reports, as well as in our release blog post.

Conclusion

To everyone who funds, follows, or simply pays attention to the work happening at Localhost Research, thank you. Please leave us some feedback if you enjoyed the report or want to learn more about our work. We’d love to hear from you.