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

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

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:

• v1.8.0 of Stratum V2 protocol libraries and v0.3.0 of Stratum V2 applications have been released.

  • During the weekly call, on Tuesday 17th, 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 Thursday 19th.

  • v1.8.0 mainly focused on improving the protocol reliability. A lot of effort was directed towards creating framing benchmarks for the different protocol crates to validate and improve their performances. Fuzz testing has also been expanded. Finally, the channels_sv2 crate has been improved by fixing several issues related to share-accounting.

  • v0.3.0 also improves reliability of the different applications. The Job Declarator Server (JDS) has undergone a major refactoring, the translator proxy and the Job Declarator Client (JDC) have been hardened, more integration tests have been developed, and new monitoring APIs are now available.

• PR1735 in CDK is implementing the new NUT-XX for efficient wallet recovery.

  • During the weekly call, on Wednesday 18th, CDK developers discussed PR1735 which is implementing the new specifications for efficient wallet recovery.

  • As of today, recovering funds through a backup requires the mint to take into account all possible transaction ever made by a wallet. In fact, a wallet has to keep track of an index to generate new tokens every time funds are sent or received. Thus, a mint will have to check every single transaction up to the latest index, T.

  • The new proposal addresses this limitation with a two-step process. First of all, the wallet has to make sure that all unspent proofs remain in a certain index range d . Thus, if a index is lower that T-d , the wallet automatically triggers a consolidation swap to move the unspent proof to a new index. Then, during recovery the mint leverages binary search to find the correct T for the wallet, allowing it to find the correct index in O(log(N)) queries. Finally, the mint has only to check the latest d indices to recover all funds.

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP448: A Taproot-native (re)bindable transaction proposal

Authors: Gregory Sanders, Antoine Poinsot, Steven Roose

Published On: March 17th, 2026

Layer: Consensus (Soft Fork)

BIP448 proposes to deploy three new opcodes bundled together, namely OP_TEMPLATEHASH (proposed in BIP446, which is part of the same PR), OP_CHECKSIGFROMSTACK, and OP_INTERNALKEY. According to the authors, the proposed opcodes are simple and well-understood and could provide powerful capabilities to improve second layer protocols while minimizing the risk of incurring in unintended behavior.

BIP446: OP_TEMPLATEHASH

Authors: Gregory Sanders, Antoine Poinsot, Steven Roose

Published On: March 17th, 2026

Layer: Consensus

BIP446 proposes a soft fork to activate a new operator for Tapscript, called OP_TEMPLATEHASH. The new opcode could be used to commit to the transaction spending an output, a capability that could replace the need for pre-signed transactions in second-layer protocols. This BIP is being proposed by Core contributors, Gregory Sanders and Antoine Poinsot, and Second CEO Steven Roose.

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP393: Output Script Descriptor Annotations

Authors: Craig Raw

Assigned On: March 17th, 2026

Layer: Applications

PR2099 introduces BIP393, which proposes a new way to add metadata to descriptors to make silent payment scanning more efficient. This metadata would be provided in the form of annotations, expressed as key/value pairs, appended directly to the descriptor string using URL-like query delimiters: SCRIPT?key=value&key=value#CHECKSUM . This proposal by the creator of Sparrow Wallet Craig Raw, also defines three keys for improving scanning efficiency, namely the block height at which the wallet first received funds, bh , the number of unused addresses to derive before stopping scanning, gl , and the maximum label index to scan for, ml .

Other News from the Bitcoin World

• Splicing Lightning: BOLTs contributor t-bast announced on X that PR1160 for Splicing had finally been merged in the BOLTs repository. Splicing allows spending the current funding transaction and replace it with a new one to change the capacity of the channel, allowing both peers to add or remove funds to/from their channel balance. Its official merge in the specifications represents a huge milestone for the Lightning Network ecosystem.

• A SHA-256 hash as a valid signature: Robin Linus shared on X his latest project, a SHA-256 hash which is also a valid BIP66 DER-encoded ECDSA signature. He spent $8 and ran ~185 trillion attempts in ~2.3 hours to find a preimage that produces a valid DER-encoded signature when hashed. Linus also shared the repository containing the source code and the explanation behind the work.

• Working on Bitcoin Core: Long time Bitcoin Core PR reviewer Jon Atack highlights his experience working on the project.

Merged PR’s

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

• validation: Explicitly move blocks to validation signals by sedited

  This enforces behaviour that is currently already implicit: The destructor for blocks runs mostly in the scheduler thread. The change should make it a bit clearer what the ownership semantics for these validation signals are.
  

  BlockConnected already takes a reference to a block that is emplaced in connected_blocks. Once connected_blocks is iterated through, it is not reused. Similarly BlockDisconnected currently takes a reference to a block that is discarded after the call to it. Note that this does not give the guarantee that blocks’ lifetimes are extended by other means once they are connected. For example after IBD, the block’s lifetime is extended in net_processing’s m_most_recent_block and ActivateBestChain itself takes a copy of the block’s shared pointer, meaning its caller may delay de-allocation.

• fuzz: wallet: add target for MigrateToDescriptor by brunoerg
  If you’re not familiar with Fuzz Testing, I would read this summary.
  
  This change by Bruno Garcia adds fuzz coverage to the scriptpubkeyman migration. It adds a new fuzz target spkm_migration. Garcia notes that this is only for migrating scriptpubkeyman, not the entire migration process. This is because attempting to fuzz the entire migration process would be much more expensive, and mocking would require significantly more refactoring.
  
  He also notes that this explicitly avoids any encryption stuff because it would make the fuzz target run much slower.

• rpc: Run type check on decodepsbt result by maflcko
  Marco Falke updated RPCResults to type-check when the type may be ELISION, because it is confusing and brittle. The elision should only affect the help output and not the type itself. We also want the type to be the real type, so we can run type checks on it.
  
  Falke also introduced a new print_elision option and uses it in decodedpsbt. Falke also gave instructions in the pull request description to test the failure.

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.

