There are five or six books that every serious cypherpunk ends up reading. A Lodging of Wayfaring Men is one of them. For two decades it lived as a quiet inheritance, copied as a PDF between people who built Tor relays, ran early e-gold accounts, traded on Liberty Reserve, wrote the Bitcoin patches that mattered, and shipped the privacy tools we use today. A new illustrated hardcover edition has been edited and republished. The timing is good, because the world the book describes is the world we are now living in.

Paul Rosenberg wrote the manuscript in the late 1990s while running the arbitration system at a project called Laissez Faire City. The project shipped a working encrypted financial system in 2001, complete with anonymous bearer certificates, a stock exchange, a futures market, encrypted webmail, and a distributed forum, all seven years before the Bitcoin white paper. Rosenberg sat across the table from the project’s principals, audited the books when one of them went bad, couriered gold coins on settled disputes, and oversaw the investigation that closed the project out. As the man who maintained the donor list of every founder who put money in, he kept it as long as the work required and burned it once the work was done.

He wrote the novel to tell the story without naming the people. The fiction was a courtesy to the donors, who needed to stay out of court. The story is theirs, lightly disguised. For the first decade it circulated by email and on private mailing lists, photocopied, forwarded, passed quietly from one builder to the next. People who held copies treated them like contraband, because in spirit they were. Every serious cypherpunk who read it walked away understanding two things at once: that the cypherpunks had already done it before Bitcoin existed, and that the work had only just begun.

What the novel does is make the cypherpunk argument as a story. Before the white paper, before Tor was a usable network, before Lightning, before Nostr, Rosenberg wrote a small group of mathematicians, ex-ministers, financiers, and Silicon Valley programmers into a story about shipping fully encrypted electronic cash from a series of safe houses across three continents. The NSA briefer in the book reads a January 1995 Treasury memo describing money the agency cannot read or trace, money whose addresses do not follow the standard protocols, money whose messages leave no record of origin or destination. The memo is fictional. Everything it describes is now operational in your pocket. Reading it in 2026 is a strange and pleasant kind of vertigo.

I should say where I am standing before going further. I met Paul years ago, and shortly afterward I sat down with the manuscript. The conversations and the reading were one continuous education. The book convinced me the work was possible and worth doing, and I went on to work on Wasabi. Years later, when the powers that be increased their pressure and attacks against us exponentially, zkSNACKs the company and its coordinator were pushed into closing. Rosenberg’s strategic logic landed in the real world exactly as he had written it. The state went after the company because the company was the named target it could reach. The wallet code had been FOSS from day one. New coordinators came online within days. FOSS is unstoppable, and Rosenberg saw the architecture twenty-five years before any of us shipped it. I am one of dozens of builders whose work is downstream of this book.

One of the book’s anchor scenes plays out like this. A coordinator named Michael Anderson counts three hundred sealed envelopes onto a table in front of a Marine survivalist friend. Each envelope contains the source code for the underground marketplace. Each carries instructions to mail it out if anything happens to him. “By distributing the code openly we make ourselves replaceable,” he says. “A thousand markets will spring up in a thousand different flavors.” This was written in the late 1990s. When zkSNACKs went down, the Wasabi code kept running and new coordinators kept the wallet alive because the architecture Paul Rosenberg describes is the architecture freedom tech has shipped ever since.

In a second scene, a Los Angeles defense attorney named Anthony Bari walks into a US Attorney’s office and forces a treason charge down to misdemeanor computer fraud by threatening to take the indictment paperwork to every newspaper that will read it. “You cannot have a public trial because everyone would learn your secret.” Around Bari orbits a veteran FBI field agent named Max Kaminski, who runs an establishment frequented by other agents and quietly feeds intelligence back through a young agent who finally defects. Max says it more than once, in different rooms, to different agents who are not yet ready to hear it. “Law enforcement is a cheap substitute for justice. Half-justice at best, and frequently much less.” Read it twice and notice the small word in the middle. Max says it is a *substitute*, the way margarine is a substitute for butter: a cheaper good produced by industrial process and sold to people who can no longer find or afford the original. Margarine is what you get when the original is taken off the shelf. Justice is what the cypherpunk defense bar is now putting back on it, one courtroom at a time.

Halfway through the book, the argument widens. The title of the book comes from Jeremiah 9: ”Oh that I had in the wilderness a lodging of wayfaring men, that I might leave my people and go from them.” A character quotes it in a Vancouver hotel lobby late in the book, and it lands as the structural key to everything that came before. A lodging is not a building. It is a portable, self-replicating refuge culture for people who want to live separately from a system that has no intention of leaving them alone. The back half of the novel dramatizes the lodging in three countries within two chapters, and once you see the pattern you cannot unsee it.

Bitcoin Twitter has the citadel meme, and Rosenberg has the lodging, and the two ideas point in opposite directions. Citadels are walled, defensive, finite, often paranoid, expressed in the language of survival under siege. Lodgings are hospitable, portable, self-replicating, and explicitly take in any nice person you know. A citadel ends with you and your stack and a perimeter. A lodging looks like physicists teaching geometry to children on an Italian beach, parents trading nights of childcare, Nobel laureates running ad-hoc seminars, landlords competing to keep the same off-season tenants the following year. Citadels are last fortresses before the end. Lodgings are first houses of the next civilization. Bitcoin culture has spent twenty years arguing about the technical layer and almost no time on the cultural layer, and Rosenberg’s late chapters are the cleanest available blueprint for the layer above the protocol.

The closest modern Free Souls houses are sovereignengineering.io and the Bitcoin++ conferences. Sovereign Engineering gathers freedom-tech builders into in-person residency cohorts to ship together. Bitcoin++ pulls protocol engineers into the same room to prototype and ship across a single shared agenda. The Italian beach in the novel, the SEC residency in the present, and a Bitcoin++ event are the same architecture under different names. Builders who would otherwise be working alone gather in physical proximity, sit at the same table, trade ideas across disciplines, eat together, build together, and walk away with friendships that hold under pressure. A lodging proves itself every time a small group of competent people gather to build something the surrounding system would prefer they did not. The lodging is already being built, and the novel gave it a name.

This hardcover edition includes the full Appendix, a body of essays attributed to the character Prester John. Appendix A is a wonderful history of religious thought, written with the directness of someone who has lived inside the material for forty years and decided to skip the academic throat-clearing. It treats the Hebrew prophets, the Gospels, the institutional priesthood, and the modern intelligentsia as a single continuous problem: human beings handing their judgment over to a class of people who claim the authority to think for them. Read on its own, Appendix A would be a respected short book. Embedded inside the novel, it is the philosophical scaffolding that makes the lodging make sense.

Whether Satoshi sat at one of those tables or read the same pages is the question Rosenberg has left open on purpose. Either he was at the table and lived the project, or he read the manuscript and ran with the lesson. Either answer is electric. Rosenberg himself has said that he would love to see whether his favorite Satoshi candidates were on the donor list, and then he reminded everyone that he burned the list on principle the day the work was done, smashing the hard drive that held it. So the names are gone, and the lineage is written into every Bitcoin block since genesis, and the only people who could close the loop are the ones with a stake in keeping it open. What we get instead is the thing the receipts hand us. The cypherpunks shipped the financial cryptography seven years before the white paper. The white paper inherited the strategic logic of the book, and the book is now sitting on the shelf where the rest of the inheritance is waiting. Read it for the technical retrospective.

Read it again for the lodging. Pair it with Rosenberg’s Untold Story of the Greatest Crypto Project Ever, which serves as the author’s quiet commentary track on his own fiction.

We are inside one of the great adventures of human history. Cryptographic primitives are sufficient, capital is in place, legal infrastructure is being built in real courtrooms by people who took Bari’s playbook seriously, and the lodgings are forming. Bitcoin is the money, Nostr is the social layer, FOSS is the strategic logic, and the lodging is the architecture we live inside while we build. What remains is for each of us to find our seat at the table, ship the next brick, and welcome the next nice person we know.

Rosenberg wrote the book to tell a story whose principals could not be named. Two decades later the principals’ work is on every laptop, in every wallet, in every courtroom where a privacy-tool defendant is finding out he has a defense bar. The donor list is gone. The donors are everywhere. Read the book, and then go find your seat at the table.

In this week update we feature the latest release of the Cashu Development Kit (CDK), which introduced a new BDK on-chain payment backend based on NUT-30.

We also cover the effort from the Marmot protocol team to draft a new set of specifications to improve the reliability of the system.

We finally present some interesting news from the Bitcoin ecosystem. Notably, Bark by Second available on mainnet, a new vulnerability found in Bitcoin Core, improvements on splicing, and a draft BIP for a new testnet.

Highlights from the bitcoin developer ecosystem

I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:

• v0.17.0 of CDK was released.

  • During the weekly call, on Wednesday 10th, CDK contributors announced that the latest version of the Cashu implementation was close to be published. The release was officially pushed some days later, on Saturday 13th.

  • The main highlight is the introduction of an on-chain backend for minting and melting ecash tokens. Based on NUT-30 specification, the new features leverages BDK under the hood to provide on-chain functionalities.

  • Other changes includes a deprecation notice for LNbits as a backend, improvements to improve recovery and reliability, and the possibility to have multiple mint backends for different currency units. The latest release is also available for Kotlin JVM, Go, Dart, and Swift though language bindings.

• Marmot v2, the new set of specification for the Marmot specifications, is currently being drafted.

  • During the monthly community call, on Tuesday 9th, Marmot maintainers announced that they were working on a second version of the protocol specifications with the aim of improving the reliability of the system. The new specifications are being drafted in the darkmatter specs repository, organized in modular surfaces with dedicated directories and clear ownership.

  • One of the most important focus of the new specifications is related to how the group reaches consensus on state change. As of today, each member of the group processes commits independently, which could result in potential forks of the group. Marmot v2 would provide hard-coded parameters to allow users to get to the same group state deterministically.

  • Another focus of the new specifications is to make the protocol transport-agnostic. While the original specifications put Nostr at the center, v2 aims to provide the possibility to use Marmot with many different transport layers, such as FIPS.

A BIPs Update

There was no newsworthy update in the last days in the BIP repository. We’ll provide new updates as soon as a new BIP gets published or gets assigned a number.

Other News from the Bitcoin World

• Bark is on mainnet: Second announced on Monday 9th that Bark, their Ark implementation, was finally available on mainnet. Second released the Ark server, the Bark SDK, and multiple wallets to try. In the following days, Bark announced that AlbyHub had integrated Bark as a possible backend option for their node, and that the Bark Wallet was available on Umbrel. Unfortunately, it also had to deal with two vulnerabilities found by Bitcoin developer Floppy, which were soon patched by Second’s team.

• Vulnerability in -privatebroadcast: The Bitcoin Core organization disclosed on Thursday 11th that a privacy bug had been found in the newly -privatebroadcast feature introduced in v31.0. The bug may cause the originator’s IP address to be revealed to a peer. A fix is expected soon in v31.1.

• Splicing out into a channel open: Dusty Daemon, the mind behind splicing, announced that he was able to make the first splice out into a channel open on regtest. In other words, he was able to remove funds from an already open channel, and put them in a brand-new one.

• Testnet5 is coming?: Pol Espinasa posted to the Bitcoin-Dev mailing list a draft BIP to replace testnet4 with a new testnet5, with the aim is to improve reliability of the testnet. Testnet5 would include the same consensus rules as mainnet, plus activation of BIP54 (great consensus cleanup).

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Nairobi this June 17- 19 to talk about working in public in open-source!

Merged PR’s

Every week, several changes are officially added to Bitcoin Core. This week, multiple changes were merged. Here are some I found interesting this week.

• rpc: make getprivatebroadcastinfo and abortprivatebroadcast fail if privatebroadcast is not enabled by polespinasa
  This change is conceptually pretty straightforward. There was a new feature added to Bitcoin Core v31.0 called private broadcast, in which two RPC calls were added for getprivatebroadcast and abortprivatebroadcast.
  
  Now it makes sense to have them enabled when we also have private broadcast enabled. The issue is that before this PR that was not the case. So, what Pol Espinasa made a condition was that if -privatebroadcast=0 then we would disable those RPC methods.

• p2p: Prevent integer overflow in LocalServiceInfo::nScore by codeabysss
  This change by codeabysss also their first change, which closes an issue from 2022.

  The overflow for signed arithmetic yields undefined behavior.
  This changes prevents undefined behavior in local address scoring by saturating nScore updates at INT_MAX in both SeenLocal() and AddLocal() update paths.

There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.

