In this week update we feature two specification improvements to the Lightning Network, with the merging of BOLT12 payer proofs, and Cashu, with the possibility to mint and melt ecash tokens through custom payment methods.

We also cover the recent COLDCARD incident. Due to a bug in the entropy generation firmware, users saw their funds drained from their wallets.

We finally discuss the new BIP460 for Cross-Input Signature Aggregation (CISA), the Indian government against India, and some other interesting news.

Highlights from Bitcoin++ — Consensus Edition

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

• BOLT12 payer proofs have been merged in the Lightning Network specifications (BOLTs)

  • During the monthly call, on Monday 27th, Lightning contributor discussed BOLT12 payer proofs, defined in PR1346, which was merged during the call. The work was carried on by developer Vincenzo Palazzo.

  • This new addition to BOLT12 defines a way to prove that an invoice has been paid. It also allows to prove that the payer proofs was actually created by the secret key used to request the invoice.

  • This new feature opens up new interesting use-cases, such as BOLT12-based zaps on Nostr. In fact, Amethyst developer Vitor Pamplona announced that the latest release of the Nostr client supported this specific feature, but noted that there is still work to do to actually use it.

• Custom payment methods are now defined in the NUT specifications of the Cashu protocol.

  • During the monthly community call, on Thursday 30th, Cashu developers discussed the new update to the Cashu specifications in PR382, which introduced the possiblity to mint and melt ecash tokens through custom payment methods.

  • The PR updates NUT-04 (minting) and NUT-05 (melting). While some specific payment methods are described in a dedicated NUT, such as BOLT11, BOLT12, and on-chain, the recent update creates an interface to allow anyone to use any custom payment method.

  • Developer have already implemented custom backends based on Bark (Second’s Ark implementation) and Spark.

A BIPs Update

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

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP460: CISA for Taproot Key Path Spends

Authors: Fabian Jahr

Assigned On: Jul 28th, 2026

Layer: Consensus (Soft Fork)

PR2212 introduces BIP460, a proposed soft fork to introduce transaction-wide Cross-Input Signature Aggregation. The draft defines a new witness version 2 , enabling Taproot-style key path spending where inputs can aggregate their signatures within a transaction. If used together with full-aggregation, the resulting aggregate signature would have a size of 64 bytes, independent on the number of signatures.

Other News from the Bitcoin World

• The COLDCARD incident: On Thursday 30th, an earthquake hit the Bitcoin world: COLDCARD users were seeing their funds drained from their wallet. Engineers from Block soon discovered vulnerabilities in the firmware of different COLDCARD models, namely Mk3, Mk4, Mk5, and Q.

  • The vulnerabilities were connected to the Random Number Generator (RNG), the component whose goal is to provide entropy during the generation of the private key. Unfortunately, a bug in the firmware prevented the generation to rely on the hardware’s RNG, instead using a pseudo-RNG, based on the some fixed values. Basically, this means that the wallet was generated deterministically.

  • In particular, the issue was more severe on Mk3 models, while latter models slightly compensate for this issue through secure-element input. Read Block’s report to know all the technical details about the issue. The vulnerabilities have been confirmed by many different sources.

  • Core-lightning contributor Dusty Daemon deep dived into the COLDCARD firmware code for the Insider, providing his point of view on what happened. Read it here!

  • Coinkite, the company behind COLDCARD, released a security advisory on the incident, providing also migration guidelines to move funds away from the broken wallets.

  • We invite user to be careful in this moment of panic. Scammers have already created fake websites, accounts, and guides to profit from the incident. Only follow the official sources.

• Bark <> Start9: Second, the company behind Bark, recently announced that Bark Wallet had been released on the Start9 registry.

• What Bitcoin Core did: Mike Schmidt posted on X a list of all the different topics that Core developers have been addressing in the last 18 months. Devs worked on many improvements, such as SwiftSync, the new mining interface compatible with Stratum V2, ASmap, and more.

• BitChat VS India: Following the protests that took place in India, the local government requested the removal of the BitChat source code. BitChat is a messaging app that allows people to communicate P2P and offline through a Bluetooth mesh. The reaction of the freedom tech communities has been overwhelming: the source code has been copied on dozens of private servers and P2P GitHub alternatives, making the request useless. Interestingly, Calle, the maintainer of the Android version of the app, posted to Nostr that the app is now able to replicate itself, by sending the apk file directly over Bluetooth to its peers.

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Berlin this October 1- 3 to talk about payments in Bitcoin!

In this week update we feature the most interesting things happened during Bitcoin++ Consensus Edition in Toronto, where devs met to discuss new consensus proposals and what are the best way forward for Bitcoin.

We also cover some other interesting news from the Bitcoin ecosystem. Notably, a PR was opened in Bitcoin Core to bring BIP54 (Consensus Cleanup) into the protocol, Lightning Labs launched a third Ark implementation, and silent payments being integrated in libsecp256k1.

Highlights from Bitcoin++ — Consensus Edition

I spent last week at Bitcoin++ Consensus Edition in Toronto. The first day of talks will be live-streamed starting from Thursday, July 30th, at 5PM UTC.

Here is what caught my eye:

• Matthew Vuk from Second kicked-off the conference by providing an historical overview on all the soft forks that have ever happened in Bitcoin.

• Fabian Jahr gave a talk about his recent proposal to bring Cross-input Signature Aggregation (CISA) to Bitcoin. The BIPs triplet is composed by BIP458 for half-aggregation, BIP459 for full-aggregation, and BIP460 (not yet assigned, but reserved for this goal) for the actual CISA sofr fork.

