bitcoin++'s Insider Edition

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.

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.

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.

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.

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.

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).

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.

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).

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.

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

Shielded Bitcoin & PIPEs: 12 Questions & Answers

~nifty~ — Wed, 30 Sep 2026 14:03:26 GMT

Since its publication last week, [[alloc] init]’s Shielded Bitcoin proposal, along with PIPEs v2 published earlier this year, has generated plenty of excitement, along with a fair share of skepticism. Not surprising. The proposals use relatively novel cryptography to pursue something ambitious: private Bitcoin transfers, programmable vaults, and more expressive spending conditions without a Bitcoin soft fork, separate blockchain, or trusted operator set.

The problem is that the public discourse has started to blur together very different kinds of criticism. Some objections misunderstand how the architecture works. Some are frustrated that the vault mechanism wasn’t detailed in the paper. Spoiler: it’s being published in its own paper for good reason – as a separate contribution to Bitcoin research. Others point to genuine trust assumptions, engineering tradeoffs, or cryptographic risks. And others are flustered that it’s just not ready for production yet.

We sat down with Clara Shikhelman, the protocol lead for Shielded Bitcoin at [[alloc] init], to answer the most important questions about Shielded Bitcoin and PIPEs — clarifying what the proposals claim, where the research stands today, and what still needs to be demonstrated.

A Shielded Bitcoin walks down a PIPE v2

#1: Isn’t this just Zcash bolted onto Bitcoin?

There’s some truth there — and an important difference. Shielded Bitcoin deliberately draws from the body of privacy research pioneered by systems like Zcash: encrypted notes, nullifiers, and zero-knowledge proofs. Unlike Zcash, Shielded Bitcoin proposes BTC-denominated shielded notes, with Bitcoin providing publication, ordering, and settlement, and the underlying BTC secured through PIPEs-based L1 vaults. The shielded transfer rules do not become part of Bitcoin consensus, but there is no separate blockchain, consensus mechanism, or token either.

There’s an interesting parallel between Zcash, Shielded Bitcoin, and the underlying cryptography for each. In 2013, Pinocchio demonstrated that zero-knowledge proofs could be made practical for the first time. Three years later, Zcash became one of their first major production applications, using zk-SNARKs for shielded transactions. But the research lineage behind Zcash had actually begun with an ambition to bring stronger privacy to Bitcoin. As Zcash co-founder Eli Ben-Sasson put it when responding to Shielded Bitcoin last week, “our original intent with Zerocash paper … was to bring privacy to Bitcoin.” But Bitcoin could not verify the required proofs (and Witness Encryption barely existed at the time), so that research ultimately found its expression in a new blockchain where the cryptography could be incorporated into the consensus rules.

Zcash took ZKPs from theory to deployment. Shielded Bitcoin could provide that path for Witness Encryption on Bitcoin. If Witness Encryption can be made secure and practical, we don’t need to build a new blockchain to bring this kind of cryptographic privacy to Bitcoin. Instead of adding new opcodes to Bitcoin to verify new conditions (along with the security and consensus risks it introduces), PIPEs can put those conditions behind a Bitcoin signature — potentially enabling privacy and other new capabilities while leaving Bitcoin itself unchanged.

So yes, Shielded Bitcoin owes an intellectual debt to Zcash and the privacy research that came before it. The interesting part is that Witness Encryption may give us a path to bring that original vision back to Bitcoin.

#2: What is Shielded Bitcoin if it’s not L1, an L2, or a sidechain?

This question comes down to being precise about semantics.

Let’s first clarify that Shielded Bitcoin is not part of Bitcoin consensus: Bitcoin nodes validate the underlying Bitcoin transactions, not Shielded Bitcoin’s private transfer rules. But Shielded Bitcoin also does not introduce another blockchain, consensus mechanism, sequencer, or validator set.

A more accurate description is a Bitcoin metaprotocol. Protocol data is published to and canonically ordered by Bitcoin, while a separate indexer/explorer parses that data to derive the protocol state deterministically. Shielded Bitcoin’s state can be reconstructed from Bitcoin L1 history rather than being reliant on client-side state storage (i.e., in Shielded Bitcoin if you lose your state, you still keep your Bitcoin), while the underlying native BTC remains on Bitcoin L1. The protocol’s rules are not part of Bitcoin consensus itself, but describing the architecture as a conventional sidechain is misleading for essentially the opposite reason: there is no second chain or separate consensus system.

#3: Even if the transfers are private, isn’t privacy compromised by transaction metadata and fees?