• refactor: Add util::Result failure types and ability to merge result values by ryanofsky

  Add `util::Result` support for returning more error information and make use of it in [LoadChainstate method](https://github.com/bitcoin/bitcoin/pull/25665/commits/d0d2535cac193a448395fbb1d32df072b2e491a3) as an initial application. Followup PRs [#25722](https://github.com/bitcoin/bitcoin/pull/25722) and [#29700](https://github.com/bitcoin/bitcoin/pull/29700) use it more broadly to return errors and warnings from wallet and kernel functions as well.

IRC meeting notes

Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.

stickies-v: #topic Kernel WG Update (sedited)
sedited: nothing to share this week

stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
sliv3r__: hi
andrewtoth: l0rinc opened #35465 to address the compaction.
andrewtoth: willcl-ark discovered a speed regression https://github.com/bitcoin/bitcoin/issues/35457. l0rinc is looking into ways to resolve that.
andrewtoth: Got some good review on #35295. We are also now continuously fuzzing leveldb along with concurrent reads, which is used for chainstate reads in that PR. More review welcome.
andrewtoth: that’s it

stickies-v: #topic Fuzzing WG Update (dergoegge)
dergoegge: no update
stickies-v: I don’t see any other WG leaders here, so that concludes the WG section unless anyone pops in last-minute
stickies-v: Anything else to discuss?
andrewtoth: Can we consider merging https://github.com/bitcoin-core/bitcoincore.org/pull/1255 and making a mailing list post?
sedited: not sure if that makes sense without a release.
andrewtoth: Do we want to let users know about workarounds before a release?
stickies-v: alerting earlier seems useful to me too, especially since the vulnerability is public already anyway
sliv3r__: I think it makes sense anouncing before a release
andrewtoth: I don’t think that blog post would make sense as is with a release, since the best workaround would be to upgrade
sliv3r__: agree, didn’t read in detail the post but it basically gives workarounds until a fix is released, makes sense to publish it as soon as it is ready
stickies-v: i think it would be useful if more contributors at least concept ack’d blog posts, not that this one seems controversial
sedited: ok
eugenesiegel: should this not have been public? afaict the security mailing list isn’t for privacy issues. anybody have an idea on the preferred way to handle this?
andrewtoth: all things considered it would be better IMO if this were not yet public
andrewtoth: but, not sure how we would have made a fix without revealing it
instagibbs: there are ways of doign so, but horse is out of the barn long ago
andrewtoth: since it is public, it would be good to get info about it out
stickies-v: alright, looks like we’re done here. thanks for bringing it up andrewtoth
andrewtoth: what is holding up a 31.1 release?
Murch[m]: 31.1 should be out soon, right?
stickies-v: (okay not done)
Murch[m]: I just took a look at the milestone, all the todos seem to be checked off
dergoegge: eugenesiegel: This was fine to be public imo
sedited: I think we were waiting on #35465
Murch[m]: Ah sorry, the list of backports refers to merged PRs, but the PR is still draft
Murch[m]: https://github.com/bitcoin/bitcoin/pull/35331
andrewtoth: #35331
andrewtoth: Please review 35465 then
stickies-v: anything else here? otherwise i’m wrapping up
Murch[m]: I though https://github.com/bitcoin-core/meta/issues/46 was an interesting question.
Murch[m]: While it seems reasonable to judge code contributions on their own merit, it also seems reasonable that extremely uncharitable behavior in other avenues should at some point be addressed.
Murch[m]: Anyway, if people haven’t seen that conversation yet, maybe take a look
Murch[m]: :s/though/thought/
instagibbs: thanks for bringing it up
Murch[m]: Like, more concretely, if someone has been accusing us (without evidence) of crimes and shitting on our project in public for years, why should we continue to platform them in our repository?
Murch[m]: I can’t think of any other situation in life where this sort of behavior would be acceptable
stickies-v: so if someone is an asshole in real life, but contributes a good patch, we should not merge it because they’re an asshole?
stickies-v: that seems unworkable to me
Murch[m]: I don’t think your description of the situation matches what’s going on
Murch[m]: Anyway, I think that a ban would be in order. I don’t understand why we continue to subject ourselves to this person.
stickies-v: maybe i missed a recent conversation or incident but i’m not getting it
stickies-v: happy to review an issue or PR if there is one, i just subscribed to the meta repo
stickies-v: it looks like we’re done here, so i’ll wrap up

Read here for the full meeting

Releases

• No releases this week

Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!

If there are any comments, suggestions, or errors, do not hesitate to reach out or comment

In this week update we feature the latest release of Stratum V2 protocol and applications, which focuses on share accounting improvements, channel-management API refinements, and protocol/specification alignment.

We also cover the latest release of Core-lightning. v26.06 starts deprecation for the pay command in favor of xpay, brings the implementation up-to-date with the latest specs changes, and fixes some bugs.

We finally present a new BIP for sharing the UTXO set between peers and other interesting news from the Bitcoin ecosystem. Notably, Olaoluwa Osuntokun discussing post-quantum updates to BIP324, researcher Conduition becoming the first Brink grantee to work to make Bitcoin quantum secure, and some thoughts from the Lightning Dev Summit in Vienna.

Highlights from the bitcoin developer ecosystem

I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:

• v1.10.0 of Stratum V2 protocol libraries and v0.5.0 of Stratum V2 applications have been released.

  • During the weekly call, on Tuesday 2nd, Stratum V2 contributors announced that the new releases for both the protocol libraries and the applications were ready to be published. The new versions were later released on Wednesday 3rd.

  • v1.10.0 of the core libraries improves share accounting, adding possibility to track rejected mining shares, refines APIs for channel-management, simplifying the public API and improving encapsulation, and fixes some misalignment between the protocol and the specifications.

  • v0.5.0 of the application libraries integrates the changes from the core protocol crate. Moreover, it introduces improvements to the Translator Proxy and the Job Declaration Client.

• v26.06 of Core-lightning, called “Quantum-Resistant Lightning Channel” is now available.

  • During the latest update calls, Core-lightning contributors discussed the features to be included in the new version of the Lightning implementation. The release was finally published on Tuesday 2nd.

  • v26.06 starts deprecation for the pay command in favor of xpay , defaulting to the latter for managing payments, it increases the channel closure wait time to 72 blocks, updating to the latest specs, and introduces an experimental BOLT12 payment proof implementation updated to latest spec draft.

  • The release also fixes some issues. Notably, it fixes a problem with high fees that caused that caused splicein and spliceout to abort, a wallet change output bug for P2TR/P2WPKH, and some issues related to xpay command.

A BIPs Update

In the last week there was some movement in the BIP repository. Specifically, one new BIP has been assigned a number by BIP maintainer Murchandamus.

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP452: P2P UTXO Set Sharing

Authors: Fabian Jahr

Assigned On: Jun 4th, 2026

Layer: Peer Services

PR2137 introduces BIP452, which introduces the possibility to share the UTXO set over the P2P layer. The proposal defines a way to improve the assumeUTXO feature by providing a way for new nodes to receive the UTXO set directly from peers, instead of from external sources. In particular, it introduces a new service bit, four new P2P messages, and a UTXO set merkle root known to the requesting node, to verify the correctness of the provided UTXO set.

Other News from the Bitcoin World

• Post-quantum BIP324: Olaoluwa Osuntokun posted to the Bitcoin-Dev mailing list his thoughts on possible upgrades needed to make BIP324 quantum secure. BIP324 introduced transport encryption for the P2P protocol, enabling peers to exchange messages on the network with improved privacy and security. This could be an easier first step to make Bitcoin quantum secure than pushing changes at the consensus level.

• Quantum researcher: Bitcoin researcher Conduition announced that he had received a grant from Brink, making him the first grantee to be funded for R&D work to bring post-qauntum cryptography to Bitcoin. He will work full-time in collaboration with Blockstream Research to draft a balanced, efficient, and secure signature upgrade.x

• What’s next for Lightning?: Lightning contributor Vincenzo Palazzo posted some takeaways on what was discussed during the Lightning Dev Summit in Vienna. Moreover, Nifty posted the summit resolutions on GitHub, highlighting the next steps for the Lightning Network.

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Nairobi this June 17- 19 to talk about working in public in open-source!

Merged PR’s

Every week, several changes are officially added to Bitcoin Core. This week, multiple changes were merged. Here are some I found interesting this week.

• test: Add test on skip heights in CBlockIndex by optout21
  Optout21 authored and had his PR merged which added additional test coverage for the internal functions GetSkipHeight() and CBlockIndex::BuildSkip().
  
  He found that the skip logics and these functions were not well documented, so adding test coverage would firstly add coverage, but also document how they are intended to function. As always, additional test coverage is always welcomed to the coverage as it helps reduce issues in the future.

• coinselection: Optimize BnB exploration by murchandamus
  This week, Murch had his PR merged, which rewrote the BnB coin selection algorithm. He created this to skip the duplicate evaluation of previously visited input selections.
  
  This update is a pure optimization of the algorithm to reduce visiting inputs more than we needed to, and also, as fewer nodes are visited, this approach would enumerate more possible combinations than the original implementation, given the same limit for iterations.

There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.

• refactor: Add util::Result failure types and ability to merge result values by ryanofsky

  Add `util::Result` support for returning more error information and make use of it in [LoadChainstate method](https://github.com/bitcoin/bitcoin/pull/25665/commits/d0d2535cac193a448395fbb1d32df072b2e491a3) as an initial application. Followup PRs [#25722](https://github.com/bitcoin/bitcoin/pull/25722) and [#29700](https://github.com/bitcoin/bitcoin/pull/29700) use it more broadly to return errors and warnings from wallet and kernel functions as well.

IRC meeting notes

Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.

stickies-v: #topic Fuzzing WG Update (dergoegge)
dergoegge: no update

stickies-v: #topic Kernel WG Update (sedited)
sedited: #32427 has been getting a bunch of review over the past week and has accrued a few ACKs
sedited: For a change that will break backwards compatibility and completely changes one of our persistence layers, I think it requires still more buy-in.
willcl-ark: yes would be nice to see more Concept ACK-ers (and others!) review that one
sedited: So I’d like to invite more people to come review it.
stickies-v: anything else?
sedited: that’s all

stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc_: I pushed a tiny optimization to https://github.com/bitcoin-core/secp256k1/pull/1859 resulting in up to ~12% signature validation speedup by force-inlining int128 mul/sqr helpers.
l0rinc_: Reproducers and Windows/MSVC experts are very welcome.
l0rinc_: adndrewtoth’s https://github.com/bitcoin-core/leveldb-subtree/pull/61 was also merged and cherry-picked to previous releases.
l0rinc_: A followup was just pushed to #35465 - it does the compaction at the assumevalid boundary to guarantee uniqueness. It’s similar to darosior’s suggestion last week, just easier to implement and explain.
l0rinc_: that’s it from me

stickies-v: #topic QML GUI WG Update (johnny9dev)
johnny9dev: Nothing major to report. Making a lot of progress with 4 actively contributing now
johnny9dev: only a few more items to get merged before we want to start getting feedback
johnny9dev: https://github.com/orgs/bitcoin-core/projects/1/views/2
johnny9dev: still on track to have unsigned builds before the end of June
johnny9dev: that is all for now

stickies-v: #topic Libevent removal (pinheadmz, fjahr)
fjahr: pinheadmz isn’t here today but full focus is on review of #35182. IMO it’s getting very close and it would be great if we can get it in early in the release cycle.
fjahr: That’s it.
stickies-v: Anything else to discuss?
sedited: Might talk about #35465?
darosior: I don’t think compacting is particularly important in the first place, so take my nit with a grain of salt, but using assumevalid instead of minchainwork means that people actually validating the historical chain won’t benefit from the compaction?
instagibbs: that was my concern too
darosior: From a quick skim through the commits, it seems that this check would never be true for people running with -assumevalid=0 https://github.com/bitcoin/bitcoin/pull/35465/changes/dbf076273476d121a6d04c8a05dfcc5492e68b98#diff-97c3a52bc5fad452d82670a7fd291800bae20c7bc35bb82686c2c0a4ea7b5b98R3418
l0rinc_: the compaction doesn’t necessarily result in a measurable speedup - except maybe smaller files, so a few more can fit into the OS memory. But without compaction (especially on HDD) we were about ~15% faster
sipa: hi
l0rinc_: “it seems that this check would never be true for people running with -assumevalid=0” - good point, it’s why originally this was triggered by getting out of IBD mode. I’ll find something, thanks for the hint.
stickies-v: looks like we’re done here? thanks for the conversation, folks
l0rinc_: I want to avoid on events that can happen multiple times, e.g. when someone starts their node weekly - we don’t want every one of these resulting in a compaction

Read here for the full meeting

Releases

• No releases this week

Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!

If there are any comments, suggestions, or errors, do not hesitate to reach out or comment

In this week update we feature the most interesting things happened during Bitcoin++ Economic Edition in Vienna, where devs met to discuss how economic incentives can shape the future of Bitcoin.

We also cover some other interesting news from the Bitcoin ecosystem. Notably, Cashu going on-chain, two vulnerabilities found in Joinmarket-ng, and a new proposal for a novel L2 on top of Bitcoin are discussed.

Highlights from Bitcoin++ — Economic Edition

I spent last week at Bitcoin++ Economic Edition in Vienna. Here is what caught my eye:

• Knut Svanholm invited developers to ask themselves a simple question when proposing a change to Bitcoin: “Does this make Bitcoin better money?”

• Matthew Vuk from Second leveraged the Austrian Economics framework to support the thesis that covenants do make Bitcoin better money.

• Rene Pickhardt discussed how Ark and Lightning Network are not competing protocols, but are actually highly complementary. Ark could be the protocol to address some of the limitations of Lightning.

• Hubertus from Bitcredit Protocol made the case for creating a credit system based on bills of exchange on top of Bitcoin, to push it from a volatile asset to a stable monetary system. He also briefly discussed their new ecash implementation, which is said to be non-custodial, which will be open-sourced in the next months.

• Matt Corallo explained which could be the economic incentives in Bitcoin once a Cryptographically Relevant Quantum Computer (CRQC) becomes a reality and the market response to the different proposals on the table.

• Rusty Russell discussed his new venture, called Century Metadata, which aims to provide a simple solution to store and serve a small amount of encrypted data for 100 years or more. No, those data will not be stored on the Bitcoin chain.

• Max Hillebrand gave a talk about “The Praxeology of Privacy”, based on his recent effort to bridge the Austrian economics theory and the cypherpunk world.

• Luke de Wolf presented an approach to understand Bitcoin as critical infrastructure and outlines a cybersecurity-based framework to defend it.

The recorded event will be broadcast starting Thursday, June 4th, at 5pm UTC on YouTube! Don’t miss it!

A BIPs Update

There was no newsworthy update in the last days in the BIP repository. We’ll provide new updates as soon as a new BIP gets published or gets assigned a number.

Other News from the Bitcoin World

• Cashu goes on-chain: Last week, Cashu contributors merged a new NUT specification, NUT-30, which defines how to mint and melt ecash tokens through an on-chain payment. The new spec has been already implemented both in CDK and cashu-ts.

• New vulnerabilities: Developer floppy.md published a new audit report on Joinmarket-ng, a novel implementation of the JoinMarket CoinJoin protocol. Notably, he reported two vulnerabilities, one linked to failure to verify identity of a bondholder and a potential DOS vector around networking slots for !hp2 messages, which would prevent other nodes from hearing about invalid PoDLEs. Both vulnerabilities were fixed.

• A new L2?: Burak presented a new design for an L2 protocol on top of Bitcoin, called Cube. By combining Ark-style unilateral exit and BitVM, Cube aims to provide trustless smart contract execution, ensuring users always keep total control over their funds.

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Nairobi this June 17- 19 to talk about working in public in open-source!

Merged PR’s

Every week, several changes are officially added to Bitcoin Core. This week, 25 changes were merged. Here are some I found interesting this week.

• refactor: disentangle miner startup defaults from runtime options by Sjors
  Sjors isolates the miner’s initial startup configuration from its ongoing runtime options.

  • The Issue: The block template builder was heavily tangled up with global node state. This made writing clean tests or reasoning about the code a pain.

  • The Fix: Pulls those startup defaults out into an independent structure so it can be tested in isolation.

  • The Big Picture: This is the structural groundwork for the Multiprocess (IPC) mining interface. By separating these options, a standalone mining process will eventually be able to run cleanly on its own without needing to read deep into bitcoind‘s internal memory state.

• wallet: Construct ScriptPubKeyMans with all data rather than loaded progressively by achow101
  In this PR, Ava Chow tackles critical technical debt by explicitly documenting and enforcing the threading and locking rules for the validation interface. This interface handles notifications like blocks connecting, disconnecting, or transactions entering the mempool but previously its concurrency requirements were ambiguous, leaving the door open for potential data races or deadlocks.
  
  By formalizing these thread safety guarantees and adding strict assertions directly into the code, this update prevents future developers from introducing subtle concurrency bugs. It is a stability and code-quality improvement, making sure the node’s background notification system remains robust as Core continues to move toward a more modular architecture.

There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.

• refactor: Add util::Result failure types and ability to merge result values by ryanofsky

  Add `util::Result` support for returning more error information and make use of it in LoadChainstate method as an initial application. Followup PRs #25722 and #29700 use it more broadly to return errors and warnings from wallet and kernel functions as well..

IRC meeting notes

Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.

stickies-v: #topic Fuzzing WG Update (dergoegge)
dergoegge: no update

stickies-v: #topic Kernel WG Update (sedited)
sedited: Some review activity happening on #32427 again, and looking for more.
sedited: I rebased my branch for splitting the mempool/policy code from validation (and thus from the kernel library): https://github.com/sedited/bitcoin/tree/mempoolout_rebase
sedited: Still not happy with the code for the split though, the interface for accesing back into the mempool and grabing its locks is very clunky.
stickies-v: nice, will get back to reviewing 32427 asap, would be a nice improvement for kernel
sedited: not sure how interested people are in this split in the first place. The code-organizational benefits are kind of nice, but beyond that the utility for the Bitcoin Core software are a bit questionable.
darosior: "Mempool eviction? -Yes but the one you are thinking about"
darosior: not*
sedited: indeed :)
darosior: If it's a win for the Kernel library, and Bitcoin Core is no worse off, that seems fine?
stickies-v: yeah i think it's a pretty big improvement for kernel users
sedited: I might open it as a RFC PR , keeping it rebased is a challenge, but it's also kind of nice to ensure on a regular basis that such a split is possible in the first place.
stickies-v: an RFC issue might make more sense?
sedited: not sure, I think most would agree that it is a good thing on the face of it, so I more think it's the refactoring price that needs to be gauged here.
stickies-v: linking a branch from an issue seems fine, but then at least you're not wasting time rebasing / addressing nits
stickies-v: anyway
stickies-v: anything else here?
sedited: that's all

stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
andrewtoth_: l0rinc is out but he said he is working on an automated compaction PR
andrewtoth_: I relayed darosior's idea to use minimum chain work as a trigger
andrewtoth_: I also have come around to thinking a ~weekly automated compaction would be good
sedited: what would be wrong with just repeatedly checking isibd?
andrewtoth_: that would trigger every startup too, which would not be ideal
sipa: andrewtoth_: 1 week worth of blocks is mayhe 2 GB of block data, a full rewrite every week would add a multiple of that
sipa: or do we necessarily already have much morr
andrewtoth_: sipa: the chainstate adds < 200MB a week to the db if uncompacted
andrewtoth_: err I'm not sure how you mean block data to be relevant here?
sipa: yeah, i'm just trying to gauge how much a weekly full rewrite of the chainstate would add in terms of disk activity
darosior: For disk IO i think?
andrewtoth_: I think today it will be like 10-15 GB of write IO per full compaction
sipa: yes, which is a multiple of what i expect we'd do without
Murch[m]: Why once per week rather than say, once per month?
andrewtoth_: we can definitely bikeshed on how often to do it. could be monthly
stickies-v: what about thriweekly
sipa: rewrite at the end of IBD, once, is more impactful i think
darosior: stickies-v: hah
sipa: stickies-v: whenever the last block hash ends in 12 zero bits
sedited: ^^
andrewtoth_: yes agreed end of IBD is important. but, saving users an extra 11% for a full compaction every so often seems worth it?
Murch[m]: sipa: Probably better if not everyone does it at the same height
b10c: murch: agree
darosior: Once a month seems fine, and then no need to do it at the end of IBD
sipa: yeah, sorry, i didn't mean to start a bikeshed here... i'm just not very convinced doing it regularly adds much, and probably adds a relatively large amount of disk activity still
sipa: Murch[m]: absolutely, it was a joke :)
andrewtoth_: i think post-IBD alone is important, since a user might shut off and never keep it running for a whole month after that
Murch[m]: E.g., do it once after IBD finishes, then schedule it for a random height 3500–5000 blocks later again
Murch[m]: Would probably be bad if all nodes did it at the same height
andrewtoth_: Murch: I think that's nearly the approach l0rinc is taking now
darosior: andrewtoth_: you would advise doing both? I was hoping for either or
Murch[m]: From reading the topic last week, my impression was that the db is bloated by several GB at the end of a full IBD
Murch[m]: So, tracking that you started a new IBD and doing it once when you have caught up to the chaintip sounds pretty useful?
andrewtoth_: i was thinking both, yes...
darosior: If we do it once at the end of IBD, how much do you expect it would help to do it regularly on top? Like if it's done once around block 950k, how much disk space would doing it around block 1M would really save?
andrewtoth_: if I had to choose one, it would be post-IBD
andrewtoth_: 11% of disk space
andrewtoth_: we save ~30% doing it immediately after IBD, then it's a slow creep up to 11% total
andrewtoth_: a periodic compaction will trim that 11%
Murch[m]: and then ~200 MB per week, roughly?
andrewtoth_: Murch: up until 11%, it gets capped
darosior: Ok. No opinion here. I don't think it matters much either way.
andrewtoth_: I feel like post-IBD can be the initial change, then we can bikeshed more on periodic compaction.
Murch[m]: Well, every week seems a bit aggressive, but either way it would be a huge improvement over doing it every hour
andrewtoth_: ok, thanks for the feedback everyone
andrewtoth_: otherwise, got some great review on #35295, thanks! will address that soon
andrewtoth_: that's it from me

