Also: last week branch-off missed the calendar. This week, sedited tagged v32.0rc1. The testing guide is up. I do not see binaries on bitcoincore.org yet, and Thursday’s meeting was ten minutes of working groups plus a nudge to still review things for v32.

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 importdescriptors interface by polespinasa

  This week, Pol Espinasa had his change merged, which tackled the fact that importing descriptors was RPC-only and the Bitcoin Core GUI does not use that interface, so it could not offer descriptor import. This is what you need for more complex wallet setups like multisig.
  
  The PR moves the core logic out of ProcessDescriptorImport and into CWallet::ImportDescriptor, then adds interfaces::Wallet::importDescriptors() so the GUI can call it directly. Results come back as wallet::ImportDescriptorResult with a FailureReason enum, and the RPC layer maps those back to JSON-RPC error codes. Pol already has a GUI menu on his fork to try it, and said he’ll open that against the GUI repo now that this is in.

• wallet: Add addHDkey interface by pseudoramdom
  Same story, different RPC. addhdkey existed. The GUI still could not call it. Ram (pseudoramdom) moved the wallet logic into CWallet::AddHDKey(), introduced a generic WalletError with a machine-readable code plus a translated message, and added interfaces::Wallet::addHDKey() which generates a new HD key and returns the master xpub. The RPC still does argument parsing, and now also exposes the master fingerprint in hex. Pair this with derivehdkey and the GUI can produce a shareable xpub during multisig setup without going through RPC.

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: don't double discard output groups with avoidpartialspends by fjahr

  fjahr called this out in Thursday’s meeting as maybe still interesting for v32. Clean merge, not a draft. If you have review time this week, start here.

  With `-avoidpartialspends` or `avoid_reuse`, `GroupOutputs` puts every positive-value output into both the mixed and the positive-only map and runs `push_output_groups` on each, so a group rejected by the eligibility filters lands in `discarded_groups` twice. `AutomaticCoinSelection` then subtracts it twice and could fail with an insufficient funds error even when there would be enough confirmed coins to cover the payment.

  Not a problem in a default wallet but it can happen with `sendtoaddress` from an `avoid_reuse` wallet, or with `-avoidpartialspends=1`.

IRC meeting notes

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

𝗳𝗷𝗮𝗵𝗿: There are no pre-proposed meeting topics this week. Any last minute ones to add?
𝗳𝗷𝗮𝗵𝗿: Ok, let's do the WGs

--- Topic 1 ---
𝗳𝗷𝗮𝗵𝗿: #topic QA WG Update (brunoerg)
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: no update this week, will have a big one next week.

--- Topic 2 ---
𝗳𝗷𝗮𝗵𝗿: #topic QML GUI WG Update (johnny9dev)
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Opened issue #36289 to track the QML staging branch
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Will use this issue to share my plan for merging gui-qml and help with organizing and prioritizing current issues that remain
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: We got another new contributor to the project this week, Andrea, and she has already fix a high priority issue for us
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: thats all for this week

--- Topic 3 ---
𝗳𝗷𝗮𝗵𝗿: #topic Benchmarking WG Update (l0rinc, andrewtoth)
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵_: no update
𝗳𝗷𝗮𝗵𝗿: That's it for the WGs afaict, anything else to discuss?
𝗳𝗷𝗮𝗵𝗿: Anything of note from release testing?
𝗳𝗷𝗮𝗵𝗿: There is still some stuff to review here: https://github.com/bitcoin/bitcoin/milestone/84
𝗳𝗷𝗮𝗵𝗿: And maybe #36284 is interesting to still make into v32

Read here for the full meeting

Releases

• v32.0rc1 was tagged 2026-09-14 by sedited. Signed git tag exists.

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’s update we feature the latest release, v3.1.0, of the bindings library for BDK, exposing the latest development to several programming languages.

We also cover the publication of BIP332, defining a new, opt-in P2P message, a a new BIP that has been assigned a number, BIP394, which defines a new output script descriptor, called rawtr() .

We finally discuss some other news from the Bitcoin developer ecosystem. In particular, we talk about a bug in the legacy gateway module in Fedimint, a blog post from Second on how to board an Ark using Payjoin, and a research from BlueWallet CTO on the security of non-custodial wallets on the App Store.

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:

• The BDK team released the latest version of their bindings, v3.1.0, bringing the whole library to several programming languages

  • During their weekly call, on Tuesday 8th, BDK contributors discussed the release of bdk-ffi v3.1.0, the library that allows to expose the Rust codebase to several other programming languages, such as Dart, Swift, Kotlin, Python, and react-native.

  • This release upgrades UniFFI — the bindings generator — to v0.31.2 and brings the bindings up-to-date with the latest release of the BDK Wallet libraries, exposing several new methods, such as those to choose the coin selection algorithm, wallet signers, APIs to load wallet parameters, and more.

  • bdk-dart — the library exposing BDK to Dart — has been upgraded to use the latests bdk-ffi library, and a new release candidate, v1.0.0-rc.4 has been published. This update brings the Dart bindings closer to a first stable release.

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP332: Stale Tip Relay

Authors: Anthony Towns, w0xlt, Ram

Published On: Sep 9th, 2026

Layer: Peer Services

BIP 332 defines a new, opt-in P2P message called staletip whose goal is to announce recent stale chain tips to peers. The message contains the block height at which a stale branch diverges (the fork point), a vector containing the block headers belonging to the stale branch, and a flag signaling willingness to serve that block data. This may be useful for monitoring the network health, since increases in the stale block rate may expose validation or relay bottlenecks, network partitions, or selfish mining behavior.

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP394: rawtr() Output Script Descriptors

Authors: jeanpablojp

Assigned On: Sep 9th, 2026

Layer: Applications

PR2251 introduces BIP394, which defines a new output script descriptor, called rawtr() . The descriptor — that has been available in Bitcoin Core since v24.0 but was never specified in a BIP — can be used to express a P2TR output directly by its output key. The key is used as the taproot output key without applying the BIP341 tweak. This is useful, for example, when the internal structure isn’t known, or the script tree hasn’t been revealed by the owner.

Other News from the Bitcoin World

• Fedimint Bug: The Fedimint team announced that they had found a bug in the legacy gateway module, the one responsible for integrating the federated ecash ecosystem with the Lightning Network.

  • The team released v0.12.1 to fix the issue and contacted all the reachable gateway operators to invite them to update their modules as soon as possible.

  • The issue only affects legacy gateway modules, those running the so-called LNv1, while those that had previously upgraded to LNv2 or those running an LDK backend can run safely. The team also point out that users’ funds, federations, and ecash are not affected by the bug.

• Boarding an Ark with Payjoin: Second, the company behind Bark, posted a thread explaining how to board and Ark using Payjoin, a feature that has been available for some time now. The same flow is also available to enter a Cashu mint. Second also provided a full write-up on the topic.

• App Store Research: BlueWallet CTO @overtorment pubished a report on the security of non-custodial wallets on the App Store.

  • The research focused on finding traces of weak entropy and private key exfiltration by decompiling and analyzing code from different wallets.

  • @overtorment was able to decompile 494 wallets, 45 of which raised red flags. He identified 23 apps with critical vulnerabilites and 22 with high-severity one. The complete list can be found at the end of the report.

• Bitcoin++ Insider Edition — News Hour: On Friday, the Insider team held its first News Hour, a livestream where we discussed the most important news of the week, interesting articles, and the latest insides from the developer ecosystem. This will become a weekly appointment, so don’t forget to tune in on Friday @ 5p UTC!

More from BTC++ Insider Edition

Articles

• Egge Wants You to Pay with Bitcoin

• How cache optimization, not broken crypto, caused inflation on Liquid

• temudandelion - This Week in Bitcoin Core #57

Videos

• Connor Aherne - BTC++ Insider Interviews

• Antoine Poinsot - BTC++ Insider Interviews

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.

• wallet, descriptor: Revert StringType::COMPAT for Miniscript expressions and drop the concept of a Descriptor ID that can be validated by achow101

  achow101 closed a wallet compatibility hole that had already bitten once.
  

  Miniscript keys were not handled StringType::COMPAT correctly when computing a Descriptor ID. To keep old wallets loading, Core had to keep hashing that ID the wrong way. This is the second time that happened, so this PR stops pretending the ID is something you can validate at all.
  

  The value read from the database is now an opaque blob that only ties records to a ScriptPubKeyMan. DescriptorID is renamed to CompatDescriptorHash — still written, no longer checked against a recomputed hash. importdescriptors and createwalletdescriptor compare descriptor strings instead of hashes. Lookup in m_spk_managers goes from a map to std::find_if (log to linear). achow101’s take: those RPCs are not the hot path, and importdescriptors might rescan anyway.
  

  The wallet backwards-compat test now includes 30.2 and 31.0 nodes plus a Miniscript wallet, so both directions get exercised. Fixes #35432. If you have a wallet with Miniscript in it from a previous release, this is the PR that is supposed to keep it loading.

• http: throttle send buffer when client stops draining by pinheadmz

  If a client stops reading the socket, Core used to keep dispatching requests and packing responses into m_send_buffer with no cap. After a complete request is parsed, before it goes to a worker, the server now checks that buffer. Already 32MiB sitting there (MAX_BODY_SIZE, open for bikeshedding) and the request stays as m_req instead of getting another worker. The misbehaving client does not get an unbounded send queue for free.
  

  This was found and disclosed by the Red Team 🟥. Same HTTP rewrite pinheadmz has been triaging agent findings on — last week he asked people to keep them coming before branch-off.

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.

