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

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP376: Spending Silent Payment Outputs with PSBTs

Authors: Nymius

Published On: Apr 11th, 2026

Layer: Applications

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

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

Other News from the Bitcoin World

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

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

Merged PR’s

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

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

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

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

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

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

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

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

IRC meeting notes

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

<abubakarsadiq> #topic Fuzzing WG Update (dergoegge)
<dergoegge> Not much to say but we published a second blog post about fuzzamoto: https://brink.dev/blog/2026/04/09/fuzzamoto-non-determinism/

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

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

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

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

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

Releases

• 31.0 Release

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Other News from the Bitcoin World

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

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

Merged PR’s

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

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

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

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

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

• cli: Return more helpful authentication errors by hodlinator

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

  This adds a few useful responses
  

  Failed to read cookie file and no rpcpassword was specified.

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

  Cookie file credentials were invalid and no rpcpassword was specified.

IRC meeting notes

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

<abubakarsadiq> #topic Net Split WG Update (cfields)
<cfields> No update this week. Should have an incoming pr or two in the next few days for a LocalAddressManager.

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

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

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

Releases

• None this week

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

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

Highlights from the bitcoin developer ecosystem...

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Published BIPs

A list of recently published BIPs

No new BIPs were published during the last week.

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP440: Varops Budget For Script Runtime Constraint

Authors: Rusty Russel, Julian Moik

Assigned On: March 25th, 2026

Layer: Consensus (Soft Fork)

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

BIP441: Restoration of disabled script (Tapleaf 0xC2)

Authors: Rusty Russel, Julian Moik

Assigned On: March 25th, 2026

Layer: Consensus (Soft Fork)

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

Other News from the Bitcoin World

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

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

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

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

Read below for more information!

Merged PR’s

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

• rpc, logging: add backgroundvalidation to getblockchaininfo by polespinasa

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

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

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

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

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

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

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

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

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

  • TxSendStatus automatically captures time_added upon emplace.

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

IRC meeting notes

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

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

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

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

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

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

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

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

Releases

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

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

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

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

The Hackathon

For those unfamiliar, we run a hackathon at nearly every Bitcoin++ conference. This time around (Exploits Edition) we split things into two tracks: our classic hackathon track where teams build projects (with bonus points for anything security or exploit themed), and a brand new bug bounty track where the objective was simple: find real bugs in real, open-source Bitcoin software.

We were nervous about this one. We had no idea if people would actually find meaningful bugs in 22 hours. By the end of the hackathon, 10 real, meaningful bugs were found in open-source Bitcoin projects. Ten. In a single day.

22 hours, ~60 participants, 21 projects submitted, 10 meaningful bugs found.

Projects

There were many impressive projects, but here’s few standouts:

MineExploit won first overall. Think Metasploit, but purpose-built for Bitcoin mining tooling. The team didn’t just demo it either. They ran it against several codebases and turned up three bugs in real StratumV2 repos.

LocalProbe won second place, a project that demonstrated how Firefox can be used to fingerprint open ports on a machine. 0xB10C showed that simply navigating to a malicious website could allow an attacker to spam a Bitcoin node by firing HTTP requests at its open ports. On stage, he had the audience DDoS his node, evicting other peers. Nasty stuff, and exactly the kind of research this hackathon was designed to surface.

Another team used fuzzing techniques to go after Alpen Labs’ codebase and found a critical vulnerability that a professional security auditor had missed just three weeks earlier. Read that again. A team at a 22-hour hackathon, fuzzing on the fly, caught something that a paid audit didn’t. That alone should make you think about how much untapped value there is in getting more eyes on Bitcoin infrastructure.

Check out all the projects here.

Conclusion

Here’s the thing we keep coming back to: this hackathon produced tangible, lasting improvements to Bitcoin’s security infrastructure in under 24 hours. Critical bugs found, new offensive security tooling built, and novel attack vectors documented. If you’re an organization that funds Bitcoin development through grants, we’d encourage you to look at what a single hackathon can produce and compare that to what a typical grant cycle yields. The return on investment here is hard to ignore.

We’re already thinking about how to level up the bug bounty format for next time. Giving participants more time to study target projects ahead of the event, working more closely with specific projects to provide better scoping, and generally adding more structure to make the bounty track even more productive. If the first attempt is any indication, this format has serious legs.

Now he’s building the Librería de Satoshi course platform, which rewards students with sats for successfully completing Bitcoin developer courses.

He traveled to BTC++ Berlin to present his work, where he met the Moneydevkit team who offered him a job. Today he splits his time between his new role and ongoing open source contributions.

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