stickies-v: #topic Libevent removal (pinheadmz, fjahr)
pinheadmz: #35182 is real close. addresed some nits yesterday and restarted integration testing. already have a few small follow-ups in the queue.
pinheadmz: And libevent removal from client was merged yay
pinheadmz: Hoping to merge with enough time before release to find anything wrong
pinheadmz: All from me

stickies-v: #topic QML GUI WG Update (johnny9dev)
johnny9dev: We continue to be on track for our “Preview” unsigned builds in June . The related work for that can be found at  https://github.com/orgs/bitcoin-core/projects/1/views/2 and I updated it this morning so it is accurate. We have wallet updates from pseudoramdom and epicleafies and node error dialogs and block status updates from me in review. Afterwards the high runners are updating the project to v31 and validating the settings and
johnny9dev: onboarding is compatible with bitcoin-qt installs.
johnny9dev: That’s all from me
stickies-v: alright, thanks for the updates everyone
stickies-v: anything else to discuss?
abubakarsadiq: novo asked me to relay silent payments update
instagibbs: IIUC point release for 31.x is held up on #35319, so let’s try and get that done?
abubakarsadiq: https://github.com/bitcoin-core/secp256k1/pull/1765 has to be merged before we can merge silent payments on Core, but reviews are welcome on https://github.com/bitcoin/bitcoin/pull/35301 and https://github.com/bitcoin/bitcoin/pull/35302.
stickies-v: yeah good shout out instagibbs
Murch[m]: One follow-up to the compaction: if the mechanism is to schedule it for specific heights, you could schedule the first compaction for a height slightly after the chaintip of the best header chain once the node has acquired one, but delay the compaction until we are no longer in IBD.
Murch[m]: Or maybe just scheduling it for the regular ~x thousand block interval but waiting until you are no longer in IBD would be enough to do one after IBD
eugenesiegel: I tried making a functional test that built on top of p2p_private_broadcast.py, but it did not go well. I had issues with the Socks5 proxy and reconnection code, hopefully vasild has a better approach
instagibbs: vasild any ETA on your version of the test, even with cleanups TODO
andrewtoth_: Murch: we need to make sure we only trigger it one time, so using a gauge like previous work was < minimum now work is > minimum could work for that
andrewtoth_: otherwise it will trigger every startup
stickies-v: will wrap up the meeting here, but conversations can of course continue

Read here for the full meeting

Releases

• No releases this week

Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!

If there are any comments, suggestions, or errors, do not hesitate to reach out or comment

In this week update we feature an upgrade in the Fedimint-based wallet, Ecash App, introducing NFC support for better payment UX.

We also cover the recent effort from Stratum V2 maintainers to publish the new UI dashboard, sv2-ui, to the Umbrel app store, for a smoother self-hosting experience.

We finally cover two recent BIPs being published, namely BIP449 and BIP450, the recent move to Complete status for BIP54, and the latest release from Sparrow Wallet integrating silent payments.

Highlights from the bitcoin developer ecosystem

I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:

• PR447 in the Ecash App added support for NFC payments.

  • During the weekly call, on Monday 18th, Fedimint developers discussed the ongoing work on Ecash App, the Fedimint-based wallet. In particular, they announced the recent merging of PR447, which introduces NFC support.

  • Specifically, PR447 adds support for receiving and transmitting Lightning invoices through NFC, allowing a user to pick up the invoice by simply “tapping” the device that generated it.

  • What is cool about the tech: NFC support improves the user experience for payments, following the footsteps of other projects in the ecosystem, such as Numo, in providing a familiar feel with everyday fiat payments.

• IS80 in sv2-ui is keeping track of the work needed to publish the mining dashboard as an Umbrel app.

  • During the weekly call, on Tuesday 19th, Stratum V2 contributors discussed the ongoing effort to publish the new mining dashboard to the Umbrel app store. There are still active issues to be addressed before publishing, but the app is already undergoing a first round of testing.

  • sv2-ui is a sef-hostable dashboard that provides real-time statistics on miners, like connection status, total hashrate from connected miners, and shares sent to pools.

  • What is cool about the tech: Publishing the dashboard as an application on UmbrelOS would allow user to one-click deploy it, allowing for a smoother self-hosting experience.

A BIPs Update

In the last days there was some movement in the BIP repository. Specifically, two new BIP have been published by BIP maintainer Murchandamus.

Published BIPs

A list of recently published BIPs

BIP450: Formosa — Seed encoding by themed mnemonic stories

Authors: Yuri S. Villas Boas, André Fidencio Gonçalves

Published On: May 20th, 2026

Layer: Applications

BIP450 describes Formosa, an expansion of BIP39. This proposal introduces the possibility to encode a seed using short themed sentences (e.g., subject, verb, adjective, object, place), which carry grammatical structure and semantic coherence with the aim to improve memorability for the human mind. This BIP is fully back-compatible with BIP39.

BIP449: OP_TWEAKADD — x-only key tweak addition

Authors: Jeremy Rubin

Assigned Date: May 23rd, 2026

Layer: Consensus (Soft Fork)

BIP449 proposes a new tapscript opcode, called OP_TWEAKADD , which would provide a simple and verifiable way to modify a public key inside a script without revealing private keys or relying on hash locks. While Bitcoin already allows this type of “tweaking”, Rubin’s idea is to make this available at the consensus level. This would enable some interesting features, such as script-level key evolution without full signature verification, spending conditions, and covenant-like constructions.

Other News from the Bitcoin World

• BIP54 is complete: Antoine Poinsot announced on X that the PR to move status from Draft to Complete for BIP54 — Consensus Cleanup — had been merged. BIP3 states that a BIP can move to Complete status “when the authors have concluded all planned work on their proposal, are confident that their BIP represents a net improvement, is clear, comprehensive, and is ready for adoption by the Bitcoin community”. Some miners are already mining BIP54-compatible blocks, but we are still far from discussing the deployment of this soft fork.

• Silent Sparrow: Sparrow Wallet announced their latest release, v2.5.0. Thus release integrates silent payments, allowing users to launch a new receiving wallet.

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Vienna this May 27- 28 to talk about Austrian Economics!

Merged PR’s

Every week, several changes are officially added to Bitcoin Core. This week, 11 changes were merged. Here are some I found interesting this week.

• cli: Replace libevent usage with simple http client by fjahr
  As part of the effort to remove libevent as a dependency altogether, Fabian Jahr authored this PR to replace the libevent usage with a simple HTTP client.
  
  In his change, he replaces the libevent-based HTTP client with a simple synchronous implementation that uses the Sock class directly.

• fuzz: target CDBWrapper by andrewtoth
  CDBWrapper abstracts the interaction between Bitcoin Core and its database, currently LevelDB but previously BerkeleyDB. There was no dedicated harness targeting CDBWrapper. Andrew Toth authored this fuzz-testing PR to add coverage for this wrapper.
  
  Also, Toth noted that OSS-Fuzz has a harness for LevelDB, but it fails, so it appears not to be maintained. Adding a harness for it on Bitcoin Core will solve that issue for us.

There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.

• refactor: Add util::Result failure types and ability to merge result values by ryanofsky

  Add `util::Result` support for returning more error information and make use of it in LoadChainstate method as an initial application. Followup PRs #25722 and #29700 use it more broadly to return errors and warnings from wallet and kernel functions as well..

IRC meeting notes

Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.

stickies-v: #topic Fuzzing WG Update (dergoegge)
dergoegge: no update

stickies-v: #topic Kernel WG Update (sedited)
sedited: released a new rust-bitcoinkernel version with hand-rolled bindings instead of the previous auto-generated ones (reducing our build-time dependencies).
sedited: Other than that, maybe stickies-v has something?
stickies-v: he doesn’t

stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
_andrewtoth_: A bug with leveldb has been reported https://github.com/bitcoin/bitcoin/issues/35298.
_andrewtoth_: A potential fix is in https://github.com/bitcoin-core/leveldb-subtree/pull/61.
_andrewtoth_: l0rinc also discovered the fix improves reindex-chainstate speed on HDDs by 17%.
_andrewtoth_: Downside is around 11% more disk usage measured from the peak of disk usage. Right now an IBD will be 12 GB, this PR increases to 15 GB. But for already synced nodes the increase in disk usage will be very gradual.
_andrewtoth_: Disk usage can be brought back down with a manual -forcecompactdb after sync, but I think we should just accept a little more disk usage on chainstate for not rewriting the entire db every hour.
_andrewtoth_: Any thoughts on this?
fanquake: Can you tldr the bug? My understanding is that we are thrashing peoples disks by continually re-writing (100s GB) chainstate?
Murch[m]: This significantly increases the minimum disk space necessary for a pruned node :-/_
Murch[m]: s/:-/_/:-/\/
stickies-v: also wdym 12GB IDB disk usage? that seems... low?
_andrewtoth_: Seek compaction is a mechanism that will compact files in leveldb due to lots of reads
Murch[m]: stickies-v: Just for the UTXO set
stickies-v: oh, i see. thx
_andrewtoth_: since we do few writes, but lots of reads, it causes all written files to be compacted down to the lowest level
_andrewtoth_: this was happening daily before v30, but v30 writes a small file every ~hour now
_andrewtoth_: it was still a bug doing it every day, but now it’s even worse
Murch[m]: Can the count of reads permitted before compaction be increased?
_andrewtoth_: the purpose of seek compaction was for old spinning disks that took 10ms to seek to a file
_andrewtoth_: Murch: possibly, was suggested by willclark
_andrewtoth_: another option is to make forcecompactdb an RPC, which can be called periodically
Murch[m]: Would it be possible to turn that feature off in general and just call it ~once per week?
_andrewtoth_: but for backports, we can suggest to users to run forcecompactdb after a full sync
_andrewtoth_: I don’t think it’s worth calling it once per week. The amount of new data written every week is < 200MB or so. And that would rewrite the whole db every week.
_andrewtoth_: I think if users notice the increase in disk usage, they can call it then?
Murch[m]: I see, but it would gradually bloat the chainstate by about ~25% over time?
_andrewtoth_: 11% over time, from peak disk usage at that point
_andrewtoth_: peak usage of chainstate historically was, like 13.5 GB? so an IBD will be 11% more than that
_andrewtoth_: if you run today, you will have a compacted db, so it will be 11% more than today
Murch[m]: Ah, I see, that’s where the 15 GB comes from
sedited: Re-writing it once a week seems fine though?
dzxzg: what about enabling compaction for dbcache full flushes and disabling it for the interval flushes?
darosior: Tweaking this parameter in our LevelDB forks would only affect disk usage, not performance at all?
abubakarsadiq: > but for backports, we can suggest to users to run forcecompactdb after a full sync
abubakarsadiq: Why can’t we automate this in the backport patch?
fjahr: How sure are we 11% is really the peak? I assume there were a few measurements so far but it could still be worse on some systems/circumstances we may be missing?
darosior: Could also just do it on startup if that’s easier than setting a timer?
_andrewtoth_: This issue in particular does not want it done at startup https://github.com/bitcoin/bitcoin/issues/29662
_andrewtoth_: re: performance, there will be some more files in the db tree, but we have bloom filters for all of them so skipping is cheap
_andrewtoth_: sedited: I think not rewriting it is the intended operation of leveldb. If users care about 11% less disk space (which we have >100x than chainstate in blocks dir), they can run the option?
_andrewtoth_: dzxzg: that would be dependent on the user’s dbcache setting as well
Murch[m]: Well, not rewriting 10 GB every hour seems like the most pressing aspect of this.
_andrewtoth_: it is my opinion that seek compaction is a bug and should just be removed
darosior: Doing what LevelDB considers normal operations and having a mechanism to optimize disk space (whatever it is) sounds good to me.
_andrewtoth_: abubakarsadiq: i don’t think we should automate it, I think we should just report to the users there may be higher disk space, and run forcecompactdb if desired
darosior: By mechanism giving the option to user, either as a startup option or an RPC command.
darosior: By mechanism i mean*
_andrewtoth_: The startup option is already there, but I think RPC is more ideal
_andrewtoth_: but, for backports the startup option is fine
Murch[m]: If there is already a startup option, an RPC shouldn’t be a too heavy lift, I take it
_andrewtoth_: Murch: yes, I believe l0rinc is already working on that
_andrewtoth_: fjahr: there are measurements in the PR, and a more lengthy explanation
abubakarsadiq: _andrewtoth_: My question was why? Specifically, I assume everyone is going to desire more disk space; is there an implication of doing so that we want users to opt into or not?
Murch[m]: Interesting issue. Your mitigation approach sgtm then
_andrewtoth_: I don’t think it can get worse, but more eyes would be good
Murch[m]: abubakarsadiq: My understanding is that users are worried about the increased writes exhausting their SSDs’ limited write capability
_andrewtoth_: abubakarsadiq: the trade off is more disk IO. It will rewrite 10s of GBs each time. It will really only save 3GB if you did a fresh IBD. Otherwise, you will be rewriting everything for not much savings.
dzxzg: esp. for pruned nodes: i assume that if people are running with prune=650  they might care
Murch[m]: _andrewtoth_: Maybe one automatic compaction at the end of IBD would make sense
stickies-v: yeah one after IBD seems like a sane default?
stickies-v: would prefer not adding an rpc for this if we can avoid it
abubakarsadiq: _andrewtoth_: Murch[m]: makes sense now, thanks.
darosior: I think the startup option should be enough yes
darosior: Doing it after IBD sounds good too
_andrewtoth_: can we track if a user did from genesis easily, and then got to tip?
stickies-v: leveldb is an implementation detail and exposing it through our public stable interface is a bit messy
cfields: +1 on avoiding an rpc. I think the number of people who will be able to use that knowingly and correctly is single-digits.
darosior: AFK
Murch[m]: Lunch? ^^
stickies-v: even startup option i would probably find overkill, unless there is clear demand for it
_andrewtoth_: ok, having the startup option exists undocumented already, but we can find a way to do compaction first time the user gets to tip.
cfields: stickies-v: agreed. Same for any option. If we can’t decide when to do it automatically, we shouldn’t expect a user to be able to know when to do it manually.
abubakarsadiq: +1 cfields: I think if we can make that decision for users, it’s more ideal
Murch[m]: +1 cfields
stickies-v: anything else here _andrewtoth_ ?
_andrewtoth_: Closed #31132 and reopened as #35295. Got some good review there that I need to address (thanks!), more review welcome. That’s it from me, thanks!
stickies-v: thanks for the comprehensive overview, sounds like you got some useful feedback

stickies-v: #topic Silent Payments WG Update (Novo__)
theStack: The libsecp SP module PR https://github.com/bitcoin-core/secp256k1/pull/1765 got some momentum and fresh reviewer eyes after coredev (thanks!). In core, Novo__ opened #35301 and #35302 now (second takes of previously #28122 and #28201, respectively) based on that. Review would be much appreciated.
johnny9dev: Sorry I have to get going. Here is my qml update. https://github.com/orgs/bitcoin-core/projects/1/views/3 is updated. We’re making steady progress and still on track to have the project in a state where we feel it is worthwhile to start getting feedback from a wider group in the middle/end of June.