• kernel: use struct-based logging and simplify logging interface by stickies-v

  sedited asked for comments in Thursday’s meeting. stickies-v just pushed after months of architecture thrash. It is open, not a draft, not Needs rebase. Last week’s prefetch PR (#36000) is still open too if you have a second tab.

  tl;dr: kernel logging is cumbersome. This PR delivers log entries as a struct instead of a formatted string, and simplifies the kernel logging interface. Closes #34062.

  Kernel logging has a few problems:

  • callbacks operate on formatted strings, so users need to parse the string to get the timestamp, category, level, ... based on which options are set. This is cumbersome, brittle, and inefficient.

  • the filtering interface is not really intuitive, requiring users to call combinations of btck_logging_set_level_category and btck_logging_enable_category when they want to produce debug or trace logs.

  • the node logging infrastructure has quite a bit more functionality than is necessary for a library.

  This PR gives bitcoinkernel its own implementation of those hooks, so it no longer depends on logging.cpp, and upgrades the C API to deliver struct-based entries. Node logging is not changed.

IRC meeting notes

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

𝗳𝗷𝗮𝗵𝗿: There are no pre-proposed meeting topics this week. Any last minute ones to add?
𝗳𝗷𝗮𝗵𝗿: Let's start with the WGs

--- Topic 1 ---
𝗳𝗷𝗮𝗵𝗿: #topic QA WG Update (brunoerg)
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: no update this week

--- Topic 2 ---
𝗳𝗷𝗮𝗵𝗿: #topic QML GUI WG Update (johnny9dev)
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: First chunk of the staging branch was merged in
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Establishes the qml foundational pieces
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: hebasto helped a ton with the final review
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: I have drafts for the next two chunks. Both will setup the wallet disabled version of the gui.
𝗵𝗲𝗯𝗮𝘀𝘁𝗼: post-merge review is always welcome; especially from python people
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Yeah everything can be updated. Nothing has to be finalized
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: I have a rough list of all of the chunks now and the order they should go in and I will create the tracking issue to "Upgrading Gui to Qml" with it.
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Pseudoramdom is updating the designs to make them more desktop friendly and consistent in parallel and epicleafies is taking care of transaction and activity issues
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: That's all for now

--- Topic 3 ---
𝗳𝗷𝗮𝗵𝗿: #topic Benchmarking WG Update (l0rinc, andrewtoth)
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: no update

--- Topic 4 ---
𝗳𝗷𝗮𝗵𝗿: #topic Kernel WG Update (sedited)
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: don't have anything from my side, but stickies-v recently pushed to #34374 again and left a comment: https://github.com/bitcoin/bitcoin/pull/34374#issuecomment-5605856730
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: would be good to get some comments there.
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: that's all.

--- Topic 5 ---
𝗳𝗷𝗮𝗵𝗿: That's it for the WGs afaict, anything to say about the release?
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: I think we are looking pretty decent for branch off
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: branch-off should be today, but there are still a few things in the milestone https://github.com/bitcoin/bitcoin/milestone/84
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: There does seem to be an outstanding thread in regards to private broadcast, which could be worth discussing now
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: Re what's left on the milestone, if any of those miss, they should also all be fine to backport into 32.x
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: yes
𝗳𝗷𝗮𝗵𝗿: What's the private broadcast thread?
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: Should we do privatebroadcast now or milestone?
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: re private broadcast. Some privacy leaks have reported to the security team, and we'd like to facilitate a broader discussion about the threat model to know how to handle those
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: I don't think there's too much to discuss on the milestone, other than, everything is looking for review
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: (or if someone thinks something is missing)
𝗳𝗷𝗮𝗵𝗿: fanquake: but is that something still relevant for the release, e.g. putting some warning in there, or is this a discussion unrelated to the release
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: fjahr: I think it's both
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: my impression is the base assumption of the feature is "no worse privacy than only connecting through tor"
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: there's one issue i think we should patch
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: not sure what we are discussing here exactly though
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: so for release, we could suggest remediations such as preferred configurations, or soft enforce them in releases. as an example
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: what do you mean with preferred configurations instagibbs?
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: I'm not sure having to speak cryptically in a public conversation is helpful. Otherwise we should have a private conversation somewhere else where we can discuss everything openly.
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: My understanding is there is more than one issue, and that it's not clear how far we want to go in patching them, and how to think about it consistently.
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: andrewtoth: i think we can discuss openly what privacy guarantees we want to provide users. Then the specific instances in which they are breached can be kept momentarily private like we do for security breaches.
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: I think a situation where we need to ship a feature with a caveat of *maybe don't use it unless you configure it a certain way*, but we don't make that the default, is not great
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: sedited f.e. we could encourage people who want higher assurance that they run onlynet=onion, or similar. Or maybe this is again just pure communication about privacy model
𝗹𝗶𝗴𝗵𝘁𝗹𝗶𝗸𝗲: yes, we could mention that private broadcast is still somewhat new/experimental and recommend to combine it with -onlynet=onion and -listen=0 if privacy is really needed instead of fully trusting it.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: ^ less inbound influence, that sort of thing yes
𝘀𝗶𝗽𝗮: (I haven't followed the issues) is there much of a point to privatebroadcast if you're in -onlynet=onion -listen=0 ?
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: I think the idea was logical OR?
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: agree with sipa, there seems to be no point to the feature if that is the case.
𝗹𝗶𝗴𝗵𝘁𝗹𝗶𝗸𝗲: sipa: correlating multiple connections originating from a node - any random outbound peer could do that.
𝘀𝗶𝗽𝗮: There is a small advantage still, namely that the receiver cannot correlate it with other traffic from you.
𝘀𝗶𝗽𝗮: Right.
𝗹𝗶𝗴𝗵𝘁𝗹𝗶𝗸𝗲: *multiple transactions, not connections
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: I think this should be a binary choice. Either it works as advertised, or it doesn't and should be removed.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: "as advertised" doing all the work
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: so what are we advertising?
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: Yeah exactly, i agree with sedited but what guarantee are we aiming to provide
𝗳𝗷𝗮𝗵𝗿: Depending on how easy to exploit the leak is, maybe documentation is not enough and we should enforce the settings until we have had the broader discussion. We should assume at least some users really need serious privacy if they use it and it seems risky no only use documentation.
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: either we are talking about the guarantees we want to provide, or we are talking about some mitigation for something we can't disclose
𝘀𝗶𝗽𝗮: The 31.0 release notes make some promises.
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: Are shooting for "If you are not a reachable node, operating only on Tor, then we guarantee the transactions you broadcast won't be easily correlated with each other"?
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: If our privacy model is "honest but curious", then AFAIK we cover that. It's also about user expectations
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: but that;s hard to to communicate, and weaker
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: "what's honest but curious": they follow protocol, but write everything down, say
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: The claims in https://bitcoincore.org/en/releases/31.0/ are "Their IP address (and thus geolocation) is never known to the recipients." & "If the originator sends two otherwise unrelated transactions, they will not be linkable. This is because a separate connection is used for broadcasting each transaction. "
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: instagibbs: so, passive observer?
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: vs active probing, protcool violations
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: yeah, that seems very clear.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: darosior they follow the stated protocol
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: whatever that means
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: the prior issue we had and fixed violated this
𝘀𝗶𝗽𝗮: There isn't even a well-defined "honest" behavior for nodes.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: sipa handwaving here
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: if we can't guarantee what's in those release notes, then we should not ship the feature imo.
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: Making a difference between passive and active attackers here make sense, but i'm concerned it would be hard to translate into an actionable information for users, and end up being a footgun.
𝘀𝗶𝗽𝗮: Right, but "honest but curious" is trivially false, if every behavior is "honest". That's a term that's used in cryptographic protocol with a well-defined prescription of how honest parties operate. Bitcoin doesn't have any of those.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: fanquake ok that note is wrong, two txs can be linked at the blockchain layer even with perfect impl
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: "not be linkable at the networking layer" maybe
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: instagibbs "otherwise unrelated" though
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: maybe that can be better defined
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: andrewtoth well, theyre all related :D but yes
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: sipa ok, then that. dont worry about my misuse of labels too much
𝘀𝗶𝗽𝗮: instagibbs: no, i literally don't understand what you mean
𝘀𝗶𝗽𝗮: like you seem to have an implicit understanding of what "an honest node" means, but i think there is no such thing, and i don't know what it ought to entail
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: What threshold are we aiming for to release this feature? That it prevents linkage at the network layer against a passive observer? Against an active one if you are not reachable? Against an active one if you are not reachable AND Tor-only? Against an active one no matter one?
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: maybe the answer is "no we have no common definitions of what we're promising"
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: ideally the strongest, but it's hard to say whether we can do it or not. Some issues preventing that can be patched easily, some I've seen are very theoretical and don't seem plausible.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: let's save the risk estimation for the security team, please
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: at least for now
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: well then we want to keep the guarantees from v31 release notes?
𝗳𝗷𝗮𝗵𝗿: We need to have some clarifying information though, the feature is called privatebroadcast so people will expect something just based on that
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: yeah, this conversation is too difficult if everything is not on the table
𝗱𝘇𝘅𝘇𝗴: +1
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: It's hard for me to see how we could give these guarantees completely as long as we have the mechanism embedded in net_processing, so plausibility may need to be discussed as part of the goal here. Are we happy to ship this feature if we give "reasonable" guarantees, i.e. kill the really low hanging fruits, on a "it's better than nothing" basis?
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: fjahr: +1 for expectations
𝘀𝗶𝗽𝗮: Maybe this needs a discussion at coredev, and a focus right now about what we can reasonable address by documentation clarification for 32?
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: ^ this
𝘁𝗶𝗴𝗲𝗿𝗠𝗮𝗳𝗶𝗮: fjahr: +1
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: how can we focus on what we can reasonably address if we can't discuss the issues?
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: Yeah i was really still on the binary question of what threshold are we setting for ourselves (which necessarily entail not shipping it at all until it meets that threshold, instead of trying to address it with documentation).
𝗱𝘇𝘅𝘇𝗴: If the security model has changed substantially since when the feature was shipped it should be disabled or renamed, but I do think something should ship which is better than the default
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: My favorite shed for the rename is -cloakedbroadcast /s
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: i don't think we should disable it, it is better than the default way to broadcast.
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: (But i do think rename makes more sense than documenting a feature called "private X" with caveats "actually not private in scenarii x, y and z")
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: dzxzg issue is I'm not sure we agreed ahead of time
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: I'm confused, what's not clear about the release note there?
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: I dont read the docs
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: *ducks*
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: :D
𝘀𝗶𝗽𝗮: instagibbs: well, you or your agent
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: sedited: fair
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: the docs seem to match my expectation of the feature in my head so maybe less confusion than im letting on
𝘆𝗮𝗻𝗰𝘆: I think the wording "never known" might give a false sense of security.
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: Ok since i don't think the status quo is desirable, i suggest we rename the feature for the upcoming release, with a name that does not give as much expectation as "private" broadcast, and make weaker claims in our release notes than we did for 31. This way we keep the option for now because it's better than the other broadcast, but also don't risk users depending on something we cannot guarantee.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: ah the easy part, naming things
𝗳𝗷𝗮𝗵𝗿: -betterthanthedefaultbroadcast it is
𝘀𝗹𝗶𝘃𝟯𝗿__: -broadcast++
𝘁𝗶𝗴𝗲𝗿𝗠𝗮𝗳𝗶𝗮: yancy: yes! given the current state of the discussion, it's VERY bold
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: I don't think it's a great situation, but i don't have a better idea for 32 literally on the day of branch off.
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: a release not warning is not enough?
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: *note
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: -notsoprivatebroadcast
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: this will have to be backported anway, so we'll have a few weeks to discuss.
𝗹𝗶𝗴𝗵𝘁𝗹𝗶𝗸𝗲: and when we fixed the known issues, do we rename it back to "private broadcast"?
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: lightlike: -evenbetterthandefaultbroadcast
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵: lightlike +1 - release note warning is better
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: I don't think a release note is nearly enough to compensate for the potential sense of security providing a feature called "private X" may give to users.
𝘁𝗶𝗴𝗲𝗿𝗠𝗮𝗳𝗶𝗮: how's "-veilbroadcast" since it's partial in privacy
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: release note warning should happen regardless
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: Anyways, i don't have much to add on this topic.
𝗳𝗷𝗮𝗵𝗿: The meeting is coming to a close in 5min, feel free to continue discussing renaming vs. release notes, but is there anything else anyone wanted to discuss/announce in the meeting?
𝗳𝗷𝗮𝗵𝗿: I think renaming should be to some name that doesn't make any promises, like -oneshottorbroadcast then we don't have issues like this with naming
𝗳𝗷𝗮𝗵𝗿: (if people want a renaming)
𝗱𝘇𝘅𝘇𝗴: no strong feeling about what the name should be, but the point of renaming in my mind is less about the promises the name makes and more to catch people that haven't read release notes or new documentation and go on using private broadcast with the wrong expectations
𝗠𝘂𝗿𝗰𝗵[𝗺]: Isn't the point that the transaction appears to come from a node that isn't the sender?
𝗠𝘂𝗿𝗰𝗵[𝗺]: So, maybe "teleportbroadcast" or "strawmanbroadcast" or smth?
𝗠𝘂𝗿𝗰𝗵[𝗺]: surrogatebroadcast? :p
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: temudandelion
𝗠𝘂𝗿𝗰𝗵[𝗺]: heh
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: im JOKING
𝗳𝗷𝗮𝗵𝗿: Murch: sounds still fine, as long as it's more descriptive of the mechanism rather than making promises of an end result
𝘆𝗮𝗻𝗰𝘆: shielded-broadcast is my bikeshed color
𝗳𝗷𝗮𝗵𝗿: sipa about to suggest -minibroadcast
𝗳𝗷𝗮𝗵𝗿: Ok, let's end the meeting with this :D
𝗳𝗷𝗮𝗵𝗿: #endmeeting

Read here for the full meeting

Releases

• 32.0 feature freeze was 2026-08-20. Branch-off / v32.0rc1 was targeted for 2026-09-10 and has not landed. The 32.0 milestone still has 5 open items. Latest still v31.1 / v30.3 / v29.4.

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’s update we feature the latest releases in the ecash ecosystem, Fedimint v0.12.0 and Cashu Dev Kit (CDK) v0.18.0.

We also cover the recent hack to the Liquid Network. Attackers, who stated to be whitehats, were able to stole 3998 bitcoin with a peg-out transaction leveraging a bug in the transaction validation logic.

We finally cover some other news, such as an implementation of multisig in Bitcoin Core GUI and a proposal to use silent payments in the coinbase transaction to pay miners for their hashrate.

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:

• Fedimint release v0.12.0 is out with new v2 modules, support for Iroh v1.0, and more.

  • During the weekly call, on Monday 31st, Fedimint developers discussed the release of Fedimint v0.12.0, called “Second Nature”.

  • The name of the release is linked to the fact that all the new v2 modules — lnv2, mintv2, and walletv2 — are now the default, with the older versions now labeled as “legacy”. Moreover, the latest version supports Iroh v1.0, the first stable release for the p2p networking stack.

  • v0.12.0 also improves the overall reliability of the system, reduces latency in Lightning payments, and allows recovery with no downtime and no blocking or stalling. Developers also released UniFFI bindings for Kotlin and Swift.

• Cashu Dev Kit (CDK) release v0.18.0 is out, bringing the implementation up-to-date with the latest protocol changes.

  • During the weekly call, on Wednesday 2nd, CDK developers announced that they had just released the new version of the Cashu implementation, v0.18.0.

  • One of the most important changes is related to the mint configuration and settings. Previously, the mint configuration could be overridden by local settings and environment variables. v0.18.0 stores the authoritative settings in the primary mint database. The team provided a migration guide for mint operators.

  • The release also adds support for animated QR codes (NUT-16), signature-based authentication for mint quote redemption (NUT-20), BOLT12 offers descriptions (NUT-25), and deterministic nonces for DLEQ for offline ecash (NUT-12).

A BIPs Update

There was no newsworthy update in the last few 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

• Liquid Hacked: On Sunday 6th, news got around that the Liquid Network, Blockstream’s sidechain, had been hacked by whitehats. The attackers stole 3998 bitcoin from the Liquid bridge.

  • Hackers contacted Blockstream directly onchain using an OP_RETURN. The discussion went back and forth, with the attackers asking the company to fix the bug before returning the funds. Developers Sjors shared a gist reporting all the discussion between hackers and Blockstream.

  • The bug seems to be connected to confidential transactions (CT), one of the feature available on the Liquid network that allows a user to hide the amount and the type of asset being sent by default. Since CTs do not show the amount being spent, two types of proofs are needed to verify that a transaction is valid: a balance proof and a range proof. The former checks that the amounts of L-BTC in input and in output are the same. The latter, checks that an hidden output falls within a positive amount.

  • Calle provided a possible explanation of what happened. Basically, since the range proof is particularly expensive to compute, Liquid nodes can cache a successful proof in memory, stored by assigning a label called cache key. Attackers were able to build two transactions with colliding cache keys. The first one was a valid transaction, checked by nodes and stored. The second one, on the other hand, was an invalid transaction, effectively creating L-BTC out of thin air. However, having the same cache key, nodes did not perform all checks and made it pass as valid.

  • The situation is still evolving. Check out BTC++ Insider Edition X account for the latest updates

• Silent Payments in Coinbase Transactions: Developer average_gary wrote a post on Delving Bitcoin explaining his idea to use silent payments to allow miners to get paid to different addresses for the provided hashrate without revealing an xpub.

  • The proposal would require a dedicated BIP since it is not currently possible to use the silent payments protocol defined in BIP352 as it is. The author is looking for feedback on the idea before moving on to a formal draft.

• Multisig in Bitcoin Core GUI: Developer sdbtc announced that he was able to integrate multisig in the Bitcoin Core GUI by using Claude. He is now reviewing the code created by the LLM and polishing the implementation with the objective of opening a real PR in the repository.

Reads from BTC++ Insider Edition

• BitPolito: How Italy’s Largest Bitcoin Student Org Is Passing the Reins to the Next Generation

• Don’t start a node in the past - This Week in Bitcoin Core #56

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!

Sedited points at the 32.0 milestone, eight items are still open and branch-off is next week. Pinheadmz is still triaging agent findings on the new HTTP server.

Sipa did quote furszy: “Claude is down, sorry”, and fjahr asked if he forgot how to join IRC without agent help :).

The two PR’s that took the most review this week are the headers-sync abort, and a -walletnotify command-injection fix that the Red Team found.

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.

• net: Disallow invalid HeadersSyncState due to lagging clock by hodlinator

  Headers presync sizes m_max_commitments from the elapsed time since the chain-start median time plus MAX_FUTURE_BLOCK_TIME. If your local clock is more than that far behind chain-start median time past, elapsed goes negative, the unsigned cap wraps to something huge, and low-work headers keep coming instead of the peer getting dropped.
  

  The old idea (#35208) was to clamp the cap to zero and let HeadersSyncState keep eating headers. This PR refuses to construct an invalid state at all and aborts the node. In practice, if you already have chainstate, startup already notices the lagging clock and shuts down first. A fresh datadir is the path that actually hits this. hodlinator filed #36134 to make that comment match reality, and that one merged too.

• util: keep wallet names literal in notification commands by l0rinc
  l0rinc fixed a v24 regression in -walletnotify.
  

  On non-Windows, %w in the notify command is replaced with the shell-escaped wallet name. Since #25803, ReplaceAll() has been feeding that replacement through std::regex_replace(). Regex replacement treats $' as “the rest of the subject,” so a wallet name containing $' can smash the quoting and run extra shell as the node user.
  

  This is not a P2P bug. You need an authenticated RPC caller who is allowed to create wallets. #35833 already started restricting control characters in new names; this one restores the literal, non-recursive contract ReplaceAll() that existed before the Boost-to-std::regex switch. The Red Team found it.

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.

• rpc: avoid quadratic JSON construction when keys are unique by l0rinc

l0rinc asked for a review in Thursday’s meeting. It is open, not a draft, and not Needs rebase. Last week’s prefetch PR (#36000) is still open too, he said a reindex-chainstate is often >50% faster now (about 30017s → 19609s on his HDD box). Branch-off is next week, so if you have one review slot, start here and keep #36000 in the other tab.

Problem: getprioritisedtransactions lets node operators inspect fee adjustments. While building the response, the RPC checks each transaction ID against all previous IDs, even though duplicates are impossible. The same unnecessary search appears in a few other RPC responses built directly from std::map or std::set keys.

Fix: Each changed response key comes from an std::map or std::set, where keys are unique, so insertion can skip the linear findKey() call.

On a Pi 4 his reproducer was almost a minute before the fix and about half that after. Same shape anywhere we build JSON from map/set keys.

IRC meeting notes

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

--- Topic 1 ---

fjahr: #topic QA WG Update (brunoerg)
brunoerg: I ran a mutation analysis for the silent payments PR and got a positive feedback about the findings and many mutants were addressed. Now that the implementation is on master, I re-ran the analysis for sp code as part of the weekly run. It got 100% of mutation score (that's perfect) - I will probably run a full analysis to check if there is any leftover. Results can be seen at: https://secp256k1.space
brunoerg: I also re-ran the mutation analysis for src/script/interpreter.cpp, since it's critical code I generated all the possible mutants. I got over 1000 mutants for this file which only 80 of them survived. There are some PRs adding more test cases for the interpreter which I hope we will soon have full coverage of them.
brunoerg: Naiyoma is helping me to test the parallelization of the analysis, I hope to get it ready soon, it will make our mutation workflow faster and more practical.
brunoerg: Also, I appreciate feedback from kernel people in #647. the idea is doing differential fuzzing between the kernel and the Core's internals.
brunoerg: That's all
fjahr: cool, thanks!

--- Topic 2 ---

fjahr: #topic QML GUI WG Update (johnny9dev)
johnny9dev: continue to work on the staging branch and fixing issues
johnny9dev: thats all for now

--- Topic 3 ---

fjahr: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: A few of the quadratic iteration fixes were merged, #36096 is similar, review would be appreciated.
l0rinc: And as mentioned yesterday, #36000 was tuned a bit more, now a reindex-chainstate is often >50% faster.
l0rinc: IBD is probably internet bandwidth bounded now, will experiment with parallel undo/block flushes to see if it helps.
l0rinc: Will also profile a neutered validation-less and UTXO-less node to see the remaining bottlenecks.
l0rinc: That's it from me, thanks

--- Topic 4 ---

fjahr: #topic Kernel WG Update (sedited)
sedited: Been getting some good review on #35641 . Also had some external projects say they would be interested in its capability.
sedited: and will circle around to the things request in the pr brunoerg linked before
sedited: that's all

--- Topic 5 ---

fjahr: Anything else to discuss? Possibly the release?
sedited: there's still a few items in the milestone: https://github.com/bitcoin/bitcoin/milestone/84
sedited: would be good to get them in before branch-off.
fjahr: Please review! Anything else?
pinheadmz: Im getting lots of agent findings in the new HTTP
pinheadmz: im triaging solutions before branch off
pinheadmz: so just keep em coming.
fjahr: #endmeeting

Read here for the full meeting

Releases

• No releases

• v32.0 is coming soon…

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

Chances are if you’re in the Italian Bitcoin community, or perhaps even those outside of it, you’ve heard of the most popular Italian students club: Politecnico of Turin’s BitPolito. Or maybe you’ve seen their logo, a pixelated blue cow, somewhere at a Bitcoin conference.

BitPolito was founded in 2018 by three students of the Politecnico di Torino: Giorgio Rasetto, Salvatore Scorsone, and Gabriele Vernetti. Inspired by their shared passion for the world’s most popular cryptocurrency, the three students united to bring a Italy’s first Bitcoin focused student’s club to life. Their objective: to bridge the gap between the academic world and the Bitcoin industry, helping members develop skills and create value for Bitcoin, by creating an educational environment focused on R&D in computer science and mathematics, holding classes for students, and organizing events in Turin and around Italy.

No price noise, just educational signal.

According to the latest annual report (2025/2026), BitPolito has more 55 active members. Historically, around 220 members have been active in the student’s organization, and there are now more than 30 former students actually working in the Bitcoin industry. For example, Gabriele Vernetti, one of the founders — known in cyberspace as GitGab19 —, is now one of the main maintainers of the Stratum V2 project.

The association is always present to the biggest Bitcoin events around the world. Other than talks at several Bitcoin++ events, in 2024/2025 the BitPolito guys could be found at the Plan B Forum in Lugano, BTC Prague, Baltic Honeybadger, and BTCHEL, and the Barcelona Cypher Conference.

In Italy, their impact can be also felt outside of the Politecnico. They organize events all over Italy — more than 70 according to the latest report —, they take part in the Italian-only conferences, such as the BitCare Forum in Breascia, and provide education to anyone willing to learn. With their “Bitcoin al Liceo” program, BitPolito is bringing Bitcoin and the Cypherpunk culture to high school students around Turin, while “BitGeneration” brings together the best educators in the Italian ecosystem to provide everyone with a full understanding of Bitcoin directly at the Politecnico.

BitPolito has also been invited to participate in an event organized by the Camera dei Deputati — one of the Italian parliamentary chambers — to present their view on what Bitcoin is and why it is important for a better future.

Franscesco Pelle has been BitPolito’s president since July 2024. After two years successfully leading the club, he is now stepping down, leaving the role to a member of the next generation. Francesco recently completed his academic journey in Management Engineering, and is graduating from the Politecnico. While his passion for Bitcoin and the BitPolito is as strong as ever, he is ready to move forward to his new chapter of life: “My main interests are entrepreneurship and product management. I currently work as a product manager at a startup, and I want to continue developing my skills in this field”, he says.

“There is no single moment that I would describe as the most important one. Serving as president of BitPolito has been one of the most rewarding experiences of my journey so far. It was both a privilege and a responsibility to be part of a group of people united by values that I consider fundamental, starting with freedom and the other principles at the heart of Bitcoin.”

Giorgio Rasetto, one of the founders, and the rest of BitPolito’s OGs personally chose Francesco as the new president in 2024, when Giorgio himself completed his academic journey and decided to focus on his Bitcoin career. “They selected the person they believe is best suited to ensure continuity in the team’s activities, responsibilities, and leadership,” Francesco says, pointing out that he “had also demonstrated a strong commitment to BitPolito and its mission.” This seems to have reassured the founders they were entrusting someone who genuinely cared about what they were building.

Being the first president outside of the circle of the original founders, continuity has been one of the most important focuses of Francesco’s term. How do you make sure that the ethos, the values, and the ideas that led to BitPolito will remain intact, even after the founders are gone? “My main goal was to ensure BitPolito’s continuity and allow the work built over the previous years to continue. Today, the team includes highly motivated people who genuinely care about the project.”

One of the best ways to ensure continuity is through education. New members are not always operational until they have absorbed what Bitcoin is really about. Moreover, the structural organization has been made so that new members can easily integrate with the ongoing activities and the association in general.

“The president is responsible for providing leadership and maintaining an overall view of the team’s activities. The president does not hold exclusive decision-making power: they are part of a board where decisions and responsibilities are shared with the heads of the team’s internal divisions.”

The role of the presidency in BitPolito is a high-profile one. Other than giving a common direction to the organization and making sure that all the important initiative are completed on time, the president is responsible for managing institutional relationships with companies, projects, and, most importantly, with the Politecnico itself. During his term, Francesco was able to secure “significantly more financial support from Politecnico di Torino than in the past,” — something he is proud of — so that the members could continue attending events and travelling across Europe, promote both BitPolito and the Politecnico, and strengthen the relationships they had built over the years.

Francesco is proud of everything he has done during his presidency. He is proud of how BitPolito has impacted the Italian Bitcoin scene and how their events have allowed many people to get a closer look to Bitcoin and get fascinated by the ideas behind it. “Discovering Bitcoin can have a profound impact on someone’s life, and I believe that BitPolito has helped create that change for many people in Italy over time,” he says. Most importantly, though, he is proud of having been able to remain true to himself while “creating an environment where people could feel at home, take an active role, and freely bring forward their own initiatives.”

“I do not have any real regrets. There are certainly things I would have liked to do better or spend more time on, but they do not change how I feel about the overall experience. I am satisfied with what I did, and I am confident that the team will continue in the best possible way under its new leadership.”

Some things remain undone, like creating a more clearly defined and robust structure for the team’s internal processes and activities. Francesco is not worried, though. He is sure that the new president and the team will be able to fill this gap and continue on the same track of the people before them.

The new president has already been chosen. Luca Visconti, former Project Manager for the AI team, will take the presidency soon. The handover has already started and Francesco is delighted about his successor.

“I was impressed by how active he was and by the dedication with which he approached the responsibilities of the role”

According to Francesco, after years of expanding the network outside of the borders of Turin, the new president will have to focus the association back to where it all began. Engaging students, spread Bitcoin awareness among them, and grow the team.

Bitcoin++ Insider Edition would like to thank BitPolito president Francesco Pelle for his availability and wishes him a bright future for his Bitcoin career. We also would like to congratulate Luca Visconti for his new role and wish him a term full of success and satisfaction.

In this week’s update we feature nutroot secrets, the latest improvement to the Cashu protocol, which allows spending conditions to be included directly in the secret.

We also cover the first Shielded CSV developer call, where devs provided an overview of the high-level architecture. The team also announced that the protocol was renamed Glass Coins.

Finally, we discuss the most interesting news from the Bitcoin ecosystem. In particular, we cover BIP SHRINCS, the vulnerabilities found in Core-lightning, and the discontinuation of the Hardware Wallet Interface (HWI) library.

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:

• Cashu devs are working on nutroot secrets, a new way to express spending conditions inspired by taproot.

  • During the monthly community call, on Thursday 27th, Cashu developers discussed the latest changes to the protocol specifications (NUTs). Notably, discussion focused around PR421, which introduces the so-called nutroot secrets. The PR has not been merged yet, since devs are waiting for the different projects to implement this feature.

  • Nutroot secrets change the way the protocol manages spending conditions. Instead of relying on a separate JSON file, the secret commits to a merkle tree which includes all the different spending conditions.

  • While nutroot secrets are clearly inspired by how taproot works in Bitcoin, developers clarified that only the commitment structure has been used and little else. No taproot property should be taken for granted.

  • Nutroot secrets comes with a new cryptographic algorithm. Developers decided to migrate to a new curve, BLS12-381, from the current scheme using secp256k1. This is because BLS makes signature publicly verifiable. The new algorithm is being introduced through PR371.

• Shielded CSV has been renamed Glass Coins, and promises a better transaction throughput on Bitcoin with improved privacy.

  • On Thursday 27th, Robin Linus, Jonas Nick, and Liam Eagen held the first developer call for Shielded CSV, a private payments protocol designed for maximum throughput and minimal latency.

  • The protocol is based on Client-side Validation (CSV), a technique that allows users to validate transactions off-chain, while relying on on-chain transactions only to prevent double-spending. The protocol comes with a minimal on-chain footprint.

  • The founders announced that the protocol had been renamed Glass Coins and shared a specifications file containing all the high-level information about it.

A BIPs Update

There was no newsworthy update in the last few 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

• A BIP for SHRINCS: Blockstream’s Head of Research Jonas Nick announced the first draft of BIP SHRINCS, the first proposal for a post-quantum signature scheme for Bitcoin.

  • The proposed scheme, called SHRINCS, provides the ability to obtain small signatures — in the context of post-quantum cryptography — of 548 bytes. It does so by using a stateful signature scheme — smaller signatures, but you must keep track of used keys (state) —, while giving the user the possibility to fall back to a stateless scheme in case the state is lost, at the cost of bigger signatures ( > 5kB).

  • If you want to know more about SHRINCS, the Insider published a deep dive on SHRINCS some months ago. We also published a deep dive on SHRIMPS, a proposal to minimize risks in a post-quantum world that can be combined with SHRINCS.

• Vulnerabilities on CLN: Last week, Core-lightning contributors announced that several vulnerabilities had been found in the Lightning implementation. According to Christian Decker, no known vulnerability can be leveraged to steal funds.

  • Christian Decker also provided information about the approach that CLN was following to address the vulnerabilities. The team will provide an embargoed release by publishing signed binaries without making the source code available. 14 days after the release, developers will publish the source code, which can be used by anyone to verify the released binaries thanks to their reproducible build system.

  • The patch release v26.06.7 was published on August 28th. The team invited anyone running a CLN to upgrade as soon as possible. In case anyone wants to wait for the source code to be released before upgrading, the suggestion is to restart the node using the --offline command, which allows the node to cut out external connections, without losing on-chain enforcement against potential cheating peers.

• Goodbye HWI: Bitcoin Core contributor Ava Chow announced that the Hardware Wallet Interface (HWI) library — which enables support to hardware signers in Bitcoin Core — will be put in maintenance mode. This means that no new functionality will be added from now on, except for MuSig2 which is currently under development.

  • One of the reason behind the choice, other than being a solo-dev project, is the fact that it is developed in Python and it does not allow for reproducible builds. This means it cannot be shipped with the whole Bitcoin Core package.

  • BHWI — developed by Wizardsardine — has been chosen as the possible successor to HWI. The library is built in Rust and it already supports the major hardware signers on the market.

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!

Last month, on July 7th, news spread amongst Bitcoiners. Someone had finally added support for bitcoin payments to Signal, the open-source, end-to-end encrypted messaging app.

Well, not Signal exactly. Radar Chat, a newly launched fork of the open source Signal project, takes the private communication network of Signal and adds Bitcoin, p2p electronic cash.

One of the minds behind the integration is Cake Wallet’s COO, Seth for Privacy.

On X, he presented Radar Chat to the world, describing it as the best way to address one the biggest issues our digital life has: sending money and communicating should be our most private acts, but in reality this is where surveillance is strongest. Radar Chat aims to provide a unified tool for people to protect themselves from surveillance for both the movement of money and information.

Radar Chat’s launch is exciting, but it is not exactly novel. Someone had already created a proof of concept of a similar solution some months before Radar Chat finally saw the light of day, and launched a campaign to raise awareness on the fact that private messaging needs private money.

It All Started with an Hackathon

Back in October 2025, developers from all over Europe came together in Berlin, Germany to compete to win the Bitcoin++ — Lightning Edition Hackathon.

One team had a simple, but powerful idea. Not many people know about it, but Signal has a built-in cryptocurrency wallet which can be used to exchange money between users. It only supports MobileCoin, a shitcoin that not even its creator remembers exists. The team, composed of some of the most knowledgeable developers in the Cashu ecosystem, decided to swap that wallet with a Cashu one, using the UniFFI bindings for Swift and Kotlin available on the Cashu Development Kit.

The project, Nuts Are Pure Signal, won. At the hackathon finals, they demoed sending ecash tokens back and forth between an Android and an iOS device using their custom Signal client.

The Android fork is still available on GitHub.

Private Messaging Needs Private Money

Less than two weeks later, the Cashu team, with the help of the Bitcoin Design Community, launched a dedicated campaign to raise awareness on the fact that private communication and private money go hand-in-hand.

The campaign was well received, with prominent bitcoiners, such as Peter Todd and Jack Dorsey, vocally supporting the effort. Bitcoin Designer Erik Cativo discussed in a retrospective that one of the strong points of the campaign was its focus on the design, which helped “presenting the idea elegantly and professionally”. The X hashtag #bitcoinforsignal remains the proof of the impact of the campaign.

Closing the Loop

Seth did not forget to give credit to the campaign. On July 10th, he published the following tweet with the #bitcoinforsignal hashtag.

Radar Chat is not based on Cashu, but provides a Lightning wallet based on Spark. While the technology is different, the ethos remains the same.

Freedom of speech and freedom to transact belongs together.

What’s Next?

In his review of “A Lodging of Wayfaring Men”, Max Hillebrand chooses Bitcoin++ as one of the modern lodges in which the future is being built. “Bitcoin++ pulls protocol engineers into the same room to prototype and ship across a single shared agenda,” he says. Having hackathon projects inspire real products and real advancement in the ecosystem is one of the things we are more proud of.

Next Stop: Berlin

Bitcoin++ is coming back to Berlin next month, 1-3 October 2026. Join us, if you want to be part of the builders shaping the future of Bitcoin!

In this week update we feature the current effort from the LDK team to add support for recurrent payments in BOLT12. We also discuss a new plugin for Core-lightning to rebalance channels in a node.

We also cover the most interesting news from the Bitcoin ecosystem. Notably, we talk about Iceberg, a new nested threshold MuSig2 signature scheme, that allows Lightning operators to thresholdize one participant inside a multi-signature protocol.

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:

• The LDK team is working to introduce recurrent payments in BOLT12.

  • During the biweekly call, on Monday 17th, LDK contributors discussed PR4882 in rust-lightning which aims to introduce recurrent payments int BOLT12.

  • PR4882 is implementing the protocol flow and all the primitives needed for recurring payments to work. On the other hand, recurrence tracking, persistence, and scheduling will be handled downstream — For example in LDK Node.

  • The implementation of recurrent payments is going hand in hand with the drafting of the specification in the BOLT repository. Specifically, LN contributors are working on PR1240.

• A plugin for Core-lightning for rebalancing channels in a node.

  • During the biweekly call, on Monday 17th, Core Lightning developers discussed a new plugin to rebalance channels called xrebalance , develoeped by the main CLBOSS maintainer Ken Sedgwick.

  • Rebalancing is done through independent circular self-payments between different channels on the same node, leveraging the askrene plugin for improved routing computation.

  • The plugin is still experimental and under active development, and works out-of-the-box with CLN versions v26.04 or higher.

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

BIP332: Stale Tip Relay

Authors: Anthony Towns, w0xlt, Ram

Assigned On: Aug 20th, 2026

Layer: Peer Services

PR2241 introduces BIP 332, which defines a new, opt-in P2P message called staletip whose goal is to announce recent stale chain tips to peers. The message contains the block height at which a stale branch diverges (the fork point), a vector containing the block headers belonging to the stale branch, and a flag signaling willingness to serve that block data. This may be useful for monitoring the network health, since increases in the stale block rate may expose validation or relay bottlenecks, network partitions, or selfish mining behavior.

Other News from the Bitcoin World

• Iceberg, a multisig for managing Lightning channels: Paul Gerhart, Nadav Kohen, Jesse Posner, and Matias Furszyfer published a paper presenting a new cryptographic primitive, nested threshold multi-signatures, which allows to thresholdize one participant inside a multi-signature protocol.

  • As a first implementation of this scheme, the group presented Iceberg, the first construction for nested threshold MuSig2 signatures. It enables one side of a Lightning channel to operate as a t-of-nthreshold group while appearing to the counterparty as a standard MuSig2 participant.

  • The proposed scheme can be used today, without any modification neither to the Bitcoin protocol, nor to Lightning.

• New major version for Coco: The Cashu team announced that a new major version — v2.0.0 — for Coco had been released.

  • Coco is a TypeScript library that provides the easiest way to develop Cashu-based wallets or integrate the ecash protocol in various applications.

  • The latest version brings the library up-to-date with the latest developments in the Cashu ecosystem. It implements minting and melting operations through BOLT12 (NUT-25) and on-chain payments (NUT-30), payment requests based on NUT-18, and custom units.

• The new Simplicity Community: Blockstream announced the official launch of the Simplicity Community, a place for devs to discuss the latest technical developments on the smart contract language and showcase the latest applications built on it.

• Responsible disclosure of an LND bug: Recently, Bastien Teinturier responsibly disclosed a vulnerability he found on LND nodes running versions before v20.0. Specifically, an LND node would forget about a collaboratively closed channel after one single confirmation, losing protection against chain reorgs. In case of a reorg, an attacker would be able to publish a revoked commitment transaction for the channel. Since the node had already forgotten the channel, it would not publish a penalty transaction, letting the attacker drain all of the channel’s funds.

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!

For years estimatesmartfee stared at confirmation history and ignored the mempool sitting right there. Empty mempool, stale high estimate, you overpay, coins don’t come back. The new estimator looks at the top block of the mempool and takes a percentile, 75th if you’re economical, 50th if you’re conservative, but only to lower what the old Block Policy Estimator already said. A miner stuffing junk into your mempool cannot pump the fee. Historical numbers from the PR: about 29% less overestimation, and a 73% success rate with 0% overestimation.

cfields asked for a freeze exception on vectorized chacha20. The room said 33.0 is fine. Co-author credit also ate a chunk of the meeting. More on that below. And last week’s “please review this” txindex PR actually merged, so the index is on a diet.

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.

• txindex: hash keys and pack positions to reduce disk usage by andrewtoth

  Last week I asked y’all to review this. This week it merged.
  

  The current txindex uses the full 32-byte txid as keys, which is about 66 GB on mainnet today. andrewtoth switched to a 5-byte salted siphash prefix and packed the tx position into the key, same trick as txospenderindex. That drops the index to about 26 GB — less than half. Collisions happen (he measured hundreds of thousands of 2-way ones on mainnet, plus a handful of 3-way and one 4-way), but the penalty is an extra disk read, a deserialize, and a hash. Lookups stayed around 0.2ms.
  

  Existing nodes can keep the old entries and append the smaller ones, or wipe indexes/txindex and reindex. Indexing was faster on his machine too: 1h19m vs 1h50m. Follow-up if you run pruned: #36002 wants to make txindex work in pruned mode.

• fees: Introduce Mempool Based Fee Estimation to reduce overestimation by ismaelsadeeq

  ismaelsadeeq (Abubakar Sadiq Ismail) has been chasing #27995 for a while. This is the version that landed, the morning after feature freeze.
  

  The trick is the one-way ratchet. The mempool estimator builds a block template, takes that percentile feerate, and is only allowed to cut the Block Policy Estimator’s number. The old estimator is not gameable the way a raw mempool snapshot is, so a Finney-style miner stuffing your mempool cannot raise what Core recommends. Underestimation is the safer failure mode now that RBF/CPFP actually work (TRUC, ephemeral anchors, cluster-size-2 package RBF): bump later; overpay and the extra fee is gone.

  It also refuses to trust your mempool unless the last 6 blocks look like you saw most of what miners saw — mempool tx weight removed vs block weight above 75%. Estimates are cached at most every 7 seconds while the tip is unchanged. The remaining miss is a sudden inflow the old estimator is slow to notice, which the PR puts at about 26% of the time. Live stats: https://bitcoincorefeerate.com/stats

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

validation: prefetch blocks while connecting by l0rinc

l0rinc called this out in Thursday’s meeting. Feature freeze already happened, but he and others treated this class of change as an optimization, not a feature. It shines on HDDs.

Block reading and decoding currently happen before block connection, even though loading is mostly I/O-bound and validation is CPU-bound.

This is a follow-up to #35295, which parallelized input prevout fetching during block connection.

Fix: Route block loading through a block fetcher, add synchronous 1-block read-ahead, then move reads to a lazily started single-worker pool that persists across activations. Queue up to 2 reads on that worker. This PR deliberately keeps 1 reader and a fixed queue size of 2 to avoid concurrent disk reads and limit the initial interface.

Credit: The idea comes from bitcoindev1337, who had already implemented a similar solution and reported comparable results.

On an HDD reindex-chainstate that was ~8.6 hours → ~6.3 hours (about 1.37x). SSD IBD still picked up ~15%. Reviewers wanted, and the co-author discussion in IRC started on this PR, so maybe don’t surprise fanquake with a Co-authored-by unless he actually wrote code.

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)
dergoegge: no update

--- Topic 2 ---
stickies-v: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: #35889 was merged, is a similar follow-up #36032
l0rinc: #35531 was also merged, #36002 is a follow-up to make it work for pruned nodes
l0rinc: and as mentioned before here, #36000 was opened since
l0rinc: it shines on HDDs especially
hodlinator: nice!
l0rinc: as mentioned here before, I'm investigating if we can extend it in a future PR with different thread context-independent CheckBlock validations
l0rinc: sipa: you mentioned you were thinking of redesigning validation to be multitreaded, does this interfere with that?
stickies-v: wdym with "different thread context-independent CheckBlock validations"?
sipa: l0rinc: not pursuing that right now
l0rinc: #36000 loads the blocks on different threads, so we can do some of the check (the ones that don't require extra connection context) there basically for free
l0rinc: that's it from me, thanks
stickies-v: i see, just CheckBlock on multiple threads
l0rinc: yes

--- Topic 3 ---
stickies-v: #topic QML GUI WG Update (johnny9dev)
johnny9dev: Started the first PR into the gui-qml "staging" branch at #871
johnny9dev: The idea is to reconstruct the project with clean, mergable history using everything we've learned building the project. I need to work on the description still
johnny9dev: The first 2 or 3 PR will likely be the most interesting as it will establish the core pieces (build, test, app lifecycle, and basic models)
johnny9dev: so I think that is the plan to move towards getting this upstreamed. I will give these PRs plenty of time to get review from anyone that would potentially be interested in them
johnny9dev: and i think now is a good time to get started
johnny9dev: thats all for now

--- Topic 4 ---
stickies-v: #topic QA WG Update (brunoerg)
brunoerg: no update
cfields: proposed topic: potential feature-freeze exception for vectorized-chacha20

--- Topic 5 ---
stickies-v: #topic potential feature-freeze exception for vectorized-chacha20 (cfields)
cfields: Very sorry for coming down to the wire here, but I'm curious if there's any appetite for an exception to the feature freeze for the vectorized chacha20 impl. It speeds up chacha20 by 1.5-3x (depending on platform/compiler), which is currently one of the most obvious pain points that shows up in flame graphs. I opened the PR months ago but I've been waiting to see what happened with upstream GCC (they're working on a substantial vectorization improvement that I assumed existed there while working on the PR. They've responded to my bug reports and I'm confident that the improvements will land, but haven't yet so I've decided to pivot). I'm working on a 128bit version (with l0rinc's help) that should perform better everywhere (though can be replaced with a better 256bit version once GCC gets its act together).
cfields: I can commit to spending the next week working on it if there's interest in doing some focused review for v32.
cfields: #34083
sipa: next week is a bad time for me, i don't think i can commit to reviewing
cfields: Nothing about it is urgent, it'd just be a nice speedup to ship for 32.
l0rinc: It's not technically a feature, optimizations can be considered bugfixes - I can continue reviewing
stickies-v: this looks like a cool improvement but i think it'd be equally cool to ship in 33?
cfields: Ok, wfm.
l0rinc: I'm fine with both, we have a few other optimizations lined up anyway
cfields: my fault for letting it sit there for so long.
cfields: thanks. next topic :)
stickies-v: so yeah, PSA: today is feature freeze