• test: throttle large testmempoolaccept rpcs in p2p_orphan_handling test by rkrux

  Addresses #34731

  Reasons why I don’t believe it is a deadlock issue based on the debug logs and debugger thread backtrace output shared in the issue:

  • The HTTP worker threads (b-http_pool_x) are waiting on the condition variable and not on the mutex that signals that these threads are idle & waiting for work to be assigned to them.

  • The HTTP thread (b-http) is epoll waiting that means it is waiting for a request (or a part of it) to be received.

  • The added logs show that the first few testmempool RPCs were successful and the next one timed out. But the logs don’t show a request for it being logged unlike in the previous ones, hinting that the server never received such a request (or in full) and thus never processed it. Even then the functional test client timed out, which means that it did send it (at least a part of it).

  • The large orphan transactions being sent are each 780KB in size that are sent sequentially by the test. It tries to send 60 of them in a loop amounting to 46MB of data over a single HTTP connection that is reused.

  This PR throttles the RPCs on client side. I’ve not been able to reproduce this intermittent issue and thus I don’t gurantee that this fixes the issue altogether.

  A previous approach in this PR tried to not reuse the HTTP connection for the RPCs in this test instead. But I noticed a CI run where this affected test took around 75mins to complete that led me to move to this approach where the HTTP connection is reused like before but with some throttling.

IRC meeting notes

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

16:02:03 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:02:17 <dergoegge> no update

16:02:28 <fjahr> #topic Kernel WG Update (sedited)
16:02:43 <sedited> aj and cory left some interesting comments on #32317. Haven’t gotten around to work on them yet, but I’d like to encourage others to read them.
16:02:54 <yancy> hi
16:04:03 <sedited> we’ve also had craig raw try out #32427 for faster silent payment scanning: https://github.com/bitcoin/bitcoin/pull/32427#pullrequestreview-3935024360
16:04:25 <sedited> which lead to some interesting discussions on that PR too.
16:04:38 <sedited> that’s all.

16:04:53 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:05:10 <fjahr> l0rinc left an update earlier
16:05:26 <fjahr> https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2026-03-19#1204475;

16:06:03 <fjahr> #topic QML GUI WG Update (johnny9dev)
16:06:35 <johnny9dev> Started PRs for wallet migration flows and wallet import/restore flows. Last PR for decoupling the qml project from the original qt-widgets is up and when those are merged that will be completed
16:07:17 <johnny9dev> We’ve introduced GMock to the project to mock out the wallet and node interfaces for easier unittesting
16:07:46 <johnny9dev> epicleafies: can you add your status?
16:08:06 <epicleafies> I’ve started PRs for adding the desktop tray icon and another for language and units settings.
16:08:44 <johnny9dev> nice
16:09:28 <johnny9dev> i think that is all for now. the PRs are pilling up so we’ll need to clear them soon

16:09:47 <fjahr> #topic Libevent removal (pinheadmz, fjahr)
16:09:51 <fjahr> A new working group just hatched 🐣. There has been quite a bit of development and review lately way to the goal is pretty clear so we thought it would be a good idea to try to give status updates regularly. All the necessary pieces already exist, you can find them all in the tracking issue: #31194.
16:09:59 <pinheadmz> Work continues on #32061 after many great reviews. After next rebase I will close that PR and reopen a fresh PR with the same code, but without a year and 300+ comments. Review has also exposed some new tests I want to add to master, and tweaks to some utilities we already merged last month I now realize are mostly wrong <grimace emoji>. SO stay tuned for three new PRs. Well, one reborn and two little guys.
16:10:19 <fjahr> pinheadmz: we should have synced better :D
16:10:26 <furszy> ACK
16:10:37 <pinheadmz> were doing great bruh
16:11:21 <pinheadmz> thats all
16:11:42 <fjahr> So review focus is on #34772 (new prerequisite to the http server) and #34158
16:12:11 <fjahr> Anything else to discuss?

16:12:35 <fjahr> #topic `MempoolUpdated` ValidationInterface callback (abubakarsadiq)
16:12:45 <abubakarsadiq> Opened #34803, which adds a `MempoolUpdated` ValidationInterface callback emitting before/after fee rate diagram chunks on every mempool update  enabling cluster-aware fee estimation and eliminating redundant block template rebuilds in the mining interface. The change is minimal; most of the diff is tests. Looking forward to feedback.
16:13:13 <abubakarsadiq> That’s all. thanks
16:13:53 <fjahr> Any other topics?

16:13:55 <jurraca> #topic ASmap
16:13:58 <jurraca> i opened #34842 to add asmap attestation scripts to contrib/asmap, wanted to ask if there are opinions for/against putting this in the core repo. The alternative would be putting them in the asmap.sigs repo along with the attestations themselves.
16:15:39 <fjahr> They are currently in the asmap.sigs repo
16:15:53 <fjahr> But these are updated a bit right?
16:15:58 <jurraca> yea

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

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:

• An update on BOLTs specifications.

  • During the monthly call, on Monday 9th, Lightning developers discussed the latest changes to the BOLTs specifications. In particular, three PRs were merged during the call after the different implementations ACKed the proposed modifications.

  • Specifically, PR1316 adds an explicit requirement for offer_amount to be greater than 0 in BOLT12, PR1312 adds a test vector to fix inconsistencies across Lightning implementation in bech32 padding by rejecting invalid BOLT12 offers according to BIP173 rules, and PR1298 adds another test vector for non-canonical signatures in BOLT11.

  • The next steps will be focused on merging two important PRs , namely PR1160, which will officially include channel splicing in the specifications, and PR995, which will enable simple taproot channels.

A BIPs Update

In the last days there was some movement in the BIP repository. Specifically, 3 new BIPs have been published, BIP128, BIP392, and BIP442, and two new BIPs have been assigned a number by BIP maintainer Murchandamus.

Published BIPs

A list of recently published BIPs

BIP442: OP_PAIRCOMMIT

Authors: Moonsettler, Brandon Black

Publishing Date: March 3rd, 2026

Layer: Consensus (Soft Fork)

BIP442 proposes a new tapscript opcode called OP_PAIRCOMMIT. The new operation would allow to add native support to commit to multiple items together. Basically, during execution the opcode would pop the two top elements from the stack, compute their hash, and push the resulting 32-byte hash back onto the stack. The idea behind the proposal it to facilitate more expressive contracts and improve data availability in Bitcoin scripts.

BIP392: Silent Payments Output Script Descriptor

Authors: Craig Raw

Publishing Date: March 5th, 2026

Layer: Applications