stickies-v: #topic Libevent removal (pinheadmz, fjahr)
pinheadmz: Ironing out edge cases in #35182. Running fuzzers 24/7.
pinheadmz: Antithesis caught something that I thought I fixed, but actually just triggered it again this morning doing a DoS test. It’s an assertion in the destructor which I think we can relax, and just delete connections that are taking to long (>60s) to close. Might needs hodlinator ‘s opinion on that before pushing...
pinheadmz: Janb84 grok-claude caught something which is not hard to fix but is harder to test because of all the nasty global state in httpserver.cpp, so trying to figure out what to include in this PR and what to punt to a follow up. Definitely the first follow-up de-globalizing http will be a very satisfying refactor.
pinheadmz: fjahr ?
fjahr: I just keep addressing review comments on the #34342 as quickly as possible. It feels like it’s getting very close though, thanks to the reviewers :)
stickies-v: alright, looks like that’s it for this week’s WG updates
stickies-v: Anything else to discuss?
jurraca: a few ASmap things
jurraca: looking for one more ACK on https://github.com/bitcoin-core/asmap-data/pull/48
jurraca: opened a PR to merge the prototype asmap.sigs repo into bitcoin-core/asmap-data as discussed at CoreDev https://github.com/bitcoin-core/asmap-data/pull/50
jurraca: and next collab run is set for June 4th, two weeks from today https://github.com/bitcoin-core/asmap-data/issues/51
Murch[m]: The CI workers seem to be very slow for the BIPs repository this morning. I assume that this also applies to the Bitcoin Core PRs. Anyone know what’s going on there?
fanquake: I wanted to bring up #35319
instagibbs: +1 fanquake
fanquake: My understanding is that “normal” -privatebroadcast usage might actually just leak your IP.
fanquake: I’m wondering if we should alert users in some way (mailing list / website?).
fanquake: Seems reasonable if there was some expectations of privacy here
Murch[m]: Also, for any BIP authors in this chat. I started the BIP metadata review that was future work for the BIP3 deployment. If you have any Informational BIPs that should be Specification BIPs, you will probably see a PR in that regard (or can open it yourself!). Similarly any BIPs that have been in Draft for years, will be proposed to be moved to Complete or Closed where applicable, or further input will be sought.
fanquake: Also there doesn’t yet seem to be consensus on how to fix / test
Murch[m]: So, if you want to help, it would be awesome if you look over your own BIPs in that regard.
instagibbs: +1 on some communication at least, brand new opt-in feature so impact is hopefully limited
eugenesiegel: there are a couple different tests, I haven
sedited: instagibbs can you provide a tldr?
Murch[m]: fanquake: What dose “normal” mean in this regard? I thought this happens when a connection downgrades from BIP324 to legacy P2P traffic?
instagibbs: sedited: on v2->v1 downgrade (if peer fails the v2 connection), if we’re using Tor exit node, we leak our ip directly to that target peer
instagibbs: It’s broken unless you connect to honest v2 peers, in other words
instagibbs: or hidden service nodes
_andrewtoth_: or honest v1 nodes
_andrewtoth_: *any v1 nodes
fanquake: (and I guess assume that spies will start trying to exploit given it’s public knowledge)
eugenesiegel: there are a couple different tests, I haven’t taken a look at instagibbs latest test. I’m partial to any functional test that can test without modifying the non-test code. as far as fixes, I think passing around an optional that defaults to nullopt kind of encourages callers to forget to set it? so maybe we could make it explicit? vasild patch does
eugenesiegel: work, just thinking how to make it robust
_andrewtoth_: really only malicious v2 nodes on clearnet
Murch[m]: Doesn’t even require a v2 node, you just have to fudge your service bits
instagibbs: eugenesiegel I made an attempt at robust test-only code changes
instagibbs: but I’m not a net expert, hoping more people look
eugenesiegel: Murch: right, a third party could also do it for some peers
instagibbs: “or honest v1 nodes” no, you leak your ip address to honest v1 nodes, you just hope no one looks at logs :)
instagibbs: oh, if bits arent stuffed, rigth
_andrewtoth_: instagibbs: you leak your ip for v1 nodes too? but it’s using the proxy and not downgrading?
Murch[m]: Wait, it always fails with v1 peers? I thought only on downgrade. That makes it way worse.
instagibbs: I retract my claim, need to re-page in how that part works
cfields: I know it’s waaay out of scope, but I mentioned this a few time at CoreDev... private tx relay would’ve been a great opportunity to launch separate short-lived tor-only instances of CConnman/PeerManager to handle the broadcast. I suspect that we continue to hit edge-cases otherwise :(
cfields: Just something to consider for the future.
eugenesiegel: It only fails on downgrade afaict and with a specific -proxy option. Though if there are v1 peers, a third party could modify service bits and force you to connect v2 and then downgrade
eugenesiegel: So, “-proxy=127.0.0.1:9050” is safe. “-proxy=127.0.0.1:9050=tor” is not safe
eugenesiegel: I have no idea on how widespread the feature is, I think sparrow uses it? I think a mailing list post could be helpful to tell people about the issue
_andrewtoth_: What is the behavior with default proxy options? So unset by the user?
eugenesiegel: _andrewtoth_: I’m not sure, does a user need to set -proxy to enable tor?
_andrewtoth_: no, and default is “disabled” according to bitcoind -h
_andrewtoth_: default also allows making pb connections to clearnet via exit nodes
eugenesiegel: how does bitcoind know the control port then? is it set to the default?
instagibbs: 4 minutes left (this conversation needs to continue anyways)
stickies-v: i’m going to call end of meeting here since we’re coming up on time, feel free to continue ofc. thanks for contributing, everyone

Read here for the full meeting

Releases

• No releases this week

Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!

If there are any comments, suggestions, or errors, do not hesitate to reach out or comment

On March 3rd, Blockstream Research demonstrated the use of post-quantum (PQ) signatures on the Liquid Network, the Blockstream powered federated sidechain. Researchers Oleksandr Kurbatov, Viktor Mashtaliar, Dmytrii Kurbatov, Mikhail Kudinov, and stringhandler were able to sign a real Liquid mainnet transaction leveraging Simplicity, Blockstream’s smart contract language, and its capacity to express custom, complex spending conditions to demonstrate what one potential quantum safe signature scheme might look like.

The scheme used for this test transaction was another produce of Blockstream Research: a hash-based algorithm called SHRINCS.

First presented by Director of Research Jonas Nick and cryptography researcher Mikhail Kudinov in December 2025, SHRINCS combines both stateful and stateless hash schemes, attempting to leverage the benefits of stateless signing while reducing the onchain footprint.

Before diving into the technical details, let’s take a moment to define the difference between stateful and stateless cryptographic signatures, highlighting the corresponding trade-offs.

Stateful and Stateless

Stateful hash-based signature schemes, such as XMSS, rely on so-called One-Time Signatures (OTS), where each key-pair must be used exactly once. Reusing a key means breaking the security fundamentals of the cryptographic scheme, allowing attackers to forge signatures and potentially steal funds. Thus, it is crucial to keep track of which keys have already been used (a.k.a. the state) to avoid compromising the funds. This means updating the state after each signature, so that we keep track of which keys have already been used. Holding onto this state introduces a layer of complexity in keys management, making static backups, or ones that aren’t updated after every use, de facto dangerous. Currently, you can find all of your funds from 12 seed words, and can sign for any key under those words without worrying about saving any additional information. A stateful scheme would mean you wouldn’t be able to do this without possibly leaking information and losing funds.

Despite their need to remember every signature, stateful schemes produce smaller size signatures, and require minimal computational effort for verification. The smaller size makes them attractive, particularly when compared to stateless signature schemes.

On the other hand, stateless signature schemes do not need to keep track of which keys have been used, making key management as simple as remembering a static backup, similar to how 12-words work today. The same key-pair can be used multiple times without compromising the safety assumptions behind it. To achieve this, stateless schemes make use of massive, multi-layered trees, which create a pool of possible signatures so large that makes the possibility of using the same key twice statistically irrelevant. As you may have already guessed, this comes at the price of way larger signatures than stateful schemes and a higher computational cost for verification.

SHRINCS: An Hybrid Approach

SHRINCS combines stateful and stateless signature schemes, attempting to take advantage of the strengths of each while mitigating their specific limitations. Specifically, SHRINCS leverages the efficiency in size and verification of a stateful scheme, while allowing users to easily recover their keys and safeguard their funds with a stateless counterpart in case the state is lost.

To achieve this, SHRINCS is built using both a stateless scheme (SPHINCS+) and a stateful scheme (Unbalanced XMSS).

During normal operation, SHRINCS uses the stateful unbalanced XMSS tree, producing a 324 bytes signature, a tiny signature compared to most other PQ signature proposals. The state is updated every time a message is signed and is securely stored, to be sure not to reuse the same key twice.

What happens if we need to restore our keys? As we said, it is not possible to recover a key from a stateful scheme with a static backup, since it would result in compromised security and possible loss of funds. If the state of the keys is ever lost, SHRINCS can fallback to the SPHINCS+ stateless signature scheme instead. Signature size will explode, reaching up to 8KB, but the funds aren’t at risk of being lost or stolen.

Unbalanced XMSS of WOTS

SHRINCS uses a stateful scheme based on an unbalanced XMSS tree of OTSs. This is basically a Merkle tree where each leaves represent an OTS.

To sign, the algorithm chooses a new OTS based on the current state, signs the message, and updates the state to signal that the chosen key should never be used again.

To verify a signature, we have to demonstrate that the OTS we are using belongs to the tree. Thus, the whole authentication path (a.k.a. the Merkle path) need to be provided together with the signature, which requires storing every hash of each sibling node up to the root.

To speed things up, SHRINCS uses an unbalanced tree, which results in a smaller authentication path and, as a consequence, smaller signatures. Moreover, the tree being unbalanced helps simplifying state tracking, since it basically matches the height of the Merkle tree.

The following image helps clarifying this concept. For the first signature, WOTS_1 will be used. The authentication path will be composed only by WOTS_1 sibling hash, while state = 1 . After use, the state will be updated to state = 2 , signaling the algorithm that the next signature would have to use WOTS_2.

To dive deeper in the chosen scheme, let’s analyze each component:

• WOTS+C: WOTS is considered the state of the art and the basis for more complex schemes. It is an hash-based signature function and, as the name suggests, a given key pair cannot be used twice. In particular, SHRINCS leverages an extension of WOTS+, called WOTS+C (which stands for “Compact”), which presents reduced signature size.

• eXtended Merkle Signature Scheme (XMSS) Tree: It is a hash-based signature scheme that combines OTS with a Merkle tree. Each OTS key represents a leaf in the binary tree, which has a predefined height h . The internal nodes of the tree represent the hashes of its children, while the root acts as the global public key. To verify an OTS signature, the authentication path (i.e. the Merkle proof, the sequence of sibling nodes from the chosen leaf up to the root) must be computed.

• Unbalanced Tree: Instead of having all the OTS at the same depth h as in a balanced tree, an unbalanced one allows to minimize the authentication path for the early signatures. In fact, the first OTS will have heigth = 1 , the second one heigth = 2 , and so on, strongly reducing the Merkle proof.

Putting this all together, we obtain the stateful scheme for SHRINCS.

SPHINCS+

The chosen scheme for stateless signing is SPHINCS+, or, as the author suggests, a variant of it.

SPHINCS+ is a complex signature scheme, built using several layers of post-quantum signature utilities, such as WOTSs, Forests Of Random Subsets (FORS), and XMSSs. When combined, SPHINCS+ produces a single quantum safe key-pair which can be used to sign many messages safely. Unlike XMSS, the algorithm doesn’t need to remember anything about prior signatures made with the key-pair for any subsequent signatures. One SPHINCS+ structure produces a single pubkey that can safely sign many messages without revealing the secret key.

This can be achieved because the final structure is huge, and the possibility to choose the same key twice is statistically irrelevant. Of course, this results in heavy signatures compared to those produced by stateful schemes, making them less practical for use in a system with limited space (like blocks).

If you want to know more about this PQ signing scheme, refer to this amazing article by Nifty.

Putting It All Together

To implement SHRINCS, there are four functions that are required: KeyGen, which sets up the initial SHRINCs structure with an Unbalanced XMSS and SPHINCS+ sub-pyramids and returns the top-level public key; Restore, which, given the seed, returns the same public key as KeyGen, and marks the state as LOST; Sign, which returns a valid signature for a message using one of the two sub-schemes (Unbalanced XMSS or SPHINCS+). If the state has been marked as LOST via a call to Restore, it uses SPHINCS+, otherwise, it signs using the Unbalanced XMSS tree. And finally, Verify, which takes a pubkey, a message, and a signature and returns true if the signature verifies, or false if not.

Most signature schemes include a KeyGen, Sign, and Verify methods; Restore is uncommon, as it marks which of the two internal schemes to use.

As outlined by Nick in the Delving post, here’s a more in-depth explanation of how each of the four functions work:

• KeyGen() : The algorithm creates a master seed and derives two secret keys, one for the stateful scheme, sk_1, and one for the stateless, sk_2. From these, the function derives the two public keys, pk_1 and pk_2. The SHRINCS public key is the hash of pk_1 and pk_2 , such that pk = H(pk_1, pk_2) . In the end, the function return the master seed , the master public key pk , and the initial state of the stateful scheme.

• Restore(seed) : This function is responsible for recovering the keys and for setting the state to LOST to signal that the stateful scheme cannot be used anymore.

• Sign(seed, state, m) : The signing algorithm first checks whether state is LOST or not:

  • if (state ≠ LOST) : The stateful scheme is used, thus the algorithm derives sk_1 and pk_2 and signs message m using the current state and sk_1. Then it returns the updated state, state’ along with the signature concatenated with pk_2 .

  • else if (state == LOST) : The stateless scheme is used, thus the algorithm derives sk_2 and pk_1, and signs message m using sk_2 . Then it returns the signature concatenated with pk_1 .

• Verify(pk, m, sig) : The verification algorithm parses sig to obtain the actual signature and the public key concatenated with it. It then verifies the signature according to the signature scheme used, and checks that the two public keys hash to the correct SHRINCS pk .

Algorithmic Agility

A question we could try to give an answer to now is: Is this algorithmic agility?

TL:DR: The short answer is no. Longer answer follows.

The Internet Engineering Task Force (IETF) gives a precise definition of this in RFC7696, which states that “Algorithm agility is achieved when a protocol can easily migrate from one algorithm suite to another more desirable one, over time” due to the fact that “advances in computing power or advances in cryptoanalytic techniques will eventually make any algorithm obsolete”.

Thus, we can see algorithmic agility as the ability for a cryptography-based system to be ready for anything (”in omnia paratus!”) that could happen to the primitives in use.

On the other hand, the goal of the hybrid approach proposed by SHRINCS is not to provide an alternative cryptographic scheme in case the main one gets broken by advancements in research and technology. Instead, it aims to supply users with a fast and efficient signing algorithm, while at the same time providing a safety net that will prevent them from losing their funds due to its already known limitations.

Why Does This Matter?

One of the greatest drawback of PQ signatures scheme is their size. This is not a problem per se, but it becomes so in the context of a decentralized protocol with limited storage capabilities. The smallest PQ signature is 10x larger than the simplest key in use today, allowing for around 3 transactions-per-second (tps), against the 7 tps currently achievable through Schnorr.

SHRINCS is a clever solution, that helps demonstrate the problem space of how to compress known hash-based signature schemes to work for the Bitcoin use case in a PQ world while retaining the current static-backup, 12-word experience that users are accustomed to. The SHRINCS innovation is a great approach for maintaining user experience while balancing the realities of limited blockspace.

On May 12th, Blockstream Research presented a first proposal for a hash-based signature Opcode for Post-Quantum Bitcoin, called OP_CHECKSHRINCS , leveraging SHRINCS as the chosen signature scheme. Research is continuing to prepare a quantum-secure future for Bitcoin.

This week update features a PR in ldk-node to add support for receiving Payjoin payments, a feature that would provide some interesting benefits to node operators.

We also cover the latest updates from the BIP repository, with BIP323 being published, and three new BIPs being assigned a number, specifically BIP138, BIP139, and BIP450. These three BIPs aims to improve in different ways how to backup wallets and their connected data.

Finally, we discuss some interesting news from the Bitcoin world, such as a new tool by Spiral to find vulnerabilities in open-source Bitcoin softwarre, and the latest mining company integrating support for StratumV2.

Highlights from the bitcoin developer ecosystem

I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:

• PR746 in ldk-node is adding support for receiving Payjoin payments.

  • During the biweekly call, on Monday 11th, LDK contributors discussed PR746 by developer Rita Anene, which aims to add support for receiving Payjoin payments in ldk-node.

  • The PR implements the receiver side of the Payjoin protocol, including session persistence, PSBT handling, input contribution, mempool monitoring for Payjoin transactions, and node restart recovery.

  • What is cool about the tech: Integrating Payjoin inside ldk-node could allow operators to use only one transaction, instead of two, to open channels when depositing from an external wallet. Operators would pay less fees, gain faster establishment of Lightning channels, and improve privacy.

A BIPs Update

In the last days there was some movement in the BIP repository. Specifically, one new BIP has been published and three new BIPs have been assigned a number by BIP maintainer Murchandamus.

Published BIPs

A list of recently published BIPs

BIP323: 24 nVersion bits for general purpose use

Authors: Matt Corallo

Published On: May 13th, 2026BIP39

Layer: Applications

BIP323 is a proposal that aims to increase the number of bits reserved for nonce space in the nVersion field of the block header from 16 to 24. This avoids the nTime field to be used as extra nonce space by header-only miners.

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP450: Formosa—Seed encoding by themed mnemonic stories

Authors: Yuri S. Villas Boas, André Fidencio Gonçalves

Assigned On: May 12th, 2026

Layer: Applications

PR2108 introduces BIP450, which describes Formosa, an expansion of BIP39. This proposal introduces the possibility to encode a seed using short themed sentences (e.g., subject, verb, adjective, object, place), which carry grammatical structure and semantic coherence with the aim to improve memorability for the human mind. This BIP is fully back-compatible with BIP39.

BIP139: Wallet metadata backup format

Authors: Pyth

Assigned On: May 11th, 2026

Layer: Applications

PR2130 introduces BIP139, which specifies a standard way to store various type of metadata, such as account descriptors, keys, labels, PSBTs, and more, allowing compatibility between different wallet implementations and a simpler wallet migration and recovery processes.

BIP138: Compact encryption scheme for non-seed wallet data

Authors: Pyth

Assigned On: May 11th, 2026

Layer: Applications

PR1951 introduces BIP138, which specifies a compact encryption scheme for output descriptors, wallet policies, labels, and wallet backup metadata to allow users to store sensible information on untrusted media. The encryption key derives from the public keys in the descriptor, allowing any keyholder to decrypt without additional secrets.

Other News from the Bitcoin World

• Finding vulnerabilities in Bitcoin: Spiral presented their new project, Loupe, an AI-enabled vulnerabilities scanner for open-source Bitcoin projects. The aim of Loupe is to help project maintainers identifying issues in their codebases before attackers do, improving the security standards of Bitcoin-related open-source projects. Many important projects have already committed to being part of Spiral’s initial tests, including Bitcoin Core, BDK, LDK, rust-bitcoin, Cashu, Blockstre am Jade, bitcoinj, and SRI. Check the full article here.

• NerdQ supports for SV2: StratumV2 announced that the NerdQ firmware had added support for the new mining protocol. NerdQ nis the third company landing support at the firmware level for StratumV2.

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Vienna this May 27- 28 to talk about Austrian Economics!

Merged PR’s

Every week, several changes are officially added to Bitcoin Core. This week, 11 changes were merged. Here are some I found interesting this week.

• wallet: addhdkey RPC to add just keys to wallets via new unused(KEY) descriptor by achow101
  Ava Chow added an RPC method named addhdkey. This allows a BIP 32 extended key to be added to the wallet without needing to import it as part of a separate descriptor. It is sometimes useful for the wallet to have keys that it can sign with, but are not (initially) involved in any scripts.
  
  Ryan Ofsky initially suggested adding an unused (KEY) descriptor, but this PR implemented it and was merged into master.

• build: Add a compiler minimum feature check by polespinasa
  As the title says, this change adds a compiler minimum feature check. This helps developers save time by failing early and explaining why, instead of having to chase down version errors.
  
  This change makes it easier for developers to build the project without wasting time.

There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.

• validation: fetch block inputs on parallel threads by andrewtoth

  Problem

  Currently, when fetching inputs in `ConnectBlock`, each input is fetched from the cache sequentially. A cache miss requires a round trip to the disk database to fetch the outpoint and insert it into the cache. Since the database is read-only during `ConnectBlock`, we can fetch all inputs of a block in parallel on multiple threads while connecting.

  Solution

  We add a ThreadPool to CoinsViewOverlay to fetch block inputs in parallel. The block is passed to the `CoinsViewOverlay` view before entering `ConnectBlock`, which kicks off the worker threads to begin fetching the inputs. The cache returns fetched coins as they become available via the overridden `FetchCoinFromBase` method. If not available yet, the main thread also fetches coins as it waits.

IRC meeting notes

Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.

stickies-v: #topic Fuzzing WG Update (dergoegge)
dergoegge: nothing from my side

stickies-v: #topic Net Split WG Update (cfields)
cfields: No update this week. I’m currently paused on the net refactor while working on some other projects (primarily multi_index replacement). Maybe best to take me out of the rotation for now?
stickies-v: alright, will do, lmk when you’d like me to re-add it, or just update the wiki when you want to!

stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
cfields: 👍
l0rinc: #35156 was merged and a few other similar ones experimented with - nothing else from my side
_andrewtoth_: worked with dergoegge to run #31132 in antithesis using drive to construct blocks with missing inputs and other things. No issues found.
stickies-v: no issues is good
_andrewtoth_: Working on creating a fresh PR with the changes, since there’s over 600 comments and most are no longer relevant
_andrewtoth_: that’s it from me

stickies-v: #topic QML GUI WG Update (johnny9dev)
johnny9dev: So it was suggested to create a project board last meeting so i worked towards that as it was a great idea
johnny9dev: and at coredev i setup the official one with all of the tasks i collected
johnny9dev: https://github.com/orgs/bitcoin-core/projects/1/views/3
stickies-v: that’s a well populated project board!
johnny9dev: it can be found here and we have a plan towards releasing. It is prioritized with “Preview” being our first build to get feedback on which should be sometime in June. “Beta” will be our target list for creating the PR sometime this fall. And “v1.0” is everthing is good to merge into bitcoin/bitcoin
jarolrod: wanted to scoot in and say: i’ll be around more formally from now on, to help qml gui ship
jarolrod: glad to be back :)
stickies-v: we’ll send over the paperwork shortly
johnny9dev: yes! excited for more contributors
stickies-v: good to see you back jarolrod!
jarolrod: 🥂
johnny9dev: epicleafies: any status?
epicleafies: Yeah, I’ve worked on implementing watch only wallet along with a few bug fixes.
johnny9dev: great. that is all for qml