--- Topic 6 ---
stickies-v: should we talk a bit more about the co-authorship thing? i don't really care much about/for it but it seems to have come up a few times
stickies-v: i think one group sees it as a tool to figure out who knows the most about a piece of code/is a person to talk to, another sees it as a way to give credit / say thank you
stickies-v: oh and also it was mentioned as a way to express copyright
sr_gi: Context?
sipa: stickies-v: i was just comparing it with copyright as a bar
stickies-v: sr_gi: https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2026-08-18#1247067 (and following days)
sipa: i see it as a way of giving credit, and the bar that sounds reasonable for that seems to roughly match the point where someome could claim cooyright
l0rinc: copyright is a bad example here: #35794: Relevant U.S. Copyright Office guidance page 5
l0rinc: > Applicants should not list an AI technology or the company that provided it as an author or co-author simply because they used it.
stickies-v: i use it when someone has contributed significant amounts of code, or in rare cases even when there was no/little code but a significant amount of architectural/design ideas that made me change course
l0rinc: I also see it as giving credit to thank people who helped in shaping the outcome. A good recent example is
 Rob spent a lot of time and money on finding these, the least we can do is acknowledge his work by adding him as coauthor.
sr_gi: I've been using it myself to give credit, specially if someone else has started the work and I've picked it up later, but the base is still theirs (e.g. Gleb with Erlay)
sipa: How so? AI tools don't have copyright, and we don't add them as co-author.
sipa: So the analogy seems to work.
l0rinc: AI is tool, we don't add clang-tidy as coauthor either
l0rinc: we don't need to thank the AIs (yet)
sipa: I'm not sure if you're agreeing or disagreeing with me.
l0rinc: I think I'm mostly agreeing
dzxzg: I don't know if it's something that needs to have well-defined meaning, everyone probably uses it a little bit differently, but all use it to mean some variation of "this person helped make this change." anything more detailed would probably need to be resolved case-by-case between the author and (alleged) coauthor
sipa: My position is that you should add someone as co-author if they could reasonably claim copyright.
stickies-v: sipa: that sounds like a good heuristic to me
sipa: It's a way of giving credit, but for actually contributed code, not.ideas.
sipa: It does not imply the co-author understands the entire commit.
l0rinc: I am very much against copyright, so the analogy gives me the creeps
johnny9dev: just an fyi, I'll be making heavy use of co-authored-by in the gui-qml staging commits as I will be compressing the large history into something digestible. The co-authors will all have been involved with constructing the relevant piece in some significant way. I will make sure I only co-author the person if I believe they can speak on the functionality introduced.
l0rinc: is there a drawback to thanking people this way? What's the reason for the pushback exactly, that it's interpreted as distributing blame?
shiza: I read it was something about grants
sipa: l0rinc: ok, read it as "contributed a nontrivial piece of code of at least 5-10 lines" then
l0rinc: what the reason for avoiding it for 1-5 lines? Is it a grant-thing as mentioned?
sipa: l0rinc: i think it is weird to credit anyone who contributed ideas or helped with benchmarks or whatever, it's a collaborative project where everyone builds on one another. Authorship is a higher bar than that.
sipa: Or suggested a few single line changes.
fanquake: Yea. My pushback to #36000, was that I'd barely looked at the code, so I didn't see why I'd be a co-author
shiza: 2026-08-14 21:28:42 aj are we using co-author to mean "wrote some of the code in this commit" or "contributed to the design" these days? i thought the former, but i've seen a few cases where the latter seems to be more in play? does the distinction matter for some people's grant KPIs?
fanquake: I guess AJ was similarly confused here, #35920, about the request to be added as co-author
sr_gi: l0rinc: reading the piece that stickies-v shared I see the issue as not giving credit instead of doing so, but I haven't read the whole history
lightlike: different policies becomes a problem when people expect others to add them as coauthors (in the way they would do it to them), but the other person has a stricter policy and declines the request.
fanquake: *about the request for someone else to be added as co-author
l0rinc: "Authorship is a higher bar than that" - if someone contributed meaningfully I just add them as main author in that case, like: #35752
sipa: you can contribute a meaningful amount of code without being the main author of a commit
stickies-v: alright, i think we can wrap up on this
stickies-v: anything else to discuss?
l0rinc: thanks for the feedback
stickies-v: #endmeeting