BIP392 specifies a new output script descriptor for silent payments, sp() . The descriptor, proposed by the creator of Sparrow Wallet, provides a standardized way to represent silent payment outputs within the output descriptor framework, enabling wallet interoperability and recovery using existing descriptor-based infrastructure. Iin particular, the new descriptor takes silent payment key material and describes P2TR outputs when combined with the sender’s input public key, as defined in BIP352. Checkout this presentation from Nifty to know more about this!

BIP128: Timelock-Recovery Storage Format

Authors: Oren Z

Publishing Date: February 27th, 2026

Layer: Applications

BIP128 specifies a standard format for storing timelock-recovery plans. The goal of this proposal is to allow users to simply importing these type of plans into services that provide automatic monitoring and execution.

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP449: OP_TWEAKADD

Authors: Jeremy Rubin

Assigned Date: March 5th, 2026

Layer: Consensus (Soft Fork)

PR1944 introduces BIP449, which 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 evolutions without full signature verification, spending conditions, and covenant-like constructions.

BIP448: A Taproot-native (re)bindable transaction proposal

Authors: Gregory Sanders, Antoine Poinsot, Steven Roose

Assigned Date: March 12th, 2026

Layer: Consensus (Soft Fork)

PR1974 introduces BIP448, which proposes to deploy three new opcodes bundled together, namely OP_TEMPLATEHASH (proposed in BIP446, which is part of the same PR), OP_CHECKSIGFROMSTACK, and OP_INTERNALKEY. According to the authors, the proposed opcodes are simple and well-understood and could provide powerful capabilities to improve second layer protocols while minimizing the risk of incurring in unintended behavior.

Other News from the Bitcoin World

• Arkade Assets are live on mainnet: Arkade announced on X that their Bitcoin-native assets solution, Arkade Assets, was finally live on mainnet. Arkade Assets allows anyone to issue assets on the Bitcoin chain by embedding data directly into transactions using an OP_RETURN output, without requiring any changes to the Bitcoin protocol.

• BIP54 is gaining traction: Two weeks ago, we covered the first BIP54 compatible block being mined. Last week, Mara, one of the largest active mining pool, joined the BIP54 movement by mining its first compatible block, at height 940548. It is possible to recognize a BIP54 compatible block by looking at the coinbase transaction nLocktime field, which must be set to blockHeight - 1.

• Bitcoin knowledge for autonomous agents: Spiral grantee Elias Roher created a new knowledge base for Bitcoin and Lightning development ecosystem. This project was specifically designed to be queried by AI agents through Model Context Protocol (MCP) servers for fast and precise lookups.

• Preventing Denial-Of-Service: Bruno Garcia, Director of Engineering at Vinteum, announced on X that he was able to find and correct two denial-of-service (DOS) bugs in Floresta, a lightweight and embeddable Bitcoin client. The first vulnerability was linked to a missing size check that could result a large memory allocation with consequent usage of all the available memory. The other bug was related to the rate-limiting mechanism implemented in Floresta, which should check whether a peer is sending more than 10 messaging per second. However, the counter was never incremented, effectively making the mechanism futile.

Merged PR’s

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

• cli: rework -addrinfo cli to use addresses which aren’t filtered for quality/recency by stratospher
  This change has been in the works since 2023 and has finally been merged. If you have not been following it, here is a quick summary of what it changes.
  
  This pull request updates the CLI -addrinfo to give back ALL known addresses instead of a subset. From version v22.0 to v30.0, the set that was given back was filtered by recency and quality. This has now changed because it does not match the logic used when selecting a peer, so this updates it to match.
  
  If you are using an older Bitcoin node version, you will also need to use an older bitcoin-cli to succesfully use this method.

• rpc: allow writing UTXO set to a named pipe by theStack
  Have you ever used the dumptxoutset for say AssumeUTXO?
  
  This change makes it so that you can call the dumptxoutset RPC and then dump it onto a named pipe. This allows the dumped UTXO set to be consumed by another process.
  
  TheStack makes use of this functionality in utxo-to-sqlite.py to directly convert the UTXO set into a sqlite file. I would say to myself that is pretty cool.
  
  He also gives an example of how it would be used in the full PR.

• threadpool: add ranged Submit overload by andrewtoth
  Andrew Toth was motivated to make this change when he had noticed that ThreadPool::Submit was not that efficient when multiple tasks had to be submitted at the same time.
  
  The reason was that the Submit method must take a lock for each task. The way Andrew resolved this issue was by taking a single lock for the batch of tasks submitted. This significantly sped up ThreadPool::Submit.

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.

• logging: rewrite macros to add ratelimit option, avoid unused strprintf, clarify confusing errors by ryanofsky

  Rewrite log macros to fix a number of issues: lack of control over rate limiting, unnecessary strprintf calls during fuzzing, and confusing error messages when macros are called with the wrong arguments.
  

  This PR is a refactoring and shouldn’t change externally visible behavior. Changes are described in detail in commit messages. There are also some internal improvements making previously implicit behaviors (evaluating unused format arguments, not outputting categories at certain log levels) explicit and better enforced.
  

  Some changes here were originally part of #29256, but they should make sense on their own and simplify both PRs.

IRC meeting notes

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

16:01:53 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:02:25 <dergoegge> nothing from my side

16:02:55 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:03:12 <l0rinc> nothing urgent from my side
16:03:29 <andrewtoth_> #34576 was merged. #31132 has been rebased with all split out PRs completed. Thanks everyone for your reviews and benchmarks!
16:03:33 <corebot> andrewtoth_: Error: That URL appears to have no HTML title within the first 32KB.
16:03:35 <corebot> andrewtoth_: Error: That URL appears to have no HTML title within the first 32KB.
16:03:42 <dzxzg2> hi
16:03:56 <andrewtoth_> I’m considering reopening #31132 as a fresh PR since there are over 500 comments and many are no longer relevant.
16:03:57 <corebot> andrewtoth_: Error: That URL appears to have no HTML title within the first 32KB.
16:04:07 <andrewtoth_> That’s it from me.
16:04:29 <andrewtoth_> What’s wrong with corebot?
16:04:37 <_aj_> github rate limits probably?
16:04:44 <achow101> It’s not having a good day I guess
16:05:11 <_aj_> (at least i’m constantly getting rate limits when not logged in, for no apparent reason)
16:05:17 <fjahr> depressed from all the ai slop
16:05:20 <fjahr> johnny9dev: you wanted yours reactivated, right? Please edit the WGs wiki page, thanks!