stickies-v: #topic Libevent removal (pinheadmz, fjahr)
pinheadmz: Working on #35182, ironing out edge cases.
pinheadmz: Restarted fuzz testing with latest commits.
pinheadmz: About to post some benchmarking I did, just running the functional test suite on all three platforms to compare timing with master (~1-2% slower than master). Debug builds are even slower because libevent is always compiled with optimization.
pinheadmz: Passed integration testing with LND, which revealed the most significant breaking change: `debugexclude=libevent` will prevent startup since the logging category is removed. Any thoughts about this? It’ll be in the release notes but we could also band-aid that for now.
fjahr: on the go but no updates from me, still need to address latest feedback on CLI pull
sipa: Should probably just leave it in, as a category with no messages associated.
cfields: pinheadmz: leave the category in and mark it deprecated?
sipa: And give a warning on startup if it’s specified.
stickies-v: that sounds like the best approach to me too, with deprecation warning log yeah
sipa: The cost of keeping it around is tiny until we run out of log category bits, right?
pinheadmz: ok janb84 and i had some back and forth about what to do with the logging category but i didnt realize at that time it would actually prevent startup
pinheadmz: so i will make that change
pinheadmz: and thats all 4 me
stickies-v: Anything else to discuss?
_andrewtoth_: We’ve started a private broadcast working group channel. Feel free to join https ://signal.group/#CjQKIIBs79NZA9NAwuNXzBteyKUWxOEWu3QqaiQSMMJZCl2hEhD80HdpVUYNB_AGrMMTZFdu
stickies-v: not to dictate my personal comms preferences on people, but i think it’d be cool if people would consider continue to use dedicated irc channels to keep public logs for posterity
stickies-v: anyway, separate topic i guess
stickies-v: looks like we’re done here, thanks for the updates everyone
_andrewtoth_: stickies-v noted thanks

Read here for the full meeting

Releases

• No releases this week

Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!

If there are any comments, suggestions, or errors, do not hesitate to reach out or comment

This week’s update features the official merge in the BOLTs repository of the specifications for creating simple taproot channels, providing improved privacy, security, and flexibility of the Lightning Network.

We also cover the first stable release of Coco, an easy-to-use, modular, TypeScript-first toolkit for building Cashu wallets and applications, and the different releases of Stratum V2 for the core protocol, applications, and mining dashboard.

We finally propose some more interesting news. Notably, we discuss the biggest player in the mining industry joining the Stratum V2 Working Group, and a new challenge by Alloc Init to break their new witness encryption scheme.

Highlights from the bitcoin developer ecosystem

I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:

• PR995 for simple taproot channels has been finally merged.

  • During the monthly call, on Monday 4th, Lightning Network developers discussed PR995, an extension bolt to allow for simple taproot channels. The proposal by developer Olaoluwa Osuntokun has been finally merged after some years of work.

  • PR995 introduces specifications to enable support for taproot, allowing developers to improve the privacy, security, and flexibility of the system. In particular, the new taproot channels use MuSig2 key aggregation to combine two keys into one, with the multisig output becoming a single P2TR key, and tapscript trees capabilities.

  • The PR also defines the concept of “extension BOLT”, a standalone document that describes how to modify an existing “base” BOLT to avoid littering the main specification, improving readability and making reviewing easier. In particular, this PR extends capabilities for BOLT 2, BOLT 3 and BOLT 5.

• Coco, a modular, TypeScript-first toolkit for building Cashu wallets and applications, has finally released its first stable version.

  • During the monthly call, on Thursday 7th, Cashu developers announced that the first stable release, v1.0.0, of Coco had been released.

  • Coco aims to simplify the development of Cashu-related wallets and applications, providing developers with a “batteries-included” toolkit. According to its main developer, Egge, Coco “provides a storage-agnostic core for wallet logic, proof management, mint sync, quote handling, subscriptions, operation recovery, and typed events”.

  • Coco is not stopping at the first release, but it is already planning a second one for the end of the month, integrating the latest breaking changes from the library it is built on, cashu-ts.

• v1.9.0 of Stratum V2 protocol, v0.4.0 of the applications, and v0.2.0 of the mining dashboard have been recently published.

  • During the weekly call, on Tuesday 5th, Stratum V2 developers discussed the new upcoming releases of the different libraries. The protocol crates were released on the same day, while the ones for applications and UI were published the day after.

  • The main highlight for v1.9.0 is the introduction of a new ExtranonceManager module, a reusable allocator for extranonce prefixes for both standard and extended channels. v0.4.0 brings the latest updates from the protocol to the applications and provides support for Bitcoin Core v31. v0.2.0 improves the mining dashboard based on the feedback from the early adopters.

  • Stratum V2 developers are also working on a new bindings library, sv2-uniffi, to bring the reference implementation to other languages, starting from Python and C++.

A BIPs Update

There was no newsworthy update in the last days in the BIP repository. We’ll provide new updates as soon as a new BIP gets published or gets assigned a number.

Other News from the Bitcoin World

• New pools are joining the Stratum V2 Working Group: Stratum V2 maintainers recently announced that some of the biggest pools in the mining industry had joined the SV2 Working Group, a specialized body that aims to steward the initiative and advance the standard across the industry. The founding entities, Braiins and Spiral, are now leading the effort towards a more efficient, private, secure, and decentralized mining alongside AntPool, Block, Foundry, Mara, SpiderPool, and DMND.

• Breaking PIPEs: Alloc Init, a cryptography-focused research group, launched a new challenge to invite researchers and developers to break their new witness encryption scheme, which is the base for the new Bitcoin PIPEs v2.

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Vienna this May 27- 28 to talk about Austrian Economics!

Merged PR’s

Every week, several changes are officially added to Bitcoin Core. This week, 11 changes were merged. Here are some I found interesting this week.

• Implement BIP 370 PSBTv2 by achow101
  Ava Chow's pull request for implementing BIP 370, which is PSBTv2 was merged this week. Now what does this mean?
  
  The issue with the way that PSBT’s are handled in version 1 was that the signed transaction could not be changed. This meant that input and output could not be added. PSBTv2 solves this. There are additional benifits in PSBTv2 such as most the information is now being put in a singular location in the input map and output map.
  
  To understand it full I suggest you read the full spec

• fuzz: compact block harness by Crypt-iQ
  Are you familiar with fuzz testing in Bitcoin Core? How about how compact blocks work? Well, you’re in luck because this change involves both.
  
  This week, Crypt-iQ has his PR merged, which added a new fuzz harness cmpctblock into Bitcoin Core. Similar to process_message it, make valid and invalid blocks, reconstruct blocks with in-mempool txns, and more.
  
  This is yet another step in getting more fuzz coverage into Bitcoin Core, and who knows, maybe this might find a bug in how compact blocks work in Core.

• kernel: Expose CheckTransaction consensus validation function by w0xlt
This change exposes the consensus-level function CheckTransaction through the libbitcoinkernel C API and adds a corresponding C++ wrapper. Before this change, there was no way to do context-free validation checks on a transaction’s structure, and this provides that.
  
  This introduces a new API btck_check_transaction, and in the C++ wrapper it looks like this: btck::CheckTransaction.
  
  The Bitcoin kernel project is one that has been ongoing for a while, and this is just another API being added to it. This brings more functionality and testing, which is always welcomed.

There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.

• validation: fetch block inputs on parallel threads by andrewtoth

Problem

Currently, when fetching inputs in `ConnectBlock`, each input is fetched from the cache sequentially. A cache miss requires a round trip to the disk database to fetch the outpoint and insert it into the cache. Since the database is read-only during `ConnectBlock`, we can fetch all inputs of a block in parallel on multiple threads while connecting.

Solution

We add a ThreadPool to CoinsViewOverlay to fetch block inputs in parallel. The block is passed to the `CoinsViewOverlay` view before entering `ConnectBlock`, which kicks off the worker threads to begin fetching the inputs. The cache returns fetched coins as they become available via the overridden `FetchCoinFromBase` method. If not available yet, the main thread also fetches coins as it waits.

IRC meeting notes

Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.

None this week as coredev is going on, because of this the IRC meeting has been postponed till next week.

Releases

• No releases this week

Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!

If there are any comments, suggestions, or errors, do not hesitate to reach out or comment

This week’s update features an interesting PR in ldk-node which aims to introduce support for applying Replace-By-Fee (RBF) to a splice transaction.

We also cover the latest movements in the BIP repository. Notably, a new BIP proposal for disposing of dust UTXOs has been assigned number 451.

We finally propose some more interesting news, such as recordings of Bitcoin++ Villain Edition, where developers discussed the most controversial things in Bitcoin, a new announcement by BDK founder Alekos Filini, and the new path forward for LDK.

Highlights from the bitcoin developer ecosystem

I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:

• PR888 in ldk-node is adding support for splice RBF.

  • During the bi-weekly meeting, on Monday 27th, LDK contributors discussed PR888 in ldk-node by developer Jeffrey Czyz, which adds support in the Lightning implementation for splice RBF.

  • Replace-By-Fee (RBF) is a node policy that allows an unconfirmed transaction in the mempool to be replaced with a different transaction with a higher transaction fee.

  • PR888 adds a dedicated API that uses RBF to substitute an in-flight splice transaction with a new one with a higher feerate. This would allow the transaction to be mined faster, since the higher feerate makes it more attractive to miners.

A BIPs Update

In the last days there was some movement in the BIP repository. Specifically, one new BIP has been assigned a number by BIP maintainer Murchandamus.

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP451: Dust UTXO Disposal Protocol

Authors: bubb1es, haris

Assigned On: Apr 28th, 2026

Layer: Applications

PR2150 introduces BIP451, which describe a standard protocol to safely dispose of dust UTXOs by spending them to an OP_RETURN output with the entire value going to transaction fees. Dust attacks are a well-known threat for on-chain privacy. Attackers send a tiny UTXO (dust) to several addresses and, leveraging the common-input-ownership heuristic, links dust with other UTXOs belonging to the same wallet. While some mitigations are already in place to safeguard privacy, they are deemed insufficient. This BIP aims to fill this gap.

Other News from the Bitcoin World

• Villains talking controversies: Check out the full recordings from Bitcoin++ Villain Edition. Developers gathered at the Hoover Dam to discuss the most controversial topics regarding the future of Bitcoin. Listen to Peter Todd discussing tail emission, take your side in the Oxford-style debate on quantum, and check out Core developer Brandon Black talking about how to break ossification.

• Enclaved: Bitcoin developer Alekos Filini announced on X the launch of Enclavia, a new service that aims to bring hardware enclaves to every Bitcoin company for End-to-end encrypted computation and storage.

• Run your LDK-based node: Spiral announced LDK Server, the new deployable Lightning node package with all the features developed by LDK. It ships with built-in LSP support, feature parity with the BOLTs specifications, and clean API for usage by non-developers.

Merged PR’s

Every week, several changes are officially added to Bitcoin Core. This week, 11 changes were merged. Here are some I found interesting this week.

• util: Return uint64_t from MiB and GiB operators by maflcko
  Marco Falke opened this PR to attempt to modify the C++ type used by _MiB and _GiB from size_t to uint64_t. Falke mentioned a few reasons for this, those being that, currently, with size_t, it is impossible to represent larger values. But if it used a uint64_t instead, it would be possible.
  
  There are other reasons as well, such as it not being necessary and that the usage of size_t encourages its usage elsewhere, which can cause bugs and CVEs in the future.

• refactor: use options struct for signing and PSBT operations by Sjors

  In this PR, Sjors Provoost changes the sign, finalize , bip32derivs and sighash_type arguments that are passed to FillPSBT() and SignPSBTInput() into a struct named PSBTFillOptions instead.
  
  Provoost mentions that the motivation for this is that in the future, there might be a need to add another argument, and instead of creating a bunch of code churn, we can just add it to this struct, and it would be much cleaner and less of a headache.

• wallet: crash fix, handle non-writable db directories by furszy
  Matias Furszyfer opened this PR to improve error messaging when the DB directory is not writable. Furszyfer noticed that when trying to load or create a wallet and the DB was not writeable, he would get a vague message.
  
  In this PR, he fixes this for both creating a new wallet and loading an existing wallet.

There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.

• validation: fetch block inputs on parallel threads by andrewtoth

  This PR parallelizes fetching all input prevouts of a block during block connection, achieving over 3x faster IBD performance in some scenarios[^1][^2][^3][^4][^5].
  
  ### Problem
  
  Currently, when fetching inputs in `ConnectBlock`, each input is fetched from the cache sequentially. A cache miss requires a round trip to the disk database to fetch the outpoint and insert it into the cache. Since the database is read-only during `ConnectBlock`, we can fetch all inputs of a block in parallel on multiple threads while connecting.
  
  ### Solution
  
  We add a ThreadPool to CoinsViewOverlay to fetch block inputs in parallel. The block is passed to the `CoinsViewOverlay` view before entering `ConnectBlock`, which kicks off the worker threads to begin fetching the inputs. The cache returns fetched coins as they become available via the overridden `FetchCoinFromBase` method. If not available yet, the main thread also fetches coins as it waits.

IRC meeting notes

Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.

abubakarsadiq: #topic Fuzzing WG Update (dergoegge)
dergoegge: no updates

abubakarsadiq: #topic Kernel WG Update (sedited)
dergoegge: will have some stuff to show at coredev
sedited: We’re migrating rust-bitcoinkernel from a bindings generator to hand rolled bindings. That’s cutting down on some required dependencies.
sedited: Otherwise looking for review for the open PRs on the board https://github.com/orgs/bitcoin/projects/3/views/1
abubakarsadiq: dergoegge: 👍 looking forward to it.
sedited: That’s all from me.

abubakarsadiq: #topic Benchmarking WG Update (l0rinc, andrewtoth)
none

abubakarsadiq: #topic Benchmarking WG Update (l0rinc, andrewtoth_)
andrewtoth_: hi
sedited: ^^
andrewtoth_: Got some good review from l0rinc on https://github.com/bitcoin/bitcoin/pull/31132. More review welcome. That’s it from me.
abubakarsadiq: nice

abubakarsadiq: #topic QML GUI WG Update (johnny9dev)
johnny9dev: We have first PRs by our new contributor pseudoramdom bitcoin-core/gui-qml#561, bitcoin-core/gui-qml#556, bitcoin-core/gui-qml#554
johnny9dev: I have PR’d some improvements to our activity page, the block clock, and PSBT support bitcoin-core/gui-qml#559, bitcoin-core/gui-qml#558, bitcoin-core/gui-qml#557
johnny9dev: epicleafies has a PR up now for feature parity receive features bitcoin-core/gui-qml#553 and is working on other remaining parity features.
johnny9dev: I am currently focused on some planning and docs to share at coredev
abubakarsadiq: johnny9dev: would it be easier to track this on a board?
abubakarsadiq: Something similar to https://github.com/orgs/bitcoin/projects/3/views/1
johnny9dev: thats an interesting idea. I will consider it.
johnny9dev: but that is the kind of thing I am trying to work out right now
johnny9dev: as I’d like to share where we are and where we plan to be at the meeting
abubakarsadiq: yeah they are quite a lots of PR’s so you can just reference the board with the summary of the update, some also use tracking issue for that
johnny9dev: ok, thank you
johnny9dev: epicleafies: anything to add?