• Julian Moik provided a panoramic on the Great Script Restoration proposal, which aims to make Bitcoin programmable money again.

• Pablo Greco, Director of Engineering at Blockstream, highlighted the differences in consensus between Bitcoin and the Liquid sidechain.

• Michael Hassard, one of Roman Sterlingov’s trial lawyers, talked about his client’s story, the ongoing process, and the next steps to make Roman a free man again.

• Russel O’Connor explained what formal verification is, and how he applied it to one of the modules of tone of he cryptographic library used in Bitcoin, libsecp256k1.

• Tadge Dryja gave a talk on the possible techniques that could be used to migrate exposed coins to new quantum-safe addresses, in case elliptic curve gets broken in the future.

• BDK contributor Thunderbiscuit discussed Compact Block Filters, how they impact users, and how wallet developers could leverage them in their applications.

• Bitcoin researcher Conduition explained to the audience what isogeny signatures are and why are they important for a post-quantum future. All through mathematics and memes.

• Peter Todd discussed his ideas on tail emission and demurrage, a way to keep Bitcoin secure after the last sat gets mined.

• Isabel Foxen Duke moderated a panel with Tadge Deyja, Conduition, and Nadav Kohen on the different proposals currently under research to make Bitcoin quantum secure.

• Calvin Kim, btcd contributor, gave a talk on what the developments of an alternative Bitcoin client looks like.

• Andrew Toth gave an overview on his recent work to make Initial Block Download (IBD) faster, an improvement that should be included in Bitcoin Core v32.

• Matthew Vuk explained how the Ark round signing ceremony works.

• Steven Roose, Second CEO, discussed what covenants are, how they work, and how we could achieve them using OP_TEMPLATEHASH and OP_CHECKSIGFROMSTACK .

• Paul Sztorc told the audience about everything he is working on right now, from his future hard fork to all that he is building on top of it.

• Chris Guida explained why he thinks that BIP110 is the best way forward for Bitcoin.

• Tadge Dryja moderated the final panel with Chris Guida, Paul Sztorc, and Peter Todd on the different views and proposals they have for the future of Bitcoin. The final panel will be live today, Monday 27th, at 5PM UTC!

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

• Next step for BIP54: Antoine Poinsot announced that a new PR35793 on Bitcoin Core had been opened to bring BIP54, the Consensus Cleanup soft fork, to Bitcoin. The PR will only implement the soft forks, without the activation mechanism.

• The 3rd Ark: Lightning Labs announced their answer to Lightning last mile problem, Wavelength. The new implementation is an Ark analog, and allows fast integration of Bitcoin payments in any application.

• Silent payments <> libsecp256k1: The cryptographic functions needed for silent payments have been recently merged into the libsecp256k1 library through PR1765.

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Berlin this October 1- 3 to talk about payments in Bitcoin!

Merged PR’s

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

• fuzz: add p2p_private_broadcast harness by frankomosh

  More fuzz coverage landed this week. Frank Ochieng had his PR merged that adds a dedicated harness for ConnectionType::PRIVATE_BROADCAST, the privacy-preserving tx relay path that barely got exercised before.
  

  The existing process_message fuzz target could create private broadcast peers, but it never seeded m_tx_for_private_broadcast, so the interesting send path basically never ran. This harness builds those peers on purpose, seeds the tx first, and only feeds in the message types private broadcast actually allows.
  

  As always, more fuzzing is welcome, and who knows, maybe this one finds something interesting down the line.

• coins: use SipHash-1-3-UJ for CCoinsMap keys by l0rinc
  This week L0rinc had a performance PR merged that speeds up hashing for the in-memory UTXO cache. The coins map was using SipHash-2-4 for COutPoint keys, and that path was doing more work than it needed to for a fixed 32-byte txid plus a small output index.
  

  The fix switches that hasher over to SipHash-1-3-UJ, a reduced-round variant with jumbo-block handling that Pieter helped design. It stays local to the coins cache and related temp sets, so nothing gets persisted or sent over the network. Benchmarks show the outpoint hash path about 2x faster, and a full reindex run was roughly 5% quicker.

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

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

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

This change adds two major features to the result class:

- For better error handling, adds the ability to return a value on failure, not just a value on success. This is a key missing feature that makes the result class not useful for functions like `LoadChainstate()` which produce different errors that need to be handled differently [^1].

- For better error reporting, adds the ability to return warning messages and multiple errors, not just a single error string. This provides a way for functions to report errors and warnings in a standard way, and simplifies interfaces

IRC meeting notes

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

--- Topic 1 ---
stickies-v: #topic Fuzzing WG Update (dergoegge, marcofleon)
marcofleon: hi
marcofleon: no update
hodlinator: hi

--- Topic 2 ---
stickies-v: #topic Kernel WG Update (sedited)
sedited: i've got nothing this week. maybe someone else?
yancy: hi
stickies-v: purpleKarrot made some more progress on his stateless validation work
stickies-v: but i think more to share on that later

--- Topic 3 ---
stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: #35215 was merged - another 5% validation speedup \:D/
l0rinc: so now we can use it in #35531
l0rinc: I'm running reindex-chainstate benchmarks to compare master with 29/30/31 to see how they stack up.
stickies-v: as in 5% faster IBD/reindex?
l0rinc: yup
stickies-v: juicy
l0rinc: in addition to the parallel prevout fetcher
l0rinc: thanks, that's it from me
dergoegge: lfg
Murch[m]: v32 should be quite the speedupz
l0rinc: especially if we can get the txindex changes in
l0rinc: Andrew is at a conference