16:05:27 <fjahr> #topic QML GUI WG Update (johnny9dev)
16:05:31 <johnny9dev> yes
16:05:36 <johnny9dev> For gui-qml I have been focused on cleaning up any dependency to the qt source code. I’ve also been working on the test coverage and automation frameworks. I am just about done with both and will be closing out the related issues on that. I will then begin PRing chunks of features next week along with Luke (epicleafies). The target features are all listed in the project’s Issues. I also plan on spending time to learn Figma Make
16:05:36 <johnny9dev> and Figma’s MCP server. I’ve seen some real world cases of it being very effective the last two weeks and need to explore this for gui-qml.
16:05:54 <johnny9dev> For gui, dergoegge asked if the test bridge would work for qt so I some time porting over the test automation bridge. It’s still a bit rough and needs some more validation/review but I started the draft on bitcoin-core/gui#933. Interested in what people think about this approach. Flakiness can be a problem initially with end to end tests so effort will need to be done to make sure it’s all solid before really moving forward with
16:05:54 <johnny9dev> something like this. Animations, process initializing, and timings can be tricky but this shouldn’t be much worse than what y’all already deal with for the bitcoind functional tests.
16:05:55 <corebot> johnny9dev: Error: That URL appears to have no HTML title within the first 32KB.
16:06:00 <kanzure> does figma export to qml?
16:06:14 <johnny9dev> you can use the mcp bridge to help translate figma to code
16:06:20 <dergoegge> johnny9dev: cool, I’ll have a look at that
16:06:59 <johnny9dev> epicleafies has been helping with qml also
16:07:25 <johnny9dev> epicleafies: can you give status?
16:08:04 <epicleafies> Yeah, I’ve finished the debug log page and am working on the proxy settings to persist
16:08:59 <johnny9dev> he also fully completed peers ban/disconnect including an end to end automated gui test with it
16:09:22 <johnny9dev> i think that will probably be the most complicated one too
16:09:26 <johnny9dev> with multiple nodes
16:10:14 <johnny9dev> i think that is all
16:11:19 <fjahr> I’m not seeing any of the other WG chairs.

16:11:25 <fjahr> #proposedmeetingtopic logging system (_aj_)
16:11:25 <corebot> fjahr: Unknown command: #proposedmeetingtopic
16:11:30 <fjahr> sorry
16:11:33 <_aj_> There’s about a dozen open PRs/issues about changing the
16:11:33 <_aj_> logging API, many of which have been open for almost two years now. Here’s a table:

16:11:25 <fjahr> #proposedmeetingtopic logging system (_aj_)
16:11:25 <corebot> fjahr: Unknown command: #proposedmeetingtopic
16:11:30 <fjahr> sorry
16:11:33 <_aj_> There's about a dozen open PRs/issues about changing the
16:11:33 <_aj_> logging API, many of which have been open for almost two years now. Here's a table: https://gist.github.com/ajtowns /ff6247953437270ce81998bc0f7d6739
Many of these changes seem to me to make things substantially worse for working on bitcoin node software, and at this point it feels like a denial of service attack: “oh, you disagreed with this PR? well, we’ll keep that one open as a sword of
16:11:33 <_aj_> damocles, but also, how about this slightly different PR with slightly different motivations?” which just leaves me giving what feel like endless “Concept NACKs” and getting more frustrated. There are still a couple of followups to #28318 that I’d like to get in (namely #34038, and once that’s done, switching the map of categories to an atomic bitfield), so I’d rather keep being somewhat involved,
16:11:33 <_aj_> but this is pretty exhausting. So I’d really like it if folks who are a bit more dispassionate on the issue could get involved and express opinions on whether any of the proposed changes are actually valuable/desired, and ideally for the number of open proposals to get trimmed down a lot.
16:11:35 <corebot> _aj_: Error: That URL appears to have no HTML title within the first 32KB.
16:11:36 <fjahr> #topic logging system
16:11:37 <corebot> _aj_: Error: That URL appears to have no HTML title within the first 32KB.
16:12:01 <achow101> (will debug the bot after the meeting)
16:12:26 <_aj_> (fin)