abubakarsadiq: #topic Libevent removal (pinheadmz, fjahr)
epicleafies: Not too much else, but I also created a PR for fixing some issues with Gmock
pinheadmz: Lots of progress on #32061 this week. Rebased on master after pre-factor commits were merged. Addressed feedback from vasild, janb84, hodlinator, and b-l-u-e. Claude found some crash bugs and HTTP violations and those have been patched. I also had Claude add functional tests to cover the most common and well-known HTTP vulnerabilities and malformed requests. Libevent actually failed one of those tests but not in a dangerous way. That PR
pinheadmz: just passed (windows) ci this morning so I closed it with 400+ comments and opened a fresh one: #35182 The PR is dead! Long live the PR!
pinheadmz: Fuzz testing and integration testing are next... especially now that lnd has fixed their ci incompatabilities with v31
vasild: hi
pinheadmz: nothigng new from fjahr
pinheadmz: that it

abubakarsadiq: #topic Net Split WG Update (cfields)
yancy: hi
abubakarsadiq: As usual, next week there won’t be an IRC meeting because of the coredev meeting.
abubakarsadiq: Anything else to discuss?

Releases

• No releases this week

Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!

If there are any comments, suggestions, or errors, do not hesitate to reach out or comment

This week’s update features the latest major release, v0.11.1, of Fedimint. This version brings a better UI for gateway management, lower memory usage, and some new experimental features

We also cover the latest movements in the BIP repository. Notably, BIP391 has been published, while a new BIP by Matt Corallo, has been assigned number 323.

We finally propose some more interesting news, such Jonas Schnelli debunking quantum FUD, an article on hashrate renting, and Numo’s battle testing at Bitcoin++ Villain Edition.

Highlights from the bitcoin developer ecosystem

I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:

• v0.11.1 of Fedimint, called “Mint Condition” is out, bringing a better UI for gateway management, lower memory usage, and some new experimental features.

  • During the weekly call, on Monday 20th, Fedimint developers discussed the recent release of v0.11.0 and the need for a patch version due to a panic happening during database migration. The patch version was later released on Tuesday 21st.

  • The new version comes with a better UI for gateway operators, including BOLT12 send and receive, channel management, and payment filtering, it adds better observability through Prometheus, it reduces memory usage, and allows users to discover guardians through the decentralized Pkarr DNS sysyem.

  • v0.11.x also adds new experimental APIs for the new v2 version of the wallet and the mint. These modules are disabled by default, and must be explicitly activated during the federation setup. Devs specify that these features are not yet production-ready and their use is still not recommended.

A BIPs Update

In the last days there was some movement in the BIP repository. Specifically, one new BIP has been published and one BIP has been assigned a number by BIP maintainer Murchandamus.

Published BIPs

A list of recently published BIPs

BIP391: Binary Output Descriptors

Authors: SeedHammer

Published On: Apr 23rd 2026

Layer: Applications

BIP391 proposes a new, efficient container format to encode an output descriptor, with support for key metadata, based on key-value maps as defined by BIP174. The aim is to provide a standard to address the issues of descriptor strings, such as the lack of machine-recognizable header, inability to represent metadata, and inefficient keys encoding. The specified Binary Output Descriptor (BOD) format consists of a fixed header, a key-value map describing the output descriptor, and a key-value map for each key.

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP323: 24 nVersion bits for general purpose use

Authors: Matt Corallo

Assigned On: Apr 22nd, 2026

Layer: Applications

PR2116 introduces BIP323, which aims to increase the number of bits reserved for nonce space in the nVersion field of the block header from 16 to 24. This avoids the nTime field to be used as extra nonce space by header-only miners.

Other News from the Bitcoin World

• Breaking Quantum FUD: Former Bitcoin Core maintainer Jonas Schnelli debunked the recent news about 15-bit ECC key being broken by a quantum computer.

• Renting hashrate: An interesting article about renting hashrate and pointing it towards Ocean mining pool using their Datum gateway.

• Battle tested: Numo, the open-source, Cashu-based Point-of-Sale (POS) application, has been battle tested during Bitcoin++ Villain Edition. Open-source designer Erik provides a precise analysis of his findings on how to improve the user experience for merchants.

Merged PR’s

Every week, several changes are officially added to Bitcoin Core. This week, 10 changes were merged. Here are some I thought were interesting from this week.

• refactor: Change CChain methods to use references, add tests by optout21
  optout21 refactored the CChain methods, no longer use pointers because of the risk of accidental nullptr dereference. The methods being updated in CChain are Contains(), Next(), and FindFork().
  
  This improves the safety of the CChain methods because there will be a lower likelihood of falling into this nullptr dereference error.
  
  Optout21 concludes that there might be future improvements that make sense.

  Further ideas, not considered in this PR:

  • Change InvalidateBlock() and PreciousBlock() to take references.

  • Change CChain internals to store references instead of pointers

  • Change CChain to always have at least one element (genesis), that way there is always genesis and tip.

  • Check related methods to return reference (guaranteed non-null) -- FindFork, FindEarliestAtLeast, FindForkInGlobalIndex, blockman.AddToBlockIndex, etc.

• test: Clean shutdown in Socks5Server by optout21

  The Socks5Server utility handles multiple incoming connections, which are handled in separate background threads. Its stop() method unblocks and waits for the main background thread cleanly, but it doesn't attempt to wait for the completion of handler threads. There is no guarantee that the handler threads are finished after stop() returns, which can lead to IO errors.

  This pull request by optout21 adds a clean shutdown to Socks5Server to avoid intermittent CI failures.

• Rollback for dumptxoutset without invalidating blocks by fjahr
  Fabian Jahr opened this change because of a need to implement dumptxoutset with a rollback. It was also wanted a way to roll back that did not use invalidateblock and reconsiderblock and instead created a temp copy of the coins DB.
  

  There are a few upsides to this approach.

  • Network activity does not have to be suspended

  • Forks can not interfere with the rollback

But also a few downsides like requiring more disk space, and performance is slower.

There are always changes being updated and reviewed in real-time. Here are some notable PR’s that are still up and looking for reviews.

• validation: fetch block inputs on parallel threads by andrewtoth

  Problem

  Currently, when fetching inputs in ConnectBlock, each input is fetched from the cache sequentially. A cache miss requires a round trip to the disk database to fetch the outpoint and insert it into the cache. Since the database is read-only during ConnectBlock, we can fetch all inputs of a block in parallel on multiple threads while connecting.

  Solution

  We add a ThreadPool to CoinsViewOverlay to fetch block inputs in parallel. The block is passed to the CoinsViewOverlay view before entering ConnectBlock, which kicks off the worker threads to begin fetching the inputs. The cache returns fetched coins as they become available via the overridden FetchCoinFromBase method. If not available yet, the main thread also fetches coins as it waits.

IRC meeting notes

Every week on Thursday, there is an IRC meeting. Here are some short notes from that meeting.

abubakarsadiq: #topic Net Split WG Update (cfields)
abubakarsadiq: I guess no update from cfields, if there is we can come back to the topic
cfields: No update this week, been working on my multi_index replacement.

abubakarsadiq: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: #35025 was merged, the deserialization benchmarks are more realistic now.
l0rinc: The untimed setup of nanobench needed a follow-up to make it more intuitive to use, see #35124.
l0rinc: #34641 was split into tiny, focused commits based on the feedback.
l0rinc: Pushed #35128 to speed up `gettxoutsetinfo` - a follow-up is already brewing based on the feedback.
l0rinc: That’s it from me, thanks for the reviews.

abubakarsadiq: #topic QML GUI WG Update (johnny9dev)
johnny9dev: Opened up a PR for new settings pages (bitcoin-core/gui-qml#551) This includes Wallet settings that has details, create backup, password add/update, and wallet deletion. Sign message will likely end up here as well. The PR also includes a Mempool settings page that shows transaction amount and memory usage as well as an input field for updating mempool memory amount. I am currently working on a flow for importing PSBT.
johnny9dev: We have a new contributor as well, pseudoramdom, who will be starting by implementing our RBF design as his first feature.
johnny9dev: With pseudoramdom on RBF, epicleafies working on Receiving and Sign message, and me doing PSBT import I think that just leaves the “Address Book” page as the last feature-parity issue needing a first implementation
johnny9dev: that is all

abubakarsadiq: #topic Libevent removal (pinheadmz, fjahr)
fjahr: I keep getting good review comments on #34342, trying to address them as fast as possible but didn’t get to the comments from yesterday yet :) Waiting for the rebase/re-open to start review on the http server again. That’s it from me.
pinheadmz: Nothing new from me this week
abubakarsadiq: I skipped some working groups because the leads aren’t here. If you have an update please propose the topic
abubakarsadiq: Anything else to discuss?

Releases

• 31.0 Release

Thank you for reading. Be sure to tune in again next week for your updates on Bitcoin Core!

If there are any comments, suggestions, or errors, do not hesitate to reach out or comment

Stacie tells us about her journey into bitcoin, and what she’s working on now

This week’s update features the latest major release, v3.0.0, of BDK wallet. This version brings major API changes to the Rust wallet library.

We also cover the new release for Core-lightning, v26.04. This version activates splicing by default, improves privacy through message padding, and increases payment reliability.

We also discuss PR630 in ldk-node, which adds support for configuring a node as a BIP353 resolver for human-readable names.

We finally feature the recent pubilication of BIP361 and some interesting interviews from the MIT Bitcoin Expo.

Highlights from the bitcoin developer ecosystem

I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:

• v3.0.0 is the latest major release for BDK Wallet, the descriptor-based wallet library written in Rust.

  • During the weekly call, on Tuesday 14th, BDK contoributors discussed the latest major release v3.0.0. Developers are now discussing which fof the new features will be included in the UniFFI bindings.

  • Major updates includes persistent UTXO locking, to keep track of those UTXOs that should not be chosen automatically for a transaction, it adds support for importing/exporting the Caravan wallet JSON format, and improves network handling by using the latest features from rust-bitcoin.

  • Moreover, due to some changes in the SQLite database, developers provided utilities to allow projects to upgrade from BDK versions older than v1.0.

• v26.04 of Core-lightning, named “Negative Routing Fees” is out.

  • During the biweekly call, on Monday 13th, CLN developers reviewed the final release requirements for v26.04. The new version was officially published today, Monday 20th.

  • Splicing is now enabled by default, after the recent merge of its specifications, offering simple commands, such as splicein and spliceout, to manage channels without closing them. Moreover, messages are now padded to a uniform length, making it harder for attackers to infer node activity from message sizes.

  • This release also offers improved payment reliability through parallel path-finding, allows users to include fees in the requested amount, effectively making receiver paying them, adds support for payment notes in xpay , and allows to configure specific peer nodes to direct payments through.

• PR630 in ldk-node is adding support for resolving BIP353 human-readable names.

  • During the biweekly call, on Monday 13th, LDK contributors discussed PR630 which aims to introduce the possibility to configure a node as an BIP353 human-readable names resolver.

  • BIP353 proposes a standard format to encode URI schemes in Domain Name Service (DNS) records. Basically, it allows to store Bitcoin payment information into human-readable strings which can be easily verified on hardware wallets.

  • PR630 allows to configure an LDK node to act as a human-readable address resolver for other nodes. The goal of the resolver is to translate the human-readable string into an actual payment instruction.

A BIPs Update

In the last days there was some movement in the BIP repository. Specifically, one new BIP has been published by BIP maintainer Murchandamus.

Published BIPs

A list of recently published BIPs

BIP361: Post Quantum Migration and Legacy Signature Sunset

Authors: Jameson Lopp, Christian Papathanasiou, Ian Smith, Joe Ross, Steve Vaile, Pierre-Luc Dallaire-Demers

Published On: Apr 14th, 2026

Layer: Consensus (soft fork)

BIP361 is a proposed soft fork to implement a post-quantum output type and to provide a multi-phase plan to sunset legacy ECDSA/Schnorr signatures. According to the authors, the goal is to make upgrading to post-quantum outputs a matter of incentives, providing a clear timeline to align the entire ecosystem.

Other News from the Bitcoin World

• Does Bitcoin scale?: BTC++ Insider reporter Niftynei chatted with Jonathan Harvey-Buschel, MIT graduate and Chaincode Labs researcher, about his work on the Lightning gossip protocol at the MIT Bitcoin Expo. See what he had to say about networking clusters, minisketch considerations, and how he’s repurposing insights from the Erlay paper to make the Lightning Network scale to the next 100k nodes.

• Quantum FUD vs Quantum Compute: Bitcoin++ announced a one hour formal Oxford debate on the topic “Quantum FUD is a greater risk to bitcoin than quantum computers”. The Villain Edition conference will take place at the Hoover Dam this week, Thurs + Fri (Apr 23+24). Alex Pruden from Project Eleven will argue the negative; Brandon Black, the affirmative. David Zell, Director of the Bitcoin Policy Institute to moderate.