--- Topic 4 ---
stickies-v: #topic QML GUI WG Update (johnny9dev)
johnny9dev: Our preview release is now published to bitcoincore.app. Already got a lot of good feedback on it to work through.
johnny9dev: I dropped down the glibc the preview builds against for increased compatibility
johnny9dev: One thing I realized too while testing is that the linux depends build doesnt have opengl and the macos depends uses metal apis so there are performance differences across platforms and it is noticeable. So with that I've been focused on optimizing all of the rendering so any page not visible isn't continuing to draw. I think i got most of the main ones and it will be working much better on linux once the PRs are merged.
johnny9dev: Then finally I removed gMock from our codebase and will make sure that doesn't get included in our staging branch.
johnny9dev: that is all
stickies-v: wdym with dropped down the glibc?
johnny9dev: built against ubuntu 22.04 instead of 24.04 toolchain
stickies-v: ooh version downgrade you mean
johnny9dev: at least one person testing couldnt run the built binary on their version of debian
johnny9dev: yeah

--- Topic 5 ---
stickies-v: #topic QA WG Update (brunoerg)
brunoerg: hi, no update this week
stickies-v: Anything else to discuss?
stickies-v: alright, let's get back to building, thanks for the updates everyone

Read here for the full meeting

Releases

• Bitcoin Core v30.3 is now available

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

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

In this week update we discuss a new library from the Stratum V2 team to test interoperability between the reference implementation, SRI, and other SV2-based software.

We also feature a PR in the Cashu Development Kit (CDK), which integrates a new NUT for retrieving mint quotes associated with a public key.

We finally provide some interesting news from the Bitcoin world. In particular, we discuss the new native applications for the OG cashu wallet cashu(.)me and we highlight new interviews from the Nairobi event.

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:

• interoperability-tests-sv2 is the new library for testing compliance with the reference implementation of Stratum V2.

  • During the weekly call, on Tuesday 14th, Stratum V2 contributors discussed the new approach for verifying compliance between their reference implementation, SRI, and other SV2-based software.

  • According to IS1, which outlines the history of interoperability tests in the mining protocol, there is an increasing need for assessing compliance between different implementations and applications, due to the fact that more and more experimentation is done on the protocol.

  • The final goal is to avoid making SV2 a protocol without interoperability across different implementations.

• PR1834 is implementing a new NUT in the Cashu Development Kit (CDK).

  • During the weekly call, on Wednesday 15th, CDK developers discussed PR1834, which aims to implement a new NUT to allow users to retrieve mint quotes associated with a public key.

  • The new NUT, which is still missing an official number, is being discussed in PR341. It introduces a new endpoint for wallets to get all locked mint quotes associated with a set of public keys. Queries require a valid signature from the owner of the corresponding private keys, to avoid abuses of this feature.

  • The PR in CDK is ready, but developers are still waiting for the specification to be officially included as a NUT before merging it.

A BIPs Update

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

Other News from the Bitcoin World

• Native Cashu: The Cashu team recently announced that the OG ecash wallet cashu(.)me had been released as a native application on both iOS and Android. The wallet is built on CDK, which provides bindings for both Swift and Kotlin, it supports lightning and on-chain, tap-to-pay, and multi-currencies.

• Insider interviews: Take a look at the latest interviews from Nairobi: Wandia Mugo discusses how Bitcoin DADA is trying to bring more African women to Bitcoin development, Fabian Jahr talks about the state of open-source contributions, and Matthew Adeyemi examines the importance of design and how he is working on empowering African designers.

• Discussing consensus: This week, Bitcoin developers from all over the world will meet in Toronto for Bitcoin++ Consensus Edition. Three days of talks, a hackathon, and much more. Come argue about what bitcoin should become, then leave with rough consensus and running code!

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Toronto this July 22- 24 to talk about finding consensus in Bitcoin!

Merged PR’s

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

• wallet: Use in-memory SQLite for temporary wallet in exportwatchonlywallet by pablomartin4btc

  Why would you want to do any on disk operations if you knew that some info would be deleted shortly after an operation? This was the motivation for this PR. pablomartin4btc wanted to change the exportwatchonlywallet RPC to put the intermediate wallet built during its operation from being put on disk to directly in memory.
  
  This gives Bitcoin Core a few benefits. Firstly, it is faster, and faster is always better, because we do not need to read from disk anymore, and we can instead read from memory operations run quicker. Secondly, making it all in memory makes it so we don’t need the cleanup_watchonly_wallet RAII handler anymore, thus simplifying the code.
  
  Overall, this change makes the code more efficient and simplifies things for future contributors.

• kernel: expose witness stack and scriptSig for btck_TransactionInput by pzafonte

  Silent payments scanning needs the public key from every input. For SegWit inputs it is in the witness stack. For P2PKH inputs it is in scriptSig. Without these new functions, callers must deserialize the raw transaction themselves to reach that data, which is difficult and error-prone.
  
  Introduces a btck_WitnessStack type and adds the following functions: btck_transaction_input_get_witness_stack, btck_witness_stack_count_items, btck_witness_stack_get_item_at, btck_witness_stack_copy/btck_witness_stack_destroy, btck_transaction_input_get_script_sig

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: Deprecate removeprunedfunds RPC by davidgumberg

Originally added in #7558 as a companion to importprunedfunds, this RPC has no known helpful use while being both dangerous and a maintenance burden.

