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!

Intro

I began investigating the Coldcard hack and was immediately shocked. I need to explain why.

When we developers work on code, we organize or code changes into changesets we call “commits.” The purpose of doing so is to show a clear history of what code was changed including why and how.

This is done precisely for instances like this where it appears Bitcoiner’s funds are being stolen en masse, so we can investigate and understand exactly how it could happen.

Good developers write clear commit messages, written notes that go along with the code changes that explain what the specific change is accomplishing.

To make a clear commit message, you typically want to the commit to represent a smaller change of code, so there’s less to comment on.

A good goal as a developer is a high commit message to change ratio. The more lines of code that you change, the more comments explaining why you’re changing the code. More message and less code changes per commit is generally a good idea.

Here is an example chosen randomly from some of my own work.

The commit message is 235 characters, and the commit changes 15 lines of code. That’s a ratio of 235/15 = ~16.

In the cold card, the commit that introduced the low entropy bug is here.

The commit message is 5 characters and is simply the word “runs.” The commit changes 1534 lines of code making the ratio 5/1534 = ~0.003

This is an atrociously bad comment to code change ratio.

There are some rare instances where a low comment ratio is justifiable -- but changing the most important part of the code is not one of those cases!

Code that touches functions critical to the security of the project need to have a higher ratio of comments to changes and more stringent review.

The second commit contributing to the weak entropy issue on Coldcards is here.

The commit message is 1 character: simply the character “x.” The commit changes ~1000 lines of code making the ratio 1/1000 = ~0.001

The Issue

In the commit titled “runs” (ratio: ~0.003), it appears they are importing and configuring C code to make custom micropython code work on the STM32, the board that all Coldcards run on.

STM32 is the most common CPU for small devices like this, and configurations like what this commit introduces are common.

In the ‘runs’ commit, the hardware RNG (Random Number Generation) was disabled with the following line of code.

#define MICROPY_HW_ENABLE_RNG (0)

This is what caused the bug. Setting this value to zero tells the default micropython rng code to not use the hardware RNG device and that it should use the Yasmarang RNG instead.

The developer added an inline comment “explaining” this change

// We have our own version of this code.

The COLDCARD version of this code appears to be in reference to the functions added in rng.h and rng.c

rng.h

MP_DECLARE_CONST_FUN_OBJ_0(pyb_rng_get_obj);

MP_DECLARE_CONST_FUN_OBJ_1(pyb_rng_get_bytes_obj);

These appear to be an attempt to override the stm32 rng library’s `pyb_rng_getobj` function. This approach ran into trouble. The stm32 rng.c file already defines the pyb_rng_et_obj variable and sets the value to `pyb_mg_get`. You can’t have two definitions of the same variable and have it compile.

rng.c

MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);

Expanding the macro and thinking of it logically is just this pseudocode:

var pyb_rng_get_obj = pyb_rng_get

Commit `37e4af5` adds a custom rng.c file, where he copy pasted the same macro definition

MP_DEFINE_CONST_FUN_OBJ_0(pyb_rng_get_obj, pyb_rng_get);

There is now no way for this code to compile. It appears that the developer is naively trying to override the `pyb_rng_get_obj` variable by creating a duplicate version of the variable. C does not work this way. This error would have given him a compiler error of “duplicate symbol pyb_rng_get_obj, because there are now two places where it is defined: the stm32 library, and in the newly added rng.c file.

From here, I assume in a bout of frustration, he set `MICROPY_HW_ENABLE_RNG` to 0, which would have resolved the compiler error.

