Transparency Report 002

  • Post date August 27, 2025
Transparency Report 002

This is our second Transparency Report. These reports offer us an opportunity to detail some of the activity our organization has engaged in over the last three months. 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 May 1st 2025 through July 31st 2025. It is non-exhaustive.

Events and Education

The last few months have been quite the whirlwind. In mid-May, in an unexpected turn of events, the focus of a large contingent of the Bitcoin ecosystem was turned to the topic of mempool relay policy. This was in response to some activity on the bitcoin-dev mailing list and the Bitcoin Core GitHub repository.

Although this area of the Bitcoin Core codebase is not generally a primary focus area of our organization, the community’s response to the activity was not something that could be ignored. From our perspective, there was a large amount of confusion and misinformation about the underlying topic that ultimately manifested in a contentious and unfriendly atmosphere.

In good faith, members of our team spent dozens of hours on forums, streams, podcasts, and in other mediums discussing the topic. Of note:

  • Ava hosted a four hour Twitch Stream, exhaustively detailing the history of OP_RETURN in the Bitcoin Core codebase.
  • Murch and Michael Tidwell hosted a OP_RETURN Q&A on Stacker News.
  • On the OPTECH Recap Podcast, Murch led a 55 minute discussion on the topic with Sjors Provoost.

To round off the conversation, the entirety of our Bitcoin Core Unit signed the Bitcoin Core development and transaction relay policy. While we ultimately understand that some fundamentally disagree with this position, we hope the community can move forward and refocus on other research areas that push our ecosystem forward.

In late May, BTC Media hosted Bitcoin 2025 in Las Vegas, a popular conference series. Within the conference, there was an Open Source Stage and Developer Zone that hosted engineering-focused content. During the conference, Murch participated in four events: three panel discussions and a BitDevs Socratic Seminar.

  • Discussing The Blocksize: Have We Found Equilibrium? - Brandon Black and Murch, lacking microphones, engaged in a standing debate shouting their arguments at each other in front of a closely huddled audience about past proposals for blocksize increases as well as the possibility of a future blocksize increase or dynamic blocksize. Although, they didn’t disagree much, their thorough exploration of the topic, steel-manning perspectives opposite of their own and the quirky situation let time pass quickly.
  • What Does Bitcoin Core Actually Do? – Mike Schmidt, Antoine Poinsot, and Murch took questions from Stephan Livera about Bitcoin Core’s recent updates, processes, and priorities. Among other topics, the panel weighed in on the OP_RETURN debate.
  • Bitcoin Node: Utreexo vs SPV Node - Murch and Tadge Dryja explained the mechanisms and trade-offs of various lightclient models.
  • BitDevs Socratic Seminar - This was an unrecorded event that was carried out under the Chatham House Rule. Murch, alongside Stephen Delorme and board member Matt Corallo conducted a BitDevs-style Socratic Seminar.

In June and July, Justin, alongside his co-moderators, led BitDevs and LitDevs events at Presidio Bitcoin and Digital Garage.

Presidio Bitcoin hosted a summit in July focused on the intersection of Bitcoin and Quantum Computing. It was an engaging multi-disciplinary event with a diverse crowd. The entire Localhost team attended and participated in many of the conversations, with Justin and Murch leading breakout sessions during the first day.

On Bitcoin Stack Exchange, Murch left clarifying answers on ephemeral dust, mutual satisfaction clauses and how to compute the total number of bytes in a taproot leaf.

Beyond this, Murch participated in 13 Optech Recap Podcasts and reviewed 14 German Optech Newsletter translations that were produced by some new contributors he recruited. He was also interviewed on the German Blocktrainer Bitcoin Podcast!

Ava also conducted her weekly stream on a variety of topics, and led the weekly bitcoin-core-dev meeting.

Bitcoin Improvement Proposals (BIP)

In our last transparency report, we covered Murch’s newfound role as BIP editor and author of BIP 3, a workflow designed to modernize the BIPs process. In June, Murch addressed the outstanding review on his BIP 3 proposal. With consensus forming around BIP 3, it may be soon time for the community to formally adopt BIP 3 while sunsetting BIP 2.