Shielded transfers provide strong cryptographic privacy, but — as with any privacy protocol — the system’s boundaries require separate consideration. Peg-ins, peg-outs, carrier transactions, timing, network activity, and fee payments can expose metadata if handled naively.

These are known design problems with practical mitigation paths. Shielded Bitcoin is being designed to minimize these linkages through mechanisms including privacy-preserving peg-outs, atomic swaps, fresh addresses, and improved fee payment flows.

The important distinction is between privacy within the shielded system, which is enforced cryptographically, and privacy at its boundaries, which depends on how users enter, exit, and interact with Bitcoin. Our focus now is hardening those boundary mechanisms so the privacy properties of shielded transfers extend as far as practical into the surrounding Bitcoin workflow.

#4: Isn’t it a trusted bridge? Who controls it?

No. The proposed architecture is fully non-custodial: there is no company, committee, operator, federation, or other party that takes custody of users’ Bitcoin or has ongoing control over whether it can be spent. There is no intermediary sitting between Alice and Bob deciding whether a transaction or withdrawal is permitted. At its simplest: it’s Alice, Bob, and cryptography in between.

This objection tends to conflate two very different concepts: trusted setup and trusted operation. PIPEs does have trusted setup assumptions. Constructing a PIPE ciphertext involves a one-time 1-of-n multiparty computation (MPC) ceremony, and the ZK proof system may introduce its own setup assumptions. But those participants do not become custodians or operators. They aren’t required to remain online, process transactions, approve withdrawals, or exercise ongoing control over users’ funds.

Instead, PIPEs is designed so that satisfying a specified cryptographic condition enables recovery of the signing key needed to spend the Bitcoin. Cryptography replaces the role that a trusted operator, committee, or multi-sig would otherwise play. Once the setup is complete, no setup participant is supposed to control the funds or participate in the user flow.

The current Shielded Bitcoin paper does not include vault architecture and details for entry and exit (i.e., “peg” in and out). This separation is deliberate because the vault architecture is a substantial protocol design contribution in its own right, with applications beyond Shielded Bitcoin. We believe it warrants dedicated treatment as a separate contribution to Bitcoin research rather than being compressed into the privacy protocol paper. A forthcoming vault design paper is largely complete and will specify and analyze that architecture in detail. We look forward to putting it forward for community review and feedback.

#5: Don’t users still have to trust an indexer or maintain client-side state?

No. Indexers are a synchronization convenience, not a trusted part of the protocol. Shielded Bitcoin transfer data is published to Bitcoin, allowing the protocol state — including the note tree, spent-nullifier set, and relevant roots — to be reconstructed by replaying that data in Bitcoin order.

An indexer therefore acts more like a block explorer than an operator. It never has access to a user’s private keys, cannot spend their notes, and has no authority over protocol state. A malicious indexer can omit data, return stale information, or refuse service, but its responses can be independently verified against Bitcoin history. Efficient verified light-client synchronization remains an area of ongoing engineering.

Users also do not need to preserve client-side state to recover their funds. The protocol state is reconstructible from Bitcoin L1 history; losing a wallet’s synchronized state does not mean losing the underlying protocol state.

This creates an important distinction from systems where users must preserve private state that cannot be recovered from Bitcoin. The relevant question isn’t whether an indexer or local state exists at all — it’s whether either must be trusted or preserved for correctness and recovery. In Shielded Bitcoin, neither needs to be.

#6: Without its own consensus, how can Shielded Bitcoin prevent double-spends or handle reorgs?

Shielded Bitcoin does not have separate consensus, but it does have agreed-upon protocol rules defining what constitutes a valid Shielded Bitcoin transaction. Bitcoin provides the canonical publication and ordering of protocol data; Shielded Bitcoin deterministically applies its own validity rules to that ordered history.

Double-spends are prevented using nullifiers. When a note is spent, its corresponding nullifier is published, and the transfer proof demonstrates that the spend is valid. If the same nullifier appears again, the second spend is invalid under the Shielded Bitcoin protocol rules. Because everyone applies the same rules to the same Bitcoin-ordered data, they can independently reconstruct the same valid shielded state.

These are Shielded Bitcoin validity rules, not Bitcoin consensus rules. Bitcoin does not determine whether a shielded transfer is valid; it determines the canonical history over which Shielded Bitcoin’s rules are applied.

