bitcoin++'s Insider Edition: Last Week In Bitcoin

New Security Policy — Last Week in Bitcoin (Oct 26 - Nov 01)

Tuma (I WILL NEVER DM YOU) — Mon, 02 Nov 2026 15:03:00 GMT

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.

In this week’s update we feature Nut November, the month-long hackathon of the Cashu ecosystem coming back for the second edition.

We also cover several news from the Bitcoin ecosystem. A new BTCPay Server vulnerability has been discovered, Fedimint is experimenting with the Ark protocol through Bark, Librería de Satoshi is rebranding to ISMOS, and the updated security policy in Bitcoin Core.

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:

Nut November — the month-long hackathon of the Cashu ecosystem — comes back for its second edition.
- During the monthly call, on Thursday 29th, Cashu developers announced the second edition of Nut November, a month-long hackathon focused on Cashu.
- The event features 6 different prizes. Other than the best overall, developers can participate to win a prize for the most difficult technical challenge, the craziest experiment, the best design, and the best tool for value4value. A special prize will also be awarded to first-time contributors to the Cashu ecosystem.
- At the time of writing, the prize-pool amounts to more than 1 milion sats. It is possible to contribute directly to the pool on the hackathon website.

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 recently published BIPs

BIP333: BIP324 One-Byte Message Type ID Alias Assignment

Authors: Anthony Towns

Assigned On: October 28th, 2026

Layer: Peer Services

PR2301 introduces BIP333, which defines a new set324alias message that permits peers using BIP324 — version 2 of the P2P encrypted transport protocol — to assign one-byte message type ID aliases to improve bandwidth usage for their outbound messages. BIP324 assigns one-byte IDs via a fixed table, requiring centralized coordination and introducing risks of conflicts. This new proposal allows peers to choose their own one-byte IDs at runtime for their own outgoing messages.

Other News from the Bitcoin World

BTCPay Server Vulnerability: On Sunday, November 1st, the BTCPay Server team warned users that they were receiving reports of hot wallets being drained. The team recommended to shut down instances to prevent loss of funds
- The vulnerability was confirmed this morning, November 2nd. The BTCPay Server team identified an attack vector targeting instances of the software running versions v2.4.1 and older. At the time of writing, no details about the vulnerability were released.
- According to the team, users running v2.4.7 — the latest release — seems not to be affected by the vulnerability, since no credible report has been produced. The team recommends keeping instances up-to-date with the latest security releases.
Fedimint <> Bark: Fedimint creator Eric Sirion published a video demoing a Fedimint Lightning Gateway based on Bark — the Ark implementation by Second.
- A Federation usually needs to run a Lightning Node to connect its users to the Lightning Network. This experiment demonstrated the possibility to run a Federation’s Gateway based on a simple Ark wallet.
Librería de Satoshi is now ISMOS: From the largest technical education organization focused on teaching Bitcoin to Spanish-speaking individuals, Librería de Satoshi is evolving into a global, full developer pipeline that aims to bootstrap careers in the freedom tech and open-source as ecosystem, called ISMOS. Check out my latest article about ISMOS.
Security policy update in Bitcoin Core: Following the wave of LLM-assisted vulnerability reports, Bitcoin Core developers decided to update the security policy of the reference implementation.
- The update covers those vulnerabilities that are deemed “easily discoverable” thanks to the help of LLM-assisted tools. For this specific case, security patches will be releases as soon as possible and the fix backported to any maintained version.
- The new rule has already been applied. Three vulnerabilities have been fixed and disclosed right away — namely PR3665, PR36667, and PR36669. Since these fixes have been merged after v32.0 had already been tagged, the major release was never published. Instead, v32.1 — containing those fixes — has been officially published this week.

🎃 FAIL does not fail the process - This Week in Bitcoin Core #64

kevkevin — Fri, 30 Oct 2026 14:17:44 GMT

Hello 👋 folks, I’m Kevkevin. I’m an open-source developer and reporter for Insider Edition. Happy Halloween 🎃! The scariest thing this week was a memory bug, and Bitcoin Core moved fast to put it to rest.

32.1 came out quickly because of security fixes. CVE-2026-117350 let a peer exhaust a node’s memory by sending TCP urgent data on anything other than Linux. It was reported on 2026-10-23, and 32.1, 31.2, 30.4, and 29.5 were all out by 2026-10-28.

On the merge side, the fuzz targets got a reachability tracker. A missed goal leaves a ghostly FAIL on stderr, but the process still exits zero unless FUZZ_ENFORCE_REACHABILITY=1. And -acceptnonstdtxn=1 on test nets now checks only consensus flags, so non-standard scripts can be relayed and mined.

Merged PR’s

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

fuzz: add corpus reachability checks by Hao Xu

A ReachabilityGoal is identified by the std::source_location of its declaration: file, line, and column. RegisterReachabilityGoal runs before any input, and ObserveReachabilityGoal ORs a hit into that goal for the life of the process. The tracker destructor writes one line per goal, PASS or FAIL reachability goal "...", with the file, line, and column.

FUZZ_ENFORCE_REACHABILITY is read in the constructor. Unset or 0 leaves enforcement off, so a miss is only that line. 1 makes a miss call std::_Exit(EXIT_FAILURE) after flushing stderr. Any other value aborts immediately. The instrumented targets include cmpctblock, p2p_handshake, package_eval, process_message, tx_pool, utxo_snapshot, and validation_load_mempool. He replayed the current qa-assets corpora for those targets with FUZZ_ENFORCE_REACHABILITY=1.

policy: Allow non-standard scripts with -acceptnonstdtxn=1 (test nets only) by Anthony Towns

-acceptnonstdtxn=1 now also skips non-mandatory script checks. The option stays test-net only. MemPoolAccept::PolicyScriptChecks used to call CheckInputScripts with STANDARD_SCRIPT_VERIFY_FLAGS unconditionally. The flag set is now STANDARD_SCRIPT_VERIFY_FLAGS when require_standard is set, and m_all_consensus_script_flags when it is not. Those are the flags that may be enforced as consensus for some chain state, so a transaction that could become consensus-invalid is still rejected.

CheckInputScripts takes CheckInputScriptsFor::Mempool or ::Block. A script failure on the mempool path is TX_NOT_STANDARD and mempool-script-verify-flag-failed. On the block path it is TX_CONSENSUS and block-script-verify-flag-failed. In p2p_segwit.py, spending a higher-version witness output is now accepted on the node with -acceptnonstdtxn.

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.

orphanage: Fix orphan reconsideration disconnect hole, add 1p1c invariant harness by Gregory Sanders

The first commit adds p2p_1p1c_liveness, an end-to-end fuzz target for parent and child relay. It drives a real PeerManager with real messages and validation. If an honest peer announces the child of an acceptable parent and child, the child has to reach the mempool within a bounded time, whatever the other peers do. Known liveness holes are flags on the target that turn the check off once that hole is open.

The second commit hands reconsideration to a remaining announcer when the marked announcement is erased, and removes the flag for this hole. The follow-up that fills the remaining holes is #36506. On the channel he said v33 is the target for that follow-up.

With that flag turned off, the target finds this bug on master from an empty corpus in under an hour on one core.

IRC meeting notes

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

--- Topic 1 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic Fuzzing WG Update (eugenesiegel, marcofleon)
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: no update from my side

--- Topic 2 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic QML GUI WG Update (johnny9dev)
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Merged in our integration test fixtures
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: We're working through some multi wallet management improvements and threading
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Once those are in well be ready to focus in building up the staging branch.
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: That's all for now.

--- Topic 3 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic QA WG Update (brunoerg)
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: just uploaded the results of a mutation testing for src/node/blockstorage.cpp, there are some interesting cases, in case anyone wants to see: https://mutanthub.space/projects/bitcoin/bitcoin/code/src/node/blockstorage.cpp?ref=4fe28722a572793da7614734a0c9cc8e1adc751a
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: That's all
𝘆𝗮𝗻𝗰𝘆: brunoerg these are some interesting mutations. I feel like this might actully be something an LLM might be good at writing fixes for.

--- Topic 4 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: that's all for the working groups! anything else to discuss?
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: i think it's pretty impressive how we managed to crank out all those releases this week, kudos to everyone helping out
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: as per https://bitcoincore.org/en/2026/10/28/disclose-tcp-oom/ : going from first report on 2026-10-23 to finishing release on 2026-10-28 must be a record?
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: stickies-v +1, good work to everyone including builders for being available to get it done

--- Topic 5 ---
𝘆𝗮𝗻𝗰𝘆: just curious, what exactly is the merge policy or is there one.
𝘆𝗮𝗻𝗰𝘆: I've submitted some small patches over the years, but never really been clear on that
𝘆𝗮𝗻𝗰𝘆: and the user docs on contributing doesn't really say anything of use
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: afaik it's not documented explicitly no, it's also really hard to quantify that in exact non-gameable criteria
𝘆𝗮𝗻𝗰𝘆: got it
𝘆𝗮𝗻𝗰𝘆: in othere projects, there's sort of a two maintaner ack policy sometimes
𝘆𝗮𝗻𝗰𝘆: wasn't sure what it might be in core since I've never observed any pattern
𝘃𝗮𝘀𝗶𝗹𝗱: yancy: there is _some_ reasoning in CONTRIBUTING.md, under "Decision Making" Process
𝘆𝗮𝗻𝗰𝘆: vasild yeah, I've read that. I was just looking for feedback on if there was or wasn't a ACK merge policy, and it doesn't sound like there is.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: PRs can sit around for a long time for various reasons
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: including lack of attention by reviewers
𝘆𝗮𝗻𝗰𝘆: for sure. Shame reviewers :P
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: can't remember the last time i saw a pr that was RFM and then not merged reasonably quickly; it's always lack of review/consensus in my experience