Beyond BIP 3, Murch reviewed and in some cases merged PRs related to the following BIPs:

He also processed the withdrawal of BIP345: OP_VAULT and worked with nothingmuch and jonatack on an updated CI script for the BIPs repository.

Ava also engaged in some BIPs related activity, making some tweaks to BIP380: Output Script Descriptors General Operation and BIP390: musig() Descriptor Key Expression.

Bitcoin Core

Releases and Build Process

In June, Bitcoin Core v28.2 was released. Ava participated in its production. Notably, this is the second Bitcoin Core release to use Ava’s new script that automatically codesigns all macOS and Windows binaries and notarizes the macOS application bundle that was discussed in the last Transparency Report.

Wallet

Over the last 5 years, Ava has spearheaded Bitcoin Core’s continued effort towards the complete and total removal of the legacy wallet and the BerkleyDB (BDB) dependency. Its removal marks an important point in the history of Bitcoin Core’s wallet architecture–it enables contributors to focus their efforts on adding new features and improving the existing codebase without the heavy burdens of dealing with legacy code that reaches as far back as the original satoshi codebase. One such example is David’s PR 32636, a refactoring PR that was greatly simplified by the removal of the legacy wallet.

In our last report, we touched on the wallet migration tool and a number of PRs related to it. Continuing in that effort, David worked with Ava on a PR that enabled wallets stored outside of the default wallet directory to successfully migrate in a specific edge case. That and other migration tool PRs were merged, enabling the project to focus on PRs related to the actual removal of the legacy wallet and BDB. The primary removal PR has been successfully merged, along with a large set of follow-ups 32511, 32459, 32619, 32620, 32523, 32618, 31423, 32758, 32944, 32984, 32977, 32481, 32985, 32620, and GUI 877), many of which were authored, reviewed, and merged by members of our team. We are extremely excited to see Bitcoin Core reach this milestone and want to specifically thank Ava for all of her hard work, as well as all of the contributors that reviewed and authored the many PRs which made legacy wallet removal possible.

Looking forward, Ava has an open PR that strengthens wallet forward-compatibility: it enables parallel rollout of new features and adds safeguards to detect when a single wallet file is carried across client versions out of order. Together, these changes reduce upgrade friction and help prevent subtle inconsistencies when users move wallets between releases. One example of a feature that would benefit from this PR is Ava’s effort to store transactions in a separate SQLite table, as opposed to using SQLite as a key-value store as it does today. This project is not a small undertaking, the underlying schema of which was partially inspired by discussions we had at the office and some early proposals by w0xlt. Ava has hosted a number of streams while working on this feature.

One big value-add of this table is that it makes reasoning about changes to the wallet simpler. Recently, our entire team worked closely together to help Ava push a PR that helps keep track of the wallet’s own transaction outputs in memory over the line, which has a follow-up PR that would see specific benefit from the table.

When combined, #27286 and #27865 improve the performance of certain operations in large wallets (i.e. wallets with lots of spent transactions) by over 1000%. This is a huge boon to any business, infrastructure provider, and/or power user who relies on the Bitcoin Core wallet in high velocity environments. David has some great notes on #27286 that are worth reviewing for those who want to dig deeper on this topic.

Beyond performance, Ava has been working towards full support for MuSig2 in Bitcoin Core. Recently, two PRs she authored that implement critical functions for MuSig2 were merged. w0xlt reviewed the latter of these two. Now that these and other supporting PRs have been merged, Ava’s primary MuSig2 PR is ready for review.

As a team, we’ve also been thinking about air-gap support in Bitcoin Core. As a wallet that attracts power users, this is a highly desirable feature. And from our perspective, this is low hanging fruit – all of the underlying primitives required to make it work more robustly already exist within the codebase. They just need to be surfaced in a way that enables users to orchestrate signing activity in an offline environment in a more direct fashion.