Despite what the name says, it allows the deletion of arbitrary transactions, and importprunedfunds does not allow the importing of transactions not belonging to the user, and listtransactions does not list transactions not belonging to the wallet, so this RPC can only be used to delete transactions actually belonging to the wallet, and in the unlikely event that transactions not belonging to the wallet are present, they cause no harm except for occupying a few bytes on the users disk.

IRC meeting notes

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

--- Topic 1 ---
stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: hi
andrewtoth: Just wanted to say thanks to everyone who helped in any way to get #35295 across the finish line. That's all.
lightlike: hi
l0rinc: nothing urgent from me, thanks
stickies-v: i've seen a lot of people talk about the speedups on twitter!

--- Topic 2 ---
stickies-v: #topic QML GUI WG Update (johnny9dev)
l0rinc: (just finished a reindex chainstate for https://github.com/bitcoin/bitcoin/pull/35215 in 3 hours on one of my servers by the way :D)
johnny9dev: Updated https://bitcoincore.app/ with permanent links to our latest preview builds.
johnny9dev: Will be sharing it increasingly with more people to get feedback and help hunt down bugs
johnny9dev: that's all for now
stickies-v: giving it a go now 👍

--- Topic 3 ---
stickies-v: #topic QA WG Update (brunoerg)
stickies-v: brunoerg shared his update right before the meeting: https://www.erisian.com.au/bitcoin-core-dev/log-2026-07-16.html#l-178
stickies-v: that's it for the WG updates today. Anything else to discuss?

Read here for the full meeting

Releases

• Bitcoin Core v31.1rc1 is now available

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

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

In this week update we feature the ongoing effort to migrate LDK from GitHub to a self-hosted instance, after the company banned the Lightning implementation from running CI.

We also cover a new BIP being published, BIP95, which defines a new testnet to replace testnet4, and six new BIPs being assigned a number. In particular, BIP453, provides common terminology for transaction components, BIPs 455, 456, and 457 compose the specifications for the SwiftSync protocol for faster IBD, and BIPs 458 and 459 describe half and full signatureaggregation, an important building block towards CISA.

Finally, we cover some interesting news from the Bitcoin ecosystem. In particular, we present some interviews from Nairobi, mempool(.)space joining the SV2 working group, and some useful information about how to protect yourself during the upcoming forks.

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:

• A new repository for LDK is being created to move away from GitHub

  • During the biweekly call, on Monday 6th, LDK contributors discussed the ongoing effort to migrate their codebases from GitHub to a self-hosted instance on Forgejo, managed by rust-bitcoin.

  • The decision to migrate to a self-hosted instance was taken after lead developer Matt Corallo denounced on X that GitHub had banned the project from running CI on their project, effectively forcing developers to look for other alternatives.

  • As of today, developers are focused on migrating rust-lightning. No new PRs can be opened, and the old repository on GitHub remains as a mirror. LDK-node and LDK-server will be the next project to be moved.

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP95: Testnet 5

Authors: Pol Espinasa, Fabian Jahr

Published On: Jun 25th, 2026

Layer: Applications

BIP95 defines a new testnet to replace the current testnet4. The new testnet removes the difficulty
exception defined in the previous iteration, due to its sustained exploitation that has historically made testing difficult. Moreover, testnet5 raises the minimum difficulty and enforces the consensus
rules specified in BIP54 from block 1

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP453: Terminology of Transaction Components

Authors: Murch

Assigned On: Jun 20th, 2026

Type: Informational

PR2195 introduces BIP453, an informational BIP that aims to provide a common terminology for transaction components to be used in Bitcoin-related technical writing and future BIPs.

BIP455: Peer sharing of block spent coins

Authors: Robert Netzke, Ruben Somsen

Assigned On: Jun 22th, 2026

Layer: Peer Services

PR2152 introduces BIP455, the first BIP that composes the specifications for SwiftSync, a protocol for clients to parallelize initial block download (IBD). BIP455 defines how additional data can be shared over the P2P network to allow a client to validate blocks in arbitrary order.

BIP456: Hints for unspent coins

Authors: Robert Netzke, Ruben Somsen

Assigned On: Jun 22th, 2026

Layer: Peer Services

PR2152 introduces BIP456, the second BIP that composes the specifications for SwiftSync. BIP456 defines a representation of the UTXO set to be used as “hint” to verify the correctness of the set of unspent coins that a client arrived at through SwiftSync.

BIP457: SwiftSync initial block download

Authors: Robert Netzke, Ruben Somsen

Assigned On: Jun 22th, 2026

Layer: Applications

PR2152 introduces BIP457, the main BIP that composes the specifications for SwiftSync. BIP457 describes the different components of the protocol and the way it tries to achieve faster IBD through parallelization.

BIP458: Half-Aggregation of BIP 340 Signatures

Authors: Tim Ruffing, Jonas Nick, Fabian Jahr

Assigned On: Jul 2nd, 2026

Layer: Applications

PR2205 introduces BIP458, which describes how to perform half-aggregation of Schnorr signatures, as per BIP340. Half-aggregation is a non-interactive process for aggregating a collection of signatures into a single signature, whose size is approximately half of the combined size of the original signatures. This approach could also be leveraged for signatures in the inputs of Bitcoin transactions, a process known as cross-input signature aggregation (CISA).

BIP459: Full-Aggregation of BIP 340 Signatures

Authors: Fabian Jahr

Assigned On: Jul 10th, 2026

Layer: Applications

PR2210 introduces BIP459, which describes full-aggregation of Schnorr signatures, as per BIP340, a standard for Discrete Logarithm-Based Interactive Aggregate Signatures (DahLIAS) interactive aggregate signature scheme. Full-aggregation is an interactive process for aggregating a certain number of signatures into a single one, whose final size is the same as a single BIP 340 signature (64 bytes), regardless of the number of signers.

One of the most interesting applications of this BIP is CISA. However, the author notes that this would require a consensus change, which is outside of the scope of this proposal.

Other News from the Bitcoin World

• Voices from Nairobi: Check out our interviews with Alex Gleason and M. K. Fain (Team Soapbox) and Sharon Murugi (Btrust) from Bitcoin++ Open-source Edition in Nairobi. Stay tuned for more!

• Mempool <> Stratum V2: The Stratum V2 project recently announced that mempool.space had joined the SV2 working group. The goal is to standardize how miners who build their own block templates leave their mark on blocks in an open format, so that block explorer can read and present them.

• Fork season: with two possible forks happening in the next months, bitcoin holders should be aware of the risks they could be facing. Murch wrote an extensive blog post on replay attacks, Robin Linus provided information on the same topic, and Calle warned against attacks on privacy and risk of leaking private keys. Check them out to be ready for what is coming!

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Toronto this July 22- 24 to talk about finding consensus in Bitcoin!

Merged PR’s

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

• validation: fetch block input prevouts in parallel during ConnectBlock by andrewtoth
  In this change by Andrew Toth, it takes a look at how Bitcoin Core processes prevouts during ConnectBlock. Specifically, he found that each prevout was done one after the other, and if we did not find it in the in-coin memory cache, then a synchronous round trip to leveldb would be done.
  
  The issue was that this would eventually stack up because these trips were being done serially as the block was being validated. This change added thread pools to do these asynchronously to help speed up the process and not bottleneck on looking up these prevouts.

• wallet: Add exportwatchonlywallet RPC to export a watchonly version of a wallet by achow101

  Currently, if a user wants to use an airgapped setup, they need to manually create the watchonly wallet that will live on the online node by importing the public descriptors. This PR introduces exportwatchonlywallet which will create a wallet file with the public descriptors to avoid exposing the specific internals to the user. Additionally, this RPC will copy any existing labels, transactions, and wallet flags. This ensures that the exported watchonly wallet is almost entirely a copy of the original wallet but without private keys.

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: Deprecate removeprunedfunds RPC by davidgumberg

Originally added in #7558 as a companion to importprunedfunds, this RPC has no known helpful use while being both dangerous and a maintenance burden.

Despite what the name says, it allows the deletion of arbitrary transactions, and importprunedfunds does not allow the importing of transactions not belonging to the user, and listtransactions does not list transactions not belonging to the wallet, so this RPC can only be used to delete transactions actually belonging to the wallet, and in the unlikely event that transactions not belonging to the wallet are present, they cause no harm except for occupying a few bytes on the users disk.

IRC meeting notes

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

--- Topic 1 ---
stickies-v: #topic Fuzzing WG Update (dergoegge, marcofleon)
marcofleon: no update this week

--- Topic 2 ---
stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: andrewtoth's #35295 was just merged!!!!!!! LFG!!!
Murch[m]: Hi
l0rinc: https://github.com/bitcoin/bitcoin/pull/35295
stickies-v: congrats guys!
l0rinc: after 2 years and 1000 review comments :D
sipa: hi
sliv3r__: gj!
yancy: hi
marcofleon: nicely done woo!
l0rinc: that's it from us I think :D - thanks for the reviews!
stickies-v: time for a holiday

--- Topic 3 ---
stickies-v: #topic QML GUI WG Update (johnny9dev)
johnny9dev: We merged in all of the features we wanted to get before publishing our preview builds. One last PR for updating the submodule and build has been ACKd and needs to be merged in as the last piece
johnny9dev: I have the macos signing and notarizing setup so we should have our first preview builds today or tomorrow to share with designers and the working group
furszy: hi
johnny9dev: these will be automatically updated and publshed going forward and we hope to use it to hunt down bugs and get feedback on the UX
johnny9dev: next week we'll update the bitcoincore.app website with a link to the builds and some testing information for users
johnny9dev: that is all
stickies-v: nice, looks like you'll get a lot more feedback that way, thanks for the update
stickies-v: Anything else to discuss?
stickies-v: nice and short

Read here for the full meeting

Releases

• Bitcoin Core v31.1rc1 is now available

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

Merged PR’s

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

• wallet: Add exportwatchonlywallet RPC to export a watchonly version of a wallet by achow101

  In this pull request, Ava Chow added a new RPC command, exportwatchonlywallet. This helps users who want an airgapped setup. This RPC will create a wallet file with the public descriptors to avoid exposing the specific internals to the user.
  
  Before this PR, creating that online watch-only counterpart was a manual, error-prone process but now it has become much more streamlined with the exportwatchonlywallet RPC.
  

• fuzz: add ipc round-trip fuzz target by enirox001

  More fuzz tests are being added this week, and this week Enoch Azariah had his PR merged, which added coverage to the IPC. This fuzz test added an IPC fuzz target to exercise the Cap'n Proto/libmultiprocess serialization bridge using an in-process two-way pipe and a reflected test interface.
  
  As always, additional testing and fuzzing are welcome to the Bitcoin Core project, and who knows, maybe this fuzz test will find a bug in the future.

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

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

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

This change adds two major features to the result class:

- For better error handling, adds the ability to return a value on failure, not just a value on success. This is a key missing feature that makes the result class not useful for functions like `LoadChainstate()` which produce different errors that need to be handled differently [^1].

- For better error reporting, adds the ability to return warning messages and multiple errors, not just a single error string. This provides a way for functions to report errors and warnings in a standard way, and simplifies interfaces

IRC meeting notes

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

--- Topic 1 ---
stickies-v: #topic Fuzzing WG Update (dergoegge, marcofleon)
marcofleon: no update
marcofleon: jk
sedited: :D
marcofleon: For in repo stuff, we have three recently merged harnesses related to LevelDB and our CDBWrapper, #34866 and #34887. These should help give some confidence to the changes in #35295 (formerly known as #31132)
marcofleon: I think #35118 is pretty much good to go, so now we have some IPC fuzzing. And then wrt to fuzz PRs, I’ll probably focus on #34651 and #34895 next, if anyone is interested.
marcofleon: dergoegge wrote this exceptional blog post on Bedrock and determinism in the hypervisor: https://brink.dev/blog/2026/06/25/bedrock-deterministic-hypervisor/. Fuzzing with Bedrock found a cheeky bug in our new http server, so that's very cool
marcofleon: nkaretnikov is helping out with Bedrock, specifically https://github.com/oss-garage/bedrock/issues/20. Nice, thank you
marcofleon: And then eugenesiegel is also making moves in Bedrock with https://github.com/oss-garage/bedrock/pull/54
marcofleon: They can elaborate more on the work if they'd like to. I think that's pretty much all I got for now. I can do semi regular updates from now on
dergoegge: lfg
andrewtoth: awesome!
eugenesiegel: stonks
stickies-v: big update, delivered
brunoerg: great!
dzxzg: sick
l0rinc: hi

--- Topic 2 ---
stickies-v: #topic Kernel WG Update (sedited)
sedited: A bunch of review went into #32427, it now supports external readers.
cfields: very cool, nice work fuzzers :)
sedited: More discussion going on in #35569 . I'd like to encourage reviewers to keep commenting, since this might set the direction to a bunch of further work.
sedited: I opened #35641 for introducing callback hooks exposing traces of the script interpreter state during script verification. This is useful for both debugging scripts and testing. This is surprisingly fun to hack on, since it allows for visualization of script interpreter operations.
marcofleon: lfg
sedited: There are also a bunch of pull requests waiting for another ACK or two before merge on the project board: https://github.com/orgs/bitcoin/projects/3
yancy: hi
sedited: that's all

