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

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

A BIPs Update

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

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP451: Dust UTXO Disposal Protocol

Authors: bubb1es, haris

Assigned On: Apr 28th, 2026

Layer: Applications

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

Other News from the Bitcoin World

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

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

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

Merged PR’s

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

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

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

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

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

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

• validation: fetch block inputs on parallel threads by andrewtoth

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

IRC meeting notes

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

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

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

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

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

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

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

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

Releases

• No releases this week

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

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

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

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP391: Binary Output Descriptors

Authors: SeedHammer

Published On: Apr 23rd 2026

Layer: Applications

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

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP323: 24 nVersion bits for general purpose use

Authors: Matt Corallo

Assigned On: Apr 22nd, 2026

Layer: Applications

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

Other News from the Bitcoin World

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

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

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

Merged PR’s

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

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

  Further ideas, not considered in this PR:

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

  • Change CChain internals to store references instead of pointers

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

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

• test: Clean shutdown in Socks5Server by optout21

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

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

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

  There are a few upsides to this approach.

  • Network activity does not have to be suspended

  • Forks can not interfere with the rollback

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

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

• validation: fetch block inputs on parallel threads by andrewtoth

  Problem

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

  Solution

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

IRC meeting notes

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

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

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

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

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

Releases

• 31.0 Release

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

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

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

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

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

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP361: Post Quantum Migration and Legacy Signature Sunset

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

Published On: Apr 14th, 2026

Layer: Consensus (soft fork)

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

Other News from the Bitcoin World

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

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

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.

#bitcoin #lightning #interview #bitcoinconference #cryptocurrency #gossip #gossipnetwork

Catch JHB and other hackers at one of our upcoming bitcoin developer conferences @btcplusplus

Website: https://btcpp.dev/

X: https: https://x.com/btcplusplus

NOSTR

#btcplusplus #devconf #bitcoineducation #bitcoinconf #bitcoindev #bitcoinconference #bitcoin #cypherpunks

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

Highlights from the bitcoin developer ecosystem

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition. I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:

• PR4297 in rust-lightning is implementing BOLT12 payer proofs.

  • During the biweekly update, on Monday 30th, LDK contributors discussed updates to various open PRs. In particular, they discussed PR4297 which is proposing a draft implementation for BOLT12 payer proofs.

  • BOLT12 payer proofs, proposed in PR1295 of the BOLTs specifications repository, are a way to prove that a BOLT12 invoice has been paid by demonstrating possession of the payment preimage, a valid signature over a merkle root, and the payer’s signatures.

  • The declared goal of the PR is to get early feedback on the design to validate the proposed APIs before the specification is finalized.

• v0.16.0 of CDK was released last week, bringing new powerful features to the Cashu implementation.

  • During the weekly update, on Wednesday 1st, CDK developers discussed the recent release of v0.16.0, which introduces new powerful features. The new version had been published the previous day, on Tuesday 31st.

  • The new version is now up-to-date with the latest Cashu specifications. In particular, it introduces Pay-To-Blinded Key (P2BK), defined in NUT-28, which adds a layer of privacy over Pay-To-Public-Key (P2PK), it implements batch minting, defined in NUT-29, to mint multiple quotes in one single batched operation.

  • The release also brings BIP321, a Universal Resource Identifier (URI) scheme for Bitcoin payments, encoding multiple types of Bitcoin payments.

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

• SHRIMPS: Jonas Nick from Blockstream Research posted to Delving Bitcoin about a new post-quantum signature scheme, SHRIMPS. Built on top of SHRINCS, their latest hash-based signature allows users to load a static seed backup in multiple signing devices to maintain a signature size of around 2.5KB, tackling one of the drawbacks of the previous scheme. Keep an eye out, a deep dive on post-quantum signatures is coming soon!

• Bark coming to mainnet: On Sunday 5th, Second announced the release of v0.1.0 of Bark, their implementation of the Ark protocol, dropping the beta tag. According to the company, the launch on mainnet is coming soon.

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.

• ci: add FreeBSD Clang cross job by fanquake
  This is an alternative to another PR, which tried to add a native FreeBSD job but had issues with permissions and caching.
  
  Overall, this change adds a new CI job adding a job named FreeBSD Cross. What Bitcoin Core gains from this change is more coverage across another type of system. That system is FreeBSD Cross.
  

• bitcoin-cli: Add -ipcconnect option by ryanofsky
  This change was motivated by a comment by Sipa that suggested to allow the bitcoin-cli to connect to the node via IPC instead of TCP. This can be used if ENABLE_IPC is enabled and the node has been started with -ipcbind.
  
  Adding this feature gives more flexibility for users of the bitcoin-cli because now they have more options on how they want to connect to their node.
  
  In addition to this change, now bitcoin-cli prefers IPC over HTTP by default.
  