16:12:54 <sipa> #proposedmeetingtopic I saw release notes editing for 31.0 moved to the wiki (https://github.com/bitcoin-core/bitcoin-devwiki/wiki/31.0-Release-Notes-Draft), it’s probably good for everyone to have a look over that and add things that users ought to see
16:12:54 <corebot> sipa: Unknown command: #proposedmeetingtopic
16:13:09 <sipa> (not really a topic, just wanted to mention)
16:13:19 <_aj_> (did anyone actually announce the branch off happened btw?)
16:13:48 <sipa> Day changed to 12 Mar 2026
16:13:48 <sipa> 01:56:13 < bitcoin-git> [bitcoin] achow101 pushed 5 commits to 31.x: https://github.com/bitcoin/bitcoin/compare/b97abdcdf139...d3737769caac
16:14:40 <achow101> _aj_: how many major opinions on logging direction are there? 2?
16:15:03 <fanquake> 3 I think
16:15:08 <fjahr> there seem to be three PR authors
16:15:13 <fanquake> depending on the part of the codebase
16:15:24 <fjahr> (of currently active prs)
16:15:52 <dzxzg2> if it’s possible to express succinctly, what are the different goals / usecases / motivations for changing the interface?
16:16:43 <_aj_> i think there’s a few different ones about the kernel (if you have multiple validation objects running, can their logs be separated; if you have multiple loggers and one validation state, can they get different info); there’s a desire to pass different amounts of state to the Log*() functions (some or all of wallet name, category, level), and there’s sometimes a desire to have all messages have a
16:16:43 <_aj_> category (LogInfo(NET, “connected to new outbound”))
16:19:10 <fanquake> Rough count but I think there’s about ~15 different logging related refactors / PRs open at the moment
16:20:21 <dergoegge> Some of the kernel related logging questions seem worthwhile solving but idk about the naming and calling conventions (that just seems like an endless pit to pour time into)
16:21:16 <_aj_> the kernel stuff impacts the calling convention -- if you want logging from CheckBlock to go two different places, you have to pass in the two different logging systems into the LogDebug(..) call, eg
16:21:40 <sipa> what does “two different places” mean?
16:22:19 <_aj_> if you’re running two different ChainstateManager’s in the same process, and want to log the work they’re doing / the failures they have independently
16:23:36 <l0rinc> are these logging change suggestions fundamentally mutually exclusive?
16:23:40 <sipa> i’m confused about why that would be the case, or why the code in question would know about it at all
16:23:45 <sipa> so i’ll need to look at the PRs
16:23:53 <dzxzg2> l0rinc: +1
16:24:02 <_aj_> #34062 is possibly a good start
16:24:04 <corebot> https://github.com/bitcoin/bitcoin/issues/34062 | RFC: separate kernel logging infrastructure · Issue #34062 · bitcoin/bitcoin · GitHub
16:24:11 <_aj_> welcome back corebot
16:24:15 <abubakarsadiq> hi
16:24:27 <l0rinc> is this related to different wallets and processes logging to different output files?
16:25:32 <sedited> fwiw I think this is a nice to have, but the discussions and time sunk into logging as opposed to making things actually more useful seems skewed. I’d be happy with a simple albeit imperfect solution for now.
16:25:44 <sedited> l0rinc I think that is orthogonal
16:26:40 <ryanofsky> yeah i think we can easily make progress on this stuff, by just focusing on logging prs that are noncontroversial
16:28:13 <_aj_> ryanofsky: closing the near-alternatives, and just keeping the “best” of them open would be a win in my view (best==your opinion after taking feedback into account, not necessarily least-controversial/most-likely-to-be-acceptable; imo anyway)
16:29:10 <dzxzg2> https://en.wikipedia.org/wiki/Wikipedia:Content_forks#Pages_of_the_same_type_on_the_same_subject
16:30:20 <l0rinc> It seems to me the logging problems aren’t obvious to most of us, it seems to be mostly working already - can we start with listing the exact problems?
16:30:21 <fjahr> Maybe ask for review here again when there is a clear point were more feedback is needed. Hard to motivate yourself to go through the full list and find that for yourself, IMO.
16:31:43 <ryanofsky> i guess my general feeling is it is not good to spend time have meta-debates about what code should be reviewed and generally peole should just review things they are interested, and maintain prs they are interested in maintaining
16:32:25 <ryanofsky> if some progress is being blocked, but i am not aware of that happening
16:32:47 <fjahr> Seems like the details of logging can continue to be discussed after the meeting. Is there anything else to discuss that should be in the meeting?
16:32:53 <_aj_> fjahr: i think you could reasonably go through the gist above and say “this is ugly, is there really a big benefit?” or “this is much better than what we do now! i like it!” and have that be a useful contribution
16:32:54 <ryanofsky> sgtm
16:33:10 <ryanofsky> yeah i’ll take a look at the gist
16:33:22 <achow101> fjahr: topic for 31.0?

16:33:37 <fjahr> #topic v31
16:33:52 <achow101> we branched on tuesday night, tagged v31.0rc1 yesterday
16:34:00 <_aj_> yay!
16:34:21 <achow101> there’s a backports pr and still a couple things in the milestone, so definitely will have a rc2
16:34:34 <achow101> any new issues to add to the milestone?
16:35:07 <achow101> also release notes draft is in the wiki
16:35:47 <janb84> Testing guide will be adressed by BOSS program / me
16:36:03 <fjahr> https://github.com/bitcoin/bitcoin/milestone/74
16:37:08 <achow101> otherwise that’s all
16:37:37 <fjahr> Any other topics?
16:37:37 <maflcko> I wanted to fix all intermittent test issues for this release, so if you are seeing any new, please let me know :)
16:37:45 <fanquake> Looks like I just saw another one
16:37:50 <fanquake> https://github.com/bitcoin/bitcoin/issues/34367#issuecomment-4048211050
16:38:03 <fanquake> (happened in the backports branch)
16:38:22 <fanquake> I assume we’ll fix all the multiprocess issues with another subtree pull?
16:38:37 <fanquake> (once the rest of the issues there are fixed)
16:38:41 <maflcko> Maybe let the functional tests run in a loop over night, this night, and see if it is still running the next morning. If not, leave an issue. (Make sure to increase --timeout-factor for smaller machines)
16:39:34 <fanquake> I don’t have a Windows machine, so someone on Windows will have to do that for that issue (maybe UCRT related)
16:40:26 <maflcko> oh, I meant in general, to see if *all* dev machines and platforms can run the tests smoothly
16:40:48 <fanquake> Yea sure, will be running
16:40:53 <maflcko> nice, thx

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

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:

• v2026.3.5 of White Noise was recently released, bringing a smoother experience to the Nostr-based messaging application.

  • During the monthly call, on Tuesday 3rd, Marmot protocol developers announced that a new version of the messaging application was ready to be released. The latest update builds on top of v0.3.0, released a week earlier, which incorporated all the rework done through the Sloth project. v2026.3.5 was then officially released on Thursday, March 5th.

  • This release integrates a breaking change that was recently applied to the Marmot specifications. Specifically, Marmot dropped support for NIP-44 encryption and replaced it with ****ChaCha20-Poly1305 due to compatibility issues between the TypeScript implementation and the Rust-based one. Developers noted that group chats created with v0.3.0 will continue to work as long as any member upgrades to the latest version.

  • On a side note, White Noise is no longer the only messaging application based on the Marmot protocol. Other clients, such as Vector and Pika, are currently integrating the new standard, providing more choice to users. Interestingly, cross-compatibility was demoed during the call, showing a group chat with four different clients seamlessly exchanging messages.

• IS946 in bdk-ffi is keeping track of the ongoing effort to bring BDK to the Go language.

  • During the biweekly call, on Tuesday 3rd, bdk-ffi developers discussed IS946, which keeps track of the work being done to bring BDK to the Go ecosystem. At the moment, some problems are being addressed by BDK developers.

  • The main issue is related to the difference in the uniffi-rs version supported. In fact, developers are leveraging uniffi-bindgen-go, the uniffi bindings generator for Go, which uses uniffi-rs v0.29.5, while BDK is working on v0.30.0, making the two libraries incompatible. Thus, LDK developer Elias Rohrer is working on upgrading the uniffi-bindgen-go generator to the same version, in order for it to be compatible with bdk-ffi.

  • In the meantime, developer Matthew Ramsden is testing Rohrer’s work. While the bindings generation succeedes, he is encountering issues in the compilation. The problem seems to be linked to an intrinsic limitation in the Go language, with developers discussing possible solutions.