Sometimes when developers are flailing, they’ll try random things to see if it helps. Setting `MICROPY_HW_ENABLE_RNG to 0 would have made the compiler error go away ***for the wrong reason***.

This swept the compiler error of having two conflicting definitions under the rug.

// We have our own version of this code.

#define MICROPY_HW_ENABLE_RNG (0)

Setting MICROPY_HW_ENABLE_RNG to zero completely removed the code that used the hardware random number generator, or lines 31 to 80 in the stm32 rng.c file. This had the side effect of removing the second definition of pyb_rng_get_obj, which “fixed” the compiler error.

The compiler error was begging the programmer to reconsider his logic. Instead of that happening, the compiler error was just silenced. The compiler was giving the developer one last chance to reconsider what he was about to do, but the alarm was ignored and silenced.

Now everything is lining up. It looks like the developer tried to override the variable, but ran into conflicting definitions. When confronted with a “duplicate symbol” error, tried changing random things to get the code to run.

He discovered that changing `MICROPY_HW_ENABLE_RNG` to 0 made it compile. He probably had no idea why but came up with a theory. We don’t need that anymore because we have our own version of the code.

His definitions of the pyb_rng_get were in place, and the code he was intending not to run had been turned off.

Confusing Call Chains

Coldcard’s firmware is written in C. The application layer, that tells the hardware what to do is written in Python. The Python code calls into the C code. The developer overwrote the pyb_rng_get functions.

Unfortunately for many, the pyb_rng_get functions that his code overwrote weren’t what is actually called from the python code. The Python code in v4.0.0 of the Coldcard calls random.bytes() in their make_new_wallet() function.


async def make_new_wallet():

await ux_dramatic_pause(’Generating...’, 4)

seed = random.bytes(32) # OOPS

assert len(set(seed)) > 4

seed = ngu.hash.sha256s(seed)

await approve_word_list(seed)

Setting `MICROPY_HW_ENABLE_RNG` to 0 turned off the stm32 library provided hardware code, but allowed the developer to set `pyb_rng_get_obj`. Problem is, pyb_rng_get_obj is the Python-visible pyb.rng() callable.

That’s not what the developer is invoking here in the wallet function. Instead, they’re using `random.bytes(32)` which skips the pyb_rng_get callpath entirely and instead calls `rng_get`, which due to the `MICROPY_HW_ENABLE_RNG` being set to zero used the micropython stm32 rng.c definition at L112, which called the insecure Yasmarang, non hardware wallet entropy.

uint32_t rng_get(void) {

return pyb_rng_yasmarang();

}

Simply put: the firmware change overwrites functions that aren’t used when creating a new wallet while, as a side effect of including the python method overrides, turns off the hardware RNG usage in every case, instead using a very weak random number generator.

The final bit of evidence is the commit message itself. It was simply the message “runs.”

Developers, if you are ever in this scenario, please stop. Whatever you’re getting paid is not worth the devastation you might potentially cause for others.

Do not ship code you do not understand.

A curse on micropython

At the core this appears to be a consequence of too many layers of complexity. There’s the micropython library, the bindings between the C code and the Python application, and the new functions that COLDCARD is adding. Was the developer that made this patch actually a python developer who was forced to write and handle C?

Micropython creates the illusion embedded developers do not need to understand C, their CPU, or other advanced concepts to do embedded programming.

That is a lie.

And this catastrophe is the result of believing that lie.

You must understand the code you are shipping. Full stop. There are no excuses. Layers of misdirection make it harder to understand.

If you make changes, make sure that you verify that they are doing what you intend them to do.

The commit messages here tell the real story. Treating the most critical part of your code with the lack of diligence and understanding shown here is inexcusable.

You, as a developer working on Bitcoin, need to take your time to understand your changes, document them clearly, and verify they do what you think.

When people’s lives are ruined, they won’t and shouldn’t give you sympathy. You need to appreciate the funds you are putting at risk. Your task as a bitcoin developer is of the highest importance. I have made mistakes myself in the past, but there are no excuses for a failure to understand what you are shipping when the code is this critical.

I hope that we, as an industry, can learn from this and lean on each other to ship secure code, as a community of developers.

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

bitcoin++ hosted its first Open Source Edition hackathon in Nairobi, Kenya, bringing together builders from Africa and around the world to work in public on practical Bitcoin software.

The hackathon ran during bitcoin++ Nairobi, the open-source edition, held June 17-19, 2026 at Pride Inn Azure Towers. The competition drew 90 participants, a record-breaking 37 submitted projects, and a prize pool of nearly 10 Million Satoshis across the main competition and sponsor tracks.

The event was supported by Bitcoin++, Soapbox, Btrust, and Minmo. Projects competed in the overall track, plus prizes for the best use of Soapbox, best contribution to open source, solving open-source contribution spam, best use of Pontmore, and the best tool for mobile-money brokers or agents using Bitcoin.

The judging panel included niftynei of Base58, Jodom of Minmo, Alex Gleason of Soapbox, Fabian Jahr of Brink, Sy of Btrust, Judy Imasuen of HRF, Kelvin Isievwore of Btrust, Michael of Cashu, Mark Kamau of Designing Africa, and Hadi Alamdar and Marvin Charles of Block.

Projects largely focused on mobile money and M-PESA, remittances, open-source developer education and support, maintainer tooling, and practical Bitcoin interfaces like Nostr relays, Lightning invoices, PSBTs, feature phones, and local merchants.

Projects

WestToEast, built by Nourou of Banxaas, won 1st Overall. The project connects West African mobile-money systems to Kenya’s M-PESA using Lightning, LNURL, Banxaas, and Tando. It lets a sender using XOF, XAF, or GNF through local mobile-money wallets in Senegal, Ivory Coast, Cameroon, or Guinea send value to a recipient receiving KES through M-PESA in Kenya.

The system uses Tando’s LNURL flow as the Kenya-side payout rail. Banxaas quotes the user in their local currency, receives the West African mobile-money payment, sends sats over Lightning to Tando, and Tando completes the M-PESA payout. According to the team’s submission, a Kenyan recipient can receive KES from three currencies and ten mobile-money wallets in less than 30 seconds.

Robin, built by Fidel Otieno of Bitika and Chris Oketch, won 2nd Overall. Robin is a context-aware guide for prospective Bitcoin open-source contributors. It asks who you are, what you know, and what you want to work on, then recommends where you can make a useful contribution.

The important idea is honest redirection. A new contributor does not always need to be pointed at Bitcoin Core. Sometimes the right answer is: not Core, not yet. Robin directs people toward work they can actually help with, while still giving stronger contributors specific routes into higher-context projects.

“Everyone else is building bouncers. We built a tour guide,” the Robin team wrote.

nairobi2, submitted by Anon Ym (GitHub), won 3rd Overall. The project is a permissionless ridesharing app with market-based price discovery and Sybil protection through verifiable Bitcoin notarization. The inspiration came from a local complaint many Nairobi riders and drivers understand immediately: platform taxis take large cuts and fix prices.

Built with Rust, Slint, Nostr, and Lightning, nairobi2 sketched an open alternative where drivers and riders coordinate directly and reputation can be anchored through Bitcoin-linked proofs rather than a closed platform.

Hodlr, built by Paul Eke, won Best Beginner Hack and an Honorable Mention. Hodlr lets users lock Bitcoin until a chosen date using the idea of CLTV-enforced savings. The project was framed around a lived problem: in weak local-currency environments, Bitcoin often becomes an emergency fund before it can become long-term savings.

Dishi Fresh, built by Thomas Cadra and Colly Sindani, won Best use of Soapbox. The project connects local recipes to nearby grocers, butchers, shops, and riders, with an M-PESA STK push flow and SMS notifications to vendors. It was one of the clearest examples of the week: useful local commerce first, Bitcoin-adjacent tooling second.

UTXOracle BTC Calculator, built by Parrish (Devpost: kingddd6767), won Best Contribution to Open Source. The project calculates a BTC/USD price from a user’s own Bitcoin node using UTXOracle instead of exchange APIs. The team also submitted a pull request to integrate UTXOracle into nix-bitcoin.

The open-source contribution spam track produced two direct maintainer tools. Filter, built by John Osezele, a Btrust grantee working on Bitcoin Dev Kit and Rust Payjoin, won the track. Filter is a configurable GitHub App that scores pull requests for spam likelihood using explicit rules around contributor reputation, PR description quality, diff patterns, AI-writing signals, and repo-specific checks.

Core-Gate, built by Aishaomaa Farah and Mary Wangui, attacked the same problem from the Bitcoin Core side. It runs as a fast GitHub Actions workflow before expensive CI, scores each incoming pull request against contribution guidelines and review-risk signals, then routes it into “needs work,” “needs attention,” or “ready for review.”

Together, Filter and Core-Gate showed that the AI-spam problem does not need to be treated as an argument about AI in the abstract. Maintainers need concrete triage tools, contributor routing, overrides, and explainable checks that reduce review waste without punishing sincere new contributors.

Pontswap, built by Wesley Nyamu and Cynthia Muemi, won Best use of Pontmore. Pontswap implements a Nostr-native coordination layer for Bitcoin-fiat swaps. Every public state transition is a signed Nostr event; private payment instructions are sent through NIP-59 Gift Wrap; and the full swap state chain can be replayed in a public explorer without exposing payment details.

LNpesa, built by Denver Mtange, Kelly Gakii, and Kendi Litala, won Best Tool for Mobile Money Brokers or Agents using Bitcoin. LNpesa is a USSD interface for Bitcoin agents built on the Pontmore open protocol over Nostr. An agent can dial a code, register from a feature phone, set liquidity, and publish signed Pontmore events to Nostr relays.

“No smartphone. No app. No internet data,” the LNpesa team wrote.

The project matters because it treats the interface as the adoption problem. In Kenya and across the continent, mobile money already works on feature phones. LNpesa brings Bitcoin agent workflows to that same surface instead of assuming every user will install a smartphone wallet first.

Tando’s Ark, built by Shamsudeen Adedokun of Tando and Matthew Vuk of Second, received an Honorable Mention. The project swapped Tando’s Lightning node infrastructure for Bark, Second’s implementation of Ark, while leaving the application layer and M-PESA payout flow intact.

For Tando, that means a path away from channel management and inbound-liquidity overhead. Existing Lightning users can still pay a unified invoice, while Ark-native users on the same Ark server can pay with arkoor transfers at 0% routing fees.

“The network effect is the product,” the Tando’s Ark team wrote.

Other Honorable Mentions included SiriScore, built by Susan Githaiga, Nkatha Kaburu, Rose Jane, and Nelly Nakhero, which scores Bitcoin transactions for privacy risks before they are signed or broadcast; Zaptip, built by Rita Anene, which adds a Lightning zap button to GitHub profiles and repos; MindfulSats, built by Tony Nakamoto, which uses Bitcoin-backed accountability for personal goals; and PoWR, built by Shannon Kioko, Lucy Kamau, Anne Mahonga, and Salma Adam, with support from the Dada Devs community.

PoWR turns GitHub contribution history into a proof-of-work-style reputation profile. The project also reflects the same maintainer problem that shaped several other submissions: not all commits are equal, and open-source ecosystems need better ways to recognize meaningful work.

Conclusions

The hackathon’s strongest through-line was pragmatism. Builders were not waiting for perfect abstractions or perfectly finished protocols. They used the tools already available: LNURL, Tando, Bark, Nostr, Pontmore, GitHub Actions, PSBTs, UTXOracle, USSD, M-PESA, and open-source AI tools. The result was rough in places, as hackathon work always is, but the direction was clear.

Bitcoin++ Nairobi showed that open-source Bitcoin work in Africa is not theoretical. It is mobile-money settlement, GitHub maintainer tooling, feature-phone UX, local commerce, contributor onboarding, transaction privacy, and protocol implementations that other teams can build on.

“The bitcoin++ week has proven once again that magic happens when people gather in one place,” said Sharon Murugi, Communications Lead at Btrust.

What began as a conference

hackathon became a practical map of where Bitcoin open-source development is going: more local, more interoperable, more aware of maintainer bottlenecks, and more focused on getting working software into the hands of people who can use it.

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

Tune in for another Insider Report!

Second (@secondhq) has partnered with Tando (@tando_me), Mavapay (@mavapay), and JunubBTC to bring Ark-powered Bitcoin settlement to mobile-money systems across five African countries.

The settlement layer is powered by Bark, Second’s implementation of the Ark protocol: a fully open-source, self-custodial stack in which every payment gateway keeps absolute self-custody, and settles bitcoin instantly over the Ark protocol without routing fees.

During bitcoin++ Nairobi, the open-source edition (June 17-19, 2026), Matthew Vuk (@matthewvuk2) of Second partnered with Tando to swap out their existing Phoenix (phoenixd) LSP infrastructure for a Bark client that connects to an Ark server for liquidity. The change replaces only Tando’s lightning infrastructure layer, while the application layer and the M-PESA payout are untouched.

It removes the two costs of running a Lightning node as a receiving business:

1. there are no channels to open and no inbound liquidity to provision (the Ark server’s Lightning gateway supplies capacity on demand),

2. Tando no longer pays inbound-liquidity fees. In practice, moving from the phoenixd LSP to a bark client cuts Tando’s liquidity costs by an estimated 50-80%: capacity now comes from the Ark server’s Lightning gateway on demand, rather than from pre-provisioned, fee-bearing channels with an LSP. Senders can still pay from any Lightning wallet; Ark-native wallets pay over arkoor at 0% routing fees; and Tando keeps full self-custody throughout.

Bhang (@DevOpsbhang), of JunubBTC in South Sudan, has joined to build a Tando-like solution for his country, working with the Second and Tando teams to demo it on MTN MoMo (Mobile Money). The collaboration lets users move value between M-PESA in Kenya and MTN MoMo in South Sudan directly, with no liquidity management and no routing fees on the Ark settlement layer. Each country runs its own bitcoin-to-mobile-money gateway and holds absolute self-custody of its own funds.

At the Nairobi BitDevs, Matthew presented the collaborative work between Tando and JunubBTC: a mobile-money gateway with 0% routing fees between Kenya and South Sudan, with settlement powered by the Bitcoin Ark.

“The Ark server is a coordinator, never a custodian,” said Matthew. “It abstracts away the channel and liquidity management, so an operator runs a gateway without running a Lightning node, and keeps absolute self-custody. Their balance is held as real VTXOs that they can always exit unilaterally and broadcast on-chain; they are not just leaves or IOUs pointing at money held overseas. For Africa, that sovereignty is the whole point: these gateways should not depend on closed-source servers, or on custodians off the continent. And because every gateway settles on the same Ark, each new gateway has a compounding network effect of cost benefits.”

The Mavapay (@mavapay) team, present at Nairobi BitDevs, has joined the working group, led by Theophilus Isah (@Extheo) and Solomon Eze (@IgboPharaoh), to extend the system beyond mobile money to bank accounts in Nigeria, Ghana, South Africa, and Kenya. Mavapay’s app already converts Bitcoin into naira, cedi, shilling, or rand and pays it out to a bank account or mobile-money wallet in under a minute over the Lightning network; settling that flow over Ark is the next step.

Together this would enable swaps across five countries and their currencies (the Nigerian naira, Ghanaian cedi, South African rand, Kenyan shilling, and South Sudanese pound), reaching a combined population of more than 400 million people in Africa. It would be the first Ark-powered settlement network of its kind, built on a fully open-source stack that guarantees the sovereignty of every gateway operator.

The system introduces a new custom Cashu NUT-05 extension that lets holders of blinded tokens in a Cashu mint melt them directly into a mobile-money gateway over Ark, at 0% Ark-network fees. Because the tokens are blind-signed, holders can privately redeem ecash for mobile money, or direct bank deposits, across the five African partner countries.

Mikey (@_mykhael), a core contributor to the Cashu project (@cashubtc), will lead a Cashu application built specifically for the African market on top of this network, moving value between local currencies and blinded ecash. It uses bark-powered Cashu mints hosted locally in Africa, which unlock a new form of proof-of-reserves made possible by the cosignatures of the Cashu Mint’s Bark client and the Ark server. The Ark server can cryptographically attest a minimum (lower-bound) balance for a mint whose Lightning node has been replaced by a Bark client.

The bitcoin++ week has proven once again that magic happens when people gather in one place.

Meeting Matthew at BTC Prague set off a two-week sprint where I’ve learned more about Ark than ever before.

Ark introduces incredible benefits for scalable, privacy-preserving, and seamless bitcoin transactions, and seeing it integrated across Tando, Mavapay, and Cashu is a massive milestone.

I’m so excited to watch the ideas born during this week continue to grow.

Sharon Murugi (@Murugi___), Communications Lead, Btrust (@btrustteam)

With the working group now established, the partners are preparing to launch a shared application layer and product suite for African markets: an open-source, self-custodial settlement network following the model of Tando where value moves freely between local currencies, mobile money, and Bitcoin, with every operator sovereign over their own funds and no money held off the continent.

The first corridors, Kenya’s M-PESA and South Sudan’s MTN MoMo, are already running on a testnet; bank rails and additional countries follow as Mavapay and new partners join. What began as a two-week hackathon sprint is becoming the settlement backbone for a continent-scale, sovereign Bitcoin economy.

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!

There are five or six books that every serious cypherpunk ends up reading. A Lodging of Wayfaring Men is one of them. For two decades it lived as a quiet inheritance, copied as a PDF between people who built Tor relays, ran early e-gold accounts, traded on Liberty Reserve, wrote the Bitcoin patches that mattered, and shipped the privacy tools we use today. A new illustrated hardcover edition has been edited and republished. The timing is good, because the world the book describes is the world we are now living in.

Paul Rosenberg wrote the manuscript in the late 1990s while running the arbitration system at a project called Laissez Faire City. The project shipped a working encrypted financial system in 2001, complete with anonymous bearer certificates, a stock exchange, a futures market, encrypted webmail, and a distributed forum, all seven years before the Bitcoin white paper. Rosenberg sat across the table from the project’s principals, audited the books when one of them went bad, couriered gold coins on settled disputes, and oversaw the investigation that closed the project out. As the man who maintained the donor list of every founder who put money in, he kept it as long as the work required and burned it once the work was done.

He wrote the novel to tell the story without naming the people. The fiction was a courtesy to the donors, who needed to stay out of court. The story is theirs, lightly disguised. For the first decade it circulated by email and on private mailing lists, photocopied, forwarded, passed quietly from one builder to the next. People who held copies treated them like contraband, because in spirit they were. Every serious cypherpunk who read it walked away understanding two things at once: that the cypherpunks had already done it before Bitcoin existed, and that the work had only just begun.

What the novel does is make the cypherpunk argument as a story. Before the white paper, before Tor was a usable network, before Lightning, before Nostr, Rosenberg wrote a small group of mathematicians, ex-ministers, financiers, and Silicon Valley programmers into a story about shipping fully encrypted electronic cash from a series of safe houses across three continents. The NSA briefer in the book reads a January 1995 Treasury memo describing money the agency cannot read or trace, money whose addresses do not follow the standard protocols, money whose messages leave no record of origin or destination. The memo is fictional. Everything it describes is now operational in your pocket. Reading it in 2026 is a strange and pleasant kind of vertigo.

I should say where I am standing before going further. I met Paul years ago, and shortly afterward I sat down with the manuscript. The conversations and the reading were one continuous education. The book convinced me the work was possible and worth doing, and I went on to work on Wasabi. Years later, when the powers that be increased their pressure and attacks against us exponentially, zkSNACKs the company and its coordinator were pushed into closing. Rosenberg’s strategic logic landed in the real world exactly as he had written it. The state went after the company because the company was the named target it could reach. The wallet code had been FOSS from day one. New coordinators came online within days. FOSS is unstoppable, and Rosenberg saw the architecture twenty-five years before any of us shipped it. I am one of dozens of builders whose work is downstream of this book.

One of the book’s anchor scenes plays out like this. A coordinator named Michael Anderson counts three hundred sealed envelopes onto a table in front of a Marine survivalist friend. Each envelope contains the source code for the underground marketplace. Each carries instructions to mail it out if anything happens to him. “By distributing the code openly we make ourselves replaceable,” he says. “A thousand markets will spring up in a thousand different flavors.” This was written in the late 1990s. When zkSNACKs went down, the Wasabi code kept running and new coordinators kept the wallet alive because the architecture Paul Rosenberg describes is the architecture freedom tech has shipped ever since.

In a second scene, a Los Angeles defense attorney named Anthony Bari walks into a US Attorney’s office and forces a treason charge down to misdemeanor computer fraud by threatening to take the indictment paperwork to every newspaper that will read it. “You cannot have a public trial because everyone would learn your secret.” Around Bari orbits a veteran FBI field agent named Max Kaminski, who runs an establishment frequented by other agents and quietly feeds intelligence back through a young agent who finally defects. Max says it more than once, in different rooms, to different agents who are not yet ready to hear it. “Law enforcement is a cheap substitute for justice. Half-justice at best, and frequently much less.” Read it twice and notice the small word in the middle. Max says it is a *substitute*, the way margarine is a substitute for butter: a cheaper good produced by industrial process and sold to people who can no longer find or afford the original. Margarine is what you get when the original is taken off the shelf. Justice is what the cypherpunk defense bar is now putting back on it, one courtroom at a time.

Halfway through the book, the argument widens. The title of the book comes from Jeremiah 9: ”Oh that I had in the wilderness a lodging of wayfaring men, that I might leave my people and go from them.” A character quotes it in a Vancouver hotel lobby late in the book, and it lands as the structural key to everything that came before. A lodging is not a building. It is a portable, self-replicating refuge culture for people who want to live separately from a system that has no intention of leaving them alone. The back half of the novel dramatizes the lodging in three countries within two chapters, and once you see the pattern you cannot unsee it.

Bitcoin Twitter has the citadel meme, and Rosenberg has the lodging, and the two ideas point in opposite directions. Citadels are walled, defensive, finite, often paranoid, expressed in the language of survival under siege. Lodgings are hospitable, portable, self-replicating, and explicitly take in any nice person you know. A citadel ends with you and your stack and a perimeter. A lodging looks like physicists teaching geometry to children on an Italian beach, parents trading nights of childcare, Nobel laureates running ad-hoc seminars, landlords competing to keep the same off-season tenants the following year. Citadels are last fortresses before the end. Lodgings are first houses of the next civilization. Bitcoin culture has spent twenty years arguing about the technical layer and almost no time on the cultural layer, and Rosenberg’s late chapters are the cleanest available blueprint for the layer above the protocol.

The closest modern Free Souls houses are sovereignengineering.io and the Bitcoin++ conferences. Sovereign Engineering gathers freedom-tech builders into in-person residency cohorts to ship together. Bitcoin++ pulls protocol engineers into the same room to prototype and ship across a single shared agenda. The Italian beach in the novel, the SEC residency in the present, and a Bitcoin++ event are the same architecture under different names. Builders who would otherwise be working alone gather in physical proximity, sit at the same table, trade ideas across disciplines, eat together, build together, and walk away with friendships that hold under pressure. A lodging proves itself every time a small group of competent people gather to build something the surrounding system would prefer they did not. The lodging is already being built, and the novel gave it a name.

This hardcover edition includes the full Appendix, a body of essays attributed to the character Prester John. Appendix A is a wonderful history of religious thought, written with the directness of someone who has lived inside the material for forty years and decided to skip the academic throat-clearing. It treats the Hebrew prophets, the Gospels, the institutional priesthood, and the modern intelligentsia as a single continuous problem: human beings handing their judgment over to a class of people who claim the authority to think for them. Read on its own, Appendix A would be a respected short book. Embedded inside the novel, it is the philosophical scaffolding that makes the lodging make sense.

Whether Satoshi sat at one of those tables or read the same pages is the question Rosenberg has left open on purpose. Either he was at the table and lived the project, or he read the manuscript and ran with the lesson. Either answer is electric. Rosenberg himself has said that he would love to see whether his favorite Satoshi candidates were on the donor list, and then he reminded everyone that he burned the list on principle the day the work was done, smashing the hard drive that held it. So the names are gone, and the lineage is written into every Bitcoin block since genesis, and the only people who could close the loop are the ones with a stake in keeping it open. What we get instead is the thing the receipts hand us. The cypherpunks shipped the financial cryptography seven years before the white paper. The white paper inherited the strategic logic of the book, and the book is now sitting on the shelf where the rest of the inheritance is waiting. Read it for the technical retrospective.

Read it again for the lodging. Pair it with Rosenberg’s Untold Story of the Greatest Crypto Project Ever, which serves as the author’s quiet commentary track on his own fiction.

We are inside one of the great adventures of human history. Cryptographic primitives are sufficient, capital is in place, legal infrastructure is being built in real courtrooms by people who took Bari’s playbook seriously, and the lodgings are forming. Bitcoin is the money, Nostr is the social layer, FOSS is the strategic logic, and the lodging is the architecture we live inside while we build. What remains is for each of us to find our seat at the table, ship the next brick, and welcome the next nice person we know.

Rosenberg wrote the book to tell a story whose principals could not be named. Two decades later the principals’ work is on every laptop, in every wallet, in every courtroom where a privacy-tool defendant is finding out he has a defense bar. The donor list is gone. The donors are everywhere. Read the book, and then go find your seat at the table.

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!