While we have given you some insight into what our team has been up to as of late, this is our first Transparency Report. As a non-profit dedicated to contributing to the Bitcoin FOSS ecosystem, transparency is fundamental to our mission. We want the world to be able to easily track and learn from our work. We also hope to build a replicable model for other organizations that want to follow in our footsteps. For that reason, we have a transparency page where important organizational documents will be posted in the coming months. Eventually, we’ll even share our Form 1023. We’ve also promised to share a more detailed vision of our organization’s mission with the community. Stay tuned for more on that front.
In these Transparency Reports, you will find a detailed record of the work our organization has undertaken. We’ll dive into specific pull requests, research, educational efforts, events and other exciting initiatives from members of our team. Because we want these reports to be useful to the community, they won’t be exhaustive; instead of detailing every single thing we’ve done, we will highlight specific items of note. These items should bring inspiration. If you find something that intrigues you, we encourage you to dig deeper and learn more on your own.
This report covers February 15th 2025 through May 1st 2025.
Events and Education
Localhost has been involved in a number of events in the last two and a half months. In mid February, Justin, Murch, David, and Ava attended CoreDev in Jamaica. CoreDev is a twice-yearly event where active contributors to Bitcoin Core get together to discuss, write, and review code/proposals/research relevant to the codebase. This was the first CoreDev that the Localhost team had a hand in helping organize. For the upcoming CoreDev, Justin and Patricia will be playing a much larger role in its organization alongside Brink.
During CoreDev, Localhost participated in a variety of ways, including leading and transcribing sessions and contributing to many of the conversations happening amongst the group. The event follows the Chatham House Rule, so we can’t speak to any specific conversations, however unattributed transcripts of much of the content are available.
In early March, Patricia organized a small fundraiser, hoping to draw out potential donors from the local Silicon Valley community. The event went very well, and we are excited to announce some of the funding commitments we have received in the coming months. Justin and Patricia also organized a small Friends and Family event last week, which was a perfect way to get connected with folks in our local community that are close to us and our organization.
Alongside the Presidio Bitcoin team, Patricia helped organize a screening of MY TRUST IN YOU IS BROKEN, a documentary about BTCPayServer. The event had an amazing turnout and everyone enjoyed themselves.
The Localhost team is also dedicated to the local technical meetup community. Justin and Murch both have years of experience moderating BitDevs Socratic Seminars, events designed to foster information sharing and lively discussion around technical topics relevant to the Bitcoin community. Justin is a regular moderator of SF LitDevs and BitDevs, and Murch guest co-hosted the most recent BitDevs at its new home at Presidio Bitcoin. Justin co-hosted the last LitDevs event and will be picking back up his regular moderation of both events come June. Justin also helps maintain the BitDevs.org archival newsletter alongside the Matthew Zipkin, which catalogues technical developments in the space. The most recent newsletter has over 100 items.
We’re involved in a number of other educational initiatives as well. David and Murch each led Bitcoin Core PR Review clubs in April, helping new contributors learn about the Bitcoin Core codebase and review process. Murch led the club on his BnB test refactor PR and David led the club on a benchmarking PR that he reviewed.
Murch is a permanent host of the Bitcoin Optech podcast and has participated in 9 since mid-February, covering a wide spectrum of interesting subject matter with his co-hosts and guests. He has also continued answering lots of questions on Bitcoin Stack Exchange, with a particularly thorough answer on Pay to Anchor and Ephemeral Dust.
Every Monday for three hours, Ava livestreams her work on Bitcoin Core. Her most recent livestreams covered a variety of topics, including much of the content covered below.
Over the last few months, David, a graduate of the Bitcoin BOSS Program, helped mentor a number of the participants from the most recent cohort who are interested in Bitcoin Core. He attended weekly calls, answered questions in group chats, suggested PRs for review, and engaged directly with individuals to give encouragement, advice, and direction.
Bitcoin Improvement Proposals (BIPs)
Recently, the BIPs repository has undergone a number of changes. In the last few years, the repository languished. To revitalize the project, additional BIP editors were given oversight of the repository with the specific mission of ensuring editorial standards are followed and new proposals are processed for inclusion in a reasonable time frame.
Murch was appointed as one of these BIP editors, and to-date, has been an active contributor to the project. Besides his day-to-day duties as an editor reviewing proposals, Murch has undertaken the task of modernizing the workflow for BIPs. In the years since BIP 2 was made Active, some aspects of the prescribed process remain unadopted. In response to this, Murch authored BIP 3 with the specific intent of replacing the current process, BIP 2, and addressing its shortcomings.
Writing and collecting peer review, then incorporating that feedback has been a significant effort. In March, the status of BIP 3 was updated from Draft to Proposed. Once BIP 3 is formally adopted, its status will change to Active as BIP 2 moves to Replaced, and then BIP 3 will be updated to Deployed, and BIP 2 will change to Closed.
Murch also has reviewed a number of BIPs in the last few months, including BIP 321 and others described later in this blog post.
Bitcoin Core
Releases and Build Process
In mid April, Bitcoin Core v29.0 was made available to the public. Preparing these releases is a significant undertaking by contributors. As a project maintainer, Ava takes on a large part of this multi-week long process that requires coordination from many contributors and multiple rounds of feedback from testers during the release candidate cycle.
Part of the release process is to actually sign the binaries that are made available to the public. For MacOS app bundles, Apple requires an additional notarization step before the binary can be run on user’s machines. Ava authored a PR that updated a script to automatically codesign all macOS and Windows binaries and notarize the macOS application bundle. Previously, macOS application bundles were not notarized; users running Bitcoin Core on macOS were required to bypass system warnings about the trustworthiness of the application. This PR embeds codesigning and notarization directly into reproducible Guix builds, removing that additional friction for users. Review was provided by many contributors, including David.
Across the entirety of the v29.0 release (from August 2024 until today), our team reviewed over 300 PRs, and cumulatively authored 33 PRs with nearly 200 discrete commits.
Consensus
There are an increasing number of soft fork proposals being debated and discussed by the community. In his role as BIP editor, Murch has reviewed a number of these upcoming proposals:
- BIP 54: Great Consensus Cleanup (GCC)
- BIP 53: Disallow 64-byte transactions, a subset of GCC
- OP_CHECKCONTRACTVERIFY
While none of these or other actively in-research proposals are currently attempting activation, it’s important that the Bitcoin Core codebase is sufficiently prepared to handle them in the event the community decides to include activation parameters in an upcoming release. BIP9, versionbits, is one mechanism by which soft forks can be deployed. In 2023, Anthony Towns refactored the versionbits code, increasing its modularity and improving its unit and fuzz tests. This PR has gotten increasing attention in the last month. Ava reviewed, ACK’d and merged it with some useful context.
Within Bitcoin Core there is the libbitcoinkernel project which seeks to encapsulate consensus logic from other parts of the codebase. w0xlt recently reviewed a PR that separates UTXO set access from validation functions, paving the way for features such as Utreexo and SwiftSync.
Benchmarking and Optimizations
Multiple members of our team have taken a particular interest in SwifSync, an exciting new proposal by Ruben Somsen to significantly speed up IBD (Initial Block Download). David has begun to study theStack’s SwiftSync branch and review hodlinator’s header sync caching branch. w0xlt implemented the createhintfile RPC, that can generate the hints required by SwiftSync clients to quickly and efficiently reconstruct the UTXO set.
If you’d like to learn more about SwiftSync, we highly encourage you to listen to Optech Recap Podcast 349, where Murch spoke to Ruben Somsen and theStack about the proposal.
David is an active contributor to the benchkit project (which is actively being transitioned from benchcoin), a toolkit designed for benchmarking Bitcoin Core. Tools like this are important because they provide contributors with a comprehensive, reproducible framework for measuring and analyzing performance changes across the project. Recently, David has worked on a branch that adds tracepoint support.
PR 30611, authored by Andrew Toth, was reviewed by both David and Ava. This PR is noteworthy because it improves node reliability by reducing the risk of data loss in the event of a crash during IBD. It does this without significantly impacting performance. This has been a pain point for some users, as restarting IBD after a failure is extremely inconvenient and risks discouraging users from running a full node. For nodes with large dbcaches, this PR also limits IO spikes caused by cache clearing (which can result in the user’s device becoming momentarily unresponsive), as well as significantly improving shutdown speeds.
Wallet
Within Bitcoin Core, we have spent significant time pushing forward the wallet. One of the big priorities within the wallet is the legacy wallet removal. This is a massive undertaking that will allow Bitcoin Core to shed thousands of lines of code and pave the way for improving the wallet codebase in a variety of ways. Wallets created today are based on Descriptors, which are much more flexible and do not depend on Berkley DB, a dependency Bitcoin Core has sought to remove for years.
However, the legacy wallet cannot be removed without a sufficiently robust and well-tested migration tool. Anyone who has a legacy wallet should be able to migrate their wallet seamlessly no matter how old their wallet might be. Our team authored, reviewed and/or tested a number of PRs related to the migration tool, including 32273, 29124, 32281, 32149, 31961, and 32149. The ability to create and load legacy wallets has also been disabled in a PR authored by Ava and reviewed by David. Reviewing the PR that actually removes the legacy wallet has also been a recent focus of ours.
Beyond the legacy wallet removal, being able to receive and spend inputs involving MuSig2 keys is an important feature for a number of different protocols that use the Bitcoin Core wallet for signing operations. Two PRs authored by Ava, one that implements PSBT MuSig2 fields and another which is necessary for MuSig2 descriptors, were recently merged, pushing the project closer to the goal of full MuSig2 support.
Bitcoin Core’s coin selection logic is an area that Murch has historically spent significant time improving. His latest efforts involve a rewrite of the Branch and Bound Coin Selection algorithm. This new approach is designed to enumerate more possible combinations within the same iteration limit. It achieves this by tracking state in a lookahead structure rather than retracing every backtrack step and avoiding re-tests of sets of UTXOs with matching effective value and weight.
This work depends on a refactor of the BnB tests, which create a more realistic framework for testing coin selection by applying an effective value to a coin (the coin’s value minus its cost to be spent) as opposed to assuming the cost of creating change and feerate are 0. Murch spent some time addressing feedback in this PR over the last two months and it is nearly ready to be merged. Both w0xlt and Ava have left feedback on this PR.
Miscellaneous
In the networking stack of Bitcoin Core, David found an issue related to transport handling when disconnecting a v2 peer after disabling your node’s network access that was fixed in 32073.
Murch chimed in on the testnet4 blockstorm debate, agreeing with many others that the difficulty reset behavior should be removed to bring testnet4 into a more usable state.
w0xlt has been responding to activity in his rust-secp25k1 Musig2 module PR, recently updating it to support “dangerous bytes” functions for secret nonces, a feature requested by members of the Ark team.
Existential Risks
Studying existential risks to the Bitcoin network is of particular interest to some of us. Risks of this nature take many forms. One such form is the increasing exposure that Bitcoin has to private mempools, out-of-band fee payments and MEVil. When combined, these risk factors can create focal points for mining centralization. There is precedent for this concern when observing the effects that private mempools and MEVil have had on censorship in the Ethereum network.
In light of the growing demand for private mempools and the excitement around new soft fork proposals that can potentially produce vectors of MEVil in Bitcoin, Justin and board member Matt Corallo published MEVpool: A Private Mempool Marketplace Standard, a paper which attempts to mitigate some of these risks. Matt and Justin are both excited and hopeful that the network will consider new soft fork proposals, with the caveat that the community understands and works to manage some of the risk born from additional expressivity in Bitcoin script. This proposal is also salient in light of the debate around relaxing limits on OP_RETURN, as restricting these limits encourages users to submit their transactions to “transaction accelerators” and other privately hosted mempool services (e.g. Slipstream).
Conclusion
And that concludes our first Transparency Report! We hope it was insightful. If you have any questions about this report, don’t hesitate to reach out on X.