• index: handle case where pindex_prev equals chain tip in NextSyncBlock() by HowHsu
  This change is a minimal improvement on when we return if the previous block tip is null. One thing I noticed in this change is that there was significant conversation for something that is mostly a refactor/code cleanup. While it is not completely a refactor and has a change to return early if pindex_prev == chain.Tip() in the NextSyncBlock function.
  
  There was just some discussion around whether new tests should be added. Ultimately, there were no new tests added.

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.

• cli: Return more helpful authentication errors by hodlinator

  Increases precision of error messages to help the user correct authentication issues.

  This adds a few useful responses
  

  Failed to read cookie file and no rpcpassword was specified.

  Cookie file was disabled via -norpccookiefile and no rpcpassword was specified.

  Cookie file credentials were invalid and no rpcpassword was specified.

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)
<cfields> No update this week. Should have an incoming pr or two in the next few days for a LocalAddressManager.

<abubakarsadiq> #topic Silent Payments WG Update (Novo__, theStack)
<theStack> no update, mostly awaiting review for the silentpayments module PR https://github.com/bitcoin-core/secp256k1/pull/1765

<abubakarsadiq> #topic QML GUI WG Update (johnny9dev)
<johnny9dev> For qml. This last week i added a gui functional test to my legacy wallet migration flow PR and undrafted the PR. This test will use v28 to create a wallet to migrate. I also completed the Fee selection controls for picking a couple of standard targets or entering a custom fee.
<johnny9dev> epicleafies: can you give status?
<abubakarsadiq> theStack: I saw some update on the mailing list as well?
<johnny9dev> Not sure epicleafies is here but he has a bunch of PRs up for the qml. Some of the ones he worked on the last week was the desktop tray and the BIP321 integrations
<epicleafies> yeah, this past week I've created a pr for adding bip21 uri support and updating previous PRs
<johnny9dev> thanks
<theStack> abubakarsadiq: ah yes, that was a demonstration of the worst-case scanning attack on signet. wallets can use this to see if/how they are affected
<johnny9dev> I think with all of what we have in PR now we're down to 6 remaining tasks out of the original 21 list to get to feature parity
<johnny9dev> Address Book and Contacts Management, Receive Request History and BIP21 sharing, Replace-by-fee Speedup and Cancel, PSBT Import/Export, Sign/Verify message flow, External Signer/HWI
<johnny9dev> that is all for this week

<abubakarsadiq> #topic Libevent removal (pinheadmz, fjahr)
<fjahr> Update from pinheadmz (not here today): This week I addressed review on #34905 and #34772 both have concept ACK and stale ACK so should be the home stretch then I’ll rebase the big daddy #32061 on those and incorporate new feedback there. Coverage results of libfuzzer and fuzzamoto are posted in the big PR, no crashes! I started on integration tests, first with lnd -- but there are already several non-http integration
16:12:37 <fjahr> issues between LND and core, from the buried taproot deployment and mempool policy changes in 29.1 (their CI is pinned at 29.0 today).
16:12:51 <fjahr> Update from me: Addressed some more feedback on #34158 but it also seems be getting close
16:13:01 <fjahr> That’s it from me

Releases

• None 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

Highlights from the bitcoin developer ecosystem...

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition. I spent 10+ hours in open-source developer calls in the Bitcoin ecosystem last week. Here is what caught my eye:

• v0.3.1 of Stratum V2 Applications was released to address some issues in v0.3.0.

  • During the weekly call, on Tuesday 24th, Stratum V2 contributors discussed the need to publish a patch version for v0.3.0 of the Applications library. The patch was later released on Friday 27th.

  • The main fix pushed is related to a race condition on chain tip updates in the Job Declarator message flow. Specifically, the error seems linked to the bitcoin_core_sv2 crate design, which needs many workarounds to work correctly with Bitcoin Core.

  • According to the developers, these workarounds could be dropped and the crate design simplified as soon as draft PR34020 in Bitcoin Core gets merged and released, which is expected to happen in v32.