Read here for the full meeting

Releases

• No releases

• 32.0 feature freeze was Thursday 2026-08-20. No v32.0 tag yet. Latest still v31.1 / v30.3 / v29.4.

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 a security patch released by Fedimint to fix several vulnerabilities in the federated ecash protocol. No funds were lost, nor any federation was affected.

We also cover several important news from the Bitcoin ecosystem. We discuss first stable release of Payjoin, the Boltz team stepping down, a new library for SHRINCS, and a new Bitcoin node implementation in Rust, rbitcoin.

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:

• Fedimint released a security patch on August 13th which fixes several vulnerabilities on the federated ecash protocol.

  • During the weekly call, on Monday 10th, Fedimint contributors discussed a security patch applied to fix some vulnerabilities. The patch was backported to previous versions and two new releases, v0.10.1 and v0.11.2, were published soon after.

  • According to the Fedimint team, the vulnerabilities were responsibly disclosed by the Red Team and Loupe. Devs contacted all known federations and had all of them upgrade to the new patched version. No funds were lost, nor any federation was affected.

  • The security patch fixes around 30 small vulnerabilities. According to PR8997, the various issues can fall in different categories, such as contract funding and claiming on the LNv1/LNv2 modules, consensus version gating, panic containment, gateway module correctness, and wallet module.

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