Bitcoin reorgs therefore naturally propagate into Shielded Bitcoin. If Bitcoin’s canonical history changes, the corresponding shielded state is rolled back and replayed against the new history. A proof referencing a root removed by the reorg may need to be reconstructed and republished. As with Bitcoin transactions generally, users can wait for additional Bitcoin confirmations when greater settlement confidence is required.

#7: Isn’t Witness Encryption novel and therefore risky?

Witness Encryption has been studied in cryptography since 2013, but unlike ZKPs, it has not yet crossed the gap from theoretical research to practical, production-grade cryptography. PIPEs should therefore not be treated as though it were a mature primitive with decades of battle testing behind it. The more useful question is whether a Witness Encryption construction can eventually be made secure and practical enough for this particular application. If proven so, it may become known as one of the most significant breakthroughs in applied cryptography since zero-knowledge proofs first became practical with Pinocchio in 2013 and later became widespread in blockchain tech in the 2020s.

Our research is making steady progress toward a Witness Encryption construction that is both secure and practical. It’s not there yet, and we’re not claiming otherwise. We have been deliberately attacking our own cryptographic constructions through cryptanalysis, open challenges, security auditing with external researchers, and open collaboration with outside researchers. That process has already yielded successful attacks that we’ve since resolved. So the conclusion at this stage isn’t that witness encryption has been proven secure. It’s that its security remains important to harden, and we are focused on doing that systematically. Keep an eye on our X for updates – and especially to get a chance at Bitcoin bounties we will offer as part of on-chain challenges; crack the scheme, and it’s yours!

#8: Isn’t the AADP Witness Encryption scheme broken?