--- Topic 3 ---
stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: Pushed #35634 to save one byte per entry in txospenderindex in a backwards compatible way. This trick was also applied to the new txindex format.
l0rinc: i.e. #35531 - I think we should apply what we learned here to the new index as well
l0rinc: that's it from me
andrewtoth: Thanks for all review in #35295. Nothing else from me.
stickies-v: we haven't had updates from the silent payments WG in a while, so I'm moving that to the archive for now. if anyone wants to pick it up again, ping me and i'll add it back to the rotation
stickies-v: johnny9dev wrote the QML GUI WG updates before the meeting, you can read them here: https://www.erisian.com.au/bitcoin-core-dev/log-2026-07-02.html#l-218

--- Topic 4 ---
stickies-v: #topic QA WG Update (brunoerg)
brunoerg: Hi, about mutation testing for PRs, I'm trying a new setup where it uses an LLM to generate a human-readable report based on the mutation analysis results. The first experiment was in the Erlay impl's PR - you can see the report here: https://github.com/bitcoin/bitcoin/pull/35591#pullrequestreview-4593554791.
brunoerg: feedbacks are welcome, that's all
stickies-v: seems pretty verbose, might be useful to hyperlink instead or put it in details?
brunoerg: yes, I intend to hyperlink
stickies-v: if all the recommendations are important it's fine, but i find llms tend to not be great at estimating priorities/impact etc, so i tend to not be interested in most such assessments
dergoegge: They can be quite good if they don't just go off their own reasoning. If the estimate is result backed (e.g. mutation tests) then I've seen them to be better
stickies-v: Anything else to discuss?
sedited: forgot to mention that we now have a CI job (introduced in #31425) tracking whether the script verification code can be compiled and linked for a bare metal riscv target. This has surfaced bugs before, and is also a first step towards making a consensus library available for such a target, since it prevents future portability regressions.
brunoerg: yes, to become shorter I intend to not inform "What the current tests do well" and focus on what could/should be improved
stickies-v: alright, looks like that's it for today. see you next week folks

Read here for the full meeting

Releases

• Bitcoin Core v31.1rc1 is now available

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

Merged PR’s

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

• Replace libevent with our own HTTP and socket-handling implementation by pinheadmz

  This is the final pull request for libevent, and after it is removed. This is part of an effort to remove the libevent dependency. There were many reasons to remove it, such as it not being regularly maintained and simply wanting to get rid of dependencies that Bitcoin Core did not need.
  
  The main takeaway is that libevent has finally been removed, and we are on the way to Bitcoin Core having basically zero dependencies.

• coins: compact chainstate regularly by l0rinc

  After each completed post-IBD full chainstate flush, give the chainstate a 1/320 chance to compact.
  With roughly hourly full flushes, this averages about once every two weeks and makes a six-month stretch without compaction about a one-in-a-million event.

  The randomized recurring trigger spreads compactions across nodes and keeps maintenance stateless, without storing last-compaction height or timestamp metadata in the chainstate database.
  Compaction runs on a background thread (utxocompact) so validation only schedules the work.

  This change affects Bitcoin Core at the database level as LevelDB is used, and after IBD, normal chainstate churn can leave obsolete entries behind until ordinary LevelDB compaction naturally reaches the affected levels, keeping the chainstate database larger than necessary.
  
  This change randomizes when compaction occurs and keeps the db size down.

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

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

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

This change adds two major features to the result class:

- For better error handling, adds the ability to return a value on failure, not just a value on success. This is a key missing feature that makes the result class not useful for functions like `LoadChainstate()` which produce different errors that need to be handled differently [^1].

- For better error reporting, adds the ability to return warning messages and multiple errors, not just a single error string. This provides a way for functions to report errors and warnings in a standard way, and simplifies interfaces

IRC meeting notes

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

stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
andrewtoth: #35295 keeps getting more review, thank you! I feel like it's close, recent suggestions are fairly minor.
andrewtoth: #35531 is a pretty big improvement for txindex, and backwards compatible. If anyone else wants to take a look.
andrewtoth: That's it from me.
l0rinc: Regular chainstate compaction after the seek compaction removal (#35465) was merged and backported to 29/30/31.
l0rinc: #35594 was added and merged since to cover background compaction in the fuzzer.
l0rinc: #35215 is also needed for #35531 now, reviews for both would be appreciated.
l0rinc: that's it from me
stickies-v: I can't see any other WG leads here, so moving on to the proposed topics

stickies-v: #topic secp256k1 maintainer transition: stepping down and proposing a new maintainer (nickler)
nickler: Hey everyone, I’m stepping down as a libsecp256k1 maintainer. Over the past few months, I haven’t been able to dedicate the time and attention that the role deserves, and I don’t expect that to change in the foreseeable future.
nickler: Pieter, Tim, and I would like to suggest theStack as a new maintainer. We’ve reached out to him, and he said he’d be very happy to take on the role. He has consistently shown that he cares about maintainability and review quality, has contributed and reviewed regularly, and has also shepherded the largest feature PR we’ve had in quite some time (silent payments module).
nickler: We’d like to hear whether there are any concerns, objections, or other feedback on this proposal.
fjahr: no concerns, ack
furszy: ACK
l0rinc: ACK for Sebastian as secp maintainer, congrats
cfields: +1 theStack
dergoegge: ack, no concerns
brunoerg: ACK
hebasto: ack
andrewtoth: ack
dzxzg: maintainer ack
sliv3r__: ack
willcl-ark: thanks for your service nickler!
furszy: +1
theStack: nickler: big shoes to fill. thanks for all your work!
sipa: ACK
darosior: hi
janb84: ack
sipa: also hi
nickler: thanks a lot for giving me that opportunity in the first place! it was an honor
stickies-v: thanks a lot for your work so far nickler, and I agree theStack would be an excellent choice if he’s up for it!
sipa: nickler: thank you for all the work you put in the project, and thanks theStack for willing to take up the role :)
willcl-ark: theStack seems like an excellent candidate to me
darosior: ACK for theStack for maintainer. One question i have (genuine, i don’t really pay attention to the repo) is how much maintainer work is the bottleneck compared to cryptography expert reviews?
b10c: thanks nickler! and ACK theStack.
darosior: (And thanks nickler for all the maintainer work up to this point.)
darosior: And how much theStack’s nomination would help with that
ekzyis: hi
l0rinc: thestACK
darosior: :)
nickler: darosior: I think most of the work is maintenance, code review, and what direction the library should take. Applied cryptographic engineering is definitely important, the more theoretical aspects (protocol security) are more rare, especially if we have a well-reviewed BIP.
abubakarsadiq: ack theStack \o/