--- Topic 6 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: despite how quickly and seemingly smooth this release went, i wonder if there are things we can do to make it easier / more automated, so we can continue to quickly publish releases when necessary
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: e.g. i think one unnecessary point of friction is that release notes are reviewed in the PR, and then again during a release. the release is often months after a PR was merged, so almost no one still has good context on that change. i feel like it makes more sense to just only review release notes in the first PR, and then the final release notes is a purely mechanistic aggregation of all those excerpts
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: this might require some more (llm-lintable) rules on release notes in PRs, e.g. make sure they are assigned to an appropriate category, are complete, etc
𝘃𝗮𝘀𝗶𝗹𝗱: stickies-v: +1

--- Topic 7 ---
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: eugenesiegel looking to get some eyes on #36437 which sets up a 1p1c fuzz harness for follow up work to improve robutness(up to a limit)
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: instagibbs: might not have time to review soon (trying to add a feature to fuzzamoto), but after that's done I can
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: cool, v33 is target for follow up which fixes the most egregious issues with few loc

Read the full meeting

Releases

32.1 and 31.2 were released 2026-10-27. Signed binaries for 32.1 are in bitcoincore.org/bin/bitcoin-core-32.1. This was a quick security release for CVE-2026-117350, with fixes #36665 and #36667 by Antoine Poinsot.
30.4 and 29.5 were released 2026-10-28. Both binary directories are up, with checksums.

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.

Payjoin <> CISA — Last Week in Bitcoin (Oct 19 - 25)

Tuma (I WILL NEVER DM YOU) — Mon, 26 Oct 2026 15:00:55 GMT

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.

In this week’s update we feature the current work to add support for splicing and dual-funding to taproot channels in the BOLTs specifications.

We also cover several news from the Bitcoin ecosystem. Fabian Jahr is teaming with Payjoin to integrate that protocol with Cross-Input Signature Aggregation (CISA), Core developer l0rinc is working to remove AssumeUTXO , Wavelength is now available on Mainnet, and more.

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:

Lightning developers are working to add support for splicing and dual-funding transactions in taproot channels
- During the monthly meeting, on Monday 19th, Lightning developers discussed the ongoing effort to add support for splicing and dual-funding transaction in taproot channels. The work is currently reviewable in PR1324 in the BOLTs repository.
- Taproot Lightning channels were introduced last May as a way to improve privacy, security, and flexibility of the system. In particular, the new taproot channels use MuSig2 key aggregation to combine two keys into one, with the multisig output becoming a single P2TR key, and tapscript trees capabilities.
- The new update to the specifications aims to add nonces in various messages of the peer protocol to allow creating musig2 partial signatures during dual-funding and splicing. It also allows to omit the prevtx field when using taproot, since that field had to be included to prevent transaction malleability when using pre-segwit inputs.

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP139: Wallet Metadata Backup Format

Authors: Pyth

Published On: October 24th, 2026

Layer: Applications

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

Other News from the Bitcoin World

AssumeUTXO Removal: Bitcoin Core develoepr l0rinc announced a draft proposal to remove the AssumeUTXO feature from the Bitcoin reference implementation. This comes after in-person discussions during the Core Dev meeting.
- AssumeUTXO allows a new user bootstrapping a node to import the UTXO set from an external source to start transacting right away, while the classic Initial Block Download (IBD) starts in the background.
- According to l0rinc, this feature adds several layers of complexity around the codebase, making porposed changes difficult to implement. Moreover, the feature does not seem to be widely used by noderunners.
- L0rinc’s provided a reference implementation of what the removal of AssumeUTXO would look like in PR36598. However, he stated that discussion on whether to remove the feature is still ongoing between maintainers.
Payjoin + CISA = PISA: Fabian Jahr announced PISA, a new integration between Payjoin and CISA.
- Jahr shared a video explaining how PISA could increase privacy on-chain — breaking the common ownership heuristic used in chain analysis —, while at the same time saving in fees.
- To send a payment, both Alice and Bob can provide an input, as in a classical Payjoin transaction. Once Alice gets back the transaction with Bob’s input and signatures, she can leverage CISA so as to aggregate their signatures into one single signature.
- To make it work, Jahr modified Bitcoin Core to include BIP460, the soft work that would bring CISA to Bitcoin. Thus, the provided test implementation is available only on regtest.
Bitcoin Design <> AI: The Bitcoin Design Community — supported by Spiral — is launching a research initiative to understand how the Bitcoin Design Guide should evolve so that it can be easily leveraged by AI agent.
- The Bitcoin Designer Community is specifically looking for builders of Bitcoin and Lightning wallet to understand how AI is used in their workflows, if the Guide is ready for the AI-driven development age, and which could be the areas where it could be improved.
Wavelength on Mainnet: Lightning Labs announced that Wavelength — their implementation of the Ark protocol — was finally available on mainnet. Wavelength was announced in July, promising fast integration of Bitcoin payments in any application.
Bitcoin-backed Dollars on Cashu: Ducat — a Bitcoin-native credit and stablecoin protocol — announced that they had launched a Bitcoin-backed dollar stablecoin built on top of the Cashu protocol. Ducat’s mint would allow users to deposit their UNIT stablecoin and receive newly minted ecash tokens.

We're reimplementing private broadcast - This Week in Bitcoin Core #63

kevkevin — Fri, 23 Oct 2026 14:53:32 GMT

Hello 👋 folks, I’m Kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week I reviewed several pull requests from the Bitcoin Core repo. One merge this week puts the functional-test dependencies in one table in test/README.md. pip, apt, brew, winget, pkg, pkgin, and pkg_add each get a row. The columns are Python, sqlite3, zmq, capnp, and lsof. Under pip the ZMQ module is pyzmq. Under apt it is python3-zmq. The FreeBSD, NetBSD, OpenBSD, macOS, MSVC Windows, and Unix build notes point at that table.

Another merge changes what Assert, Assume, and CHECK_NONFATAL print when the condition is false. The old line was the condition by itself, so pindex != nullptr read as if that were the state the node had observed. StrFormatFailedCheck wraps it. The report is `pindex != nullptr` check failed.

Thursday’s #bitcoin-core-dev meeting took the fuzzing and QML working groups, a second Windows code signer, and a stateless rewrite of private broadcast. v32.0 is tagged. The final binaries are not in the download directory.

Merged PR’s

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

doc: Improve test suite dependencies documentation by Hennadii Stepanov

The per-OS test-suite install snippets in the FreeBSD, NetBSD, OpenBSD, macOS, and MSVC Windows build notes are gone. Each file now links to one table in test/README.md, and doc/build-unix.md gets the same link. The table has a row for each package manager (pip, apt, brew, winget, pkg, pkgin, and pkg_add) and the package name for Python, sqlite3, zmq, capnp, and lsof. Under pip the ZMQ module is pyzmq. Under apt it is python3-zmq.

If an optional dependency is not installed, the tests that need it are skipped, not failed. The from-source pycapnp recipe is gone, and the pip row is the named pycapnp.

util: Clarify the assertion message in assertion failures (Assert, Assume, etc.) by optout

A message of Internal bug detected: pindex != nullptr does not say whether that comparison held. StrFormatFailedCheck now wraps the condition, so a failed Assert, Assume, or CHECK_NONFATAL reports `pindex != nullptr` check failed.

NONFATAL_UNREACHABLE now honors the same abort flag as CHECK_NONFATAL. Both go through the new internal_non_fatal_helper, which aborts if G_ABORT_ON_FAILED_ASSUME is set (a debug build) and otherwise throws NonFatalCheckError. util_check_tests, util_not_null_tests, and rpc_misc.py expect the new text.

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.

Reimplement private broadcast as node state-less jobs + package relay support by Gregory Sanders

Private broadcast on master drives its attempts from node state, and that has already produced a series of careful fixes. This PR replaces it with jobs that do not consult addrman, the mempool, or -onlynet. A job is one broadcast of one transaction. It resolves DNS seed names through Tor, then delivers over BIP324 v2 connections on its own proxy streams, which do not show up in getpeerinfo.

The same job runs inside bitcoind -privatebroadcast or in the standalone bitcoin-privbcast. Part 4 adds one-parent-one-child package relay. The logic is about 4,600 net lines outside consensus, with the rest tests and documentation. He is asking for a concept ACK and a decision on whether parts 1 through 3 are the v33 goal.

The primary failure mode of the in-master private broadcast is that it relies on node state for operation, and this has led to a number of “careful coding” fixes.

IRC meeting notes

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

--- Topic 1 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic Fuzzing WG Update (eugenesiegel, marcofleon)
𝗺𝗮𝗿𝗰𝗼𝗳𝗹𝗲𝗼𝗻: no update from me
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: currently just working on getting bedrock into shape so we can run fuzzamoto with it. some faults I added found some really minor database consistency issues
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: like e.g. a node having a power loss at a super specific point during -reindex prevents the node from starting up again. should things like that be fixed?
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: if it's a loud failure, i wouldn't personally consider that worth spending a lot of energy or complexity on
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: silent consensus failures/money losing behaviour is a different thing of course
𝘆𝗮𝗻𝗰𝘆: might it also be OS disk corruption?
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: I don't think it's a disk corruption issue, just things not being persisted in the proper order. It wasn't clear to me what guarantees the codebase should have when there's no consensus failure or money loss
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: perhaps it depends on how complex the fix would be?
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: I think the fixes are pretty small. I don't think it's likely that anybody will run into these issues though

--- Topic 2 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic QML GUI WG Update (johnny9dev)
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: We're working through the feedback from last week
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: We've got a PR to clarify storage choices during onboarding
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Priority is getting the staging branch ready
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: I am increasingly interested in making a pruned wallet setup work and have started looking into txindex and compact block filters
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: You mean pruned rescans?
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Yeah, pruned rescans. Block retrieval. I think that becomes a high priority for the QML project once the staging branch is settled
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: eugenesiegel: worth at least opening an issue for those. May be a symptom of a bug that could open up more serious inconsistencies. As far as I know we should always be able to recover from a crash
𝗠𝘂𝗿𝗰𝗵[𝗺]: One argument is that a change this large should merge very early in a release cycle, right after branch-off, so the new GUI would only be considered for v34. The new GUI has better testing and more eyes, and I'm uncomfortable releasing the old GUI while hardly anyone is looking at it. Maybe we should talk about getting it into v33
𝗵𝗲𝗯𝗮𝘀𝘁𝗼: it seems premature until the staging branch is ready
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: My current view is that we'll have the PR by the end of the year. Likely end of November or early December
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: I'm not sure merging a huge amount of new code is necessarily safer, so I don't think we should feel time pressure because of that
𝗠𝘂𝗿𝗰𝗵[𝗺]: Sure, let's revisit when the staging branch is available
𝗵𝗲𝗯𝗮𝘀𝘁𝗼: agree