BIP461: Deterministic ECDSA Signatures

Authors: Liam Gilligan

Assigned On: Aug 13th, 2026

Layer: Applications

PR2224 introduces BIP461, which defines how to obtain deterministic ECDSA signatures. A signature is now encoded using the Distinguish Encoding Rule (DER), which results in two numbers r and s , treated as big-endian signed integers. Due to the sign, in case a r number has its most significant bit set to 1 , hence treated as negative, a null byte is added to keep it positive. BIP461 describes how to do low r grinding of an ECDSA signature, to avoid adding an additional byte to it. The described process is deterministic, following RFC6979.

Other News from the Bitcoin World

• Stable Payjoin: On August 12th, Payjoin contributors announced the release of the first stable version of the payment batching protocol, v1.0.0.

  • The release includes support for both the legacy Payjoin, described in BIP78, and the most recent asynchronous version, defined in BIP77.

  • The Rust crate comes also with UniFFI bindings for several programming languages, such as Python, Dart, C#, and JavaScript.

  • The first stable release comes after more than three years of development and integration with several wallets.

• The Boltz team steps down: On August 12th, Boltz announced that the whole founders team had step down from the company.

  • In the X post, the team explained that the decision was taken due to the impossibility “to withstand the current level of attacks in the long run,” given the limited resources with which they have been operating over the years.

  • According to the team, a new group of veteran bitcoiners is taking on Boltz. The identities of the new team have not been revealed yet.