In such an environment, you need two devices: one which is online and can generate unsigned transactions, and second device which can sign these transactions while completely offline. Bitcoin Core supports PSBTs, descriptors, signing operations, and watch-only wallets. It is only missing support for an RPC that enables users to export a watchonly version of a wallet in one fell swoop. Ava authored this PR as well as three others that were required for its inclusion, alongside an update to the GUI. Our team will be focusing some of their review effort on the export functionality in the coming days. There was also a review club on the PR as well, hosted by ryanofsky.

Murch continues to work towards his rewrite of the Branch and Bound Coin Selection algorithm. His refactor of the BnB tests was recently merged and he opened two test-related PRs, one which adds a new fuzz test against BnB and another which “slays” BnB mutants. Both Ava and w0xlt reviewed the mutant PR.

At Localhost we also encourage our team to experiment and push boundaries. In the last three months, w0xlt has published a few proof of concepts in the wallet, one of which included support for BIP 353: DNS Payment Instructions. This BIP introduces a mechanism by which users can generate human-readable names for payment instructions that are stored in DNS TXT records. They are a powerful tool that improve the UX of sharing payment details.

w0xlt’s PR led to some interesting discussion and avenues of research, with much of the conversation turning to two questions: what is the safest way to introduce the required cryptographic primitives and how is the functionality made available in releases. For now, the PR will be shelved until which time receive-side Silent Payments has been merged, as to prevent encouraging address reuse.

He has also been exploring PayJoin support and opened a PR that implements a secp256k-1 based HPKE (Hybrid Public Key Encryption) scheme that provides the core cryptographic componentry required of the PayJoin v2 protocol.

Other interesting PRs authored by the team that have seen recent activity include:

Networking

In August of 2024, 0xB10c shared compact block reconstruction stats on Delving Bitcoin. His data showed a concerning trend: that compact block reconstruction rates had fallen significantly and were effecting block propagation times. This poses the risk of increasing block races across the network, a phenomena that disproportionately hurts small miners.

One idea intended to improve reconstruction rates includes expanding the set of prefilled transactions beyond just the coinbase. This scheme has been around since the first publication of BIP-0152, however it was never implemented. The idea is as follows: if a node is missing a set of transactions when it learns of a block, it can predictively include those transactions in the compact block announcement it makes to its peers. By doing this, it avoids an additional network round trip from the receiving peer if/when it determines it does not have those transactions and must request them. These round trips are costly (in time) and should be avoided whenever possible.

David was inspired by this discussion and decided to test the prefilling concept on mainnet. He connected two patched Bitcoin Core nodes and measured the outcome. He took close measurements and carefully observed the behavior between these two nodes. The data he collected was quite promising, showing a significant improvement in reconstruction rates. He also came away with a number of potential improvements to the prefilling scheme as well as some areas for future research. He also opened a PR in Bitcoin Core that added additional logging to help measure the performance of compact block reconstruction.

Consensus

In areas of the codebase related to consensus, Ava reviewed one PR by mzumsande that improves internal handling of invalid blocks, and reviewed+merged a PR by darosior that is a prerequisite for the Great Consensus Cleanup.

David and w0xlt have also shown an interest in libbitcoinkernel, a project intended to encapsulate and make available Bitcoin Core’s consensus engine as a library. They lightly participated in discussions/review in 32427, 31382, and 32317. 32317 is particularly interesting to our team as it lays the groundwork for exposing UTXO validation to kernel users, functionality we intend to use in a future project.

Policy

With the recent rollout of TRUC, package relay, and related schemes, mempool policy PRs have captured attention from our team. Ava, David and w0xlt reviewed instagibb’s PR which introduced a functional test to correctly detect non-standard TRUC transaction sizes. Ava and w0xlt reviewed glozow’s PR that improved the performance of a 1P1C DoS test.

Ava also reviewed and merged a policy-related PR that is intended to prevent trivial DoS against unupgraded miners during the activation of the Great Consensus Cleanup.