stickies-v: #topic QA WG (brunoerg)
nickler: Ok, sounds like we should go ahead with the transition. Thanks for the feedback. And if there are any other comments, let us know.
brunoerg: Hi all, talking with some people, to concentrate/facilitate efforts/communication, a Quality Assurance WG has been created. The idea is moving on QA stuff such as corecheck, mutation testing, CI/infra, etc. If anyone wants to join, here is the signal link: https://signal. group/#CjQKIOZPujaWLLDbJN91B1-je7Zg6W-Dj2J8J-LRh7zRblkrEhDjb97gnPt94glYTmcpxXlDinstagibbs: nickler thank you for your service
stickies-v: nice brunoerg, shall i add you to the WG rotation for the weekly updates?
brunoerg: yes
brunoerg: thanks
vasild: hi
stickies-v: am probably beating a dead horse here, but would be nice if WGs keep their comms in open channels like irc (when it makes sense)
stickies-v: Anything else to discuss?
fjahr: Yes, on ASMap a heads-up that there is a demo of a dashboard available that our Summer of Bitcoin intern is working on: https://jorisstrakeljahn.github.io/asmap-dashboard/
fjahr: He couldn’t be here right now but it would be great if people interested in ASMap could take a look and leave feedback/questions/feature requests on his delving post: https://delvingbitcoin.org/t/asmap-dashboard-tracking-the-asmap-data-history-against-the-observed-network/2652
fjahr: Thanks!
jurraca: also, next ASmap run is scheduled for next week: https://github.com/bitcoin-core/asmap-data/issues/60
stickies-v: that’s a cool dashboard!
ekzyis: i sent a request to join the group, i’m Ram on Signal, can’t set a member label before joining
yancy: hi
stickies-v: looks like we’re all set for today, thanks everyone