• A library for SHRINC: Blockstream’s Head of Research Jonas Nick announced the release of libshrincs, a hand-written and formally-verified C implementation of WOTS+C , the one-time signature scheme used by SHRINCS.

• A Rust Bitcoin Node: Rearden announced on X that he has been working on a new Bitcoin node implementation in Rust, called rbitcoin. While it is not deemed production ready yet, it already supports Electrum, Esplora, and core RPC interfaces.

• Listen to the Insider: The Insider Edition now has a dedicated podcast feed where you can listen to our audio-only interviews. Check it out!

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!

Release binaries were never built with it. Those are MinGW. Native Windows from source is the last place MSVC still shows up, and clang-cl already works there. #31507 would make Clang first-class on Windows, which is when reviewers started asking why we still carry workarounds for a closed-source compiler we cannot patch.

The case for keeping it was compiler diversity. In practice, the bugs it finds are bugs in MSVC, patches already get almost no review, and it would be the only platform with three toolchains. A few ACKs later, the room was “so let’s drop MSVC support.” hebasto is opening an issue for how hard we cut.

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.

• rest: add Cache-Control headers to REST responses by w0xlt
  
  This week w0xlt had a REST PR merged that finally tells caches how to treat Bitcoin Core’s REST responses. Before this, REST replies had no Cache-Control header, so a reverse proxy or CDN sitting in front of a node had no idea what was safe to cache and what would go stale.
  

  The policy is conservative on purpose. Hash-addressed, immutable data (raw /block and /block/notxdetails bin/hex, plus /blockpart, /blockfilter, /spenttxouts, and /deploymentinfo/.json) gets Cache-Control: public, immutable, max-age=86400. Everything else — JSON block views with tip-dependent fields, /tx, /headers, /chaininfo, mempool, UTXOs, errors, unmatched 404s — gets no-store.
  

  Reviewers pushed back on a one-year TTL for immutable responses. A day is enough to take load off the node, and it avoids getting stuck with a stale cached format after an upgrade. Operators who want something more aggressive can still override the defaults in nginx or a CDN.

• wallet, test: Ancient Wallet Migration from v0.14.3 (no-HD and Single Chain) by w0xlt

  w0xlt also landed test coverage for migrating wallets from Bitcoin Core v0.14.3 — that’s 2017 — over to today’s descriptor wallet format. The point is to make sure users can upgrade without losing funds, history, or addresses.
  

  The test covers two old wallet types that current migration tests were not hitting: non-HD wallets created with -usehd=0, and the first-generation HD wallets from that era (VERSION_HD_BASE, single chain). A 0.14.3 node cannot use the normal test-framework sync RPCs, so the test feeds blocks over with dumb_sync_blocks before running the migration.
  

  It also checks encrypted variants, that migration does not sneak in a rescan, and that the backup is a real file. If you still have a wallet from that vintage sitting around, this is the kind of coverage you want in Core before you hit migrate.

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.

txindex: hash keys and pack positions to reduce disk usage by andrewtoth

The current txindex uses the full 32-byte txid as keys, which takes up about 66 GB of disk space today on mainnet. Using a 5-byte key prefix instead drops the disk usage to 26 GB - cutting the size to less than half.

Using the full 32-bytes is unnecessary since a 5-byte salted siphash will produce collisions in about 1 in 1.1 trillion. Some collisions will occur, but the penalty is just an extra disk read, deserialization and hash.
The tx position can be appended to the key instead of used as a value, and a LevelDB iterator can seek to the prefix and then scan for the correct tx. This is an almost identical approach to txospenderindex.

IRC meeting notes

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

--- Topic 1 ---
fjahr: #topic Fuzzing WG Update (dergoegge, marcofleon)
dergoegge: I have some fun things to share
dergoegge: I've vibed up an extension to https://github.com/antithesishq/bombadil that can test the qml gui
dergoegge: https://drive.google.com/file/d/1ioXLPUTvnxi9oo1gn4Hb6ggHsXVb26KY/view this is a video of the fuzzer working
dzxzg: hi
dergoegge: I also had claude use fuzzamoto to test a vibe coded node implementation (rbitcoin) over the weekend
dergoegge: It found a lot of bugs: https://github.com/reardencode/rbitcoin/tree/master/docs/external_findings (a couple of them are from the red team, the rest is from fuzzamoto)
dergoegge: Not an attempt to dunk on the implementation but perhaps this increases the confidence in the types of bugs that fuzzamoto can find
dergoegge: There are some funny ones in there too imo
dergoegge: that's it
dergoegge: actually i think eugene has something to share as well
eugenesiegel: Hi yes
eugenesiegel: I've been working on something called incremental snapshots for fuzzamoto and wrote up a short blog post about benchmarking it:
eugenesiegel: https://crypt-iq.github.io/2026/08/07/incrementalsnapshots.html
eugenesiegel: It's basically a way to speed up the fuzzer and focus on deeper code paths
dergoegge: 🚀
eugenesiegel: that's it, if you have any questions or something was unclear let me know
marcofleon: lfg
brunoerg: nice
sipa: really cool

--- Topic 2 ---
fjahr: #topic Benchmarking WG Update (l0rinc, andrewtoth)
l0rinc: #35531 is ready for review, I think it would fit nicely with the other optimizations we did in this release
l0rinc: and the good news is that I have benchmarked bitcoindev1337's idea to prefetch blocks before connection and it does show a significant speedup, more than my 5% estimation, so it's worth a deeper investigation!
l0rinc: bitcoindev1337 do you want to push something or do you want us to do it? If the latter, what's your github username to add you as coauthor?
l0rinc: that's it from me

--- Topic 3 ---
fjahr: #topic QML GUI WG Update (johnny9dev)
johnny9dev: We got a ton of feedback last week on the preview and have started working on those issues. The project board will continue to the be place where we track the work.
johnny9dev: We currently have about 80 issues we want to complete before starting our PR and about 20 that we think need to have complete before it is releasable.
johnny9dev: I think the feedback/impressions i got on the current staging branch were all i needed to decide to change course. I am now working on just taking the best version of what we have and building up the application in stages. This will include introducing all of our testing frameworks right from the start. The different stages will be very similar to our current git history on the project
johnny9dev: 1. Introduce the build and main  2.add first node lifecycle and model. 3. add onboarding, settings, and node running features 4. add desktop wallet creation 5. add send/activity/receive .... with he last few stages will be adding feature pages to the app.
johnny9dev: this should make cleaner history and easier to review. I will make an effort to attribute each commit with all contributors involved
johnny9dev: When I get closer I think I will create an issue in bitcoin/bitcoin with the plan and include tracking all of the steps we need to complete and look to start the PR for the first chunk.
johnny9dev: thats all for this week

--- Topic 4 ---
fjahr: #topic QA WG Update (brunoerg)
brunoerg: Hi, published at https://bitcoincore.space the latest analysis for src/psbt.cpp and src/private_broadcast.cpp. Also, spent some time filtering the survived mutants for src/script/interpreter.cpp, so the surviving ones may be most of interesting ones to be addressed. That's all, thanks.
fjahr: That's it for the WGs