The original construction was successfully attacked, and we have since fixed the scheme to address every identified attack. The AADP Witness Encryption construction published in February 2026 (link) was successfully attacked both through our own cryptanalysis and by researchers participating in [[alloc] init]’s Open Challenges (link). These attacks demonstrated a method to make a parametric rank drop within AADP matrices larger than we expected earlier, which reduced the complexity of brute-forcing a correct key through an incorrect witness (https://www.allocinit.xyz/posts/commutator-attack). We have since revised the construction to address the identified attacks and plan to formalize those changes in upcoming publications.

The distinction between “broken and subsequently fixed” and “still broken” matters. Finding and fixing attacks is a normal and valuable part of cryptographic research (e.g., MuSig2, Signal’s PQXDH), particularly at this stage of a new construction. But it would also be premature to treat an unpublished revision as though it had already received the scrutiny of the original proposal. The successful attacks are therefore neither evidence that the research has failed nor something to gloss over: they identified concrete weaknesses (the complexity of a parametric rank drop was reduced for sparse circuits), those specific attack vectors have been addressed, and the process of breaking, improving, and scrutinizing the construction continues.

#9: Don’t PIPEs require 338 TB? How could this possibly be practical?

Subsequent research has reduced the ciphertext size from approximately 338 TB to roughly 10 TB under current parameters — a more than 30x reduction since the original construction. The 338 TB figure reflects the AADP construction published in February 2026 (here), not the current state of the research. The ciphertext also does not need to be stored by each user. Because it can be public, storage can be outsourced or distributed across inexpensive, high-latency storage infrastructure without introducing an additional trust assumption.

While a substantial improvement, 10 TB is obviously still large. We do not present it as a production benchmark or promise, and reducing both ciphertext size and computational requirements even further remains an active area of research efforts. The claim that PIPEs “still requires 338 TB” is outdated. The broader question — whether PIPEs can ultimately become practical enough to deploy — remains open.

“Practical” also depends on the use case. PIPEs are not intended to be decrypted for every transaction. Moving and managing Bitcoin inside a shielded system does not require decrypting a PIPE at all; decryption is primarily needed to exercise the unilateral L1 vault exit mechanism. Users requiring frequent entry or exit could also use cheaper mechanisms, such as atomic swaps. The relevant question, then, is not whether PIPE decryption is cheap enough for every Bitcoin transaction, but whether its cost and latency are practical for the specific operations that actually require it.

#10: Can’t a circuit bug secretly inflate the supply?

First, Shielded Bitcoin cannot alter Bitcoin’s total supply.

The relevant risk is whether an implementation bug could create unbacked shielded claims against the BTC held in the system’s Bitcoin vaults.

That risk should be taken seriously. A sufficiently severe bug in the ZK circuit or protocol implementation could cause an invalid state transition to be accepted. Mitigating this requires formal verification where possible, audit-friendly tooling, independent audits, adversarial testing, and extensive cryptographic review.

The protocol constantly enforces two critical invariants to ensure supply integrity:

Transfers within the shielded system cannot create value (and the supply is being checked using ZK proofs within the circuit during each encrypted note formation).
Shielded issuance cannot exceed the amount of BTC committed to the system. Because PIPEs require cryptographic proof during peg-out, Witness Encryption will not decrypt a key to allow a user to retrieve BTC on the L1 if the notes do not pass validity checks.

These invariants are designed to prevent inflation at both the shielded transfer and L1 settlement boundaries, significantly reducing the underlying risk. The most critical remaining risk lies in implementation: bugs that could undermine these guarantees. Preventing them requires rigorous testing, independent audits, formal verification where possible, and adversarial review. Zcash’s historical inflation vulnerability is a useful reminder of why these invariants deserve particularly aggressive scrutiny.

#11: Can Shielded Bitcoin and PIPEs become quantum-safe?

Yes, the architecture is designed to be cryptographically adaptable, although post-quantum security ultimately also depends on Bitcoin itself becoming quantum-safe.

For signatures, the key encrypted within PIPEs could move from Schnorr to a post-quantum signature scheme such as SHRINCS. For ZK proofs, the underlying proof system could similarly be replaced with one based on post-quantum-friendly assumptions, including hash-based constructions using functions such as Poseidon (created by our colleague Markus Schofnegger and others), while much of the circuit logic remains unchanged.

We’re also designing around “harvest now, decrypt later” risks, where ciphertext collected today could potentially be attacked by future quantum computers. There are meaningful efficiency and security tradeoffs to work through, but PIPEs and Shielded Bitcoin are not fundamentally locked into today’s cryptographic primitives. The primary external dependency is Bitcoin L1’s own path toward post-quantum signatures.

#12: Does Bitcoin need a soft fork for any of this?

No. Bitcoin continues to process ordinary Bitcoin transactions under its existing consensus rules, while Shielded Bitcoin applies its own metaprotocol rules to data published and ordered by Bitcoin. No new opcodes, consensus changes, or soft forks are required.

But “no change to Bitcoin” shouldn’t be confused with “nothing else needs to be built.” There is a lot that needs to be formalized at the security level and built at the engineering level.

That is probably the most useful way to understand Shielded Bitcoin and PIPEs today. They are research proposals rather than finished products, and some of the hardest questions — particularly around Witness Encryption security, performance, and the vault boundary — remain open. At the same time, several common criticisms assume architectural properties the proposals don’t actually have, such as a separate blockchain, an independent consensus mechanism, or a federation that controls the underlying Bitcoin.

So the interesting debate isn’t whether the cryptography has been solved or whether Shielded Bitcoin is production-ready.

The more consequential question is: what becomes possible if the underlying cryptography can be made secure and practical? If PIPEs and Witness Encryption work, the implications extend far beyond Shielded Bitcoin. They could open an entirely new design space for Bitcoin: privacy, covenants, programmable vaults, non-interactive ZK verification, and new metaprotocols — without requiring Bitcoin itself to change.

That’s why we think our work is worth attacking, breaking, improving, and scrutinizing. There are hard problems left to solve, and the work should be judged by whether it survives that process. So attack it. Find the weaknesses. Suggest improvements. Build on it.

We believe that PIPEs and Shielded Bitcoin are not only possible, but just the beginning of what we can build on Bitcoin. We still have a long way to go, and we plan to move forward carefully and steadily, one step at a time.

Thanks to Clara Shikhelman and the rest of the [[alloc] init] team for making themselves available for this FAQ. Clara has served as the Head of Research at Chaincode Labs since 2022, and now leads protocol research at [[alloc] init] on Shielded Bitcoin, a proposal for private Bitcoin transactions.

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

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.

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

Nayoma | Node Fingerprinting - BTC++ Inisder Interviews

Matthew — Tue, 15 Sep 2026 18:00:52 GMT

Naiyoma tells us how fingerprinting attacks can link a Bitcoin node’s clearnet and Tor identities, weakening privacy.

Read the thread by @danielabrozzoni on her research with Naiyoma here.

Naiyoma - BTC++ Insider Interviews

Matthew — Mon, 14 Sep 2026 16:22:14 GMT

Naiyoma tells us about Private Broadcast, which she reviewed in Bitcoin Core. It sends transactions over short-lived Tor or I2P connections to hide the origin IP.

She talks about the Private Transactions June bugfix, and encourages you to run your own Tor node.

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!

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

Sat, 12 Sep 2026 13:55:39 GMT

Steven Roose, the CEO of Second and an ex-Liquid team engineer at Blockstream, deep dives on what, exactly, happened that lead to the Liquid Network hack of almost 4,000 on Sept 6, 2026.

I worked for Blockstream as part of the Liquid team for about five years. I am quite certain that I speak for all my former colleagues that an inflation bug as we witnessed over the last few days was our greatest fear whenever we had to touch the complex section of code that implements Liquid’s Confidential Transactions.

This is a walk through what actually happened, at the level of the code. Which bugs existed, how they were exploited, and how an attacker managed to run away with 4000 Bitcoin.

What Liquid is, and how the peg works

Liquid is a federated sidechain to bitcoin. Instead of proof-of-work, eleven signatures are required to produce a valid block. These signatures are placed by the Liquid functionaries: around fifteen independent businesses running a specialized server, or HSM. The functionaries take turns to propose a block roughly every minute. As long as five functionaries remain honest, no invalid blocks can be produced.

The principal asset that circulates on Liquid is L-BTC, and it is meant to be backed one-to-one by bitcoin held in reserve. The reserve is held in a wallet managed by the same federation of 15 functionaries. Converting Bitcoin to L-BTC is a peg-in: you send Bitcoin to a federation-controlled address on the bitcoin mainchain, and, after enough confirmations, the same amount of L-BTC is credited to you in Liquid. Getting out is a peg-out: you destroy L-BTC on Liquid, and the federation releases the corresponding Bitcoin to you from reserve on the mainchain. Similarly, as long as five functionaries are honest, no one can take more money out of the system than they deserve. Or that was the idea.

Confidential transactions, confidential assets, and range proofs

On bitcoin, every output amount is public. On Liquid, amounts can be hidden. This feature is called Confidential Transactions. In a confidential transaction, the output amount field doesn’t hold a plain number. Instead, it carries a Pedersen commitment, or a curve point that binds the amount behind a blinding factor. The Pedersen commitment hides the amount while still supporting arithmetic. A verifier who cannot see any individual amount can still add up the input commitments, add up the output commitments, and check that the two sides balance. That is the balance proof, and it ensures transactions always have balanced inputs and outputs. In other words, the balance proof confirms that no new Bitcoin were created in the confidential transaction.

Confidential Assets extends the same idea to which asset an output holds, not just the amount. L-BTC, Tether USDt, and every other Liquid asset look alike in the blockchain; a per-output surjection proof ties each output’s asset back to the inputs.

Balance alone is not enough, and this is the crux of the whole incident. Pedersen commitments live in a finite group, so arithmetic wraps around in modulo. A commitment can encode a value so large it behaves like a negative number. If I am allowed to do that, I can build a transaction that balances on paper while minting money:

Imagine a transaction with an input of 1 L-BTC and two outputs: one of 100 L-BTC and one of “minus 99” L-BTC. The sums on both sides match up: 1 == 100-99. You can discard the -99 L-BTC output but keep the 100 L-BTC one.

The thing that forbids this is the range proof. Every confidential output must carry a zero-knowledge proof that proves the hidden amounts lie in a sane, positive range and not in the wrap-around zone. Range proofs are what make hidden inflation impossible.

The cache

Range proofs are big — a few kilobytes each — and expensive to verify. Liquid nodes see the same proof more than once: once when a transaction arrives in the mempool, again when it appears in a block. Re-running the elliptic-curve verification every time is wasteful, so Elements remembers successful verifications in a cache. The idea is simple and, in bitcoin, entirely standard: verify a proof once, remember that this exact proof passed, and skip the math if you see it again.

A cache needs a key. For a signature or a proof, the key is a hash of everything the verification depended on. Get everything into the key and the cache is safe: two verifications collide only when they truly are the same check. Leave something out and you have a problem, because now two different checks can share a key and the cache will happily answer “already valid” for a check it never ran.

That single sentence is the entire vulnerability that got Liquid hacked. The details is which fields went missing, and when.

The 2018 cache key change

The original cache implementation was using an existing function that Bitcoin Core uses to cache transaction signatures. Due to an upstream change to that function, in commit 9572165, a custom cache key function is introduced for range proofs specifically. Here’s the relevant changes:

+    void ComputeEntry(uint256& entry, const std::vector& proof, const std::vector& commitment)

+    {

+        CSHA256().Write(nonce.begin(), nonce.size()).Write(proof.data(), proof.size()).Write(commitment.data(), commitment.size()).Finalize(entry.begin());

+    }

-    rangeProofCache.ComputeEntry(entry, uint256(), vchRangeProof, pubkey, vchAssetCommitment, scriptPubKey);

+    rangeProofCache.ComputeEntry(entry, vchRangeProof, vchValueCommitment);

The new cache key is SHA256(nonce || rangeproof || value-commitment). The asset commitment and the scriptPubKey, which were previously there, are gone. The verification function still received them and still verified against them, but the cache no longer remembered that it had. Two range proof checks with the same proof and the same value commitment, but a different asset or a different output script, now would hash to the same cache entry.

This design violates the requirement that all relevant fields for validation must be part of the cache key, so it’s definitely a bug. Let’s look at how it could be exploited.

If the value commitment was a Pedersen commitment to the value alone, it would require breaking the elliptic curve logarithm problem to create an identical commitment to a different value. That means that it is as hard as forging a bitcoin signature. However, because of how Confidential Transactions and Confidential Assets work, the value commitment that is used here, is actually made up of two parts: it contains a commitment to the value, but it’s also mixing in a asset-specific factor so that you can’t blend different assets.

The commitment contains an additional generator H that is calculated from the asset. Now, if we could invent a different asset with generator -H, we can create an identical value commitment for the same amount, but negative.

Choosing our own asset generator would also require breaking our crypto, but we don’t really have to. The validity of the asset generators is checked in what is called the asset “surjection proof”. But, this check only happens after the range proofs are checked. This means that I can just claim to have an output for asset generator -H and a value of 1 BTC. The rangeproof will pass and be stored in the cache. Afterwards, the surjection proof will fail and the transaction will be invalid.

But any node that actually validated this transaction, will have made an entry in its rangeproof cache and will now accept a rangeproof for -1 BTC under asset generator H which allows the same transaction to add an extra output for 1 BTC without having sufficient input value.

What this means in practice is that an attacker could cause inflation if he could make enough functionary nodes first validate (and reject!) an invalid transaction and then propose a block that has an inflationary transaction in it.

The Liquid network has some protections against this sort of behavior: users cannot send transactions directly to the functionaries. All transactions pass through “bridge nodes” that then relay them to the functionaries. While this protects the functionaries somewhat against outside attackers, it still means that anyone with privileged access to the inner network could have exploited this bug and confirmed an inflationary transaction.

Also, if for example a malicious functionary would perform this attack, the entire rest of the network would reject this block because they hadn’t seen the invalid tx preceding it. So while an inflationary exploit was possible, it was pretty hard to execute, would be noticed way faster and could only be performed by Liquid’s inner circle.

Why variable sized fields should always have a prefix

On 1 September 2026, five days before the attack, commit c26d719 fixes the 2018 bug by putting the missing fields like the asset commitment back into the cache key:

-void SignatureCache::ComputeEntryRangeProof(uint256& entry, const std::vector& proof, const std::vector& commitment) const {

+void SignatureCache::ComputeEntryRangeProof(uint256& entry, const std::vector& proof, const std::vector& commitment, const std::vector& asset_commitment, const CScript& scriptPubKey) const {

     CSHA256 hasher = m_salted_hasher_range_proof;

-    hasher.Write(proof.data(), proof.size()).Write(commitment.data(), commitment.size()).Finalize(entry.begin());

+    hasher.Write(proof.data(), proof.size()).Write(commitment.data(), commitment.size()).Write(asset_commitment.data(), asset_commitment.size()).Write(scriptPubKey.data(), scriptPubKey.size()).Finalize(entry.begin());

 }

Read that Write chain carefully. The key is now:

SHA256( nonce || proof || commitment || asset_commitment || scriptPubKey )

All four fields are present, which looks like exactly what you want. I wrote above that in the old key, only the range proof field was of variable length, and that’s why a collision could only happen for exactly the same range proof and value commitment. In this new cache key, two fields are of variable length and they are hashed without having a length prefix.

When you glue variable-length fields together without length prefixes, the boundaries between them stop being meaningful. Only the total byte string matters. If I can make the proof longer by the same number of bytes that I make the script shorter, and arrange the bytes in between them to line up, I can produce an identical concatenation for a completely different (proof, commitment, asset, script) tuple.

This implementation lets you create two identical cache keys for a different amount, asset, and script. If you can get a Liquid node to first parse a valid transaction and then an invalid one with a junk proof and a forged amount, but that is carefully crafted so that the cache key for this transaction matches exactly with the cache key of the first one, it won’t even validate the range proof because you convinced it that it has already done that before.

This is a commonly known pitfall in cryptography. Hashing structured data by raw concatenation is unsafe precisely because distinct structures can share a byte encoding. The 2016 signature cache in bitcoin gets away with concatenation because its fields are all fixed length. The moment two variable-length fields sit next to each other, concatenation is a trap.

I remember from my time at Blockstream that whenever we would introduce any new consensus-critical serialization, we would ask Russell O’Connor to review it. Russell has the reputation as the expert in spotting this kind of byte-shifting vulnerabilities.

Here is the field layout, from a diagram mononautical, an engineer at Mempool.space, made while going through the same rabbit hole. The cache key is proof | amount | asset | script. Feed it a genuine “primer” and a crafted “exploit” and the two produce the same 4,301 bytes with the field boundaries in different places:

Cache key format: the primer and the exploit serialise to the same 4301 bytes with different field boundaries

How to print 4000 L-BTC

The exploit ran in two steps, exactly as the layout predicts. I pulled the raw transactions from the explorer and reconstructed the cache keys byte for byte.

Step one, the primer. In Liquid block 4,050,335 the attacker published two nearly identical transactions: 27117… and 71c93d. Note that just one transaction would have sufficed. The second is presumably insurance.

Each has an output that is an OP_RETURN carrying a genuine, valid range proof, 4,166 bytes, verifiable in its own right. The clever part is the script on that output. It is a 69-byte OP_RETURN whose pushed data is not random: it embeds, byte for byte, the value commitment, asset generator and script head that the second transaction will need. When a node verifies this proof, it computes the cache key over proof || commitment || asset || script and stores a success. The primer’s only job is to plant that entry.

Step two, the exploit. One block later, in 4,050,336, transaction f24a4b… creates an output whose “range proof” is 4,234 bytes that would never pass as a valid range proof. But those 4,234 bytes are not random either: they are the primer’s 4,166-byte proof, followed by the primer’s 33-byte commitment, followed by the 33-byte asset generator, followed by the two script-header bytes 6a 43. In other words, the exploit’s proof field has swallowed the primer’s proof, commitment, asset and script-head. The exploit’s own commitment, asset and a one-byte 6a (OP_RETURN) script then follow in their proper places, as they were encoded in the primer’s OP_RETURN data.

Line up the two cache-key preimages and they are the same string:

primer:   <4166B proof> | <33B comm> | <33B asset> | < 2B head> | <33B comm> | <33B asset> | <1B script>

                                                     └───────────────── 69B script ────────────────────┘

exploit:  <4166B proof> | <33B comm> | <33B asset> | < 2B head> | <33B comm> | <33B asset> | <1B script>

          └───────────────── 4234B “proof” ───────────────────┘

The exploit’s forged output collides with the primer’s cache entry, so the range proof checker short-circuits to “valid” and never looks at the invalid proof. That output hides a massive overflowing amount (the “negative” output from the balance-attack sketch earlier) and a sibling output credits the attacker with a large positive amount. The balance proof, which is real and which the attacker cannot fake, sums to zero. The range proof, which should have stopped it, was answered from cache.

The chain split

Interestingly, the attack did not fool most of the Liquid network. It only fooled nodes whose cache had been poisoned, and because the commit that introduced the buggy fix had not been included in an official Elements release yet, most of the network was not running this version of the Liquid node software. It looks like the Liquid federation decided to first deploy this bugfix release to the internal Liquid infrastructure. This is a common thing to do when deploying security fixes.

But it meant that most of the network actually rejected the attacker’s transaction. They didn’t have the cache key change, so no cache hit and they actually validated the range proof and rejected the transaction, as well as the block that the transaction was relayed in.

These nodes stalled at height 4,050,335: the last block before the exploit. The nodes running the vulnerable build, including the federation’s bridge nodes, accepted 4,050,336 and kept going.

You can still watch this split today. Blockstream’s explorer, blockstream.info, sits above height 4,051,000. mempool.space’s Liquid node, liquid.network, is frozen at exactly 4,050,335.

OrangeSurf published the reproduction recipe: run a build that includes the vulnerable commit, invalidateblock 4050335 to push the primer back into the mempool so the poisoned key gets re-inserted, then reconsiderblock and your node reorgs onto the federation’s inflated chain.

Out the front door: PAK and SideSwap

Inflating L-BTC is only half a heist. The attacker still had to convert unbacked L-BTC into real BTC, and Liquid does not let just anyone pull from the reserve. Peg-outs are gated by PAK, the Pegout Authorization Key system. Each peg-out output must carry a whitelist proof tying the destination to a registered key belonging to a trusted federation member. A peg-out to an unauthorized key is simply invalid as per Liquid’s consensus rules.

So the attacker needed a PAK holder to peg the coins out for them. Enter SideSwap, a Liquid member that runs a peg-out pass-through service: you send it L-BTC, it peg-outs under its own PAK key, and it forwards the resulting BTC to whatever mainchain address you give it. This is a useful product. It is also a good way to render the entire PAK system pointless.

In Liquid block 4,050,349, thirteen blocks after the exploit, the coins were pegged out. On the bitcoin side the federation released the reserve as designed: roughly 3,996 BTC landed at SideSwap’s whitelisted address bc1qgslsydz56d0ed6827hdemfmk5w2f6ldyc6wt7p, which forwarded it on to the attacker’s address bc1ql4mfu6aundtkksxklfajs2h3t9nzcd6gyqjlte.

Because the balance and PAK checks all passed, SideSwap’s node and every functionary treated it as an ordinary authorized withdrawal. Liquid’s own incident report confirms the shape: the validation failure was at the transaction level, before the peg-out, so nothing downstream had reason to object.

The part that should give every system designer pause: neither the peg-out mechanism nor SideSwap had either a built-in time delay or an upper limit on amounts. A single transaction that moved on the order of 4,000 BTC, roughly 400M USD at the time, went straight through: no waiting, no manual review, no velocity check. Before the incident the reserve held about 4,205 BTC. Nothing was in place to prevent 95% of that from leaving the system in about half an hour.

The white hat and the negotiation

Then the story takes a very unexpected turn. Bitcoin heists like this usually are followed by total silence in which the funds stay put, or by transactions showing the attacker is trying to obfuscate his trails and white-wash the coins.

Instead, a few hours after the drain, with a transaction paying 1,000 sats to the federation wallet, the attacker left a note in an OP_RETURN:

Blockstream replied from a known address: “Please contact security@blockstream.com”, then an encrypted message signed with their security key. The attacker agrees to send the funds back to the federation address but demands the bug be fixed first:

Blockstream clear-signed ”Yes, thank you,” and later ”Bridge nodes are patched, safe to return the funds.”

On 7 September at 16:09 UTC, the attacker returned exactly 3,400 BTC to the federation’s wallet and kept about 598.5 Bitcoin (roughly 15%) in his own wallet.

That 15% was not an accident, and the tone did not stay collegial. In a later message the attacker dropped his white-hat pose entirely:

Whatever you call someone who drains a chain, pegs it out through an unwitting third party, and then negotiates a bounty under threat, “white hat” is not a term I would use. As of writing, Liquid is still paused, the 3,400 BTC is back, and roughly 598 BTC is outstanding while the two sides argue over the difference.

The whole exchange is visible on the bitcoin mainchain, signed and verifiable; Sjors published a script and transcript, that checks the PGP signatures against Blockstream’s published key, and there is a readable viewer where you can follow the entire conversation live.

The real fix, and what it teaches

The actual repair got shipped, as part of Elements release v23.3.4. It stops hashing the cache-key fields by raw concatenation and serializes them through CHashWriter instead, which length-prefixes every field. Once each variable-length field is preceded by its length, the byte-shift trick is dead: a longer proof and a shorter script no longer produce the same encoding, because the lengths themselves are part of the hash. The release also adds a -norangeproofcache switch to turn the cache off entirely.

There are a few lessons here, and none of them are exotic.

A cache key is a security boundary. The instant a verification result is memoized, the key that identifies it inherits the full weight of the check it replaces. Leave a field out and you have silently widened what counts as “the same”.

Simple concatenation is not safe serialization. Gluing variable-length fields together without lengths or safe delimiters is a canonicalization bug waiting for someone with creativity to find a way to abuse it.

Fixes deserve the same fear as features, especially security fixes under time pressure. The recent change was trying to make the key correct and ended up breaking it instead. The dangerous edit was the one that looked like a patch.

And, finally, defense in depth is not optional at the money layer. Bugs happen to all of us, but the loss was 4,000 BTC because a single peg-out with no limit could carry the entire reserve out in half an hour. The consensus bug is fixed. The question of why the pegouts have no delay and no ceiling is the one Blockstream and SideSwap still have to answer.

bitcoin++ Insiders Edition will be in Berlin, this coming October 1 — 3 at the upcoming payments edition bitcoin++ conference. Join us for three days of hacking, talks, and hands-on workshops. Use code INSIDER for 20% off a ticket.

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.

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

bitcoin++'s Insider Edition

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.