Read here for the full meeting

Releases

• No releases this week

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

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

In this week update we feature PR2049 in CDK, which aims to integrate Payjoin in the Cashu implementation.

We also cover Century Metadata, the new venture by former Core-lightning developer Rusty Russell, which promises long term reliable storage and retrieval for small amounts of private data.

We finally present other news from the ecosystem. Notably, Bitcoin++ held its first-ever African conference, LDK banned by GitHub, and a guest book review on the Insider Edtion.

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:

• PR2049 in CDK is adding support for Payjoin in the Cashu implementation.

  • During the weekly call, on Wednesday 17th, CDK contributors discussed PR2049, which aims to integrate Payjoin in the Cashu implementation. As of today, the PR is still in draft.

  • Payjoin is a technique that allows two users to gain more privacy in an on-chain transaction. The receiver provides one of his own UTXOs as an input, breaking the common-input heuristic that chain-analysis companies use.

  • Developers are working in parallel to draft a specific NUT for Payjoin. This PR builds on top of the recent integration of on-chain minting and melting in the Cashu protocol (NUT-30), and on BIP77, the proposal for the asynchronous version of Payjoin.

• Century Metadata is a new project by former Core-lightning developer Rusty Russell.

  • On Monday 15th, Century Metadata founder and former Core-lightning lead developer Rusty Russell presented his new venture during the first ever weekly call.

  • The project promises long term reliable storage and retrieval for small amounts of private data. According to Rusty, this would be very useful for storing those auxiliary data needed to retrieve Bitcoin wallets, such as descriptors.

  • Rusty will hold weekly calls to provide updates on the project. If you want to know more about Century Metadata, watch Rusty’s presentation at Bitcoin++ Economics Edition, where he presented both the general idea behind his venture and the possible tech stack to achieve its goal.

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