--- Topic 3 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic QA WG Update (brunoerg)
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: no updates this week

--- Topic 4 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic another windows code signer (achow101)
𝗮𝗰𝗵𝗼𝘄𝟭𝟬𝟭: Windows code signing is done by only me, which is a single point of failure. If anyone is interested in being a code signer, message me
𝗮𝗰𝗵𝗼𝘄𝟭𝟬𝟭: Needs to be someone who currently builds, or will commit to building, all releases and release candidates shortly after tagging

--- Topic 5 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic Reimplement private broadcast as node state-less jobs + package relay support (#36608) (instagibbs)
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: I've been working on a node state-less variant of private broadcast. I think it's mature enough to be considered as a replacement for v33. It makes some opinionated decisions so the privacy properties are easier to reason about
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: It's a feature swap on the same sendrawtransaction path, with 1p1c package relay support, plus a standalone tool that is a thin wrapper around the same job
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: Roughly +4,600 net lines of logic, all outside consensus. The rest is tests and documentation. In-master net_processing private broadcast goes away
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: Short term I'm looking for concept and approach ACKs, and a general buy-in that we want this for v33. Also: do we want the standalone tool, or should it fold into bitcoin-util? And should package relay be a follow-up PR?
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵_: I haven't looked in depth, but I'm not sure a 17k line PR is realistic for v33. Conceptual feedback on the previous branch doesn't look addressed
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: I responded to those comments. It's ~4.6k lines net of logic. The rest is tests
𝗰𝗳𝗶𝗲𝗹𝗱𝘀: This overlaps my multiprocess p2p work. I'll take a look
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: This is a big lift for a single feature, but it's more attractive if it comes with a better architecture
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: Maybe it's two releases, but I don't think it has to be. I think it's a removal of risk
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: I agree with the approach: fix the node-state leaks structurally, then consider carving out exceptions for UX, instead of the opposite
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵_: Can we quantify the remaining risks? There were several private-broadcast fixes in v32. What gaps are left, given it's experimental and the guarantees were softened?
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: The risk is sharing node state, which leaks in dozens of ways. The part to debate is the addrman-less design. addrman is heavily attacker-influenced, and there are tradeoffs
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: We can't guarantee perfect privacy. If private broadcast is supposed to provide any limited guarantee against an adversary, separating it from node state is a requirement
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵_: Private broadcast already protects a user's privacy against linkinglion. Default broadcast exposes the transaction origin even with BIP324
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: Current private broadcast can expose origin too, if someone cares enough to attack. I don't think we should offer a feature branded as privacy that doesn't hold up to that bar
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: We can continue off-channel
𝗱𝗮𝗿𝗼𝘀𝗶𝗼𝗿: On the tool: I don't see why we need a new binary. bitcoin-util is fine. A separate tool is a small cost and a useful canary against reintroducing node state. On the split: package relay can be a follow-up, but the swap itself should not be split, or master ends up with two implementations
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: I started with the tool so I wouldn't re-add node state to the jobs, then reused that library inside the node
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: agreed with darosior on not splitting the swap

--- Topic 6 ---
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: v32.0 has been tagged
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: The security policy update is merged: https://github.com/bitcoin-core/bitcoincore.org/pull/1281
𝗳𝗮𝗻𝗾𝘂𝗮𝗸𝗲: PR to enrol Core in the Anthropic OSS scanner: https://github.com/anthropics/oss-scanner/pull/1018

Read the full meeting

Releases

v32.0 is tagged: github.com/bitcoin/bitcoin/releases/tag/v32.0 (tagged by sedited). The final binaries are not published yet.

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.

More Offchain Protocols — Last Week in Bitcoin (Oct 12 - 18)

Tuma (I WILL NEVER DM YOU) — Mon, 19 Oct 2026 14:03:36 GMT

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.

In this week’s update we feature current effort to add support for recurring payments with BOLT12 in LDK.

We also cover the announcement of two new offchain protocols on Bitcoin, namely Zark by Lx DEV, a statechain with a blinded co-signer and zero-knowledge proofs, and LayerTree by Lightning Labs, a non-custodial scaling solution which allows multiple users to share a Bitcoin UTXO.

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:

LDK contributors are working on adding support for BOLT12 recurrence in the Lightning Implementation.
- During the biweekly call, on Monday 12th, LDK contributors discussed the latest updates to the Lightning implementation. One of the most interesting things devs are working on right now is adding support BOLT12 recurrence in LDK Node.
- Developer Shashwat Vangani is currently working on PR1119 in LDK Node, which builds on the previous work done in rust-lightning — which introduced protocol primitives, message handling, and payment flow.
- This PR introduces the management whole recurrent payment workflow to LDK Node, such as persistence of recurrent payment state, updates, scheduling, and APIs for applications to manage recurrence.

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

Zark: Lx Dev announced a new protocol for private, offchain Bitcoin transfers called Zark. The protocol is based on the statechain paradigm and leverages zero-knowledge proofs to improve users’ privacy.
- The protocol’s coordination relies on a co-signer. This entity is blinded, which means that it signs a UTXO transfer without getting to know the specific details about the transfer itself. Users need to trust the co-signer to delete the keyshares belonging to a previous owner.
- Users can prove their ability to spend, receive, and withdraw coins using zero-knowledge proof. This means that inside the protocol the amount of leaked information about previous owners — such as payout addresses — is highly reduced, improving privacy.
- Lx Dev published an extensive overview of Zark, which dives into how the protocol works and which are the trade-offs to be taken into account.
LayerTree: Lightning Labs announced LayerTree, a new non-custodial scaling solution on Bitcoin, which allows multiple users to share a Bitcoin UTXO.
- Ownership is recorded offchain into a Merkle-sum tree in which each leaf represent a user’s balance, and Each node of the tree holds a hash of its children, up to the root. The shared UTXO commits to the root of this tree.
- The protocol cannot work on Bitcoin as it is today. According to Lightning Labs CTO Olaoluwa Osuntokun, LayerTree needs covenant to work. Interestingly enough, no specific opcode is needed, but the protocol could work with any of the proposals already drafted.
- Lightning Labs published a full website, which allows users to interactively understand how the protocol works.
Post-quantum Shielded CSV: Jonas Nick reported that a research group from Imperial College had published a paper introducing a post-quantum version of ShieldedCSV, called Compact ShieldedCSV. Unlike ShieldedCSV — where the nullifier carries a signature — Compact’s nullifiers carry no signature, only something called a “degriefer”.

The prefill was already there - This Week in Bitcoin Core #62

kevkevin — Fri, 16 Oct 2026 14:02:29 GMT

Hello 👋 folks, I’m Kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week I reviewed several pull requests from the Bitcoin Core repo. One merge this week changes the compact-block reconstruction log. When a peer prefills a transaction this node already has, in the mempool or in the extrapool, that prefill is now its own count and its own byte size. The old line folded the extrapool into the mempool number. The new one reports prefill, mempool, extrapool, and the transactions that still had to be requested as four separate numbers.

Another merge removes -persistmempoolv1. That option wrote mempool.dat in the legacy format so a node could downgrade to v26 or earlier. Those releases are unsupported. The file is always written in the current format, with a random XOR key. A v1 file still loads.

Thursday’s #bitcoin-core-dev meeting was not held. stickies-v left a reminder that many people could not attend. Later, eugenesiegel asked about startup failures after power loss, and nkaretnikov pointed at the missing-undo report and the chainstate rewrite discussion. v32.0rc4 is tagged, and the binaries are up. Final v32.0 is not.

Merged PR’s

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

cmpctblock: Improve logging of cmpctblock message reconstruction statistics [part of prefill series] by David Gumberg

The compact-block reconstruction log used to fold extrapool hits into the mempool number. On a successful FillBlock it now prints four separate counts with byte sizes: prefilled, from mempool, from extrapool, and requested. A second debug line reports redundant prefills, meaning prefilled transactions the node already had in its mempool or extrapool.

These stats are only collected when cmpctblock debug logging is on, otherwise they stay zero. At trace level, every requested txid is now logged in one line, not only when fewer than five were missing.

mempool: Remove -persistmempoolv1 option by Fabian Jahr

-persistmempoolv1 wrote mempool.dat in the old v1 format, without the XOR key, so a node could downgrade to v26 or earlier. v26 has been end of life since April 2025, so the option is gone. DumpMempool always writes the current format with a fresh obfuscation key, and a v1 file still loads.

mempool_compatibility.py now tests against v31.0, the last release with the flag. mempool_persist.py also checks that importmempool rejects a truncated file.

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.

mempool: remove time-based transaction expiry by Abubakar Sadiq Ismail

Evicting by age can drop a transaction that could still be mined, so this PR (fixing #33510) deletes CTxMemPool::Expire and the two-week default. LimitMempoolSize now only trims to the size limit, and LoadMempool no longer skips old saved transactions.

-mempoolexpiry stays as a hidden option that only logs a warning if set. The entry_time index and mempool_expiry.py are removed.

Time-based mempool expiry has been removed, and the -mempoolexpiry startup option no longer has any effect (a warning is logged if it is set).

IRC meeting notes

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

--- Topic 1 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: reminder: there's no IRC meeting today as many won't be able to attend

--- Topic 2 ---
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: there are a few obscure cases where power loss can prevent a node from being able to startup, nothing serious. how should these be handled, should I make an issue to track them? Some of these might have already been reported by the LLM audits. I've run into a number of them while fuzzing + emulating power loss with the bedrock hypervisor
𝗻𝗸𝗮𝗿𝗲𝘁𝗻𝗶𝗸𝗼𝘃: eugenesiegel: this reminded me of #25539 which i assume was reported by you as well
𝗻𝗸𝗮𝗿𝗲𝘁𝗻𝗶𝗸𝗼𝘃: there was also a mention of power loss in this recent discussion #35298

Read the full meeting

Releases

The v32.0rc4 binaries are now published: bitcoincore.org/bin/bitcoin-core-32.0/test.rc4 (tagged by sedited).

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.

Making Taproot Annexes Standard — Last Week in Bitcoin (Oct 05 - 11)

Tuma (I WILL NEVER DM YOU) — Mon, 12 Oct 2026 14:03:16 GMT

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.

In this week’s update we feature the latest news from Marmot — with the team working on bringing multi-device to the protocol — and the implementation of efficient animated QR codes in Cashu.

We also cover the effort by Robin Linus to make taproot annexes standard in Bitcoin Core, an attack to Second that resulted in 0.75 bitcoin stolen, and the latest patch release for Core-lightning.

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:

Marmot protocol specifications are now stable and the team if focusing on the next features, such as multi-device.
- During the monthly community call, on Tuesday 6th, Marmot developers discussed the latest improvements in the protocol for secure, private messaging and in the White Noise application and gave an update on the next steps.
- Marmot specifications are quite stable now and the Marmot Development Kit (MDK) is nearly on par with them. The team solved a bug that did not allow a group to have more than 50 users and is currently working on making media upload faster and more efficient and focusing on how to make Marmot itself more private.
- Devs are now focusing on one of the most requested, multi-device — i.e. the possibility to have the same chats, with the same messages, on multiple devices. This is one of the most complex features to work on, given the decentralized nature of the protocol. The team is currently gathering ideas on that and is working toward a draft specification.
Cashu developers are implementing efficient animated QR codes thanks to a discussion at the bitcoin++ conference in Berlin.
- During the weekly call, on Wednesday 7th, CDK developers discussed PR2646 which aims to add binary fountain token transport, a way to make animated QR codes more efficient.
- This new feature comes from a discussion between Cashu developer Egge and Fedimint contributor Joschisan during the Berlin bitcoin++ conference. Joschisan had previously implemented custom, efficient fountain QR codes in Fedimint.
- The feature is also being implemented in cashu-ts — the TypeScript implementation of the Cashu protocol — and an upgrade to the NUT-16 specification is currently under discussion. Moreover, Egge published the nut-fountain repository which includes a TypeScript implementation and a playground to test the new feature in the browser.

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

Making taproot annex standard: Robin Linus — BitVM creator and developer working on Shielded CSV (now Glass Coins) — decided to open a pull request to make taproot annexes standard in Bitcoin Core.
- A taproot annex is an optional field in the witness structure of taproot inputs that can be used to store additional data. This field still hasn’t a clear use-case and was reserved for future updates.
- Glass Coins need to post data to the main chain, as a requirement to prevent double-spending in the client-side validated protocol. Linus’ idea would be to leverage the annex for that specific purpose. However, Bitcoin Core does not relay annexes by default. Linus’ PR aims to change that, allowing Bitcoin Core nodes to relay them.
- As Rearden pointed out, however, two implementations already relay the annex by default, namely LibreRelay and rbitcoin.
Bark Hacked: Second revealed that the company had been hacked on Monday 5th. An attacker exploited a bug in the Ark Server’s boarding flow and managed to steal 0.75 bitcoin of Second’s own liquidity. No users’ funds were stolen.
- The attacker was able to exploit a bug that allowed him to board the Ark Server using only his own signature. Usually, the process requires a co-signature from the Server itself. Thus, the attacker was able to exit the ark protocol with the funds, while at the same time spending his VTXOs through Second’s Lightning gateway.
- No funds from Second’s users were stolen, thanks the design of the Ark protocol. In fact, users’ VTXOs sit on a pre-signed exit path that no one else — server included — can spend.
- An interesting thing about this attack was that the liquidity used to perform it was linked to the hack that hit Blink couple of weeks ago.
Upgrade Core-lightning: The Core-lightning team released a new patch version, v26.06.9, that fixes a vulnerability that could lead to a loss of funds. The team suggested an immediate upgrade for node operators running version v26.06.8 and lower.

The comma is the limit - This Week in Bitcoin Core #61

kevkevin — Fri, 09 Oct 2026 14:04:26 GMT

Hello 👋 folks, I’m Kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week I reviewed several pull requests from the Bitcoin Core repo. The merge with the most review this week puts the IPC connection cap on the bind address itself. There is no new global -ipcmaxconnections. -ipcbind takes the number after a comma: -ipcbind=unix:/path/to.sock,max-connections=8. Each listener defaults to 16 simultaneous clients, and will not go above 256.

The next merge by review activity is util::NotNull. The standard library has no type for a smart pointer that is not null. This one checks at construction, deletes assignment from nullptr, and refuses raw pointers. Call sites that used to Assert before a dereference now get that check from the type.

Thursday’s #bitcoin-core-dev meeting, chaired by stickies-v, went through the working groups. Kernel logging landed as a struct instead of a formatted string, and the script-evaluation tracer is up for review. L0rinc left a note on an opt-in pruned assumevalid mode. The QML work is moving functions off the GUI thread. mutanthub can take a request for a mutation run on a pull request. The v32.0rc3 binaries are up.

The channel agreed to skip next week’s meeting (I suspect because of TabConf). After it ended, Sedited said to keep testing the release candidate.

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.

ipc: support per-address max-connections options on -ipcbind by Enoch Azariah

Instead of a global -ipcmaxconnections, the IPC connection cap now lives on the address itself: -ipcbind=unix:/path/to.sock,max-connections=8. A global number can’t give two sockets different limits, and the inline form leaves room for more options later. Each listener defaults to 16 clients and tops out at 256. Extra clients can still connect, but they wait in the backlog until an accepted client disconnects.

Startup also checks the file descriptor budget before binding. Each -ipcbind costs one listening socket plus its connection slots, and the total has to stay at or under 257, otherwise init fails with “Too many IPC file descriptors requested”.

util: Add util::NotNull by MarcoFalke

std::reference_wrapper covers a raw pointer that can’t be null, but smart pointers had no equivalent short of an Assert at every use. util::NotNull Asserts the pointer at construction, deletes construction and assignment from nullptr, and rejects raw pointers. NotNullUniquePtr and NotNullSharedPtr are the shorthands, and get() still Assumes the pointer is non-null in case it was moved from.

The first users drop their manual checks: CDBWrapper::DBContext(), CoinsViewOverlay‘s thread pool, CNode::m_transport, and CTxMemPool::GetChangeSet().

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: Add script evaluation tracer by sedited

This is the PR sedited asked for review on in the kernel update. alexanderwiederin is already calling it from rust-bitcoinkernel #230 for an experimental BIP440 integration.

The kernel C header gets a callback for the script interpreter’s state on each step. It is compiled only with -DENABLE_SCRIPT_TRACE=ON. Otherwise the hooks are stubs. Evaluation is split into frames. RAII records a start frame and an end frame for every run, and each instruction gets its own frame. The ScriptError from script_pubkey_verify is on those frames so the error code is visible in the trace. The same frames are a way to check that the interpreter did what a script test thinks it did, including under fuzzing.

This adds a callback hook to the kernel library C header for getting the current script evaluation state on each script evaluation step.

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 get going with the working groups!

--- Topic 1 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic Fuzzing WG Update (eugenesiegel, marcofleon)
𝗺𝗮𝗿𝗰𝗼𝗳𝗹𝗲𝗼𝗻: no official update from me, but know that high quality fuzzing is occurring
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: we will continue sleeping soundly

--- Topic 2 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic Kernel WG Update (sedited)
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: Merged #34374, which gives kernel users a more flexible logging interface by providing a struct instead of a formatted string.
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: It also got rid of reliance on the logging module.
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: other than that I'm looking for review on #35641. alexanderwiederin is using it over here https://github.com/sedited/rust-bitcoinkernel/pull/230 for experimental BIP440 integration.
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: that's all.

--- Topic 3 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic Benchmarking WG Update (l0rinc)
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: Copying from above:  I can't make today's meeting, but wanted to share https://github.com/bitcoin/bitcoin/issues/36476: an opt-in pruned assumevalid mode that downloads blocks without witnesses, buffers them in memory, then deserializes and connects them without writing blocks or undo data to disk. Early tests bring pruned IBD on a 2 GB Pi 4 from ~22 days to under a week (3 days on an earlier prototype), which could make low-end devices practical again.
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: oh thanks, I missed that!

--- Topic 4 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic QML GUI WG Update (johnny9dev)
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: We got a lot of really good feedback from testing last week. The preview build should be updated and I have been cleaning up the project board.
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: the focus right now is finalizing some UX, moving every function off of the gui thread and adding regression tests around that, and then finalizing the feature set for the staging/upstream to bitcoin/bitcoin
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: thats all
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: thanks for the updates!

--- Topic 5 ---
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #topic QA WG Update (brunoerg)
𝗷𝗼𝗻𝗮𝘁𝗮𝗰𝗸: nice work (kernel and ibd)
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: mutanthub now has a dedicated page to request a mutation analysis for a pull request - https://mutanthub.space/projects/bitcoin/bitcoin/requests#request-a-run
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: so if you'd like a mutation testing run for your PR, please request there
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: that's all
𝗷𝗼𝗻𝗮𝘁𝗮𝗰𝗸: (and gui)
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: anything else to discuss?
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: no meeting next week?
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: sgtm
𝘀𝗹𝗶𝘃𝟯𝗿__: yup
𝘀𝗹𝗶𝘃𝟯𝗿__: sgtm too
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: grazie a tutti
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: #endmeeting
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: and keep testing the release candidate!

Read the full meeting

Releases

The v32.0rc3 binaries are now published: bitcoincore.org/bin/bitcoin-core-32.0/test.rc3 (tagged by fanquake).

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.

Payments Edition — Last Week in Bitcoin (Sep 28 - Oct 04)

Tuma (I WILL NEVER DM YOU) — Mon, 05 Oct 2026 14:01:44 GMT

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.

In this week update we feature the most interesting things happened during Bitcoin++ Payment Edition in Belrin. During the three-days conference, developers met to discuss how to make Bitcoin payments better for everyone.

We also cover some interesting news from the Bitcoin ecosystem. Notably, we discuss Peter Todd joining MARA Foundation, an interesting deep dive by Vinteum, and Blink Wallet’s post-mortem on the recent attack to their users.

Highlights from Bitcoin++ — Payments Edition

I spent last week at Bitcoin++ Payments Edition in Berlin. The first day of talks will be live-streamed starting from Thursday, October 8th, at 5PM UTC.

Day 1

Rene Pickhardt kicked-off the Berlin conference by talking about his experience in working on Lightning.
Calle gave a talk describing how they are working towards federaing Cashu ecash, so as not to rely on a single mint.
Erik Cativo, the designer behind several Cashu applications, talked about how they built the Numo point-of-sale app by working closely with the merchant using it.
Steven Roose, CEO at Second, described how Bark — their implementation of the Ark protocol — can make self-custodial Bitcoin payments easier.
Allen Farrington came back to Berlin for a sequel talk on the fiat payment stack. This time, he talked about how the different layers of Bitcoin can improve payment technology.

Day 2

Aleksei Moskvin and Markus Schofnegger, researchers at [[alloc]init], talked about Shielded Bitcoin, the new metaprotocol that promises ZCash-style private Bitcoin payments on-chain with no consensus change needed.
Setor, the developer behind BilndBit, talked about how is product is trying to balance UX and privacy for silent payments.
Elias Rohrer gave a talk about Loupe, the AI-assisted security scanning suite used in several projects across the Bitcoin ecosystem.
Jesse Shrader examined the technologies and opportunities behind cross-currency payments on Bitcoin using Lightning.
Niftynei moderated a panel with Calle, Joschisan, Michael, and Elias, where the devs discussed their different experiences with LLMs and tried to understand if Bitcoin can survive the current AI onslaught.

Day 3

Stutxo gave a talk on how to make Bitcoin magical internet money again, thanks to the ongoing effort of several projects.
Pim Keer presented a protocol for accountable Chaumian ecash, which protects users from token overissuance while maintaining unlinkability.
Jungly described the P2Poolv2 Share Chain, a way to make miner payouts non-custodial.
Ilya Evdokimov presented Zerosats, an experiment that aims to make Bitcoin transactions private while keeping the base chain maximally transparent.
Lightrider talked about his 7-years long experience in accepting Bitcoin as a payment method.
Niftynei moderated the final panel with Liam Eagen, George, Matthew Vuk, and Markus Schofnegger, exploring which should be the future Bitcoin stack for payments.

A BIPs Update

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

Other News from the Bitcoin World

Peter Todd <> MARA Foundation: MARA Foundation recently announced that Peter Todd had joined them as Lead Maintainer of Slipstream, a private mempool service that allows direct submission of transactions to MARA’s mining pool. Todd’s involvement with Slipstream is mainly due to the use of the service as a proving ground for different proposals in the Bitcoin R&D space.
Vinteum’s Deep Dive on Privacy: Vinteum — the organization behind open-source Bitcoin development in Brasil — published an interesting deep dive on how chain analysis work, with the aim to understand how private are Bitcoin transactions.
Blink Wallet Attack Post-mortem: Blink recently published the post-mortem for the attack that affected their wallet and that resulted in 6.61 bitcoin stolen from their users. It seems that the attacker leveraged a flaw in their admin tools to gain access to 35 accounts. All affected users were made whole, and the company put a bounty as high as 50% of the recovered funds.

v32.0 is around the corner - This Week in Bitcoin Core #60

kevkevin — Fri, 02 Oct 2026 14:01:47 GMT

Hello 👋 folks, I’m Kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week I reviewed several pull requests from the Bitcoin Core repo.

The merge with the most review this week is the wallet fee ceiling. -maxtxfee is a total fee, an amount, and the default is 0.10 BTC. The wallet was using that amount as the upper bound on the fee rate. #29278 adds-maxfeerate, a rate, default 0.10 BTC/kvB (10,000 sat/vB). The wallet will not create a transaction above that rate, and broadcast rejects one the same way.

The next merge by review activity is a Guix time-machine update. On riscv64, guix shell failed because python-lief 0.17.5 does not support that system. The pin moves to Guix 60f6956a, and that build works again.

Thursday’s #bitcoin-core-dev meeting, chaired by abubakarsadiq, went through the working groups, a mutation-testing site, and a proposal for automated review on pull requests. In the channel, fanquake tagged v32.0rc3.

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 maxfeerate wallet startup option by ismaelsadeeq
Abubakar Sadiq Ismail (ismaelsadeeq) merged the fix for #29220. -maxtxfee stays the absolute cap on the fee of one wallet transaction (default 0.10 BTC, and it still lives under debug/test options). -maxfeerate is a wallet startup option, in BTC/kvB. The default is CFeeRate{COIN / 10}, 0.10 BTC/kvB, 10,000 sat/vB.
CreateTransactionInternal already refused a fee above m_max_tx_fee. It now also refuses when current_fee is above m_max_tx_fee_rate.GetFee(tx_vsize). That error is MAX_FEE_RATE_EXCEEDED. The absolute cap still returns MAX_FEE_EXCEEDED.
Broadcast takes both limits. SubmitTxMemoryPoolAndRelay passes m_max_tx_fee and m_max_tx_fee_rate into broadcastTransaction. The node test-accepts the transaction, then fails if the base fee is above -maxtxfee, or above what -maxfeerate allows for the transaction’s vsize. The strings are split. An absolute-fee failure is “Fee exceeds maximum configured by user (maxtxfee)”. A rate failure is “Fee rate exceeds maximum configured by user (maxfeerate)”.
Startup treats the two options differently. -maxfeerate below -minrelaytxfee is an error, so the wallet cannot be configured to build transactions that will sit under the relay floor. -maxtxfee set so that a 1 kvB transaction at that absolute fee would be under -minrelaytxfee is a warning: some transactions at the relay floor will not fit under the absolute cap, and the wallet will refuse to create them.
guix: Update time-machine to 60f6956aeffa7f30285745bd0ea615e9acfc74f8 by hebasto
Hennadii Stepanov (hebasto) fixed #36232. On master, a Guix build on a RISC-V host failed with package python-lief@0.17.5 does not support riscv64-linux. The unsupported package is an indirect dependency. python-lief pulls in python-scikit-build-core, which pulls in python-cattrs, which pulls in python-msgspec. python-msgspec had (supported-systems (list "x86_64-linux" "aarch64-linux")).

The time-machine commit is Guix 60f6956aeffa7f30285745bd0ea615e9acfc74f8. That includes Guix commit b35905695afd, which updates python-msgspec and drops the system allowlist. Along with that pin, git-minimal goes from 2.52.0 to 2.54.0, linux-headers from 6.1.166 to 6.1.172, python-lief from 0.17.5 to 0.17.6, and python-minimal from 3.11.14 to 3.12.12.

python-lief and nsis-x86_64 also pull in packages whose tests fail when they are built natively on riscv64: python-psutil, python-pytest-xprocess, and python-sh through python-lief, and python-psutil through nsis-x86_64. Those tests are skipped for now.

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

net: always complete all initial private broadcast connections by andrewtoth
Andrew Toth (andrewtoth). Open, not a draft, mergeable, on the 32.0 milestone. This is the one to read while v32.0rc3 is out and milestone 84 still has open pull requests. It is an alternative to #34707.
Private broadcast is supposed to open three connections. If the node stops once the transaction shows up in its own mempool, or once the transaction is a mempool conflict, the missing connection is itself a signal. An observer who can see which connections completed can line that up with acceptance. The same class of timing leak is described on #34707 and on #29415.
This PR keeps the three initial sends. A transaction that comes back, or that conflicts in the mempool, is MarkResolved rather than Remove, so the node does not treat that as “stop talking.” Disconnects are tracked, and a retry has to go through TryGrantRetry, so a stale failure does not turn into an extra connection on top of the original three.
always send 3 times regardless if the tx is received in our mempool or is otherwise invalid

IRC meeting notes

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

--- Topic 1: Fuzzing ---
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: #topic Fuzzing WG Update (eugenesiegel, marcofleon)
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: I'm not sure if marcofleon is here, but no update from my side
𝗺𝗮𝗿𝗰𝗼𝗳𝗹𝗲𝗼𝗻: no update this week
𝗺𝗮𝗿𝗰𝗼𝗳𝗹𝗲𝗼𝗻: possibly next

--- Topic 2: Kernel ---
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: #topic Kernel WG Update (sedited)
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: I think @sedited is not here, so I will move on.

--- Topic 3: Benchmarking ---
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: #topic Benchmarking WG Update (l0rinc, andrewtoth)
𝗹𝟬𝗿𝗶𝗻𝗰: nothing from my side, but want to present something next week
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵_: I haven't had an update in this WG in a while. I think I can be removed as lead.
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵_: I will still actively review speedup PRs and benchmark, but I don't really have regular updates to give.
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: alright, if l0rinc also has no update, it can be archived.

--- Topic 4: QML GUI ---
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: #topic QML GUI WG Update (johnny9dev)
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Pseudorandom has completed a comprehensive overhaul of the UX
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Its looking good and were close to a design we think will work for release
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Will start getting more feedback on it.
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: If anyone is interested in trying its in the qt6 branch of the project
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: That's all for this week
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: thanks @johnny9dev
𝘄𝗶𝗹𝗹𝗰𝗹-𝗮𝗿𝗸: are there pre-built bins johnny9dev?
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: willcl-ark: by the end of the day bitcoincore.app will have them

--- Topic 5: QA / mutation testing ---
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: #topic QA WG Update (brunoerg)
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: I've been working on a new project which is a collaborative mutation testing platform (https://mutanthub.space/). I've noticed that we have people using different tools and approaches to create mutants, different PRs addressing mutants (some overlaps), etc.
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: So the idea of this new platform is that everything is centralized there and it becomes more collaborative.
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: Anyone can submit surviving mutants, reproduce and evaluate them.
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: For every surviving mutant, people can claim that a commit or PR kills it (so people can test it and/or avoid overlaps), as well as we can have discussions about mutants there.
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: In the coming days, I will probably shutdown https://bitcoincore.space and https://secp256k1.space and centralize everything on mutanthub.
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: feedback is welcome
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: that's all
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: @brunoerg whats the process of submitting mutants?
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: e.g. you can open any file from our source code (at https://mutanthub.space/projects/bitcoin/bitcoin/code), click on a specific line and suggest a mutant. Me as admin of the platform or any other people that wants to help in this process have to approve it (just to avoid trolls).
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: we also have a feature that me and selected people can do bulk import from a json file.
𝗱𝘇𝘅𝘇𝗴: The killed mutants are the ones where a fix has been pushed to the project?
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: killed mutants are the ones that are detected by any of our tests
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: considering the tests at the same commit point from where that mutant was created
𝗱𝘇𝘅𝘇𝗴: ah i see, thanks for sharing it looks awesome

--- Topic 6: 32.0 milestone ---
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: Anything else to discuss?
𝗱𝘇𝘅𝘇𝗴: Maybe just an ask there's still some items on the 32.0 milestone, it would be helpful if anyone has extra hands to look thee
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: https://github.com/bitcoin/bitcoin/milestone/84

--- Topic 7: fuzzamoto ---
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: would people find it helpful if they could tag some sort of bot or add a label that says they want a fuzzamoto build on their PR (assuming fuzzamoto covers the code in the first place)
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: eugenesiegel remind me where is there a spot to look at scenarios covered
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: eugenesiegel: sounds useful to me
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: instagibbs: scenarios here: https://github.com/oss-garage/fuzzamoto/tree/master/fuzzamoto-scenarios/bin but the ir scenario covers most of the p2p stuff
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: I can vibe-code a bot ppl can ping and make it as un-invasive as possible, that's all from me
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: instagibbs: no watering hole

--- Topic 8: AI review ---
𝘄𝗶𝗹𝗹𝗰𝗹-𝗮𝗿𝗸: I'm wondering if there'd be interest in a limited trial of automated AI reviews on PRs. I've already been testing this in my mirror of bitcoin/bitcoin, and I feel the results are useful enough. If there is interest, I think we could start on PRs coming from contibutors outside the frequent-contributor group.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: could we start with allowing people to call it in for their PR, so people can sample it
𝘄𝗶𝗹𝗹𝗰𝗹-𝗮𝗿𝗸: My suspicion is that some (or all) PRs arrive with LLM assistance or review in some capacity, and that human reviewers will then download the branch and make another llm-assisted first pass review. An automated review could do some of that initial work once and make the findings available to everyone/the original author.
𝘄𝗶𝗹𝗹𝗰𝗹-𝗮𝗿𝗸: instagibbs: that could also be an approach
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: can we make it so that another person can't invoke it on your own PR if it's opt-in?
𝘄𝗶𝗹𝗹𝗰𝗹-𝗮𝗿𝗸: If you want to see what the reviews are like first, then you can check new/recently-synced PRs here: https://git.fish.foo/bitcoin/bitcoin there should be a comment from "ralph" after some time with a review
𝘆𝗮𝗻𝗰𝘆: I think that would be interesting upon request
𝗱𝘇𝘅𝘇𝗴: what model is it using?
𝘄𝗶𝗹𝗹𝗰𝗹-𝗮𝗿𝗸: I have to run out now, but will read all following messages when I get back. Happy to provide more details/links to bot code/prompts etc if folks want
𝘄𝗶𝗹𝗹𝗰𝗹-𝗮𝗿𝗸: I had codex make a crazy "how it works" chart which is here, and has the models in use for each agent/pass: https://github.com/willcl-ark/nix/blob/master/pkgs/forgejo-review-bot/README.md
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵_: I think most of the value of LLM reviews is still having it be distilled by experienced contributors. So just posting the LLM output on a PR doesn't add much value IMO.
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: andrewtoth_: +1, I think it can be noise sometimes, so a dev should review the LLM reviews and post them.
𝗮𝗯𝘂𝗯𝗮𝗸𝗮𝗿𝘀𝗮𝗱𝗶𝗾: #endmeeting
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: I think status quo could be greatly helped, especially in terms of new contributors, I'm not sure what the right system is but I am not sure everyone pretending to not meat proxy is the right way. Could we give willcl-ark a long leash to try something on a trial period and adapt as we go? something to discuss i guess
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: Obviously we wouldnt want multiple instances rampaging around
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵_: I think maybe new contributors are the least likely to benefit from non-distilled review output. LLM reviews are fuzzy and will generally always return a bunch of "issues" with the code that can be "improved". It still takes a human to tell it when to stop, and newer contributors won't know which threads to pull and which are false positives/noise.
𝘆𝗮𝗻𝗰𝘆: less frequent contributors does not necessarily mean less skilled, but good point.
𝘆𝗮𝗻𝗰𝘆: I guess maybe the original suggestion of outside the frequent-contributor group is better than new
𝘆𝗮𝗻𝗰𝘆: anyway, I think something on request is interesting since there seems to be a lot of unknowns, so a trial like that would be nice
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: there's a whole spectrum of things we could do, we are not beholden to 2025 processes "just because".
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: andrewtoth_ Goose team at spiral does this
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: https://goose-docs.ai/blog/2026/07/30/issues-are-the-new-prs/
𝗺𝗮𝗳𝗹𝗰𝗸𝗼: willcl-ark: I am not sure about directly putting the LLM review in the main repo. My hope is still that the repo discussions are from humans for humans. I want to read comments written in the indidual voice and language of the human author. But seeing the share of monotone claude-speak in the repo today, maybe that ship has sailed :(
𝗺𝗮𝗳𝗹𝗰𝗸𝗼: My recommendation would be to add an anchor link to it (https://github.com/willcl-ark/nix/pull/1), so that it is easier to jump to it, for anyone who wants to, and also easy to ignore for anyone who does not want to.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: I would definitely say that the author isn't liable to respond to the review, like they are in general required to respond to humans
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: is the author required to respond to a human copy-pasting llm output though
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵_: I think adding this review to corecheck.dev or similar is better than having it in the main repo. That way it can still be pointed to when useful.
𝗶𝗻𝘀𝘁𝗮𝗴𝗶𝗯𝗯𝘀: eugenesiegel no, which is why I think status quo is already bad
𝗯𝗿𝘂𝗻𝗼𝗲𝗿𝗴: andrewtoth_ I feel few people check corecheck
𝗲𝘂𝗴𝗲𝗻𝗲𝘀𝗶𝗲𝗴𝗲𝗹: andrewtoth_: you "can't", but you can guess I suppose
𝗮𝗻𝗱𝗿𝗲𝘄𝘁𝗼𝘁𝗵_: if it's people I've met, then I assume they are the ones copy-pasting. But otherwise I assume it's a bot behind the avatar.
𝗹𝟬𝗿𝗶𝗻𝗰: I like the idea of extending corecheck in a non-invasive, opt-in way with careful AI review - it's a lot easier to instruct new contributors to just check that instead of reexplaining the same concepts.
𝗹𝟬𝗿𝗶𝗻𝗰: My concern is that those reviews will be very opinionated/centralized by whoever writes the prompts, so we should probably have our preferences documented in Core
𝗹𝟬𝗿𝗶𝗻𝗰: and the code review prompt be something simple like "review this PR based on locally available docs" or if we want to force deeper work: 1) create an issue from this PR 2) implement this issue 3) compare these two implementations and add comments based on their differences
𝗹𝟬𝗿𝗶𝗻𝗰: But it would help reviewers a lot if the basics were already covered by robots (the bot could even ACK when it thinks there are no blockers) - given that human review is even more of a bottleneck than ever...
𝗺𝗮𝘅𝗲𝗱𝘄: happy to add AI review page to Corecheck if people think it's useful.
𝘆𝗮𝗻𝗰𝘆: corecheck.dev is pretty nice for frequent contributors that know about the dashboard. New people are probably not going to look at it, even if the PR says look over there.
𝗹𝟬𝗿𝗶𝗻𝗰: drahtbot could automatically convert to draft for new contributors if the AI review finds any blockers - with a response on how to mitigate the problem
𝗹𝟬𝗿𝗶𝗻𝗰: if we end up using AI review, they should combine outputs from multiple models, not just the cheapest ones - which will likely cost thousands of dollars per month
𝗸𝗮𝗻𝘇𝘂𝗿𝗲: instead of having people donate AI output tokens, they should donate AI API keys to specific developers who can prompt better and burn those tokens for more useful outputs.

Read the full meeting

Releases

v32.0rc3 was tagged 2026-10-01 by fanquake. Signed git tag (fbdd0f96, commit 2633a1de). Message: "Bitcoin Core 32.0 release candidate 3". No GitHub Release page. The bump is #36400, on top of the backports in #36300.

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

Private Bitcoin Payments — Last Week in Bitcoin (Sep 21 - 27)

Tuma (I WILL NEVER DM YOU) — Mon, 28 Sep 2026 14:01:47 GMT

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.

In this week’s update we feature some new NUT specifications currently being discussed for improving the Cashu protocol.

We also cover Shielded Bitcoin, a new protocol by [[alloc]init] to private bitcoin transactions, the new plugin by Second for simplifying accepting Bitcoin through BTCPayServer, Ben Carman’s work to include Lightning in the x402 specifications, and the latest maintenance release for Core-Lightning.

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 Cashu ecosystem is working on implementing new features and proposing new NUT specifications.
- During the monthly community calls, on Thursday 24th, Cashu developers discussed the latest news from the ecosystem. In particular, they presented new additions to the NUT specifications.
- PR433 introduces compact state filter, a concept similar to compact block filters (BIP158) available on Bitcoin. This new feature aims to increase the privacy of the protocol by allowing a wallet to retrieve the information about the state of a token locally, without providing the mint with all the token identifiers. Instead, the mint would provide the wallet with filters containing the state of a token.
- PR450 adds an optional NUT that allows a mint to publish a bid and an ask price on its own liquidity. Since there are several payment methods available for minting and melting — LN, on-chain, Bark —, this NUT would allow the mint to set different prices on the liquidity available on different payment methods, thus attracting liquidity where needed the most.

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP138: Compact encryption scheme for non-seed wallet data

Authors: Pyth

Published On: Sep 21st, 2026

Layer: Applications

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

Other News from the Bitcoin World

Shielded Bitcoin: [[alloc]init] presented a new metaprotocol to make Bitcoin transactions more private, called Shielded Bitcoin. The proposal — presented in a dedicated paper by Clara Shikhelman, Misha Komarov, and Aleksei Moskvin — does not require neither changes to the Bitcoin consensus, nor operators or trusted third parties.
- A Shielded Bitcoin transaction is a blob of data included in an on-chain transaction through an OP_RETURN or other data-carrying fields. The transaction validation is demanded to an external node, called Indexer, which has also the task to update the state of an output.
- Shielded Bitcoin uses a specific type of output, called note, which plays a similar role as a Bitcoin UTXO. However, while UTXOs are deleted from the set once they are consumed, notes are spent by posting a proof and nullifier. To check whether a note has been spent or not, a user checks if its nullifier has already been used or not.
- For what concerns the peg, the protocol uses Bitcoin PIPEs v2. This is a witness encryption method that can be used to reproduce covenant semantics without changes to Bitcoin consensus. Basically, instead of locking a certain output behind a spending condition, it allows a user to specify those conditions on the key needed to move those funds, adding prerequisites on whether a valid signature can be produced or not.
Bark <> BTCPayServer: Second — the company behind the Ark implementation Bark — announced that their plugin for BTCPayServer was available for use in production.
- Historically, BTCPayServer has relied on Lightning to allow merchants to accept Bitcoin payments. That meant taking on all the difficulties of running a full Lightning node, such as channel management, liquidity, and maintenance.
- The new Bark plugin allows merchants to accept Bitcoin without all of that. Users will now be able to run their self-hosted BTCPayServer instance without running a Lightning node behind and to accept self-custodial, instant Bitcoin payment in a simpler way.
Lightning <> x402: LDK maintainer Ben Carman announced that Lightning had been officially included in the x402 specifications.
- x402 is an open standard for native internat payments built on top of HTTP. It is currency-agnostic, which mean that it can support any payment rail, such as Bitcoin, stablecoins, and fiat. It is supported by some of the biggest corporations in the world, such as Amazon, Amex, Google, Mastercard, but also by come big companies in the wider crypto industry, such as Ripple, Coinbase, Solana.
- Given the companies involved, it is not surprising that Bitcoin had not been added yet to the x402 standard. Ben Carman was able to close this gap, pushing for the inclusion of Lightining in the specifications.
CLN Release: The Core-lightning team announced the release of a new maintenance version of the Lightning node software, v26.06.8. This version includes several fixes for bugs and vulnerabilities that were responsibly disclosed in the last weeks. Contrary to the previous version, no embargo was put on this release, making the source code available from the beginning. However, the team noted that some tests were withheld from publication to prevent attackers from reverse-engineering the vulnerabilities.

Silent Payments finally made some noise - This Week in Bitcoin Core #59

kevkevin — Fri, 25 Sep 2026 14:03:44 GMT

Hello 👋 folks, I’m Kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week I reviewed several pull requests from the Bitcoin Core repo. The most-reviewed merge this week is silent payments, and the PR still doesn't open a wallet. BIP352 take 2 is on master as protocol code: public keys, private keys, and the BIP test vectors as unit tests. Receiver labels are optional in the BIP, so they stay out. The wallet scan is a different pull request.

BIP352 is the silent-payment construction. The sender tweaks the receiver’s spend key with a shared secret from the sender’s input keys and the receiver’s scan key, and pays to that one-time output. The receiver recomputes the same tweak from the input public keys. #35301 keeps that logic off the wallet and off transaction objects, so the tests do not need a wallet backend. It replaces #28122 and is built on libsecp256k1 #1765. The tracking issue is #28536. Receiving is still draft #32966.

The next merge by review activity is listrawtransactions. listtransactions only emits transactions with an economic category, so a consolidation or a self-transfer never appears. The new RPC lists every wallet transaction once, with the net balance change and the fee when this wallet funded it.

Thursday’s #bitcoin-core-dev meeting had three topics: dergoegge is leaving full-time fuzzing work, the QML GUI group is still in design and staging, and the v32.0rc2 binaries are up.

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.

Silent Payments: Implement bip352 (take 2) by Eunovo
Oghenovo Usiwoma (Eunovo) merged the second attempt at BIP352. The first attempt was #28122. This one is based on secp256k1 #1765 and tracked in #28536.
The PR is only the BIP. It takes public and private keys directly, instead of a wallet backend and transactions, and the BIP test vectors are unit tests. Labels, which let one scan key from multiple addresses, are deferred. Nothing here wires silent payments into CWallet. That receiving work is still #32966, and it is a draft.
wallet, rpc: Add listrawtransactions RPC by pablomartin4btc
listtransactions returns sends to an external address and receives from outside the wallet. A consolidation or a self-transfer has no external party, so it is invisible. listrawtransactions returns every transaction the wallet knows about, each one once. The entry carries the net wallet balance change (amount) and, when this wallet funded the transaction, the fee. count and skip match listtransactions. Closes #34632.
#35009, by alfonsoromanz, was closed so this could be its own RPC, which is what achow101 asked for. The PR itself lists the follow-ups: a filter (all / received / sent / self) once the per-tx meaning is agreed, and a cleanup of TransactionDescriptionString() fields such as replaced_by_txid and parent_descs that still refer to category.

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.

fees: return block_policy fee rate estimate when mempool_policy is not ready by ismaelsadeeq
The mempool fee estimator cannot always answer. Right after startup or a re-sync it has not tracked enough blocks. An empty or sparse mempool cannot fill the requested percentile. Recent blocks can cover too little of what was in the mempool. The mempool can still be loading. For a sparse mempool, Core used to return the fee floor (the higher of the minimum relay fee and the mempool minimum fee). That can sit far under the feerate those missing transactions would have implied.
This PR makes the mempool estimator return an error instead of flooring an unfilled percentile. The combined estimatesmartfee path starts from the block policy estimate and only lowers it when a mempool estimate exists. An error is returned only when block policy itself is unavailable. Calling estimatesmartfee with fee_rate_estimator=mempool_policy still returns the failure. The first commit renames the default mode from none to auto.
If the mempool fails to load (persistence off, or a missing or corrupt mempool.dat), init notifies the estimator and clears its mined-block window. Otherwise that window would still describe a mempool the node no longer has. Clearing it makes the estimator report insufficient data until the window refills, and the combined estimate uses block policy in the meantime.
The mempool estimator now returns an error instead of flooring an unfilled percentile, so an empty/sparse mempool is treated like any other not-ready state rather than potentially silently underestimating.

IRC meeting notes

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

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

𝗳𝗷𝗮𝗵𝗿: #topic Fuzzing WG Update (dergoegge, marcofleon)
𝗱𝗲𝗿𝗴𝗼𝗲𝗴𝗴𝗲: After this week I won't be contributing here full time anymore (maybe in my spare time, but let's see), as I've accepted a job elsewhere
𝗱𝗲𝗿𝗴𝗼𝗲𝗴𝗴𝗲: Most of my projects/work will be taken over by Brink's Marco and Eugene, so please direct any questions or review requests that you'd have for me towards them
𝗱𝗲𝗿𝗴𝗼𝗲𝗴𝗴𝗲: I'll open PRs to remove myself as a security contact by the end of this week
𝗱𝗲𝗿𝗴𝗼𝗲𝗴𝗴𝗲: It's been really great working with you all!
𝗳𝗷𝗮𝗵𝗿: :/ sad
𝘄𝗶𝗹𝗹𝗰𝗹-𝗮𝗿𝗸: :(
𝘁𝗶𝗴𝗲𝗿𝗠𝗮𝗳𝗶𝗮: dergoegge: very sad. only the best
𝘀𝘁𝗶𝗰𝗸𝗶𝗲𝘀-𝘃: :( thanks for all your contributions. this project is in a much safer place because of it. have fun on the next thing!
𝗱𝘇𝘅𝘇𝗴: Thanks for all your work on fuzzing!
𝗳𝗷𝗮𝗵𝗿: I hope to still see you around somehow if possible. All the best! Is there still some update on the WG? I guess not since marcofleon isn't here...
𝗱𝗲𝗿𝗴𝗼𝗲𝗴𝗴𝗲: No update otherwise
𝗷𝗮𝗻𝗯𝟴𝟰: Thanks for you work, sad to see you leave. Good luck on the new job
𝗳𝗷𝗮𝗵𝗿: I hope the next one is a better update ;)

𝗳𝗷𝗮𝗵𝗿: #topic QML GUI WG Update (johnny9dev)
𝗰𝗳𝗶𝗲𝗹𝗱𝘀: :(
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: Nothing too significant this week. We're working through design, issues, and staging
𝗰𝗳𝗶𝗲𝗹𝗱𝘀: dergoegge: Thank you for all of your hard work, dergoegge!
𝗷𝗼𝗵𝗻𝗻𝘆𝟵𝗱𝗲𝘃: That's all for qml
𝗳𝗷𝗮𝗵𝗿: brunoerg teased a yuge update last week but I guess he couldn't make it...
𝗳𝗷𝗮𝗵𝗿: maybe later, moving on

𝗳𝗷𝗮𝗵𝗿: #topic 32.0 release candidate testing (sedited)
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: yes, the 32.0rc2 binaries are now available for testing.
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: the umbrella issue over here: https://github.com/bitcoin/bitcoin/issues/36315 links to both the proposed release notes and the testing guide. If you find something, do use this for tracking.
𝗳𝗷𝗮𝗵𝗿: sedited: that's it on that topic right?
𝗹𝟬𝗿𝗶𝗻𝗰: thanks for your work dergoegge
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: we've picked up a few pull more requests in the milestone for backporting https://github.com/bitcoin/bitcoin/milestone/84
𝘀𝗶𝗽𝗮: dergoegge: not a surprise, but still sad to see you go
𝗳𝗷𝗮𝗵𝗿: l0rinc: you still want to give an update?
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: please do test, we've hadn't had a release note this long in a while!
𝘀𝗲𝗱𝗶𝘁𝗲𝗱: that's all.
𝗹𝟬𝗿𝗶𝗻𝗰: fjahr: no, thanks
𝗳𝗷𝗮𝗵𝗿: Anything else to discuss?
𝗳𝗷𝗮𝗵𝗿: #endmeetingRead here for the full meeting

Read the full meeting

Releases

v32.0rc2 was tagged 2026-09-18 by sedited

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

Quantum Lightning — Last Week in Bitcoin (Sep 14 - 20)

Tuma (I WILL NEVER DM YOU) — Mon, 21 Sep 2026 14:02:16 GMT

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.

In this week’s update we feature the latest releases for the Stratum V2 protocol. Maintainers focused mainly on hardening, refactoring and bug fixing, while also introducing support for BIP323.

We also cover several news from the developer ecosystem. Notably, we discuss a first working proof-of-concept for a post-quantum Lightning implementation, a new scaling protocol to bring self-custody to a huge number of users, and other interesting news.

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 Stratum V2 published new releases for the Stratum protocol, the applications, and the new UI.
- During the weekly call, on Tuesday 15th, Stratum V2 developers announced that the new versions for the Stratum V2 libraries were ready to be published. The releases were published on Thursday 17th.
- v.1.12.0 is the new release for the protocol libraries. Developers focused on hardening and refactoring several parts of the protocol, introducing several breaking changes. Moreover, this release introduces BIP323, which reserves 24 bits in the nVersion field as extra nonce space for miners.
- Releases for sv2-apps and sv2-ui were also published. sv2-apps v0.8.0 hardens the applications by fixing several issues found by Loupe — the AI-assisted vulnerability scanner by Spiral —, improves the translation proxy (tProxy) and the Job Declaration Client (JDC), and adds supports for BIP323. sv2-ui v0.7.0 mainly addresses vulnerabilities found by Loupe.

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP461: Deterministic ECDSA Signatures

Authors: Liam Gilligan

Published On: Sep 16th, 2026

Layer: Applications

BIP461 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

Quantum Lightning: Ahmet Kurt, a researcher from East Texas A&M University, posted to Delving Bitcoin to present a first proof-of-concept for a quantum-secure implementation of the Lightning Network, called PQLN.
- Kurt published a paper, which presents a hybrid post-quantum extension of Lightning that protects all the different layers composing it — gossip, onion routing, invoice, peer services — with the lattice-based standards ML-DSA and ML-KEM. The proposed changes don’t need any modification to the consensus layer of Bitcoin, since they are LN-specific.
- As the author specifies, the huge cost for PQLN is bandwidth. A PQLN node on regtest needs to download 10 times and needs to store around 9 times more data than a legacy node. On the other hand, computation seems not to be the bottleneck, since the most expensive operation — ML-DSA signing — only takes 0.33ms.
- A fork of rust-lightning that implements the new post-quantum approach is already available on GitHub.
Depot: John Law posted to Delving Bitcoin a proposal for a new scaling protocol whose goal is to provide self-custodial Bitcoin to a large number of users. This new protocol is called Depot.
- The proposal builds upon three principles: it has a small, on-chain footprint, it allows user to participate even if they don’t have enough bitcoin to put a transaction on-chain, and it avoids creating more off-chain transactions than can be put on-chain before theft occurs.
- An operator funds one Taproot output that can be used to create probabilistic off-chain Lightning channels for a high number of users. Each user buys channels though a LN payment, which can be used to make payments.
- The security of the protocol depends on expiry management, expected values, and penalties that make griefing economically irrational. To be viable, the proposal would require new opcodes, such as OP_CTV and OP_CSFS.
Swaptopia: Grubles, researcher at Second, launched Swaptopia, a new swap service to move funds between on-chain and Lightning. Swaptopia is built upon Bark — Second’s Ark implementation —, it’s self-custodial, and runs completely in the browser.
- To move funds from on-chain to Lightning, this service boards the Ark Server and send a Lightning payment for the specified amount. On the other hand, to move from Lightning to on-chain the service receives the payment and offboards the Ark Server, moving funds on-chain.
CLN Security Advisory: The Core-lightning team provided a security advisory, suggesting operators running their nodes with experimental features enabled to switch-off that feature immediately. The advisory comes after reports from users of a possible loss of funds, and an investigation is currently ongoing.

The GUI doesn't speak RPC - This Week in Bitcoin Core #58

kevkevin — Fri, 18 Sep 2026 15:20:19 GMT

Hello 👋 folks, I’m Kevkevin. I’m an open-source developer and reporter for Insider Edition.

Last week I reviewed several pull requests from the Bitcoin Core repo. This week there were multiple PR’s that dealt with a constraint that keeps showing up in wallet work: Bitcoin Core GUI does not speak RPC.

Descriptor import and addhdkey lived in the RPC layer, which is fine if you’re the bitcoin-cli, and a dead end if you’re the GUI trying to do multisig. This week both of those grew a real wallet interface.

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

New Bindings — Last Week in Bitcoin (Sep 07 - 13)

Tuma (I WILL NEVER DM YOU) — Mon, 14 Sep 2026 14:01:24 GMT

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.

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!

temudandelion - This Week in Bitcoin Core #57

kevkevin — Fri, 11 Sep 2026 14:02:12 GMT

Hello 👋 folks, I’m Kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week, I reviewed several pull requests from the Bitcoin Core repo.

In the Bitcoin Core 31.0 release notes, the private broadcast feature promised that your IP would never be known to the recipients and that unrelated transactions would not be linked. In the weekly IRC meeting, there was discussion on whether Bitcoin Core can still back that.

Fankquake mentioned that privacy leaks had been reported to the security team, and they wanted broader threat model discussion before releasing v32.0. There was also discussion on renaming the flag; here are some of the options. (-cloakedbroadcast, -oneshottorbroadcast, -notsoprivatebroadcast, -temudandelion)Branch-off for v32.0 was supposed to be yesterday. But there is still no 32.x branch and no v32 tag yet. Five items are still open on the 32.0 milestone.

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

Liquid Hacked — Last Week in Bitcoin (Aug 31 - Sep 06)

Tuma (I WILL NEVER DM YOU) — Mon, 07 Sep 2026 14:02:01 GMT

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.

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

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!

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

kevkevin — Fri, 04 Sep 2026 14:01:12 GMT

Hello 👋 folks, I’m Kevkevin. I’m an open-source developer and reporter for Insider Edition. Last week, I reviewed several pull requests from the Bitcoin Core repo.

In hodlinator’s headers-sync PR, if your system clock is so far behind the chain-start median time past that the unsigned commitment cap wraps, Core now aborts the node instead of eating low-work headers. Fresh datadirs hit this path. Existing chainstate already shuts down at load.

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

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

Tuma (I WILL NEVER DM YOU) — Wed, 02 Sep 2026 14:03:12 GMT

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.

Glass Coins — Last Week in Bitcoin (Aug 24 - 30)

Tuma (I WILL NEVER DM YOU) — Mon, 31 Aug 2026 14:03:22 GMT

Hi Insiders. This is Tuma, open-source reporter from the Insider Edition.

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!

bitcoin++'s Insider Edition: Last Week In Bitcoin

New Security Policy — Last Week in Bitcoin (Oct 26 - Nov 01)

Highlights from the Bitcoin developer ecosystem

A BIPs Update

Numbered BIPs

BIP333: BIP324 One-Byte Message Type ID Alias Assignment

Other News from the Bitcoin World

More from BTC++ Insider Edition

News Hour

Videos

Articles

🎃 FAIL does not fail the process - This Week in Bitcoin Core #64

Merged PR’s

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

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.

IRC meeting notes

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

Releases

Payjoin <> CISA — Last Week in Bitcoin (Oct 19 - 25)

Highlights from the Bitcoin developer ecosystem

A BIPs Update

Published BIPs

BIP139: Wallet Metadata Backup Format

Other News from the Bitcoin World

More from BTC++ Insider Edition

News Hour

Videos

Articles

We're reimplementing private broadcast - This Week in Bitcoin Core #63

Merged PR’s

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

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.

IRC meeting notes

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

Releases

More Offchain Protocols — Last Week in Bitcoin (Oct 12 - 18)

Highlights from the Bitcoin developer ecosystem

A BIPs Update

Other News from the Bitcoin World

More from BTC++ Insider Edition

News Hour

Videos

Articles

The prefill was already there - This Week in Bitcoin Core #62

Merged PR’s

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

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.

IRC meeting notes

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

Releases

Making Taproot Annexes Standard — Last Week in Bitcoin (Oct 05 - 11)

Highlights from the Bitcoin developer ecosystem

A BIPs Update

Other News from the Bitcoin World

More from BTC++ Insider Edition

News Hour

Articles

Bitcoin++ — Payments Edition Livestream

The comma is the limit - This Week in Bitcoin Core #61

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.

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.

IRC meeting notes

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

Releases

Payments Edition — Last Week in Bitcoin (Sep 28 - Oct 04)

Highlights from Bitcoin++ — Payments Edition

Day 1

Day 2

Day 3

A BIPs Update

Other News from the Bitcoin World

More from BTC++ Insider Edition

Articles

v32.0 is around the corner - This Week in Bitcoin Core #60

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.

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.

IRC meeting notes

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