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

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

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.

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.

• validation: make CCoinsView a pure virtual interface by l0rinc

  This change is an improvement to the CCoinsView interface. What this PR does is make CCoinsView a pure virtual interface. It introduces CoinsViewEmpty which is a noop coins view. Instead of declaring a dummy coinsDummy and then creating a CCoinsViewCache from that, we can just use CoinViewEmpty::Get().
  
  All of these methods were made to be pure virtual, PeekCoin, GetCoin, HaveCoin, GetBestBlock, GetHeadBlocks, BatchWrite, Cursor, EstimateSize. This change also removed the legacy default implementation from coins.cpp.
  
  This change is a refactor, so it does not give any functional change to the codebase, but it does make interfacing with CCoinsView much more straightforward to understand. Refactoring the confusing codebase of Bitcoin Core to become easier to understand is always a win.
  

• test: modernize interface_http and cover more libevent behavior by pinheadmz
  This is a follow-up to tests: Expand HTTP coverage to assert libevent behavior and a prerequisite to Replace libevent with our own HTTP and socket-handling implementation. If you have been following these posts, you would know that the Libevent removal is moving forward.
  
  This is yet again another PR that helps get Libevent removed in favor of our own HTTP socket handling implementation. This PR was only a testing change updating test/functional/interface_http.py to cover more Libevent behavior, so when the migration is fully complete, there are no hidden bugs or functionality that was expected to exist.
  
  If you want to keep up to date on the Libevent changes, be sure to follow the tracking issue.

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.

• fuzz: add p2p_private_broadcast harness by frankomosh
  

  Add a fuzz harness for ConnectionType::PRIVATE_BROADCAST, a privacy-preserving transaction relay mechanism whose p2p code paths had no meaningful fuzz coverage.
  

  Current process_message touches it but is insufficient in exercising it. It creates PRIVATE_BROADCAST nodes via ConsumeNode(), but some structural problems prevent it from covering the relevant logic:

  1. m_tx_for_private_broadcast is never seeded, PushPrivateBroadcastTx always takes the immediate disconnect path (7 accidental hits, all on lines 3559–3562). Lines 3564–3570 (the actual INV send) had 0 hits.

  2. ALL_NET_MESSAGE_TYPES is used as the message pool. CConnman::PushMessage silently drops anything outside the five-type allowlist for private broadcast connections, wasting most iterations.

  3. Connection types are picked randomly, hence private broadcast coverage is accidental.

  
  To solve the issues above;

  • this harness explicitly constructs nodes with ConnectionType::PRIVATE_BROADCAST

  • seeds m_tx_for_private_broadcast via InitiateTxBroadcastPrivate before the peer connects, so PushPrivateBroadcastTx reaches the transaction send path

  • constrains the message pool to the five types permitted by CConnman::PushMessage on private broadcast connections (VERSION, VERACK, INV, TX, PING)

  • passes ServiceFlags{NODE_NONE} to InitializeNode, matching what PushNodeVersion advertises for private broadcast peers.

IRC meeting notes

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

<abubakarsadiq> #topic Benchmarking WG Update (l0rinc, andrewtoth)
<l0rinc> #34124 was merged, thanks for the reviews!
<l0rinc> Based on the discussion there, I opened #35078 as the next step in the coins cleanups.
<l0rinc> #34132 and #34320 were rebased after the recent merge - the Ubuntu PPA is probably still down, so CI doesn't always pass, but they're ready for review again.
<l0rinc> I'll be at a conference for the next few days, but want to focus on #34887 and #31132 again next week.
<l0rinc> I have also remeasured full reindex-chainstate on my Mac with our pending optimizations: it finished in 1h 14m
<l0rinc> on Umbrel is ~5h, full IBD aroun 8-10
<l0rinc> that's it from me - andrewtoth?

<abubakarsadiq> #topic Net Split WG Update (cfields)
<cfields> been working on other things, no update this week