Other News from the Bitcoin World

• Decentralizing Swaps: Electrum recently reported that there are now 9 providers supplying liquidity for submarine swaps through their wallet. This feature was introduced around 6 months ago in v4.6.0 to boost decentralization in swap services, with the goal to allow anyone to become a swap provider by advertising their fees and liquidity over Nostr.

• Bindings for the win: Recently, Steven Roose reported that Bark, the implementation of the Ark protocol by Second, was available in multiple programing languages. While the main codebase is written in Rust, the Second team was able to generate bindings in different languages, specifically Go, React Native, Dart, Swift and Kotlin, by leveraging uniffi-rs, the bindings generator for Rust, which is now becoming the gold standard in the Bitcoin ecosystem.

• Benchmarking fee estimates: Abubakar Sadiq Ismail posted on X about his latest project, a full-stack application for monitoring and validating Bitcoin Core transaction fee estimates against actual block data. The project compares fee rates estimated by Bitcoin Core with actual data from the blockchain, to verify the accuracy of the predicted data. A nice UI is already available to visualize data in a simple manner.

Merged PR’s

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

• Update libmultiprocess subtree to be more stable with rust IPC client by ryanofsky
  The Rust mining client was having issues with async requests and unclean disconnects. To fix that, this PR synced Bitcoin Core with what is on the libmultiprocess subtree. Specifically, there was a change to avoid async errors in non-C++ clients.
  
  New tests were added in this change, and in the conversation it seems there were some issues with a memory leak that were resolved.
  

• test: let connections happen in any order in p2p_private_broadcast.py by vasild

  A few months ago private broadcast was merged into Bitcoin Core by Vasild that change allowed transactions to be sent over short-lived Tor and I2P connections. This change, as you can tell by the title tag, is a test change. Specifically, it was a change to the functional test where we want to let connections happen in any order in a private broadcast.

  If the following two events happen:

  • (likely) the automatic 10 initial connections are not made to all
    networks

  • (unlikely) the network-specific logic kicks in almost immediately.
    It is using exponential distribution with a mean of 5 minutes
    (rng.rand_exp_duration(EXTRA_NETWORK_PEER_INTERVAL)).

  So if both happen, then the 11th connection may not be the expected
  private broadcast, but a network-specific connection.

• wallet: call SyncWithValidationInterfaceQueue after disconnecting chain notifications by achow101

  When the wallet disconnects from getting chain notifciations it does not expect futher notifications to execute. But from what was found in tests, that was not the case.
  
  Right now, we disconnect the chain notifications and then continue the shutdown. Instead, the wallet now waits for the validation interface queue to be drained before shutting down the rest of the 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: refactor: remove ConnectTrace by stickies-v

The sentinel pattern in ConnectTrace has been unnecessary since conflicted transaction tracking was removed in 5613f98. Without that tracking ConnectTrace is a trivial wrapper around std::vector, so it seems better to just replace it with the vector directly.

Also modernize/update naming along the way, renaming PerBlockConnectTrace to ConnectedBlock

Refactor, no behaviour change.

IRC meeting notes

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

16:01:32 <fjahr> #topic Fuzzing WG Update (dergoegge)
16:01:38 <hodlinator> hi
16:01:59 <dergoegge> I made a dashboard for Brink's fuzzing infrastructure: https://dergoegge.github.io/fuzzor-dashboard/
16:02:19 <darosior9> hi
16:02:25 <dergoegge> Please let me know if you have ideas on how that can be made more useful
16:02:28 <fjahr> very cool
16:02:29 <pinheadmz> Yo
16:02:36 <l0rinc> hi
16:02:44 <dergoegge> Already got some good feedback in the fuzzing wg (thanks!)
16:02:57 <dergoegge> Also wanted to bring up https://github.com/bitcoin-core/gui-qml/pull/503
16:03:08 <dergoegge> It would be cool have something like this for the qt gui
16:03:36 <hebasto> qml will be a new gui soon
16:03:53 <dergoegge> If we're gonna keep maintaining it, it could be nice to increase our confidence with some fuzzing, which would be enabled by this approach
16:04:34 <willcl-ark> hi
16:04:49 <dergoegge> I'm not gonna work on it myself, but if someone is interested, I'd be willing to help with review or writing the fuzz tests
16:05:50 <fjahr> dergoegge: that's it?
16:06:34 <dergoegge> yes unless someone has something to add
16:06:36 <johnny9dev> Hi. I can throw some tokens to research it for Qt widgets. I've built this same thing before in another qml project
16:06:57 <dergoegge> Great! lmk how that goes!

16:07:05 <fjahr> #topic Kernel WG Update (sedited)
16:07:54 <sedited> don’t have anything to share this week.

16:08:00 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:08:04 <l0rinc> nothing from me
16:08:56 <andrewtoth_> I opened #34692 based on feedback from last week’s meeting and in #34641. Hopefully that is simple enough to get into v31. It would be a big UX improvement for our users. We can continue improving dbcaching in v32 afterwards.
16:08:58 <corebot> andrewtoth_: Error: That URL appears to have no HTML title within the first 32KB.
16:09:00 <corebot> andrewtoth_: Error: That URL appears to have no HTML title within the first 32KB.
16:09:38 <andrewtoth_> That’s it from me

16:09:59 <fjahr> #topic Net Split WG Update (cfields)
16:10:14 <cfields> Still no update, focus has been elsewhere. Really hoping to get going this week. Thanks for your patience :)
16:11:29 <fjahr> Not seeing silent payments, but the k_max discussion is making progress afaict (bip change is merged I think) and the focus is again on the secp Pr that implements this.
16:11:39 <fjahr> Anything else to discuss?
16:12:15 <sipa> hi
16:12:20 <johnny9dev> I would like to get the qml project back onto the weekly topic list. I’ve spent the last 2 weeks working on it again and I am not have full momentum again.
16:12:34 <johnny9dev> I now have full momentum*