• Talking about open-source: Last week, Bitcoin++ hosted its first ever African event in Nairobi, with a focus on what it means to work in public as open-source contributors, and how their work impacts several projects in the Bitcoin ecosystem. The conference streaming will be available on Thursday 25th.

• Banned: LDK contributor Matt Corallo revealed that the Lightning implementation repository had been banned by GitHub with no apparent reason. In particular, LDK developers are no more allowed to run CI, neither a self-hosted instance, on their project, effectively forcing to look for other alternatives.

• A Lodging of Wayfaring Men: Cypherpunk writer Max Hillebrand reviewed for the Insider a book that any modern Cypherpunk should read, A Lodging of Wayfaring Men by Paul Rosenberg. Max describes how this book laid the foundation for what Bitcoin and the whole open-source movement represents today.

• Last Week in Bitcoin goes on Holiday: Your favorite open-source reporter is going on holiday for a couple of weeks! I will be back with the latest news from the Bitcoin developer ecosystem soon, but in the meantime be sure to follow our X account to stay always up-to-date!

Looking for an opportunity to join up with some bitcoin devs in person? Join us in Toronto this July 22- 24 to talk about finding consensus in Bitcoin!

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

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

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

Highlights from the bitcoin developer ecosystem

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

• v0.17.0 of CDK was released.

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

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

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

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

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

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

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

A BIPs Update

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

Other News from the Bitcoin World

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

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

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

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

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

Merged PR’s

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

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

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

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

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

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

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

IRC meeting notes

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

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

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

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

Read here for the full meeting

Releases

• No releases this week

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

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

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

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP452: P2P UTXO Set Sharing

Authors: Fabian Jahr

Assigned On: Jun 4th, 2026

Layer: Peer Services

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

Other News from the Bitcoin World

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

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

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

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

Merged PR’s

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

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

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

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

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

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

IRC meeting notes

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

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

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

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

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

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

Read here for the full meeting

Releases

• No releases this week

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

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

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

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

Highlights from Bitcoin++ — Economic Edition

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

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Other News from the Bitcoin World

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

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

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

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

Merged PR’s

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

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

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

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

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

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

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

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

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

IRC meeting notes

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

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

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

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

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

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

Read here for the full meeting

Releases

• No releases this week

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

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

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

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP450: Formosa — Seed encoding by themed mnemonic stories

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

Published On: May 20th, 2026

Layer: Applications

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

BIP449: OP_TWEAKADD — x-only key tweak addition

Authors: Jeremy Rubin

Assigned Date: May 23rd, 2026

Layer: Consensus (Soft Fork)

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

Other News from the Bitcoin World

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

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

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

Merged PR’s

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

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

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

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

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

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

IRC meeting notes

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

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

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

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

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

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

Read here for the full meeting

Releases

• No releases this week

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

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

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

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP323: 24 nVersion bits for general purpose use

Authors: Matt Corallo

Published On: May 13th, 2026BIP39

Layer: Applications

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

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP450: Formosa—Seed encoding by themed mnemonic stories

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

Assigned On: May 12th, 2026

Layer: Applications

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

BIP139: Wallet metadata backup format

Authors: Pyth

Assigned On: May 11th, 2026

Layer: Applications

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

BIP138: Compact encryption scheme for non-seed wallet data

Authors: Pyth

Assigned On: May 11th, 2026

Layer: Applications

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

Other News from the Bitcoin World

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

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

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

Merged PR’s

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

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

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

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

• validation: fetch block inputs on parallel threads by andrewtoth

  Problem

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

  Solution

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

IRC meeting notes

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

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

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

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

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

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

Read here for the full meeting

Releases

• No releases this week

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

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