<abubakarsadiq> #topic QML GUI WG Update (johnny9dev)
<johnny9dev> Finished up external signer support with bitcoin-core/gui-qml#547.  Now working on the remaining set of wallet functionality bitcoin-core/gui-qml#548, bitcoin-core/gui-qml#550, and have a “Wallet Settings” page designed and will be implementing backup, password change, and delete with that. Finally, fixing an onboarding regression update with bitcoin-core/gui-qml#549
<johnny9dev> Also have had a lot of success with AI assisted designing using Figma and Christoph’s web prototype to generate some of these settings pages. So am pretty excited about that.
<johnny9dev> epicleafies: any update?
<johnny9dev> I don’t see him here but he has been focused on finishing all of the Receiving features
<johnny9dev> we;re getting really close to having the core features have some sort of implementation now.
<johnny9dev> that is all

<abubakarsadiq> #topic Libevent removal (pinheadmz, fjahr)
<pinheadmz> I think we can target v32 for libevent removal
<pinheadmz> Some goodies merged this week
<pinheadmz> #32061 I’m gonna rebase and close and reopen a fresh PR with latest comments from hodlinator and basil’s
<pinheadmz> Oops vasild
<pinheadmz> That’s all!
<abubakarsadiq> There are no pre-proposed meeting topics this week. Any last minute ones?
<abubakarsadiq> Anything else to discuss?
<janb84> pinheadmz: pleas also look at my comments, they are hand checked / poc hand crafted
<pinheadmz> Oh yes artisanal comments
<pinheadmz> Really great actually. Thanks

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

This week’s update features PR1870 in CDK, which aims to integrate on-chain payments in the Cashu implementation using the Bitcoin Development Kit as a backend.

We also cover the new MIP-06 specification for the Marmot Protocol, which aims to standardize how to leverage the secure messaging protocol on different devices using the same Nostr identity.

We also discuss two new post-quantum proposal, one by StarkWare researcher Avihu Levy, and another by Lightning Labs CTO Olaoluwa Osuntokun.

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:

• PR1870 in Cashu Development Kit is integrating on-chain payments in the ecash protocol.

  • During the weekly call, on Wednesday 8th, CDK developers discussed the ongoing effort to integrate on-chain payments in the ecash protocol. The draft PR1870 was opened the day after, on Thursday 9th.

  • This new feature would allow Cashu mints to mint and melt quotes through on-chain transactions, expanding the number of supported payment methods.

  • As an on-chain backend, PR1870 leverages the Bitcoin Development Kit (BDK), which provides all the needed functionalities to perform payments, such as receiving and sending, BIP84 key derivations, blockchain synching through Bitcoin Core and Esplora, and confirmations tracking.

• MIP-06 is the new specification for the Marmot protocol to allow users to share the same identity on multiple devices.

  • During the monthly call, on Tuesday 7th, Marmot developers discussed the new Marmot Improvement Proposal (MIP) which aims to add support for using the same Nostr identity on multiple devices.

  • According to MIP-06, each device would generate its own key material, while sharing the same public key in their basic MLS identity information. This would allow clients to recognize each device key as belonging to the same user.

  • Each device would maintain its own independent MLS gorup state and message history, since no shared state is possible. Moreover, message decryption would happen separately and independently on each device.

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

BIP376: Spending Silent Payment Outputs with PSBTs

Authors: Nymius

Published On: Apr 11th, 2026

Layer: Applications

BIP376, proposes adding new per-input fields in Partially Signed Bitcoin Transactions (PSBTs) v2, described in BIP370, to allow for silent payment outputs spending.

While BIP375 already specifies how to create outputs locked with silent payments in PSBTs, a specification on how to unlock them is still not available. The BIP, proposed by BDK contributor Nymius, closes this gap in the specifications.

Other News from the Bitcoin World

• Quantum-Safe Bitcoin Transactions Without Softforks: StarkWare researcher Avihu Levy recently shared his latest work on a qunatum-safe scheme that does not require any softfork to the Bitcoin protocol to work. His research builds on a previous proposal by BitVM creator Robin Linus called Binohash, a new, collision-resistant hash function for Bitcoin Script.

• A zk-STARK Escape Hatch for BIP-32 Wallets: Lightning Labs CTO Olaoluwa Osuntokun presented a new proof-of-concept for a method to prove ownership on funds using zero-knowledge proof. In case of an emergency post-quantum softfork, many funds may remain locked in non-secure wallets. This scheme would allow users to prove the ownership of a certain address by demonstrating knowledge of a BIP32 master seed, without revealing it.