• PR348 in the NUT repository adds BIP321 to the Cashu protocol specifications.

  • During the monthly community call, on Thursday 26th, Cashu developers discussed the recently-merged PR348, which adds BIP321 to the NUT specifications.

  • This PR modifies NUT26, which defines Bech32m encoding for payment requests. In particular, it adds a section specifying how to create BIP321 payment requests. This BIP introduces a Universal Resource Identifier (URI) scheme for Bitcoin payments, encoding multiple types of Bitcoin payments, such as on-chain, LN, or Cashu, in a single, unified QR code.

  • What is cool about the tech: BIP321 allows to improve the UX of Bitcoin payments, providing a layer-agnostic method for receiving Bitcoin.

A BIPs Update

In the last days there was some movement in the BIP repository. Specifically, 2 new BIPs have been assigned a number by BIP maintainer Murchandamus. These BIPs belong to the so-called “Great Script Restoration” (or “Grand Script Renaissance” as AJ Towns framed it), a proposal that was first presented during Bitcoin++ Austin in 2024.

Published BIPs

A list of recently published BIPs

No new BIPs were published during the last week.

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP440: Varops Budget For Script Runtime Constraint

Authors: Rusty Russel, Julian Moik

Assigned On: March 25th, 2026

Layer: Consensus (Soft Fork)

PR2118 introduces BIP440, which defines a varops budget, a generalization of the sigops budget introduced in BIP342 for non-signature operations. This BIP aims to provide an explicit cost framework that uses the length of the stack inputs to limit the amount of operations allowed in a script to ensure rapid evaluation.

BIP441: Restoration of disabled script (Tapleaf 0xC2)

Authors: Rusty Russel, Julian Moik

Assigned On: March 25th, 2026

Layer: Consensus (Soft Fork)

PR2118 introduces BIP441, which proposes a new tapleaf version 0xC2 which restores Bitcoin scripts to its pre-v0.3.1 capabilities, building on BIP440 varops budget to prevent excessive computational time. This BIP aims to reenable all the opcodes that were disabled in Bitcoin v0.3.1 due to CVE-2010-5137.

Other News from the Bitcoin World

• Wallet fingerprinting can damage Payjoin pivacy: PDK maintainer Armin Sabouri published an interesting article discussing how choices made by individual wallets implementations can jeopardize the privacy gains from using Payjoin. These choices, such as coin selection algorithm, fee estimation, and signature encoding, can create well-defined patterns in Bitcoin transactions, known as wallet fingerprints, that can be used by chain analysis firms to improve their heuristics and decrease users’ privacy.

• Numo + BIP321: In its effort to improve the UX for Bitcoin payments, the latest release of Numo, the tap-2-pay enabled Cashu point-of-sale, integrates BIP321, recently added in the NUT specifications. Merchants can now provide a single, unified QR code to their customers.

• Stratum V2 call-to-action: Recently, Stratum V2 project manager Pavlenex launched a call-to-action to form a small team to test a new feature developers have been working on recently. If you have a miner, reach out to Pavlenex.

This week, Sjors Provoost has his PR merged, which deleted the DEPLOYMENT_TAPROOT from consensus.vDeployments. This might sound scary, but this is just some cleanup work done now that, since v24.0, taproot is enforced for all blocks.

Read below for more information!

Merged PR’s

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

• rpc, logging: add backgroundvalidation to getblockchaininfo by polespinasa

  Pol Espinasa opened this PR last year in August to update the getblockchaininfo RPC. This is because, before this change, it would return verificationprogress=1 and initialblockdownload=false even if there was background validation.
  
  What Espinasa’s change does is add information about background validation to the getblockchaininfo RPC is similar to how the validationprogress RPC does.

• Policy: Report debug message why inputs are non standard by ismaelsadeeq
  This PR is the second attempt at making this work. Abubakar Sadiq Ismail took a second attempt at a PR that was closed in 2018 that when a transaction goes through its validation checks and fails the PreChecks due to it being non-standard now returns an invalid validation state and a debug error message.
  
  Before this the debug error message would not specify why the inputs were considered non-standard. This means it would be difficult for a developer or user to understand why their transaction was marked as non-standard and failed.

• Remove Taproot BIP 9 deployment by Sjors
  As mentioned earlier, it has been a while since we have included the taproot upgrade to Bitcoin Core. Since v24.0, all blocks enforce taproot to be exact. Sjors Provoost figured that it made sense to drop any code that might be related to the delployment of Taproot since we can safely assume that it has been successfully deployed and no longer needed.
  
  This change removes DEPLOYMENT_TAPROOT from consensus.vDeployments. The logic for removing and not marking it at burried is because the activation height has been removed from the codebase, unlike DEPLOYMENT_SEGWIT of which the height is still relied on.

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.

