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

Merged PR’s

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

• wallet: Add importdescriptors interface by polespinasa

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

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

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

• wallet: don't double discard output groups with avoidpartialspends by fjahr

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

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

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

IRC meeting notes

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

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

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

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

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

Read here for the full meeting

Releases

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

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

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

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

In this week’s update we feature the latest release, v3.1.0, of the bindings library for BDK, exposing the latest development to several programming languages.

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

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

Highlights from the Bitcoin developer ecosystem

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

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

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

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

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

A BIPs Update

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

Published BIPs

A list of recently published BIPs

BIP332: Stale Tip Relay

Authors: Anthony Towns, w0xlt, Ram

Published On: Sep 9th, 2026

Layer: Peer Services

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

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP394: rawtr() Output Script Descriptors

Authors: jeanpablojp

Assigned On: Sep 9th, 2026

Layer: Applications

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

Other News from the Bitcoin World

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

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

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

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

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

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

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

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

More from BTC++ Insider Edition

Articles

• Egge Wants You to Pay with Bitcoin

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

• temudandelion - This Week in Bitcoin Core #57

Videos

• Connor Aherne - BTC++ Insider Interviews

• Antoine Poinsot - BTC++ Insider Interviews

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

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:

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<unsigned char>& proof, const std::vector<unsigned char>& 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<unsigned char>& proof, const std::vector<unsigned char>& commitment) const {

+void SignatureCache::ComputeEntryRangeProof(uint256& entry, const std::vector<unsigned char>& proof, const std::vector<unsigned char>& commitment, const std::vector<unsigned char>& 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:

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:

> we are whitehats. contact us on chain

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:

> Please fix the bug first. The chain is under risk at latest commit right now. Make sure every node is patched. Then we will transfer the money back safely after confirming the fix.

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:

Your dereliction of duty is obvious that you allocated only $1.5M (maybe even 0) to secure $5B assets. […] You SHALL pay 10% using your own money as bug bounty or you will cause all your holders a 15% loss for your irresponsibility and stinginess. […] Anyway we are going to publish the private key to decrypt our conversations afterwards.

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.

Merged PR’s

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

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

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

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

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

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

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

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

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

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

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

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

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

  Kernel logging has a few problems:

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

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

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

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

IRC meeting notes

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

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

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

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

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

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

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

Read here for the full meeting

Releases

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

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

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

Christian Lewe, a researcher at Alpen Labs, explains the one-time signature schemes used in BitVM bridges: Lamport, Winternitz, and adaptor signatures. He describes how anti-chain Winternitz counters the malleability of ordinary hash chains, why these signatures support off-chain proof and fraud-proof workflows, and why BitVM currently needs them under Bitcoin Script’s opcode limitations.

The conversation then turns to the potential of `OP_CHECKSIGFROMSTACK` and Schnorr signatures, which could make the bridge construction more efficient if activated. Christian also discusses witness encryption, PIPEs v2, the difficulty of cryptographic research, and Alpen Labs’ work toward simpler, more secure bridges.

We reached out to talk with him about bitcoin-based payments, which will be the main topic at the next Bitcoin++ conference in Berlin.

Hi Egge! Tell us a bit about yourself and what you are working on! What are you going to talk about in Berlin?

I’m an open-source developer working mostly on Bitcoin payments and Cashu. My goal is to make Bitcoin payments accessible to anyone, enabling a more sovereign world.

A lot of my current work revolves around Coco, a TypeScript framework for building applications on top of Cashu. Cashu already provides really powerful payment rails, but there is still a lot of complexity involved in implementing a full wallet or payment system correctly. Coco tries to abstract a large part of that complexity while still giving developers control over how their application works.

In Berlin I’ll be doing a workshop showing how easy it can be to integrate Bitcoin payments into products using Cashu and Coco. I want developers to leave with the feeling that adding Bitcoin payments to an app or ecommerce product doesn’t have to be a massive undertaking anymore.

The topic of Bitcoin++ Berlin is payments. Where do you stand on the Bitcoin monetary-scale? Is Bitcoin more a Store of Value (savings) or a Medium of Exchange (payments)?

Both are incredibly important, but personally I care even more about Bitcoin as a medium of exchange.

Bitcoin being a global, accessible, fair and equal form of money is what makes it so powerful. The store-of-value aspect is obviously important for building sustainable wealth, but the freedom to transact freely is even more fundamental to me.

If I had to choose between a world where Bitcoin becomes the dominant savings asset but everyone continues paying through fiat systems, and a world where hundreds of millions of people actually transact using Bitcoin-native payment rails, I would choose the latter.

That said, I think the distinction is mostly theoretical. I find it hard to imagine Bitcoin being adopted globally as a payment system without also establishing itself as a major global monetary asset and taking market share from other stores of value.

Currently, we can see both a lack of merchants accepting bitcoin and users spending it. Do you think it is more an economical problem — i.e. bitcoin exchange rate is continuously rising and people do not want to spend it — or a UX one — it is difficult to use and accept bitcoin?

I think it is a combination of several things.

There are already very orange-pilled merchants who would like to accept Bitcoin, but the additional integration work, accounting, tax considerations and general operational complexity make it unattractive.

On the user side there are similar problems. People have to figure out how to convert fiat into Bitcoin, which wallet to use, which provider to trust, how custody works, what payment method they need and so on. Even terminology like addresses, invoices, payment requests, sats, Bitcoin, Lightning and ecash can become intimidating very quickly.

And then you have the classic chicken-and-egg problem. Merchants are more willing to do the work of adding Bitcoin if it lowers their fees or brings them additional customers. Users are more willing to learn how to pay with Bitcoin if they can actually use it in many places.

I don’t really buy the argument that people will not spend Bitcoin because it appreciates. People need to consume regardless of what currency they save in.

“Spend and replace” is a completely valid strategy: spend Bitcoin and use the fiat you would otherwise have spent to replace the Bitcoin. You can take that even further and simply get paid in Bitcoin.

I think the HODL movement has sometimes created this idea that spending Bitcoin is inherently bad. I disagree with that.

How do we make sure that Bitcoin is actually used as a payment method? How do we convince more merchants to accept it and more people to spend it?

A big part of it is simply making the experience dramatically better.

We need Bitcoin payment systems that can compete with PayPal and Visa on UX. A normal person should not need to understand payment rails, liquidity management or protocol details just to pay for something.

I think we will increasingly see wallets and merchant applications dynamically choose between different payment mechanisms behind the scenes. BIP321 is already moving in this direction by allowing payment requests to contain several possible payment methods.

We experimented with this in Numo, a mobile Cashu point-of-sale application. A merchant can present a single payment-request QR code and accept both Lightning and Cashu bearer payments. The merchant does not need to present different buttons or explain different protocols to the customer.

There are situations where understanding the underlying technology is absolutely critical. Cold storage is the obvious example: if you are protecting your life savings, you need to understand what you are doing.

But spending-money applications are different. We should be comfortable hiding complexity there.

At the same time, I do think we should actively explain why spending Bitcoin matters. Bitcoin does not become a widely used monetary system simply by everyone holding it forever.

You are one of the leading voices in the Cashu ecosystem. Do you think Cashu is the best attempt at making Bitcoin everyday money? What are the strongest advantages in using Cashu as money compared to other layers? What are its disadvantages?

I don’t think there is an absolute best solution. Every payment system has trade-offs.

What I think Cashu does exceptionally well is UX. Representing money as a digital bearer asset enables interactions that feel much closer to physical cash.

You can make offline payments. You can literally put money into a message or an email. You can drop money into a digital tip jar. The receiver does not necessarily have to be online at the exact moment the payment is created.

Cashu can also interact with the wider Bitcoin ecosystem, so it does not need to exist as an isolated payment network.

Another major advantage is what it can do for developers. Cashu encapsulates an enormous amount of payment complexity, and the developer tooling has become very good. With libraries like CDK and Coco, and increasingly capable AI development tools, building a functional Cashu wallet can genuinely become an afternoon project.

That accessibility is important to me. If we want thousands of applications experimenting with Bitcoin payments, developers need primitives they can actually build with.

The most obvious trade-off is custody. A Cashu mint is a custodian, and you have to trust it with the Bitcoin represented by the ecash it issues.

But Cashu is not supposed to be a vault. I think of it much more like the cash you carry in your pocket. Long-term savings belong in proper Bitcoin self-custody.

One useful property of Cashu is that the custodial risk can also be distributed across multiple independent mints. Instead of putting all your spending balance with one custodian, you can hold ecash from several.

There are also interesting approaches for reducing trust further. Federations are one option, although they introduce their own complexity. TEEs are another promising approach for reducing how much trust needs to be placed in the operator. There are a lot of experiments happening here, and I think we will learn over the next few years which models work best.

Another challenge is simply domain knowledge. Cashu makes many things technically easier, but users can still be confronted with Bitcoin terminology and then additional concepts such as ecash, tokens and mints.

That is ultimately a UX problem for us to solve. Users should not need to become protocol experts in order to spend money.

Other than Cashu, what are you most excited to see at Bitcoin++ Berlin?

Definitely the hackathon.

It is always incredibly fun seeing what people come up with when you put a lot of smart Bitcoin developers in one place and give them permission to experiment.

Some genuinely novel ideas and projects come out of these hackathons, including things nobody would have predicted beforehand. That experimentation is one of my favorite parts of Bitcoin++.

We’d like to thank Egge for his availability for this interview. Would you like to attend Egge’s workshop and see what devs are working on? Join us in Berlin this October 1- 3 to talk about payments in Bitcoin!

In this week’s update we feature the latest releases in the ecash ecosystem, Fedimint v0.12.0 and Cashu Dev Kit (CDK) v0.18.0.

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

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

Highlights from the Bitcoin developer ecosystem

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Other News from the Bitcoin World

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

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

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

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

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

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

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

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

Reads from BTC++ Insider Edition

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

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

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

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

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

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

Merged PR’s

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

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

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

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

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

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

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

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

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

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

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

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

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

IRC meeting notes

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

--- Topic 1 ---

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

--- Topic 2 ---

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

--- Topic 3 ---

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

--- Topic 4 ---

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

--- Topic 5 ---

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

Read here for the full meeting

Releases

• No releases

• v32.0 is coming soon…

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

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

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

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

No price noise, just educational signal.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Highlights from the Bitcoin developer ecosystem

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

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Other News from the Bitcoin World

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

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

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

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

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

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

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

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

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

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

Introduction

It’s 2034 and mid-day on a Thursday. Your mom just called, she needs some urgent help paying a ransom to get access to her emails and bank passwords — someone’s locked her computer. You go to find your hardware wallet only to discover that your dog just destroyed your ‘primary’ signing device. Luckily, you moved your funds back in 2028 to a new key format that Blockstream Research launched in 2026, SHRIMPS, which will let you use your backup key to sign for your funds without a problem and without spending all the available balance for fees.

Backing up wallet state is a big issue for post-quantum hash-based signatures. Blockstream Research’s latest update is a push in the direction of better, stateless backups without giving up gains in conserving blockspace.

The previous Blockstream Research post-quantum signature scheme was reported on by Insider Edition. Our deep dive on SHRINCS, a quantum-resistant scheme combining both stateful and stateless hash-based signatures shows how stateful and stateless schemes can be combined in a single signature. Stateful schemes allow for smaller signatures, at the cost of needing to keep track of which signatures have been already used (this is the ‘state’ you’re tracking).

If the record of what signatures have already been made is lost, like in our opening horror story, you can no longer use the keys without risking compromising their security, which would allow someone else to move your funds.

On the other hand, we have stateless signing schemes. These can be easily restored from a static backup such as a seed phrase, but the signatures they produce are quite large — you trade cheap onchain signatures for a guarantee of being able to use it if lose your device.

SHRINCS, Blockstream Research’s first post-quantum (PQ) signature proposal, fuses a stateful and stateless scheme to give you the best of both worlds. The combined signature scheme uses the stateful scheme which produces smaller signatures for ordinary operations, but falls back to the stateless, more expensive signatures, if your signing history is lost. SHRINCS’s stateless signing mode removes the risk of producing weak or forgeable signatures from lost state, while allowing you to benefit from smaller, stateful signatures in the default case.

On March 27th, Director of Blockstream Research Jonas Nick introduced a new scheme called SHRIMPS on the popular technical forum, Delving Bitcoin. SHRIMPS is another PQ signature scheme proposal. As a product of one of Bitcoin’s most experienced research labs, it aims to improve on the earlier SHRINCS proposal.

By default, a SHRINCS backup signing device would default to using the stateless signing mechanism. In this case, your keys lose the ability to produce smaller signatures, moving from 324 bytes per signature to up to 8KB, a 25x increase in on-chain weight. This is problematic, given that you pay for every byte used in a bitcoin transaction. Backup signing devices, if used, would produce 25x more expensive transactions.

SHRIMPS, the latest proposal, aims to optimize the fallback option of SHRINCS. Instead of having a single fallback option, SHRIMPS would allow user’s backup devices to sign in a compact form until a threshold number of signatures is reached, and only once the limit on smaller signatures is reached, falling back to the more expensive, larger signature signing option.

Basics of SHRIMPS

The construction of SHRIMPS combines two instances of SPHINCS+, a stateless hash-based PQ signature scheme. SPHINCS+ is complex. It’s constructed using several WOTS+ and XMSS nested trees to produce a single quantum safe key-pair. A SPHINCS+ key-pair can be used to sign many messages safely.

The depth of navigating the SPHINCS+ hash tree to locate the public/private key is what contributes to the large size of SPHINCS+ stateless signatures. The statelessness comes from the low probability of ever picking the same path in the tree again, at random. However, there is an upper bound to how many signatures can be produced in a SPHINCS+ tree before the odds of picking the same path again goes above what is considered ‘safe’.

In the SPHINCS+ literature, q_sis this upper limit. It’s the bound on the number of signatures that can be securely produced under a single SPHINCS+ key tree. q_s also governs the depth of the nested SPHINCS+ trees. So a smaller q_s means smaller resulting signatures, as it takes less data to describe the path through the SPHINCS+ forest. A smaller tree means less signatures that can be safely produced, but also less data per signature.

SHRIMPS uses this q_s to create two different SPHINCS+ key trees, and then binds them together into a single key, which can sign using either of the two SPHINCS+ trees. The trees only differ on the value of their q_s parameter: The first instance, referred to as compact path, uses a low q_s, which allows for smaller, but very limited number of signatures; the second instance uses a larger q_s. It produces much larger signatures, but can sign an almost infinite number of times.

Since both options are using SPHINCS+, both tree options are independently stateless. Unlike in SHRINCS where on one path you must remember what you’ve signed, SHRIMPS’ paths only need to remember how many times the lower-bound SPHINCS+ tree has been used.

According to Nick, for the compact instance q_s = 2^10 would be a good, conservative bound — providing around 1024 signatures —, while the fallback instance should be implemented with a sufficiently large parameter, such as q_s = 2^40 or q_s = 2^64 — an upper bound of around 1.85 x 10^19 signatures.

The SHRIMPS public key p_k is the hash of the public keys of each of the two SPHINCS+ treesets. A signature consists of a SPHINCS+ signature under the chosen instance s_k1 and the public key of the other p_k2. The verifier reconstructs the signing instance’s public key p_k1 from the SPHINCS+ signature, hashes p_k1 and p_k2 to reconstruct the combined public key, and compares it to the known SHRIMPS public key, p_k.

When initializing a new device by providing a seed, it will deterministically derive keys for each of the two SPHINCS+ instances. Each device will have its own, independent, persistent state to check whether the compact path has already been used or not.

How Many Signatures?

Assuming that the compact signature can be used to sign at most once for every device, q_s basically becomes the upper limit to the number of devices that could be initialized, n_dev. Setting q_s = n_dev = 2^10 means giving the user the possibility to initialize more than one thousand devices, which seems a lot, even in the most pessimistic cases. Hopefully, no one would lose access or break a device more than one thousand times!

The “budget” could also be expanded to provide each device with more than one compact-path signature to be used. For example, setting n_devsigs = 2^4 would provide the possibility to sign 16 times with the compact instance with each device, nevertheless resulting in a signature smaller than 3KB. In this case, the parameter would be set to q_s = n_dev x n_devsigs .

As we said, each device needs to store an independent counter to decide whether to use the compact signature or not. The counter will be log2⁡(n_devsigs + 1) bits in size, depending on the number of signatures available for each device.

In the simplest case — one device, one compact signature — the signing flow would require to check whether the independent, single-bit counter is 0 or 1. In the first case, the device will sign using the compact SPHINCS+, resulting in a 2.5KB signature at 128bit security. Otherwise, it falls back to the larger instance. In case n_devsigs > 1 , the device will be able to use the compact signatures several time until exhaustion — 16, in case n_devsigs = 2^4.

If the number of compact-path signatures exceeds the q_s budget, security does not break down immediately. Instead, it degrades gradually, as the the table provided by Nick clearly shows. With a budget set to q_s = 2 ^10 , the security of the scheme is 128.0 bits. Using 2^11 signatures doesn’t degrade security, which only start to drop tp 125.1 bits when signing with the compact scheme 2^12 times (i.e. 4 times the available budget).

Putting it all together

As previously said, the aim of SHRIMPS is to improve on the stateful scheme side of SHRINCS to provide a safe path towards funds recovery. When using SHRINCS, if a single signing device is lost, the scheme allows the user to recover its keys using a static backup. However, it will default to use the heavy stateless scheme as soon as the state for the smaller signature scheme is lost.

SHRIMPS provides an intermediate step between the lean stateful signatures (324 bytes) and the huge stateless ones (~8KB), by allowing for a series of devices, each which can track their state independently and produce smaller SPHINCS+ signatures until the counter expires.

Putting together SHRINCS and SHRIMPS would result in the following workflow:

• The first device is initialized, and the stateful scheme is used to sign any transaction. The stateful scheme is used until the state is known, to avoid breaking the cryptographic assumptions of the scheme. Each signature is 324bytes in size.

• Once the state is lost (i.e. first device is no more usable), a new device is initialized. The compact SPHINCS+ instance is used to sign until the budget n_devsig for the device is reached. Each signature is ~2.5KB in size.

• When the whole budget has been drained, the SPHINCS+ with the larger q_s parameter, and thus larger signatures, is used. Each signature would be between ~4KB and ~8KB depending on the exact parameters chosen, but the number of signatures available is high enough to allow for practically unlimited signing.

In the following table, we can see the size of the signatures produces by the different algorithms:

Post-quantum Bitcoin is Moving

Brink recently announced that they had hired quantum cryptography researcher Conduition, to focus on making Bitcoin quantum-secure. His main area of focus will be to make SHRINCS a reality, providing a usable protocol and draft BIP for the signature scheme. This seems to point to the fact that SHRINCS could be a viable solution in a post-quantum future. Building upon this protocol, thus, follows a natural course. SHRIMPS is another clever solution to improve the UX of post-quantum signatures even more.

And earlier this month, following the rash of LLM powered attacks on existing Bitcoin infrastructure, Jonas Nick announced a preliminary C library — libshrincs. It is a handwritten C library implementing WOTS+C, the one-time signature used by SHRINCS for the stateful signing path.

On August 27th Jonas Nick also announced the publication of BIP SHRINCS, the draft proposal specifying all the underlying cryptography needed for the scheme to work. While using SHRINCS in Bitcoin Script would require a separate BIP, this proposal defines the design choices, new parameter set, and improvement on top of the original proposal. The BIP is up for debate and the SHRINCS working group — composed by Conduition, Mike Casey, Ethan Heilman, Remix, Boris Nagaev, Mikhail Kudinov, Oleksandr Kurbatov, and Nick himself— is waiting for feedback on the proposal.

Research on post-quantum signature for scarce resource environments is still at the beginning, but the ball is already moving. Improving on the small signatures, and fallback in case of state loss is another step towards a better experience using Bitcoin securely and cheaply in a post-quantum world.

He is equipping the local community to carry it forward through BitDevs Toronto.

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

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

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

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

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

It All Started with an Hackathon

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

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

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

The Android fork is still available on GitHub.

Private Messaging Needs Private Money

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

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

Closing the Loop

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

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

Freedom of speech and freedom to transact belongs together.

What’s Next?

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

Next Stop: Berlin

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

At his first Bitcoin conference, Julian is enjoying the chance to meet people he previously knew only through Twitter.

00:40 — What Is Script Restoration?

Script Restoration is a broad effort to make Bitcoin Script more expressive. The goal is to give developers a stronger foundation for building new protocols on Bitcoin.

01:48 — Why Drop “Great” from the Name?

The proposal is now called simply “Script Restoration.” It restores historical functionality while extending Script with newer capabilities.

02:51 — Continuing Rusty Russell’s Work

Rusty Russell’s research and writing helped shape the proposal. Julian continued developing those ideas after seeing that few others were actively working on them.

05:06 — Is Script Restoration a Single BIP?

Rather than one large proposal, Script Restoration comprises multiple BIPs addressing computational budgeting, restored functionality, introspection, and related extensions.

06:52 — Covenant and Introspection Opcodes

The conversation covers OP_TX, PREVOUTs, and selector-based transaction introspection, comparing this general approach with OP_TXHASH, TEMPLATEHASH, and CTV.

09:12 — Script Restoration and Simplicity

Extending the existing scripting language is compared with replacing it more comprehensively. Script Restoration represents a smaller departure from Bitcoin’s current design than Simplicity.

11:13 — What Makes Script Restoration Exciting?

Research around verifiable computation could bring new capabilities to Bitcoin. Greater expressivity may improve scalability, privacy, and the user experience.

13:08 — Benefits for Bitcoin Users

Script Restoration is a low-level change intended primarily for developers and researchers. Users would experience its benefits indirectly through better wallets, protocols, and second layers.

15:23 — What Is ShieldedCSV?

ShieldedCSV is presented as a client-side validation design offering privacy and scalability. The blockchain would prevent double-spending without publicly validating every transaction.

16:44 — Making Permissionless Bridging Feasible

Script Restoration could provide the primitives needed for permissionless bridging. That could make designs such as ShieldedCSV more practical without relying on one-way bridges.

19:28 — Taproot, Ark, and Unknown Possibilities

Taproot and Ark illustrate how a protocol upgrade’s best applications may emerge later. Script Restoration could similarly unlock ideas that researchers have not conceived yet.

19:43 — Following Julian’s Work

Listeners are invited to read and review the published BIPs or contact Julian on X. The next steps include testing the implementation on the Bitcoin Inquisition signet and gathering more feedback.

He’s interested in metaprotocols and shares his hackathon project based on Counterparty.

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

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

Highlights from the bitcoin developer ecosystem

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

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

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

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

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

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

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

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

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

A BIPs Update

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

Numbered BIPs

A list of BIPs that recently got assigned a number

BIP332: Stale Tip Relay

Authors: Anthony Towns, w0xlt, Ram

Assigned On: Aug 20th, 2026

Layer: Peer Services

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

Other News from the Bitcoin World

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

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

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

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

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

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

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

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

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