--- Topic 5 ---
fjahr: #topic Compiler diversity: to drop MSVC or keep it? (hebasto)
hebasto: hi
hebasto: On Windows, as on most other systems, there is more than one compiler that can be used to build Bitcoin Core.
hebasto: Clang provides the clang-cl.exe tool, which is compatible with MSVC's cl.exe. The latter point is important when it comes to a shared libbitcoinkernel.dll.
hebasto: While it's possible to use clang-cl.exe now, #31507 improves the build experience and makes Clang support first-class on Windows.
hebasto: At some point, reviewers suggested that support for MSVC, which produces inferior binaries, could be dropped entirely.
hebasto: Dropping MSVC support has many benefits, but the drawback is that it reduces the diversity of compilers testing the Bitcoin Core codebase, which was noted by cfields during the last CoreDev.
hebasto: Here is the question for today's meeting:
hebasto: Do we want to keep MSVC as a supported compiler?
purpleKarrot: Should this be a vote?
cfields: I think that depends on the meaning of "support".
fanquake: I think this also came up because #31507 (which drops it) was tagged for 32, but there are other PRs like #24773 open, which add more MSVC specific code
fanquake: Confusing to have simeltaneous PRs open which drop support for a thing, and add more support for a thing
hebasto: by support I mean workaroands for compiler bugs and MSVC- specifc diagnostics
purpleKarrot: By support I understand having a requirement that the code builds and tests run successfully when using MSVC as the compiler. Everything else (workaround for bugs, etc) are downstream from that requirement.
cfields: I think it'd be a shame to stop building/testing against non-(gcc|clang). I think "should we avoid pessimizing because MSVC doesn't support X" is a different question.
hebasto: note that clang-cl still uses MS's standard library
fanquake: We also don't want to end up in any one of these "nightly" support loops, where no real CI is run, and we have to continue to re-factor/change code to support something after the fact
fanquake: (similar to what we've seen with all the BSDs lately)
hebasto: fanquake: we can keep a MSVC ci job in the main repo though
dzxzg: if a MSVC ci job was kept in the main repo what would be changing about our support for MSVC
cfields: hebasto: could you describe exactly what you mean by dropping support, then? Explicitly allowing MSVC builds to fail? Ripping out the MSVC ifdefs?
cfields: Asking because as-of-now, release builds are mingw. So strictly as far as users are concerned, MSVC is "unsupported".
hebasto: https://github.com/bitcoin/bitcoin/pull/31507/changes/96d2380dc40e703e342dc0fad5d294cc49b25ff9 removes the ci jobs, documentation and msvc-specific diagnostics from the build system
hebasto: yes, it's not related to release binaries
hebasto: but we support building from source on Windows
cfields: I still think it'd be a shame to lose that diversit. But that's easy to say as someone who doesn't do any work to keep msvc compiling.
cfields: *diversity
hebasto: fanquake: do you agree to keep the current msvc support?
cfields: Perhaps there's a middle-ground keeping some subset of builds working? kernel? bitcoind?
fanquake: I don't mind that much. As mentioned, this doesn't meaningfully change our release binaries, but that was also a reason to push back, because 31507 is adding support for clang, awhich dds *another* way to compile for windows (new ci jobs, more build complexity etc), without actually improving anything we ship
fanquake: Some pushback here too: https://github.com/bitcoin/bitcoin/pull/31507#issuecomment-3928937728
sedited: it would be the only platform where we support targeting it with three different toolchains.
hebasto: well, clang-cl produces much better binaries for people who prefer build from source on Windows
fanquake: basically, if the motivation to use clang, was to avoid all the MSVC compiler bugs/ICE, then we are we continuing to keep supporting/testing it, with all the baggage
fanquake: *why are we
fanquake: Especially given off all the compilers we use, it's the only one we can't actually fix
fanquake: (can't submit patches upstream, microsoft forum for supporting bugs close to useless etc)
purpleKarrot: We should not mix two different topic. We want to build release binaries with the compiler that produces the best binaries. And we want a diverse test setup to find issues in the code.
cfields: sedited: good point. And with the fewest eyeballs.
fanquake: purpleKarrot: the only issues we've found with MSVC so far, as bugs in the compiler, as far as I'm aware
fanquake: Not sure what the "best" compiler is for building releases, but it needs to be an open source one
cfields: fanquake: yeah, ok, I withdraw my objection. I suppose it's philosophical without much grounding in reality these days. It may be diverse, but it's also shitty :p
dzxzg: +1, although having compiler diversity is nice, MSVC is by far the most opaque when issues arise, it is hard to weigh an uncertain but possible benefit that MSVC might catch something that otherwise would have gone unnoticed against the real and constant maintenance cost
sipa: (only half following, am travelling) I think it makes sense to have two different levels of "support", (1) whatever our published release binaries use and (2) systems/platforms where we think people should ve able to build for, but without testing guarantees. For example, I think some BSDs fall in the second category.
sipa: And (2) is great to help for testing diversity too, but doesn't need specifically optimizing for
fanquake: sipa: sure, but that maintains the loop of merging, and having to continually re-factor/fix code
fanquake: where breakage is reported after the fact
fanquake: wasting reviewer time, and creating churn
fanquake: Maybe that is fine, and the build can just remain broken on those platforms/in the cis, until people want to circle back to it
jonatack: hi
janb84: If it does not provide new code issue/insight abd only compiler issues/bugs that need workarounds, i do not see what it brings us
hebasto: cfields: did I get it correctly that you are no longer against dropping msvc support?
sipa: fanquake: or we can choose to treat MSVC as not even falling under (2) ?
fanquake: (maybe we should just have more jobs in the CI in the repo)
sipa: there can even more fine-grained levels i guess, e.g. a "no CI for this config, but we accept patches to fix for"
hebasto: ^^ this seems reasonable
cfields: hebasto: not on the grounds of benefiting from diversity, at least.
lightlike: do we know if we have users/devs who build with msvc (and tend complain if something breaks), or is it just CI?
stickies-v: accepting patches but not running in ci seems like the worst of both worlds to me tbh
dzxzg: lightlike: we have some since it's currently the only supported windows build system, but I imagine we would have close to 0 after clang-cl support is merged and is used in the build instructions
hebasto: lightlike: I build from source on Windows, but prefer clang-cl
sedited: yeah, msvc patches are already getting close to no review. Not having it in CI will probably drop that to zero.
cfields: dzxzg: hmm? Not the only one for Windows.
dzxzg: *native windows not WSL or cross-compiling
sipa: stickies-v: i think that is the reality for e.g. FreeBSD, or has been in the past at leasr; i'm more trying classifying thr current reality than suggesting a policy
fjahr: Let's tie this topic up in the next 2-3 minutes and possibly continue after the meeting
stickies-v: if it's not helping us catch a lot of bugs, it's not used much, and it's a closed source and painful toolchain to use, fully dropping support seems sensible to me, but i'm not really involved with it so happy either way if ppl want to support it
hebasto: could end up keep support for both msvc and clnag-cl for a single release cycle and decide later?
hebasto: * clang-cl
sipa: m
cfields: stickies-v: +1. I think I'm onboard with that opinion now. It'd be different if it were open and we could improve it. But thinking towards a future where we (for ex) migrate to c++26, it's hard to imagine supporting MSVC doing anything for us but slowing us down.
fjahr: sedited: Did you still want to give a kernel update?
sedited: not today
hebasto: so let's drop msvc support
sedited: ack
janb84: ack
stickies-v: maybe open an issue for it?
cfields: hebasto: how about opening an issue with a concrete proposal and we can resume discussing there?
hebasto: will do
cfields: It's still unclear to me exactly how much you propose we drop. For ex, ripping out everything from CMake would mean that no one could even _try_ to build it anymore.
fjahr: Sorry, let me squeeze in my lil topic and continue discussion in the issue :)

--- Topic 6 ---
fjahr: #topic Kartograf 0.5.0 (fjahr)
fjahr: Hi, we have a new release for kartograf, v0.5.0. The big headline is that there are two bugfixes that are breaking reproducible results so with this new version you are not able reproduce the maps that were created with an older version of kartograf and included in the asmap-data repository. For this reason I am proposing to add a note on that in the asmap-data repo to make users aware of this:
fjahr: https://github.com/bitcoin-core/asmap-data/pull/67 In the past we have seen many users just use master and that might lead to some false alarm in the future.
fjahr: Some more info for people to understand the impact: The two bugfixes are 1. https://github.com/asmap/kartograf/pull/145 A bug in the merge code prevented shorter prefixes from being merged when longer prefixes where already present in the higher priority input of the map. This means the results after the fix with the same inputs have more entries and larger coverage but the new coverage appears to be mostly unutilised address space
fjahr: included in IRR DBs, so the real impact is for our purpose appears to be small. On the last 5 historical maps, the impact to the bitcoin network is that 3-4 peers which previously did not have a mapping do have one with the new map. See a more detailed analysis by Joris here: <>
fjahr: 2. https://github.com/asmap/kartograf/pull/148 The IRR DBs we were downloading have inconsistent formatting and since we expected them to always end with an empty line, sometimes the very last entry was skipped when that was not the case. This only resulted in in a single additional prefix mapping (if any) in the final file in the recent runs and bitcoin nodes mappings were not affected by it.
fjahr: Also, I previously stated that I don’t think releases make sense for us because participants usually just use master anyway but in this case it makes communication a lot easier so I guess we aren’t moving away from it for now.
fjahr: Happy to hear feedback on this. Of course we did some additional (AI assisted) review of the code base to ensure we aren’t leaving any other breaking changes we would want on the table that we could bundle with this. But we couldn’t find anything else.
fjahr: And sorry for dumping a wall of text but the kartograf repo doesn't get so many eyes so I rather put it here directly.
sipa: do we expect more agreement on the kartograf output with these changes?
sipa: (among participants all running 0.5.0)
fjahr: Afaict that should be unrelated, the disagreement typically come from rpki which these changes don't have impact on
sipa: ok
fjahr: We still don't know where the recent rise in mismatches comes from exactly but the last one was better so the smaller changes in the downloading steps we made might have helped
fjahr: Last one was 7/10 matches
sipa: nice
fjahr: "My code doesn't work, I have no idea why; My code works, I have no idea why"
fanquake: Next asmap run likely to be the one included in 32.0 ?
fjahr: Yeah, good queue I guess: feature freeze is in 1 week. Any last minute comments on that?
sipa: does new asmap data count as a feature? :)
fanquake: I think new asmap data is more like chainparams and similar
fanquake: So just pre branch off
fjahr: Yeah, no, but I forgot about making room for that topic :)
sipa: also fyi i'll be back from vacation tomorrow, i hooe to do some reviews for 32 where valuable still

Read here for the full meeting

Releases

• No releases

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 Fedimint exposing APIs for atomic swaps, the Cashu Development Kit (CDK) adding support for Iroh, and Marmot upgrading to version 2 of the messaging protocol.

We also cover several important news from the Bitcoin ecosystem. We discuss the current effort by the Red Team to find vulnerabilities in Bitcoin related project and responsibly disclosing them to maintainers, Boltz stopping its swap service, a critical bug in BTCPayServer, and the BIP110 fork.

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:

• PR8913 is exposing APIs for raw Hashed Time-Locked Contracts (HTLCs) APIs in Fedimint.

  • During the weekly call, on Monday 3rd, Fedimint developer discussed PR8913, a new feature providing raw HTLCs APIs. This feature has been widely requested by the community, and the PR, which is still in draft, is addressing this need.

  • The main goal for exposing such an interface is to enable atomic swaps between fedimint ecash and other Bitcoin layers, such as Ark, Cashu, and even Bitcoin on-chain.

  • While the mechanism is already implemented in the Lightning module LNv2, the APIs are not yet exposed to the clients in its raw form.

• PR2285 in the Cashu Development Kit (CDK) is adding support for Iroh.

  • During the weekly call, on Wednesday 5th, CDK contributors discussed PR2285, which aims to introduce a new crate to support Iroh.

  • Iroh is a P2P transport layer for fast and reliable connection between devices. Instead of relying on IP addresses, every Iroh endpoint is actually a cryptographic key.

  • The new feature would allow mints and wallets to communicate over Iroh, instead of relying only on HTTP. The PR introduces a new iroh:// URL scheme so wallets can connect to mints through their public key.