• net: fix premature stale flagging of unpicked private broadcast txs by Mccalabrese

  Motivation
  Currently, freshly added transactions in private_broadcast are almost immediately flagged and logged as stale by the resend-stale job.
  

  The Bug
  m_transactions maps a transaction to a std::vector<SendStatus>. When try_emplace adds a new transaction, this vector is empty. When GetStale() runs, DerivePriority() evaluates the empty vector and returns a default Priority struct where last_confirmed evaluates to the Unix Epoch (Jan 1, 1970). The stale checker sees a 50-year-old timestamp and flags it on the next resend-stale cycle.
  

  The Fix
  Rather than modifying the transient Priority struct or creating a “Zombie Transaction” edge case by ignoring transactions with 0 picks, this PR modifies the state container:

  • Wraps the SendStatus vector in a new TxSendStatus struct inside private_broadcast.h.

  • TxSendStatus automatically captures time_added upon emplace.

  • GetStale() now checks p.num_confirmed == 0 to measure age against time_added using a new 5-minute INITIAL_STALE_DURATION grace period, falling back to last_confirmed and the standard 1-minute STALE_DURATION once network interaction begins.

IRC meeting notes

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

<fjahr> #topic Kernel WG Update (sedited)
<sedited> no updates from me this week, and am going afk for the next three weeks.

<fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
<andrewtoth_> nothing from me this week

<fjahr> #topic Net Split WG Update (cfields)
<cfields> Finally some progress! I have a branch which cleans up all of the local address handling which is currently just a bunch of global functions used all over the place (GetLocal(), AddLocal(), etc). Ultimately they are all used for GetLocalAddrForPeer().
<cfields> My first step has been just to remove the dependencies on CNode and move all of the functions into a new LocalAddressManager. For now, it’s instantiated as a static global. Functionally there’s no change but it’s now 10x easier to understand how it all works and test. The next step will be to actually instantiate it and store it in node.
<cfields> While working on it, I discovered a few nasty leaks that should potentially be fixed. I’m working on testing and documenting so that I can propose some fixes and behavioral changes.
<cfields> Both streams (refactor and fixes) could potentially happen in parallel, but imo it’s _much_ easier to understand what’s going on and test after refactoring to a sane manager class. So I’ll probably PR that work first.
<fjahr> Cool, anything else on net split?
<cfields> Nope, that’s it for now.

<fjahr> #topic QML GUI WG Update (johnny9dev)
<johnny9dev> The decoupling of qml from the qt widgets gui is done. A part of that also included the last piece of automated test tools for the project. Specifically gmock for mocking the wallet and node interfaces
<johnny9dev> so the project now has comprehensive testing. unittests, qml tests, and end to end gui tests
<johnny9dev> Feature wise wallet import/restore was merged and a pr for wallet migration is up and this week i did all of the features for fee setting. Those will be PR’d the next couple of days
<johnny9dev> epicleafies has a bunch of PRs lingering for features he completed so my top priority is to finish reviews of all of those now that the test frameworks are settled and they all no longer have conflicts
<johnny9dev> epicleafies: can you share your status?
<fanquake> gmock as in Google Test / Mock?
<epicleafies> Yeah, this past week I’ve created PRs for adding desktop tray icon/functionality and the rpc console page
<johnny9dev> yeah thats what I know for mocking. open to swapping it out later but I’ve always liked it.
<johnny9dev> only using gmock, nothing from gtest
<fjahr> seems like that’s it for gui?
<johnny9dev> yeah thats it. we’ll be PRing a few more features and then i will likely do another assestment to see what the remaining gap is and I will share that

<fjahr> #topic Libevent removal (pinheadmz, fjahr)
<pinheadmz> #32061 has been rebased following great reviews on code style and deeper http protocol. I am running fuzzers on the branch this week and will re-run my integration tests with lnd, electrs, etc as well. The first 7 commits add tests and utilities, and are split off in to two small PRs which are in review, and I’m pushing updates today: #34772 and #34905
<fjahr> From my side, I am still getting some good on the torcontrol PR (#34158) and respond to that as quickly as possible. I think it looks to be in pretty good shape by now.
<fjahr> *good review
<fjahr> That concludes the WGs unless I missed someone

<fjahr> #topic asmap file format & tooling (sipa)

There was quite a bit of conversation on this topic, read the full meeting in minutes to get the full scoop

Releases

• https://github.com/bitcoin/bitcoin/tree/v31.0rc1

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

Ignacio started his career working for Buda.com, where he was introduced to bitcoin maximalism. It was at Santiago BitDevs where he learned about the B4OS program by Librería de Satoshi. He earned a grant contributing to LDNK, under the guidance of a fellow Chilean mentor.