Merged PR’s

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

• Replace boost signals with minimal compatible implementation by Cory Fields
  This change is one to help reduce the use of the boost dependency for bitcoind. In this change, the use of boost was reduced to boost::multi_index. This change is part of the v32.0 milestone, and hopefully, bitcoind can eventually remove its reliance on boost entirely.
  
  This change implemented a minimal compatible version of boost signals in src/btcsignals.h that bitcoind uses. This ultimately will be the replacement.
  
  From my perspective, this feels like a part of a larger effort to remove most dependencies from bitcoind. As I will continue to talk about in the next pull request that was merged.

• torcontrol: Remove libevent usage by Fabian Jahr
  Another dependency removal project is also underway. As I had mentioned in a previous edition of “This Week in Bitcoin Core” there is a new working group dedicated to removing the libevent dependency from bitcoind.
  
  In the pull request, it was removing the libevent usage from torcontrol, specifically, it replaces the libevent-based async I/O with blocking I/O utilizing the existing Sock and CThreadInterrupt.

Follow this link if you want to keep track of the progress of the libevent removal changes. From what I see, 3 more PRs are waiting to be merged, and a draft PR tracking what it would look like if it were completely removed today.

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.

• wallet, rpc: add include_change parameter to listtransactions by alfonsoromanz

  Currently, listtransactions silently hides transactions whose outputs go exclusively to change addresses. This can be confusing, as reported in #34632: a user created a consolidation transaction sending funds to a change address, and the transaction disappeared from listtransactions, making it appear as though funds were lost.
  

  listsinceblock already supports an include_change parameter for this purpose. The internal ListTransactions helper also already accepts it. This PR simply wires the parameter through the listtransactions RPC handler for consistency.

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> Not much to say but we published a second blog post about fuzzamoto: https://brink.dev/blog/2026/04/09/fuzzamoto-non-determinism/

<abubakarsadiq> #topic Net Split WG Update (cfields)
<cfields> I just pushed #35040. It’s move-only. please have a look :)
<abubakarsadiq> Nice. Is that it?
<cfields> 👍

<abubakarsadiq> #topic Libevent removal (pinheadmz, fjahr)
<pinheadmz> hello
<pinheadmz> From fjahr: “#34158 was merged. Now my only PR left on this project is #34342 and since it depended on some changes from #34905, which was also merged, I was now able to take it out of draft status and it’s ready for review. It has some small parts shared with #32061 but I have decoupled it for now to allow for independent review.”
<pinheadmz> And for me, now that #34905 was merged, next PR is #34772 which currently has 2 ACKs. Then I can rebase #32061 (removing the first 7 commits) and address the feedback there from hodlinator and vasild.
<pinheadmz> and thats all for us !
<cfields> 🚀
<dzxzg> Very cool

<abubakarsadiq> #topic QML GUI WG Update (johnny9dev)
<johnny9dev> focused on external signer support this week. I have configuration and wallet creation and working through getting signing setup in the send flow.
<johnny9dev> epicleafies: any status?
<epicleafies> was out of town, planning on working on another uri issue and fixing up previous PRs
<johnny9dev> thanks, that is all

<abubakarsadiq> #topic Kernel WG Update (sedited)
<cfields> I believe he’s still away
<abubakarsadiq> sedited is not here, but I pushed #35000, to add unit + fuzz test for block validity, motivation and other details are in description.
<abubakarsadiq> That’s it from me. I don’t think there is any kernel-related update.

<abubakarsadiq> #topic Benchmarking WG Update (l0rinc, andrewtoth)
<l0rinc> #34208 was merged, from now on we can make a few benchmarks more realistic by excluding the expensive setup times from the measurements.
<l0rinc> A follow-up was pushed to #35025 and #32554 was rebased.
<l0rinc> #34124 was also rebased after the change, it’s ready for review again.
<l0rinc> That’s it from me.
<abubakarsadiq> Nice
<andrewtoth_> no update from me

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