• Marmot has been officially upgraded to the version 2 of the protocol.

  • During the monthly call, on Tuesday 4th, Marmot developers discussed the official upgrade to version 2 of the messaging protocol based on Nostr and Messaging Layer Security (MLS). The new specifications are organized according to the protocol surface, effectively deprecating the precious MIP-based approach.

  • The new version aims to make the protocol more stable, mainly from the group consensus point of view (message ordering, user additions/removals, etc.), allowing each user to reach the same state deterministically. It also aims to make Marmot agnostic with respect to the transport layer.

  • Marmot v2 is currently being integrated in the White Noise client. Its release is expected soon, promising a smoother, faster, and more stable experience.

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

• The Red Team: Following the COLDCARD incident, a group of developers announced a huge red teaming operation to find critical vulnerabilities affecting Bitcoin-related software.

  • The effort, lead by AncorWatch CEO Rob Hamilton, is currently ongoing. According to the last report, the team has discovered around 8000 vulnerabilities, with more the 1200 of critical or high severity level. Bugs are being responsibly disclosed to the various project maintainers.

  • The Red Team is making heavy use of LLMs to discover vulnerabilities, in particular leveraging the frontier, open-weight model Kimi K3. As of today, this is probably the only model able to dive into cybersecurity issues without hitting those limits introduced by producers.

  • As of today, devs focused on red teaming Bitcoin have spent tens of thousand dollars in LLM tokens to bring on their work. Many people have already donated to the cause, while no-profits as OpenSats have launched specific funds to provide grants to people assessing security of Bitcoin software.

• Boltz stopped: On Monday, August 3rd, Boltz announced that they were stopping their service until further notice. As of today, operations haven’t got back to normal yet.

  • According to the Boltz team, the decision came after months of continuous exploits from AI-assisted and automated attacks to their infrastructure. While no users’ funds were stolen, Boltz itself incurred in losses as a result of the attacks.

• Critical bug in BTCPayServer: On Friday, August 7th, the BTCPayServer team announced a vulnerability in their software was actively being exploited by attackers, resulting in loss of funds.

  • The critical bug affects those instances of BTCPayServer (version < v2.4.2) running with an LND Lightning node. The issue allows an attacker to obtain the .macaroon credentials for the node without authenticating. Those credentials can be used to take full control of the LND node, effectively letting a remote attacker move funds.

  • Check BTCPayServer’s security advisory for more information and migration guides. We recommend any user with running an instance to upgrade immediately to v2.4.2.

• BIP110 forked: On Saturday, August 8th, at block height 961632 the period for mandatory signaling for activation of BIP110 began.

  • Block 961632 was mined by AntPool. The pool did not signal for BIP110, effectively rejecting the soft fork. Soon after, Ocean mined a block signaling for activation, thus creating a chain-split.

  • The legacy chain soon took up steam, with new blocks coming regularly. On the other hand, miners on the BIP110 chain were able to only mine another block. Later on, hashrate on the BIP110 chain moved back to the legacy one. BIP110 did not activate.

• Proposal to remove Luke Dashjr from BIP editor: Following the failure of the BIP110 activation, Murch launched a motion to remove Luke Dashjr from the role of BIP editor. The proposal is based on several factors: lack of involvement in the BIP processes, decisions taken over BIP110 with conflict-of-interest concerns, and break of trust and communication with the other editors.

• Coinswap protocol: CitadelFOSS is close to release their implementation of the Coinswap protocol, the foundation for a decentralized atomic-swap marketplace. The protocol is nearly ready for a launch on mainnet, and the developers are actively looking for wallets willing to integrate it in their stack. According to the team, they ready to provide any tech assistance, and the integration requires a few simple API calls.

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.

• wallet: store all witness variants of a transaction by achow101

  
  In this pull request, Ava Chow fixed a long-standing wallet gap where a same-txid transaction with a different witness would just get ignored. Now the wallet keeps those witness variants alongside the known tx, so it actually knows about every wtxid version of its own transactions.
  

  That also helps with fee math on replacements, since different witnesses can mean different feerates. One variant is picked as the canonical tx (confirmed if there is one, otherwise the lightest), older wallets can still load the data, and gettransaction / listtransactions now surface the extras via an alternate_wtxids field. Nice close to an issue that had been open for years.

• fuzz: exercise the transaction-handling path in process_message(s) by HowHsu
  
  More fuzz coverage landed this week. HowHsu had a PR merged that finally gets the process_message and process_messages harnesses into the transaction-handling path that was basically unreachable before.
  

  Those targets used to stay stuck in IBD and mine bare OP_TRUE coinbases, so net processing bailed early and anything that did spend those coinbases got rejected as nonstandard. The mempool stayed empty the whole time. Now the fuzz input can toggle IBD, coinbases use a spendable P2WSH_OP_TRUE output, and the reused mempool gets rebuilt when it goes dirty.
  

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

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 ---
fjahr: #topic Fuzzing WG Update (dergoegge, marcofleon)
dergoegge: https://github.com/dergoegge/bitcoin-antithesis
dergoegge: I've published the antithesis test repo
dergoegge: Please come contribute if you are interested
dergoegge: Some more docs on how the tests are structured: https://antithesis.com/docs/product/test_templates/
dergoegge: lmk if there are any questions
dergoegge: that's it
fjahr: dergoegge: any specifc area where you think more tests are most interesting?
dergoegge: I think we could test assumeutxo with this really well
dergoegge: I have some more ideas on this, feel free to join the bitcoin-core-fuzzing channel to discuss
fjahr: thanks!

--- Topic 2 ---
fjahr: #topic Kernel WG Update (sedited)
sedited: I've pushed an update to #35187
sedited: The introduced block validation function there now takes a callback to fetch coins supplied by the caller
sedited: purpleKarrot opened #35904 as a proposed plan for factoring out a separate validation library.
sedited: The idea being that this library lives one level underneath the kernel library.
sedited: The kernel library would eventually link against it and re-use some of its headers.
sedited: maybe purpleKarrot wants to add something?
willcl-ark: I like the idea of the stateless validation library
cfields: hi
fjahr: purpleKarrot: speak now or... ;)
purpleKarrot: Yes, please have a look #35904. If you want more background information, read my blog at purplekarrot.net and also have a look at std::bitcoin.
cfields: willcl-ark: +1
purpleKarrot: https://github.com/purpleKarrot/std-bitcoin
fjahr: thanks

--- Topic 3 ---
fjahr: #topic QML GUI WG Update (johnny9dev)
johnny9dev: Deciding on what to finish before theoretically merging upstream. Those will be tagged as Beta in the project board.
johnny9dev: I think we have most of that tagged.
johnny9dev: Working on the staging branch in parallel
johnny9dev: https://github.com/johnny9/bitcoin/pull/1
johnny9dev: This is a theoretical first chunk
johnny9dev: The preview build has some significant performance fixes in and published at bitcoincore.app
johnny9dev: That's all for now
willcl-ark: so +5k lines in 247 commits (to review); does that all need to go in together? Or are there ways to break that down for review
fanquake: Where does the base of that PR start? Looks like the first commit is also modifying files that don't exist in master?
fanquake: i.e src/qml/bitcoin.cpp
johnny9dev: Github renders the order strange for me by date.
johnny9dev: And the it goes right into the qml app commit history
fjahr: it?
johnny9dev: The PR.  It is based on a recent master and it starts with cmake files and the initial app module
johnny9dev: Then goes into the qml app commit history
johnny9dev: Sorry just had spotty network.
willcl-ark: ok

--- Topic 4 ---
fjahr: #topic QA WG Update (brunoerg)
brunoerg: no updates this week

--- Topic 5 ---
fjahr: #topic Benchmarking WG Update (l0rinc, andrewtoth_)
andrewtoth_: l0rinc made some pretty cool benchmarks https://github.com/bitcoin/bitcoin/pull/35531#issuecomment-5170999892
andrewtoth_: not much else to report, thanks

--- Topic 6 ---
fjahr: #topic static builds (fanquake)
fanquake: Just wanted to raise that #25573 is now in a state where it can get some proper testing.
fanquake: It's switched to glibc 2.44, which has some changes we upstreamed, and the final (cross arch) reproducibility issues have been fixed.
fanquake: There are some bins up here https://github.com/fanquake/bitcoin/releases/tag/static_bitcoind_ff01e5af948d
fanquake: It would be great to have some testing in more environments/setups.
fanquake: I've posted something with a bit of info to the mailing list as well: https://groups.google.com/g/bitcoindev/c/UgGHs-_YGvw
fanquake: Thats all
sedited: nice :D
fjahr: Anything else to discuss?
fjahr: Feature freeze is in 2 weeks I think?
sedited: yes, feature freeze
sedited: It would be nice to get #35642 before feature freeze (though it needs rebase and I guess sipa is not here).
sedited: Also would be good to get some eyes on #35351.
sedited: Release schedule at #35122
darosior: I'll take a look at 35351
darosior: Sorry, 35642
fjahr: Anything else?
darosior: I started setting up a ckpool for testnet5. Configuring it for testnet4 for now, so we can have some hashrate pointed to it. Then i could use it to mine the genesis block (maybe at the end of the month?) and support the network until professional miners take over.
fanquake: Would be good to get another set of eyes over #35699, can probably put that in soon, before it gets any chunkier
darosior: Hosting it at Chaincode. Anybody who has some hashpower they can plug for a couple months would be welcome
darosior: fanquake: will review that too.

Read here for the full meeting

Releases

• No releases

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 two specification improvements to the Lightning Network, with the merging of BOLT12 payer proofs, and Cashu, with the possibility to mint and melt ecash tokens through custom payment methods.

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

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

Highlights from Bitcoin++ — Consensus Edition

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP460: CISA for Taproot Key Path Spends

Authors: Fabian Jahr

Assigned On: Jul 28th, 2026

Layer: Consensus (Soft Fork)

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

Other News from the Bitcoin World

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

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

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

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

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

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

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

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

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

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

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

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

Highlights from Bitcoin++ — Consensus Edition

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

Here is what caught my eye:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Other News from the Bitcoin World

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

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

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

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

Merged PR’s

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

• fuzz: add p2p_private_broadcast harness by frankomosh

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

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

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

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

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

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

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

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

This change adds two major features to the result class:

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

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

IRC meeting notes

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

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

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

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

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

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

Read here for the full meeting

Releases

• Bitcoin Core v30.3 is now available

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

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

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

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Other News from the Bitcoin World

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

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

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

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

Merged PR’s

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

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

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

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

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

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

wallet: rpc: Deprecate removeprunedfunds RPC by davidgumberg

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

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

IRC meeting notes

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

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

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

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

Read here for the full meeting

Releases

• Bitcoin Core v31.1rc1 is now available

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

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

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

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP95: Testnet 5

Authors: Pol Espinasa, Fabian Jahr

Published On: Jun 25th, 2026

Layer: Applications

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

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP453: Terminology of Transaction Components

Authors: Murch

Assigned On: Jun 20th, 2026

Type: Informational

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

BIP455: Peer sharing of block spent coins

Authors: Robert Netzke, Ruben Somsen

Assigned On: Jun 22th, 2026

Layer: Peer Services

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

BIP456: Hints for unspent coins

Authors: Robert Netzke, Ruben Somsen

Assigned On: Jun 22th, 2026

Layer: Peer Services

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

BIP457: SwiftSync initial block download

Authors: Robert Netzke, Ruben Somsen

Assigned On: Jun 22th, 2026

Layer: Applications

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

BIP458: Half-Aggregation of BIP 340 Signatures

Authors: Tim Ruffing, Jonas Nick, Fabian Jahr

Assigned On: Jul 2nd, 2026

Layer: Applications

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

BIP459: Full-Aggregation of BIP 340 Signatures

Authors: Fabian Jahr

Assigned On: Jul 10th, 2026

Layer: Applications

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

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

Other News from the Bitcoin World

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

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

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

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