Given the intense community debate, our team also spent time on the policy PRs addressing OP_RETURN limits and minrelay.

Benchmarking and Optimizations

Following up from our last report, Ava reviewed and merged andrewtoths’s work on node reliability, as well as two PR’s from l0rinc that improve Initial Block Download (IBD) speeds, one that stores P2WSH/P2TR/P2PK scripts inline in prevectors, and another which batches block obfuscations in a more performant and cache efficient fashion. Both of these PRs are part of l0rinc’s wider project focused on improving the speed of IBD.

David benchmarked sipa’s replace cluster linearization algorithm with SFL PR and benchmarked+lightly reviewed Crypt-iQ’s PR that attempts to mitigate disk filling attacks.

Miscellaneous

Outside of the work above, Ava reviewed and merged work related to the process separation project. This particular PR provides a wrapper executable that acts as the entry point used to run Bitcoin Core components in a multiprocess setup, integrates the libmultiprocess subtree, updates the CMake build to support it, and refreshes documentation to explain the subtree and its usage.

David and Ava also reviewed (and merged) a PR by furszy that prepares the codebase for two exciting features: running indexes in a separate process and parallelizing the block filter indexes’ initial synchronization. Similarly they reviewed (and Ava merged) a process-separation related PR by Sjors which adds getblocktemplate and generateblock equivalent functionality to the IPC mining interface. David has some notes on this PR as well. In a PR by theuni, David and Ava reviewed work related to the cleanup/modernization of Core’s threading primitives, by tightening the rules around what can touch shared data at the same time, replacing fragile manual lock/unlock steps with safer automatic guards, and laying the groundwork for newer shared locks so more code can read in parallel without stepping on each other.

Finally, Ava did some light maintenance work on her DNS seed and introduced testnet4 support to her dnseedrs project.

Cryptography

In July of last year, w0xlt (under a different pseudonym) opened a PR in rust-secp256k1 that introduced MuSig2 support. After maintaining the PR for almost a year, it was merged! He also reviewed apoelstra’s follow-up PR that added an API for the underlying functionality.

Mining

As Localhost matures, our team remains on the lookout for opportunities to participate in the network in meaningful ways–especially as it relates to Bitcoin mining, an area in which we see concerning trends of centralization. Even though we are not miners, pool operators, or otherwise active participants in the business of Bitcoin mining, we believe there are a number of ways in which we can help reduce these pressures.

While we are still in the process of formulating our long-term approach to contributing to the mining ecosystem, we have recently taken on a project that we believe to be a good first step. We plan to publish a more thorough blog post dedicated to this effort once it is deployed; in the mean time we would like to catalogue some of the work in this Transparency Report.

Many years ago, board member Matt Corallo operated the Bitcoin Relay Network, a project which later evolved into the FIBRE Network. The FIBRE network was crafted to propagate blocks amongst participating nodes at nearly the speed of light, by utilizing UDP, Forward Error Correction, a modified version of Compact Blocks and a carefully selected set of datacenter locations.

The primary goal was to reduce the number of block races and ensure that asymmetries in block propagation do not have disproportionate effects on small Bitcoin miners. In the face of a increasingly fractured mempool and falling compact block reconstruction rates, we believe this mission to be more important than ever.

Matt eventually took the network offline and stopped maintaining the patchset against Bitcoin Core. Recently, with the guidance of Matt, Justin and w0xlt took on the task of rebooting the FIBRE network. After a significant effort, w0xlt successfully rebased the FIBRE patchset against Bitcoin Core master and Justin found a new set of datacenter providers to host the network. We are actively testing the performance of the rebase against modern network conditions before bringing it online. Stay tuned for more detail as we bring the network online. If you are a miner and would like to connect, please reach out.

Conclusion

Our work is far from finished and we hope you’ll continue to join us for the ride. We appreciate the time our community takes to read our transparency reports. In that spirit, Localhost is commited to publishing more research updates throughout 2025 and beyond. Feedback is always welcomed.

If you have any questions about this report, don’t hesitate to reach out on X.