16:12:59 <fjahr> #topic QML GUI WG Update (johnny9dev)
16:13:01 <fjahr> :p
16:13:03 <johnny9dev> I have another contributor helping me as well who will like to update their progress too
16:13:09 <willcl-ark> nice!
16:13:35 <fjahr> johnny9dev: You don’t have to ask for permission IMO, just move it up in the wiki page
16:14:11 <johnny9dev> My goal is feature parity and have setup the test automation frameworks and have done the decoupling from the original qt project. epcileafies has completed the features for peer disconnect/ban and completed a full e2e test for it using the gui test framework
16:15:18 <johnny9dev> the list of features has been added to the issues of the project.
16:15:52 <johnny9dev> thats all for this status i think

There was more converstaion on this, read the full meeting in minutes

16:41:42 <fjahr> #topic 31.0 milestone
16:41:57 <achow101> Btanching is scheuled for the 10th, which is in 5 days
16:42:36 <achow101> There are still 8 open PRs in the milestone: https://github.com/bitcoin/bitcoin/milestone/74
16:42:47 <achow101> please review them
16:43:07 <sedited> also #34735 as an outstanding issue.
16:43:08 <corebot> https://github.com/bitcoin/bitcoin/issues/34735 | Intermittent failure in rpc_gettxspendingprevout.py, line 98, assert_equal(node0.gettxspendingprevout([..]), [..]), JSONRPCException: No spending tx for the outpoint :0 in mempool, and txospenderindex is unavailable · Issue #34735 · bitcoin/bitcoin · GitHub
16:44:32 <achow101> that’s all

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

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:

• Numo was released last week, aiming to level up the user experience for Bitcoin payments.

  • During the monthly community call, on Thursday 26th, the Cashu team demoed Numo, the first tap-2-pay point-of-sale solution which allows merchants to easily accept Bitcoin. The first version of the Android application, v0.1.0, had been officially launched a couple of days before, on Tuesday 24th.

  • Numo is a simple, free and open-source, Android application, which enables user to receive ecash payments through the Cashu protocol using tap-2-pay. Merchants can also accept BOLT11 payments through QR codes. Notably, the application also supports automatic withdrawal to self-custody and provides users with management tools for creating item catalogs and baskets, a tipping system, and the possibility to review payment history.

  • According to Cashu developers, the aim is to improve the user experience for Bitcoin payments, bringing it up to the level of mainstream solutions, such as Apple Pay.

• Alby Sandbox is the new educational tool from Alby to test, explore, and understand the Lightning Network.

  • During the monthly community call, on Thursday 26th, Alby developers showcased on their latest tools, the Alby Sandbox.

  • The tool provides an interactive sandbox to test and explore the Lightning Network in real world scenarios, from creating a simple invoice, to more complex use-cases such as recurring payments.

  • What’s cool about the tech: Alby Sandbox provides code snippet, flow diagrams and example prompts to allow users to leverage all Alby’s Lightning and NWC capabilities in the real world.

• An update on the latest NUT changes: Pay-to-Blinded-Key (P2BK), prediction markets, and more.

  • During the monthly community call, on Thursday 26th, Cashu developers presented the latest changes to the NUT specifications.

  • NUT-28 has finally been merged, officially bringing P2BK payments to the protocol. This NUT leverages ECDH-derived blinding scheme to blind the public key. This allows to enhance privacy in Pay-To-Public-Key (P2PK) payments. Moreover, changes have been applied to NUT-05 to improve asynchronous melting operations, and new error codes for maximum input and outputs in an operation have been added.

  • New NUTs have also been proposed. Notably, PR337 proposes a technique for encoding prediction markets into Cashu tokens, while PR342 introduces binary search for more efficient wallet recovery.

Other News from the Bitcoin World

• The first BIP54 compatible block has been mined: On Thursday 19th, WhitePool mined the first BIP54 compatible block, at height 937404. BIP54, usually referred to as Consensus Cleanup, is a proposed soft fork by Antoine Poinsot and Matt Corallo which aims to fix some small bugs present in Bitcoin consensus. Specifically, it aims to solve the timewarp attack, reduce the worst case block validation time, prevent Merkle tree weaknesses, and avoid duplicate transactions without BIP30 validation. It is possible to recognize a BIP54 compatible block by looking at the coinbase transaction nLocktime field, which must be set to block height minus 1.

• Hackathon project found two bugs in Bitcoin library: During the BTC++ hackathon, Brazilian hacker Lucaslgol05 found two bugs in BitcoinJs, the JavaScript Bitcoin library for Node.js and browsers. His project consisted in applying differential fuzzing between BitcoinJS and rust-bitcoin. Differential fuzzing involves providing the same input to multiple similar programs and comparing their outputs to identify discrepancies, which may indicate bugs. Curious about what happened in Floripa? Streaming will be available from Thursday, March 5th, @ 6pm UTC on BTC++ X profile!

Merged PR’s

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

• mining: add cooldown to createNewBlock() immediately after IBD by Sjors
  If a mining client connected to a Bitcoin Node in IBD or catching up on the last 24 hours, they would receive a flood of new templates.
  
  This change modifies createNewBlock() from a method that can return quickly to one that can be blocked for a few minutes. This is because, instead of returning quickly, the cooldown waits for IBD to finish. Then, as the tip moves forward, it waits a few seconds to see if the tip is updated. If so, then the timer is restarted.
  
  The cooldown is optional because it should not be used for internal non-IPC code, and also should not halt when testing the IPC client in some situations, like Signet.
  
  Sjors has been working on improving the IPC interface, and this is another installment of his changes!

• miniscript: Use Func and Expr when parsing keys, hashes, and locktimes by achow101

  Miniscript has a parser, and it currently only looks for the next “)” when parsing key, hash, or locktime expressions. This causes failures when the expression contains a nested expression. Currently, nested expressions are only possible with musig() inside key expressions. Achow101 noticed that this pattern could be generalized to handle hahses and locktimes, so they implemented that as well.

• Cluster mempool: SFL cost model (take 2) by sipa
  This is part of the cluster mempool tracking issue. This change improves the accuracy of the cost model for spanning forest linearization (SFL). The SFL cost model controls how much CPU time is spent in the algorithm for clusters that cannot be linearized within a reasonable amount of time. The goal is to have a metric for the amount of work performed. We want to impose a lower bound and an upper bound on how much work is done while linearizing.
  
  There are conflicting design goals. On one had it is ideal if the metric is closely correlated to actual CPU time, but at the same time, it can be a nightmare to make it system-dependent because then it would be hard to predict/reason network-wide.
  
  There are multiple solutions which are listed in the PR, but Sipa went the middle ground, counting function calls/branches/loops with weights that were determined through benchmarking.
  
  You can read the full specification in the PR.

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.

• mining: add submitBlock to IPC Mining interface by w0xIt

This PR adds a submitBlock method to the IPC Mining interface, equivalent to the submitblock RPC. It accepts a serialized block over IPC, validates/processes it via the normal block-processing path.

The method uses the same result shape as checkBlock: bool + reason/debug out-params. It reports duplicate, inconclusive, and invalid-block rejection details, and initializes reason/debug on every call.

Closes #34626

IRC meeting notes

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

16:01:37 <fjahr> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:02:21 <sipa> I have closed #30289. Sadly, that also means dissolving the cluster mempool WG.
16:02:34 <fjahr> RIP!
16:02:52 <sipa> Thanks everyone for getting us this far.
16:03:29 <sipa> that’s it :)
16:03:45 <fjahr> Congrats on getting this far and thanks!
16:03:55 <instagibbs> well fought project, congrats
16:04:17 <andrewtoth_> congrats sipa!
16:04:47 <sipa> just over 3 years since sdaftuar and I started talking about it :)

16:03:47 <fjahr> #topic Kernel WG Update (sedited)
16:04:45 <sedited> another RFC PR for improving blockmap and cchain concurrency was opened in #34654
16:04:54 <sedited> that’s all from me.

16:05:16 <fjahr> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:05:39 <andrewtoth_> #34165 was merged, thanks everyone!
16:05:46 <andrewtoth_> I rebased #31132 for that as well as furszy’s ThreadPool. I’m hopeful we can merge that soon after v31 branch off
16:06:18 <andrewtoth_> Not sure if l0rinc is here, but he opened #34641 after last week’s meeting. Would be nice to get that in for v31
16:06:29 <andrewtoth_> that’s it from me

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

Bitcoin Improvement Proposals (BIPs) are the fundamental documents used to propose enhancement to the Bitcoin protocol. Any proposal has to undergo a thorough review process before being added to the BIPs repository. The process, recently updated by maintainer Murchandamus, is described in BIP3 and anyone proposing a new feature, expansion, or standard must follow it. Moreover, more developers have been granted the role of BIP Editor, thus more BIPs are being evaluated, numbered, and published.

From now on, the Insider will cover all new BIPs being published and new proposals getting assigned a number. Since this is the first issue of this series, we will cover all the BIPs discussed during February.

Before starting, an important clarification is needed. A BIP being published does not mean that it has been added to Bitcoin Core, or that it has been adopted by a project. It just means that the BIP has been assigned a number and its PR merged because Editors have deemed it mature enough. The BIP will remain in Draft status until “authors have concluded all planned work on the proposal, and are confident that their BIP represents a net improvement, is clear, comprehensive, and is ready for adoption by the Bitcoin community”.

Published BIPs

A list of recently published BIPs

BIP360: Pay-To-Merkle-Root

Authors: Hunter Beast, Ethan Heilman, Isabel Foxen Duke

Publishing Date: February 11th, 2026

Layer: Consensus

BIP360 proposes a soft fork to create a new output type called Pay-To-Merkle-Root (P2MR). This new output aims to provide protection against long-exposure attacks by Cryptographically Relevant Quantum Computers (CRQCs) for outputs that support Tapscript and script trees.

This new output commits to the Merkle Root of a script tree and provides nearly most of the functionalities of P2TR outputs. However, it removes the quantum vulnerable key path spend, which exposes scripts of spent outputs which could be leveraged by a CRQC to derive the private key, through a process called quantum key recovery.

BIP110: Reduced Data Temporary Softfork

Authors: Dathon Ohm

Publishing Date: February 7th, 2026

Layer: Consensus

BIP110 is a proposed soft fork that aims to temporarily limit the size of data fields at the consensus level. To do so, it restores the previous 83-byte policy limit on OP_RETURN outputs.

BIP89: Chain Code Delegation

Authors: Jesse Posner, Jurvis Tan

Publishing Date: February 4th, 2026

Layer: Applications

BIP89 defines Chain Code Delegation (CCD), a method for multi-signature wallets to withhold BIP32 chain codes from non-privileged participants. In particular, it limits the visibility on extended XPUBs or descriptors to a multisig counterparty , allowing him to receive only the minimum data needed for signing. This methodology keeps policy enforcement feasible for a non-privileged signer, while preserving privacy for the main actor.

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP392: Silent Payments Output Script Descriptor

Authors: Craig Raw

Assigned Date: February 6th, 2026

Layer: Applications

PR2047 introduces BIP392, which specifies a new output script descriptor for silent payments, sp() . The descriptor, proposed by the creator of Sparrow Wallet, provides a standardized way to represent silent payment outputs within the output descriptor framework, enabling wallet interoperability and recovery using existing descriptor-based infrastructure. Iin particular, the new descriptor takes silent payment key material and describes P2TR outputs when combined with the sender’s input public key, as defined in BIP352.

BIP446: OP_TEMPLATEHASH

Authors: Gregory Sanders, Antoine Poinsot, Steven Roose

Assigned Date: February 6th, 2026

Layer: Consensus

PR1974 introduces BIP446, which proposed a soft fork to activate a new operator for Tapscript, called OP_TEMPLATEHASH. The new opcode could be used to commit to the transaction spending an output, a capability that could replace the need for pre-signed transactions in second-layer protocols. This BIP is being proposed by Core contributors, Gregory Sanders and Antoine Poinsot, and Second CEO Steven Roose.

The PR also introduces another BIP, bundling together OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK, and OP_INTERNALKEY. However, this BIP has not been assigned a number yet.

BIP361: Post Quantum Migration and Legacy Signature Sunset

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

Assigned Date: February 11th, 2026

Layer: Consensus

PR1895 introduces BIP361, 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.

BIP376: Spending Silent Payment Outputs with PSBTs

Authors: Nymius

Assigned Date: February 5th, 2026

Layer: Applications

PR2089 introduces BIP376, which 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.

BIP128: Timelock-Recovery Storage Format

Authors: Oren Z

Assigned Date: February 5th, 2026

Layer: Applications

PR2068 introduces BIP128, which specifies a standard format for storing timelock-recovery plans. The goal of this proposal is to allow users to simply importing these type of plans into services that provide automatic monitoring and execution.