Bitcoin Optech

Bitcoin Optech Newsletter #418

2026-08-14T00:00:00+00:00

This week’s newsletter describes a proposed contract protocol for mitigating Lightning Network channel jamming, reports on the availability of static Bitcoin Core binaries for testing, and summarizes a change replacing Bitcoin Core’s per-peer transaction rate-limiting with a global approach. Also included are our regular sections announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

● Conditional message transfer contract to solve jamming: Antoine Riard posted to Delving Bitcoin a new approach to mitigate channel jamming on the Lightning Network. Jamming is a denial-of-service attack in which the attacker sends HTLCs or PTLCs and then holds them unresolved, tying up the channel liquidity along a route at no cost to itself. Riard’s proposal makes holding expensive by charging a withhold fee proportional to how long a payment is held, converting a currently free attack into a costly one.

The mechanism is a conditional message transfer contract (CMTC) which is a Bitcoin Script construction that lets two channel counterparties later prove whether a specific message (such as a payment preimage) was exchanged between them by a given block height, which Riard treats as a universal clock. The parties agree on a temporal window and assign an adaptor point to each point in time within it, so the withhold fee can be settled according to when the message was delivered. The contract offers three settlement paths:
- ● Message transfer success: the preimage is delivered from Bob to Alice and cryptographically acknowledged, and the two split the withhold fee based on delivery time.
- ● Liveness challenge: if Alice is offline and cannot counter-sign, Bob can exit the contract and recover the locked funds minus an equilibrium penalty fee.
- ● Message transfer failure: if Bob is offline or otherwise fails to transfer the message, Alice can exit and recover the withhold fee.
Riard notes that the proposed solution needs further analysis, both of its cryptographic correctness and of its incentives, and that it remains open whether this approach, or an expansion of it, could solve other types of problems in Bitcoin.
● Static Bitcoin Core binaries available for testing: Michael Ford (fanquake) posted to the Bitcoin-Dev mailing list announcing test builds of static Bitcoin Core release binaries produced using the project’s existing Guix infrastructure. Test binaries are available for bitcoind and the other command-line utilities on x86_64 and aarch64 Linux, with more platforms planned. The bitcoin-qt GUI binary is unchanged.

Bitcoin Core’s current Linux release binaries are dynamically linked, meaning that they contain most of the code they need but depend on the C library (glibc) and a few related libraries provided by the user’s operating system. Those libraries are located and loaded each time the program starts, a dependency that carries some risks. The binaries only run on systems that provide a compatible glibc (currently version 2.31 or newer), their behavior can vary with the host’s libraries, and some of the code the node actually executes falls outside the binary that reproducible builds allow users to verify. A static binary instead includes all of the code it needs, so the same verified executable runs the same way on nearly any Linux system, including older releases, distributions built on a different C library such as Alpine Linux, and minimal container images that ship no system libraries at all. The new binaries remain position-independent executables, preserving the ASLR exploit mitigation of current releases, and are only about 1 MB larger.

The mailing list post continues years of work in Bitcoin Core #25573, which Ford opened in 2022. Progress required changes to the GCC compiler and to glibc itself, including fixes to glibc’s name resolution code, historically the main hazard of statically linking glibc. Some preparatory changes to the Guix build process (see Bitcoin Core #35537) have been merged, but the main PR remains open and under review. Readers who run Bitcoin Core on Linux are encouraged to try the test binaries and report any problems, or successes, to the mailing list or the PR.
● Replacing per-peer transaction rate-limiting with global rate limits: Anthony Towns posted to Delving Bitcoin announcing the merge of Bitcoin Core #34628, which replaces the per-peer transaction rate-limiting with a global approach.

For each of its peers, a node keeps a queue of the transaction announcements it intends to send to that peer, called m_tx_inventory_to_send, sorts those announcements by ancestor feerate, and sends the best of them first. To limit bandwidth and to make it harder to probe the relay topology, a node announces no more than about 7 transactions per second to each peer. In normal times this rate is enough to drain the queue, but a sudden burst of transactions can fill it faster than the limit lets it drain. Because the node re-sorts the growing queue on every announcement, this can consume an excessive amount of CPU, a denial-of-service (DoS) vector previously described in Newsletter #324.

Towns’ PR replaces the per-peer rate-limiting with a global rate limit, using two token buckets that meter total announcements by count (number of transactions) and by size (serialized witness size). If there is enough capacity, an incoming transaction is relayed immediately, otherwise it is added to a single global backlog sorted by feerate and cluster mempool rules. Transactions selected from that backlog are then placed in a small per-peer queue used for privacy batching. Sorting one shared backlog instead of a separate queue per peer avoids the repeated per-peer sorting that made the original design a DoS vector.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

● BTCPay Server 2.4.2 is a security release that fixes a critical vulnerability affecting all releases before 2.4.2. An unauthenticated remote attacker could obtain an LND node’s .macaroon credential files and use them to take control of the node and move funds. The project reports that the vulnerability was exploited and funds were stolen. BTCPay Server operators using LND should update to 2.4.2 and LND 0.21.1 immediately, audit their node for unauthorized activity, and rotate their macaroon credentials, since an attacker may have already obtained them. BTCPay Server’s onchain wallets and deployments using other Lightning implementations are not exposed to this specific risk.
● LND v0.21.2-beta is a maintenance release of this popular LN node implementation. It fixes two database migration failures, bounds memory usage during channel graph synchronization, and fixes bugs affecting onion messages, RBF cooperative closes, invoice updates, blinded-payment forwarding, and HTLC resolution.
● LND v0.20.3-beta is a maintenance release of LND’s 0.20 release branch. It backports several fixes also included in 0.21.2-beta, including bounds on memory use during channel graph synchronization and fixes for cooperative closes, invoice updates, blinded-payment forwarding, and HTLC resolution.

Notable code and documentation changes

Notable recent changes in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

● Bitcoin Core #35493 fixes a false warning that indicated private keys were missing when importing MuSig2 descriptors (see Newsletter #366) with all the required private keys. Previously, the importdescriptors RPC checked for a corresponding private key for every public key produced when expanding the descriptor, including the MuSig aggregate key, which doesn’t have a standalone private key. This could cause a descriptor containing all of its participants’ private keys to be reported as incomplete. The completeness check now accounts for MuSig participant keys, so complete descriptors import without a warning, while those missing participant private keys still trigger a warning.
● Core Lightning #9150 introduces impressions, a new type of liquidity information that records successful payments through a channel and allows the askrene RPC command (see Newsletter #316) to adjust its liquidity estimates for subsequent routing attempts. Additionally, the getroutes RPC command is updated to provide more specific error messages when routing fails, such as when the source has insufficient funds or the destination has insufficient incoming capacity. Also, the PR limits invoices generated from BOLT12 offers denominated in another currency to a 10-minute expiry by default to account for exchange rate fluctuations.
● BIPs #2248 updates BIP3 to remove Luke Dashjr from the list of BIP editors, following discussion on the Bitcoin-Dev mailing list. See Newsletter #299 for previous coverage of the editor set.
● BIPs #2225 and #2245 update BIP110 (see Newsletter #412) following its unsuccessful activation attempt. #2245 changes its status to Closed. #2225 makes BIP433’s policy rule requiring pay-to-anchor (P2A) spends to carry an empty witness stack into a consensus requirement.
● Eclair #3346 fixes a crash and makes several onchain and channel-handling improvements. It now verifies that decrypted payment failures correspond to a valid intermediate position in the payment route before using them as routing information, preventing malformed or maliciously crafted failures from the recipient from triggering an out-of-bounds access that could crash the payment lifecycle actor. It also starts retrying onchain transaction broadcasts when it receives error messages from Bitcoin Core it can’t classify, instead of potentially abandoning a time-sensitive transaction. When using CPFP to fee-bump a peer’s zero-fee commitment, it now accounts for the full parent-and-child package weight instead of only the parent’s weight. Finally, Eclair now uses the MuSig2 nonce associated with the funding RBF attempt that actually confirmed when sending channel_ready, instead of assuming that its latest RBF attempt is the one that confirmed.
● Eclair #3341 prepares to relay future channel_update gossip messages that use currently undefined message_flags or channel_flags in BOLT7. Previously, if Eclair received an update with an unknown flag bit set to one, it would discard that value and encode the bit as zero when forwarding the update. This modified the signed message and invalidated its signature. Now, Eclair preserves unknown flag values when decoding and re-encoding channel_update messages, allowing Eclair nodes to relay updates containing flags they don’t yet understand.
● LND #11019 fixes a data race in the legacy cooperative-close state machine, which could occur when the link goroutine (which tracks the channel’s HTLC and commitment state) and the peer goroutine (which processes close messages from the remote peer) advance concurrently. Now, instead of advancing the closer itself, the link reports to the peer’s channel manager when a channel has been flushed (pending HTLCs have been drained), ensuring that all close state-machine transitions run on a single goroutine. The PR also ensures that the RBF cooperative-close path (see Newsletter #347) checks that the peer’s delivery script is present and uses an accepted output type, even when no upfront shutdown script was negotiated (see Newsletter #76).
● LND #11023 changes update_fee handling to match BOLT2’s replaceable-state model and prevent redundant uncommitted fee updates from growing the update log. If a newer fee update arrives before the previous one has been included in either party’s commitment transaction, LND now replaces the previous fee value in place. The PR also limits channel mailboxes to 1,000 queued messages and 4 MiB of serialized data. If a message cannot be accepted, LND disconnects the peer instead of dropping the message and processing subsequent messages out of order. This allows the ordered channel state to be recovered upon reconnection.
● Libsecp256k1 #1904 strengthens the startup self-test for applications that provide their own SHA256 compression function (see Newsletter #396). Previously, the self-test hashed a single 63-byte message, which could detect general incorrect implementations but not ones that failed when processing multiple blocks, unaligned input, or a SHA256 state other than the initial one. The new test uses different message lengths and input alignments. It rejects a supplied compression function if its results differ from the expected SHA256 results, allowing faulty implementations to be detected during initialization rather than producing incorrect results later.
● HWI #839 fixes several PSBT parsing and transaction reconstruction issues that were revealed when adding the complete BIP174 and BIP370 test-vector suites. When reconstructing a transaction from PSBTv2, HWI now applies the computed locktime instead of leaving it at zero and uses the specified final sequence value (0xffffffff) when an input omits PSBT_IN_SEQUENCE. For PSBTv0, HWI rejects v2-only input and output fields and strictly parses the global unsigned transaction using non-witness serialization, while correctly recognizing an empty unsigned transaction as present. The PR also validates that required height and time-based locktimes fall within their specified ranges and adds tests for BIP370 locktime determination.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on August 18. The discussion is also recorded and will be available from our podcasts page.

Bitcoin Optech Newsletter #417 Recap Podcast

2026-08-11T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Conduition, Ram, and Fabian Jahr to discuss Newsletter #417.

The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

Download audio

News

● Draft BIP for stale tip relay (29:26)

Changing consensus

● CISA for taproot keypath spends (BIP460) (40:38)
● Segwit commitment to post-quantum witness data (57:51)
● PQC output type discussion (1:45)
● Input-triggered transaction expiry (1:03:36)
● Layered quantum recovery of hashed addresses (21:53)
● Segregated Data (SegData) BIP draft (1:08:33)

Releases and release candidates

● Libsecp256k1 0.8.0 (1:15:24)

Notable code and documentation changes

● Bitcoin Core #35501 (1:18:10)
● Core Lightning #9298 (1:22:47)
● Core Lightning #9353 (1:25:02)
● Eclair #3336 (1:26:15)
● LND #10942 (1:27:53)
● LND #10992 (1:29:35)
● Rust Bitcoin #6364 (1:31:55)
● Rust Bitcoin #6642 (1:33:22)
● BTCPay Server #7491 (1:36:52)
● BTCPay Server #7488 (1:38:35)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #417. Today, we’re going to talk about a draft BIP for stale tip relay. We have our monthly segment on Changing Consensus which, as usual lately, is pretty beefy. We’re going to talk about cross-input signature aggregation (CISA); we have a handful post-quantum-related Changing consensus discussions as well; and then we’ll move to Releases, we have the secp release. And then, we have a bunch of Notable code and documentation changes. Murch, Gustavo and I are joined by some guests this week. We’ll have them introduce themselves briefly. Conduition, who are you?

Conduition: Hey, Mike. Hi, I’m Conduition, I’m a freelance and open-source engineer and researcher, now focused primarily on post-quantum stuff and funded by Brink.

Mike Schmidt: Ram?

Ram: Hey, my name is Ram, I also go by pseudoramdom on the internet. I’m an open-source contributor/researcher at Localhost Research, primarily working on Bitcoin Core. Thanks for having me here.

Mike Schmidt: Fabian?

Fabian Jahr: Hey, I’m Fabian, I’m a Bitcoin open-source contributor and I’m supported by Brink.

PQC output type discussion

Mike Schmidt: Thanks for joining us, we appreciate your time. We’re going to rearrange, for listeners who are following along. We’ll go a little bit out of order in deference to our guests. So, we’re going to jump to Changing consensus. We have a few items that Conduition is going to help us get through on the quantum front, that I saw that he was engaged with on Delving. The first one, “PQC output type discussion”. So, conduition, nearly everyone in these discussions agrees that Bitcoin may eventually need and should put some time toward researching post-quantum and maybe a new address type that can survive quantum computers. Maybe the problem, or maybe not a problem, but one consideration here is that there’s about a half dozen of these different designs, each being debated in their own threads, some on the mailing list, some on Twitter, some on Delving. And so, Pieter Wuille opened up a thread to sort of put them all in one table and then compare them head-to-head. Maybe I’ll just leave that as the intro. Maybe you can talk a little bit about what aspects things are being compared on and maybe what some of the important candidates or distinctions are between the different candidates?

Conduition: Yeah, absolutely. Thank you. Pieter’s post here does a great job at summarizing it, so I’ll try not to regurgitate too much. I would highly recommend you read it first. But the major salient trade-offs of any post-quantum output type in a quantitative sense is its efficiency, how cheap it is to spend. But also, there’s qualitative properties like, is it secure against a quantum computer without follow up? And that’s one of the main debate points between the different output types that are under consideration. And there’s even some subtlety there in that question, because there’s one output type called Pay-to-Taproot-Hash (P2TRH), which is secure until you spend from it. So, there’s a lot of different subtleties, and Pieter does a great job at summarizing them all. He separates his posts. The first one is purely factual, unopinionated, and it goes over the different trade-offs in a very unbiased way, I really appreciate that. And then, he separates out his own stance and what he would into his second post. And his recommendation was to deploy Pay-to-Taproot v2 (P2TRv2) and Pay-to-Merkle-Root (P2MR), which are two different output types, in tandem or perhaps in a staggered release fashion. And these two address types will do very different things for different people.

Mike Schmidt: So, Pieter recommended both, because I know I’ve seen you and him going back and forth on P2MR vs P2TRv2. He’s saying do both?

Conduition: Yeah, yeah. There’s two different perspectives generally in this debate. There’s the absolute security perspective, which is that if we want a post-quantum output type, it should be post quantum. We shouldn’t have to do some sort of follow-up fork to close up a security hole later. But then there’s the migrationist perspective, which is that we want to maximize the incentive for everyone to migrate as soon as possible so that we don’t have to deal with things like rescue protocols; or at least if we do, the fallout of instituting rescue protocols will be much less and will be less worrisome. And both have their merits and both have their trade-offs. But deploying both output types, as Pieter is saying, will appease both camps.

Mark Erhardt: Sorry, could you explain which of the two is only post-quantum, because I thought that P2MR would also have ECDSA signatures in the output, in the scriptpath, and P2TRv2 would not be only post-quantum either, so I don’t really understand?

Conduition: Great question. So, there’s a lot of subtlety here in which signature types are available on which outputs, and there’s different options. P2MR, as it’s currently defined, will support both classical and post-quantum signatures. So, it’s theoretically possible to use P2MR in a quantum-secure way, as long as you never expose your elliptic curve public keys to a quantum attacker. And the point that Pieter makes and that Antoine has made before in the mailing list debates is that that’s a big ask. And there is an option to deploy P2MR without classical elliptic curves. That’s what sipa calls P2QR, Pay-to-Quantum-Resistant. This one, I don’t know of anybody actively pursuing this path, primarily because, well, if you were wanting to deploy P2QR, you would want to deploy a different output type alongside it, because otherwise nobody would migrate to P2QR before Q-Day. And then, we would still run into the problem of having to rescue a whole bunch of coins, a lot of people might get hacked. So, it doesn’t seem like a desirable option for most people.

Mark Erhardt: Right, because of course spending from P2QR would incur huge scripts due to the quantum-resistant signature scheme.

Conduition: Exactly, unless there were some massive witness discount or SNARK verification, which we can talk about in a bit. But as to your question, yes, there’s P2MR, P2TRv2. They both support classical and post-quantum signatures. The difference is in whether the public keys that you validate against are hidden by the hash or not. To be clear, in the case of P2MR, everything is hidden behind hashes; and in the case of P2TRv2, we post a bare public key on chain, just as in P2TR.

Mark Erhardt: Right. So, P2MR, the argument would just be that it’s resistant to long-range attacks because the public key material is not visible until it’s reused or a transaction is in the mempool, okay. I thought you meant quantum-resistant as in with quantum-resistant signature scheme and only that as it’s only spending option. But as you clarified, that is now referred to as P2QR.

Conduition: Yeah, exactly. I think it’s good to distinguish, because it avoids confusion as to what exact spending conditions are available. I think P2QR could be viable, but it would require a lot of other technologies, like SNARK signature aggregation, to be economically viable.

Mike Schmidt: Maybe that’s a good segue to one of my follow-up questions. You, Conduition, pointed and encouraged listeners to read the source material on what Pieter put together. Unfortunately, Pieter couldn’t join us, so we will encourage people to go read that firsthand. But since we do have you and you added some contributions to that thread, there’s two pieces that I pulled out at least. There’s the potential, you were talking about Fabian, who’s here, his CISA proposal for signature aggregation, and then there’s also block-wide PQ-SNARK aggregation. So, maybe you want to double-click on both of those?

Conduition: Yeah, absolutely. So, there’s some great interplay between many different proposals, like Fabian’s, and post-quantum migration. And I hadn’t thought about this until recently. So, it’s kind of been changing my mind a little bit on this post-quantum output-type debate and making me rethink what’s going on and what the best options are. So, maybe we should do a little brief thing on CISA before we talk about how CISA affects post quantum. Maybe I’m not the best person to talk about this, since we have the author of CISA in the room here.

Mike Schmidt: Fabian, do you want to spoiler-alert your other item by sort of summarizing it briefly here, and then we can dig in maybe a little bit deeper later?

Fabian Jahr: I think for the purpose of this question, maybe we can just remind people that CISA means that a transaction that has multiple inputs, which typically corresponds to multiple signatures, with CISA those could be aggregated into a single signature, which is smaller. And there are two different types, one which roughly halves it and the other one makes it a constant size. I think it creates a lot of space-savings on the chain in terms of the signatures. I think that’s enough for now for this conversation.

Conduition: Yes, and the fact that CISA exists is really awesome because Fabian’s proposal introduces a new output type by necessity. In order to institute and deploy CISA, you need a new output type, because the validation rules are changed, and that would be a hard fork if you just introduced it on P2TR. And this new output type that CISA proposes could exactly be P2TRv2. All you need to do is introduce a new leaf version that supports post-quantum signatures. I say, ‘all you need to do’, I mean there’s a lot of work that goes into that, of course, but this means that the CISA output type and the P2TRv2 output type could just be the same thing. And that provides a really cool incentive, because CISA has asymptotic efficiency, like as the number of inputs grows, of just about 1 or 2 bytes per input. And you only need a single signature for all the inputs in a given transaction, in the best case. But that is contingent on using schnorr signatures. And this is all based on discrete log, which is broken by quantum computers. And so, while CISA does incentivize people to migrate, and then everyone will be on addresses with post-quantum cryptography, we won’t be able to use CISA after Q-Day, if Q-Day happens.

Mike Schmidt: Conduition, maybe you can elaborate on where you left off there, because I’m with you that you can’t aggregate post-quantum signatures, and so there’s not a magic bullet, which I’ve always hoped for in years past, where you just, “Oh, these signatures are large, but you can aggregate them, right?” So, we can’t do that. So, what you’re saying is we have a P2TRv2 that is CISA-enabled, which would help with what, even if it’s not helping with post-quantum?

Conduition: Sorry, I should clarify. Because CISA is so efficient, people who may not care at all about quantum cryptography could migrate to it and would have incentive to migrate to it to save money. And that would put more people onto addresses and wallets that use a hidden post-quantum fallback leaf in their P2TRv2 script tree. And so, if the soft fork that disables keyspending is deployed in time, then all those people who migrated will be safe almost by accident, because they may not have even intended to secure their funds against quantum computers, but just by following incentives, they did so. Now, Murch, I think you had your hand there?

Mark Erhardt: Yeah, so one of the ideas behind P2TRv2 was because it doesn’t give a financial incentive, the idea would be that people only switch over once they also add a post-quantum-resistant leaf in their script tree. If we now give a financial incentive to switch to P2TRv2, wouldn’t we expect that more people switch to P2TRv2 due to the financial incentive, without actually going the extra step and adding the post-quantum leaf? So, wouldn’t we set ourselves up to those people rugging themselves per this foot gun?

Conduition: That is possible. However, every description of P2TRv2 that I’ve seen, and in this case that’s what we’re talking about, has included a contract, a sort of social agreement implicit in its use, where if you want to use this output type, you need to have a post-quantum fallback. If you don’t, you are submitting your coins for confiscation, because the part of P2TRv2 that everybody debates about so much is that eventually we have to disable the keyspend path. Otherwise, all the coins can be stolen by a quantum computer. And if you opt yourself out of that, any user can destroy their coins if they really want to, and this would be exactly that.

Mark Erhardt: Right. I think that Pieter mentioned in this context that the tripwire plays an important part in the social contract, simply because you don’t necessarily have to negotiate the soft fork to disable the EC spending, if you build it into the output type from the very beginning, to be triggered by any participant that can show the proof that an output without a keypath spend has been spent. And so, if you construct a P2TR output, you can use something called a NUMS point (nothing-up-my-sleeve). And the idea would be that there would be some such NUMS points used to create output. And if someone can prove that they used a NUMS point and their output was still spent with a keypath spend, then that would be proof that a quantum computer was used to derive the key that underlies the NUMS point, which the user of the NUMS point couldn’t have known. And thereby, quantum computers are real and the EC path is disabled.

So, having the tripwire in from the very beginning means that anyone with this proof can disable the EC path, and thereby people would be forced to have a post-quantum fallback, or they would set themselves up to be disenfranchised of their coins, even without a soft fork being negotiated to remove the EC signing.

Conduition: That’s exactly right. I highly recommend any interested listeners check out the mailing list thread, I believe it was called, “Giving teeth to EC disabling”, started by Pieter as well. And I think as I learn more about CISA and how it interplays with post quantum, I start to realize that this problem is really the core dependency that many other problems rely on solving, but nobody has yet fully solved it, and it’s a worthwhile debate to be to be discussing.

Mike Schmidt: Should we also talk about your contribution to the thread in terms of post-quantum SNARK aggregation?

Conduition: Yes, I’m sorry, I left off on that. So, there is a technology called Succinct Non-interactive Arguments of Knowledge (SNARK), which let you prove that you executed a certain computation on certain inputs without necessarily forcing the person verifying your proof to have all of those inputs. And one thing that you can do with a SNARK is you can take a whole bunch of, say, large hash-based post-quantum signatures, verify them all against a bunch of pubkeys on a bunch of different messages, and then produce a succinct proof that you executed that verification correctly. And this scales logarithmically with the number of signatures. So, as you get more signatures, the size of the proof kind of caps off around a few hundred kilobytes. And I’m talking strictly about post-quantum SNARKs here. There are more succinct SNARKs, but they are not strictly post-quantum. There’s also different assumptions that you can use to make the proofs smaller or faster, but I’m talking specifically about hash-based SNARKs here. And if you were to use, say, a hash-based SNARK to aggregate a whole bunch of hash-based signatures into a single proof and then attach that to a block, well now the size of any specific signature is asymptotically almost zero, which is almost the same behavior as CISA. It’s just that we have to add this big block-wide proof, which is where most of the difficulty and complexity of this approach comes from.

This isn’t new, this has been talked about before. I think Ethan Heilman proposed this, titling it BitZip, a year or two back. And this trick, I think, might be a potential way to incentivize people to migrate to post-quantum cryptography in the same manner that CISA does, but without the caveat that it becomes useless after Q-Day. It would persist after Q-Day, but still provide incentive for people to migrate, although there is a lot of complexity that comes with using SNARKs. You have to design your circuits correctly, you have to make sure your verifier is sound. There are countless examples of SNARK proving and verification systems having soundness bugs, like for example the recent Zcash infinite money glitch that was patched. And we don’t know if anybody actually exploited it or not. We think not, but how do we know? And If we were to have that same soundness in Bitcoin using this SNARK signature aggregation system, it would mean that anyone who knows about this bug could, in theory, spend the coins of any other user, as long as they’re able to produce a valid proof.

Mike Schmidt: Is there something about this proposal that requires it to be block-wide and not transaction-wide?

Conduition: Good question. The main constraint is the size. Unlike CISA, which has aggregated signatures of about 64 bytes, you need hundreds of kilobytes.

Mike Schmidt: They’re coming for you, Conduition!

Mark Erhardt: Sounds like New York singing you the song of its people!

Conduition: Yeah! You need proof sizes, and because the proof sizes are so big, if you aggregated these signatures on a per-transaction basis, you could only fit maybe, at most, 8 to 10 of these signatures. I say, ‘signatures’, they would actually be aggregated proofs, into a block. And this is the real rub is that in order to deploy this, you need some mechanism for miners to either produce these proofs themselves in a reasonable amount of time before they start mining on a block template because remember, this is essentially a witness which means it needs to be included in the witness commitment in the coinbase transaction, which means that the miners have to produce it before they start mining. And then, every time they want to change their block template, they change the different set of transactions that are in the block, they have to redo this whole proof. And creating a proof like this is expensive.

Layered quantum recovery of hashed addresses

Mike Schmidt: Seems like we’ll probably be talking about these kind of ideas further into the future as well, but I appreciate you sort of going on a tangent with us in this particular discussion. I think maybe in the interest of time, we can move to the next quantum-related item, Conduition, that you participated in titled, “Layered quantum recovery of hashed addresses”. And this was a post, I think, on the mailing list and also Delving by Shinobi. And maybe, Conduition, I’ll let you frame this one up for the audience. What’s Shinobi getting at here? What’s the story?

Conduition: Yeah, so this is a post about recovery protocols. So, for those not familiar, a recovery protocol is a way of rescuing legacy pre-quantum coins after Q-Day without any action from the user. This has a few caveats. This isn’t possible for every UTXO. Only certain UTXOs can do this, and it relies on what I call knowledge asymmetries. The idea of a knowledge asymmetry is that in the toolchain of Bitcoin, there’s many different ways of deriving addresses. For example, you might have a public key that you hash; or you might have a script that you hash; you might use BIP32 to derive your secret key, which then turns into a public key which you hash. There’s a lot of different computational pipelines that all end up in a Bitcoin output. And some of those are actually quantum-hard relations. By which I mean If you give the quantum adversary your address, they might not necessarily be able to invert your address into a witness to that relation.

So, for example, a hashed address is a very simple example of a knowledge asymmetry. Provided that you’ve never exposed your public key, the quantum computer can’t invert a hash function and find your public key. However, if you’d exposed your public key before, there still are potential knowledge asymmetries, because that key was most likely derived via BIP32. Specifically, BIP32-hardened derivation is a quantum-hard relation, because even if you’re given the public key and the quantum computer inverts it to get the secret key, you can’t invert the hash function used by BIP32 to derive that secret key. And rescue protocols make use of these knowledge asymmetries. And what Shinobi is saying is that by layering different knowledge asymmetries, we can get more complete coverage of the UTXO set after Q-Day, because most likely, when Q-Day rolls around, not everyone will have migrated to P2MR or P2TRv2, or whatever new output type is deployed. And so, in order to prevent either mass theft or mass confiscation, we can deploy rescue protocols, which would let people rescue their coins using these knowledge asymmetries that are kind of baked into the UTXO set, not via consensus, but just via the toolchains that have been standardized around Bitcoin.

My response to his initial post was that he had some claims that weren’t exactly correct. He claimed that P2TR was not rescuable. It is. There is a neat little thing in taproot, where every output is supposed to commit to a script or an empty script tree, even if it doesn’t have any script spending conditions. And this actually constitutes a knowledge asymmetry, which you can use to rescue any taproot output. He also said that you can cover 100% of coins. And that’s also not true because there are always going to be coins that don’t have knowledge asymmetries, case in point being P2PK coins; JBOK (Just-a-Bunch-of-Keys) wallets, which were the standard before BIP32 existed; and those, if they are on an address with an exposed public key, those are also not rescuable. I tend to call these recoverable or unrecoverable coins, depending on whether they do or don’t have a knowledge asymmetry.

Mike Schmidt: Now, so the idea from Shinobi is to take some of these, and I guess we’ve covered some of these before, so like the BIP32 proofs, I think roasbeef had something, I know Tadge has done commit-reveal-related work. And so, the idea is to sort of stitch these together in what he calls this layered approach. Is that the idea that he’s come up with, or does he have additional proofs that he’s adding to this?

Conduition: No, that’s the gist of this post. He’s saying that by layering multiple knowledge asymmetries or multiple rescue protocols together, perhaps in combination with pre-registration, which is a different thing, we can achieve 100% coverage of the UTXO set, rescuing them all after Q-Day. I don’t think that’s true, because there are going to be coins that don’t move in time, don’t have knowledge asymmetries, and don’t pre-register. And I had a reply that I actually sent a week ago, but I sent it without hitting, “Reply all”, so I just posted a further reply just earlier today saying exactly this. There’s always going to be some coin that you can’t rescue.

Mike Schmidt: Conduition, you were breaking up for me. I don’t know if it’s for others as well. We may have slightly lost Conduition. There’s an interesting sort of parallel, I’d say, with some of the stuff that’s gone on with COLDCARD the last few weeks. I know some folks were trying to also determine what sort of knowledge asymmetry, or hardware asymmetry, there may be between somebody who’s cracked another user’s keys due to the bad entropy, and the person who actually had the device that generated the seed and the keys. Obviously, totally different when we’re talking about post-quantum, but I know some folks have been working on that as well in the background with the COLDCARD thing.

Conduition: Yes. I sent a reply to Shinobi a week ago, but I forgot to hit, “Reply all”. I just resent it this morning.

Mike Schmidt: What’s the gist of that?

Conduition: I was saying basically exactly the same thing that I said a minute ago, that you can’t have 100% coverage. We’re going to get the UTXO set that we’re going to get, not the one we want, on Q-Day, and we have to work with what we have. And when that comes around, we’ll have to decide what rescue protocols we want to deploy and how, because some rescue protocols will confiscate coins and others won’t. And that choice will be probably a very contentious one when the time comes.

Mike Schmidt: Indeed. Anything else on this item, Conduition?

Conduition: No, I think that’s most of it.

Mike Schmidt: All right, well, thank you for joining for these two. You’re welcome to hang on. We’ve got a bunch of other things we’re going to be talking about, but we understand if you have other things you’re working on and need to drop.

Conduition: Thanks. Yes, I’ve actually got some stuff I’ve got to do today. But it’s been a pleasure, and thank you all, guys.

Mike Schmidt: Thanks, Conduition. Cheers.

Conduition: Bye.

Draft BIP for stale tip relay

Mike Schmidt: We’re going to jump up to the News item. We had one item this week, and Ram has joined us to discuss this, titled, “Draft BIP for stale tip relay”. Maybe we can start with the basics. Ram, what is a stale tip and why would we want to be relaying them?

Ram: Sure. I’ll probably start with that maybe what a stale block is. Maybe from there, we can probably understand why we’re relaying only the tip. Yeah, a stale block is basically a valid block that is no longer part of the active chain. So, because block propagation is not instantaneous, two miners can potentially find blocks at roughly the same time for the same block height. And different parts of the network may see different blocks first. So, there’s essentially two valid blocks at the same height. And miners can only pick one to mine on top of, and the other block, which the miners didn’t get to pick, effectively becomes stale. And just to clarify, this is not to be confused with an orphan block or an invalid block. And that’s what a stale block is. Currently we see around, like, 1 stale block every 1,000, 1,500 blocks. And the idea of this proposal is not new. It’s come up in earlier community discussions, including comments from Greg Maxwell, Antoine Poinsot, when they were discussing selfish mining and correlation to stale rates. Why release stale blocks? Was that the follow up question?

Mike Schmidt: Yes.

Ram: Yeah. So, at a high level, yeah, this proposal basically introduces an opt-in P2P message for relaying recent stale chain tips. When I say tips, a stale branch can contain more than one block. So, for more pedantic reasons, it’s called tips, because we are relaying only the tips and not the entire block. And we relay headers and stuff instead of the full block. Coming back to the point, “Why relay?” the main reason is observability. Stale rate has direct correlation to block propagation. As a community, we’ve done enormous efforts in reducing the block propagation time with efforts like compact block relay, FIBRE, and the main reason block propagation needs to be short is it keeps mining more decentralized, it keeps mining more like a lottery and less like a race; and increase in block propagation can lead to more miner centralization naturally.

So, stale rate is mostly like a proxy to measure block propagation time, and the frequency and the shape of the stale branches can tell us something about the health of the network. For example, increase could point in slower block propagation times, or there are any validation bottlenecks or any regressions that we introduced in the software. It could also indicate if the network healed from a partition, or if miners are doing any adversarial mining strategies like selfish mining. Famously or infamously, there are certain mining pools who are trending near the threshold to actually successfully perform selfish mining. So, it’s purely for observability. Measuring stale rate actually does not detect that such an activity is being performed, but it can help us investigate what’s going on in the network. An added side benefit is – sorry, Murch, you had a question?

Mark Erhardt: No, just tell us about your added side benefit first.

Ram: Yeah, I was about to get to that. The added side benefit is if the chain undergoes a reorg, your stale block is already downloaded. So, it’s just the reorg can be done faster. You have the block already downloaded and validated. So, if the stale block happens to become an active part of the active chain, the reorg can be done faster as well. So, that’s an added side benefit.

Mark Erhardt: Sorry, could you clarify? You said that only the tip is relayed and you talked about headers being relayed, but now you’re saying that the block is already downloaded. So, do you mean that the entire block is propagated or just the header?

Ram: The staletip message contains a known fork point that the receiver knows already and the headers leading up to the tip. So, when the receiver gets that, they would try to construct the branch, and using the headers, they would request for the entire block details.

Mark Erhardt: I see. So, I was wondering, one of the concerns maybe with propagating more data is that there is a DoS vulnerability. Would you like to get into why propagating block headers of valid blocks is not a DoS vulnerability?

Ram: Yeah, on mainnet, creating a valid header near the tip requires real PoW to be done, so that prevents spam. A malicious actor or malicious peer may not give you invalid stale tips. Hopefully, that answers your question. But one thing it does not prevent is, like, an attacker repeatedly sending invalid or replayed messages. In such an event, I think the implementation has to apply peer-specific limits or global rate limits.

Mark Erhardt: Well, we already have protections against invalid messages. I think we disconnect peers that send us invalid messages.

Mike Schmidt: So, Ram, there is some slight behavior change beyond just relaying this message, right? You mentioned the side benefit, actually having that block and doing some behavior, the node is changed other than some relaying of that observability, okay.

Ram: Yeah. Fabian?

Fabian Jahr: Yeah. I was curious about your choice for using BIP434 for signaling this, because I think since this is an opt-in feature for monitoring, basically, I would expect that not a lot of nodes enable this. So, it would be interesting probably for the nodes to discover each other and connect, because if a node has a stable block, but then it doesn’t have any other peers that have this feature enabled, then maybe they cannot relay it. I was just curious about your rationale for this.

Ram: Are you suggesting using something where it’s discoverable in the gossip network that a node is capable of this feature before connecting?

Fabian Jahr: Yes, exactly.

Ram: I think since this was an optional feature, we decided to use 434 mainly because this is an optional feature and it’s not something of that interest. So, maybe that’s something we can follow up in the discussion actually, yeah.

Mark Erhardt: Yeah, it might make sense to explore whether it should be a service BIP.

Ram: Yeah, that was considered. But I believe because 434 is a good way to actually negotiate optional features, I think that’s what it was intentioned for, this seemed like a perfect fit for 434. But if the community feels there’s more interest in getting to know about nodes that advertise stale tips, we can potentially move to a service BIP.

Mark Erhardt: Yeah, I think we can follow up offline.

Ram: That’s a good question, Fabian, thanks. I’ll keep an eye on it.

Mike Schmidt: Ram, what has reception been to the idea?

Ram: It’s been fairly quiet, mainly sort of coincided just before the COLDCARD incident, so the community has been distracted since then. But I’ve gotten one-off direct feedback from a couple of developers that they’re happy to see this effort being taken on. And one thing I should preface this was a collaborative effort between like AJ Towns, me, and another developer, called w0xlt. Feedback has been good so far.

Mike Schmidt: I would assume that the BNOC folks, who do a lot of the monitoring, would be having a strong opinion on wanting to have this information to be able to analyze the network.

Ram: Absolutely, yeah. I think getting stale tip information has required special monitoring infrastructure, and there’s not many that do it. 0xB10C has a monitor that’s a fork monitor by BitMEX. So, I know folks who are interested in P2P monitoring, I think they’ll be specifically interested in this.

Mike Schmidt: All right, Ram, anything else before we wrap up this item?

Ram: No, that’s all I have. Thank you so much for having me.

Mike Schmidt: If listeners are curious, obviously check out the draft and comment accordingly. Ram, we appreciate your time. Thanks for joining us.

Ram: Thanks so much.

CISA for taproot keypath spends (BIP460)

Mike Schmidt: We’ll jump back to the Changing consensus segment for, “CISA for taproot keypath spends (BIP460)”. Fabian, we had you on a few weeks back to talk about BIP459. Now, we’ve got 460. I think back in 459, you were careful to say that signature aggregation is separate from the actual consensus change, right, how you might do the aggregation? And so, maybe as a way to introduce 460, we can maybe just quickly summarize 459, and I don’t remember the BIP that came out last year for halfagg. But maybe you can sort of tie it all together and distinguish CISA from the other two components?

Fabian Jahr: Yeah, the BIP editor has been nice enough to reserve numbers so we have consecutive numbers. It’s 458, 459, and 460. So, good to remember. So, the signature-aggregation algorithms that we have are distinctive in the sense that 458, we use half aggregation, which is done on existing schnorr signatures, so BIP340 signatures. And these are aggregated in a process where the result is roughly half the size of the list of the signatures. And this process is non-interactive. And then, in contrast to that with 459, it’s an interactive process where a fully-aggregated signature is created, which has constant size of 64 bytes, so the same size of a single signature, independent of how many participants are in that process and how many signatures would have existed, or how many messages are being signed. So, the key distinction that I also didn’t make clear enough in the BIP initially, but that we improved on now, is that for the 459, there’s no BIP340 signatures existing beforehand. They never exist. They basically could exist in theory, but this aggregate signatures is created in this interactive process. And so, these are the two choices that basically are available with BIP460.

Mike Schmidt: You mentioned those two choices, and then there’s an explicit opt-out, right? So, if you use the new witness version, you could also choose to not use either aggregation scheme?

Fabian Jahr: Right, there’s an explicit opt-out that’s primarily because of adaptor signatures, which is basically a way to hide information within a signature. And there are a couple of protocols that were built on top of that, where adoption doesn’t seem to be huge, but it’s not clear. I mean, it’s a nice privacy feature, so maybe we don’t know about the usage patterns. And so, yeah, this is definitely a feature that people would like to preserve. If it’s not being used now heavily, maybe potentially in the future it’s going to be used more. And so, yeah, that’s why we want to have a way to opt out to make sure that on consensus level, a certain signature can be preserved if we want to.

Mark Erhardt: Could you maybe mention how the opt-out works?

Fabian Jahr: Yeah, so there’s a marker byte, and that basically tells you explicitly what the inputs are using. So, for half aggregation, for full aggregation, and for opt-out, there’s a specific marker byte that marks each of these cases.

Mark Erhardt: Isn’t that a privacy leak then, indicating which inputs are using adaptor signatures potentially?

Fabian Jahr: Sure, this is one issue with the proposal, I would say, or I’m not sure if it’s really an issue. If you were to construct very unique ways of constructing a transaction with a combination, for example, of half aggregation, full aggregation, and opted-out inputs, then yeah, this looks very unique and would be a very easy fingerprint to do. And so, yeah, the question is, is that really a problem? Does that prevent potential future uses of protocols in that way? I’m not sure. I think for the DLC use case, for example, that’s I think the biggest use case that I’m aware of for this kind of protocol. The information is usually out there anyway, what the signature is. I’m not an expert on it, but at least as far as I know. So, that potentially would be an example of an adaptor signature where it’s fine that people know that it’s an adaptor signature.

Mike Schmidt: I think we kind of jumped into some of the mechanics here, and maybe, given some of the discussions we’ve had over the years, it’s obvious to people. But maybe, Fabian, you can articulate for the audience why this is valuable, and what are the benefits to Bitcoin and Bitcoin users of doing these types of aggregation?

Fabian Jahr: Yeah, so the types of transactions that really profit from this are transactions that have a lot of inputs. And with each input so far, we typically associate a signature. And when we can reduce the size of the signatures and aggregate them together, then we can save space. And space on the blockchain translates to costs, so we can save a lot of fees with this as well. And so, the first kind of transaction that really comes to mind, where there’s a lot of inputs, would be maybe a consolidation transaction from big businesses. So, these are a very easy win. They can save a lot of money when they consolidate their UTXOs and incentivize further that the UTXO set shrinks. But I think the use case that more listeners of the podcast probably will get excited about is that this also incentivizes usage of coinjoins and payjoins. These types of transactions also usually have a quite high number of inputs. Best practice, of course, you want to have a high anonymity set. And so then, these kinds of transactions can be cheaper than they are currently. And when you use it correctly, when there’s wide adoption, they can potentially even be cheaper than just doing your own transactions in the usual way. So, this is kind of the blockbuster feature, that it makes privacy-preserving usage of the Bitcoin protocol a lot cheaper.

Mike Schmidt: Maybe we could talk to some of the feedback that you’ve received. Can you comment on Adam Gibson’s (waxwing), I guess, questioning of the single-group-per-scheme limit and how you’re thinking about that?

Fabian Jahr: Yeah. I think this is probably the most interesting question about the BIP right now for me, because it’s the big question where I’m flexible to change my mind based on feedback from reviewers. So, right now, what the BIP prescribes is basically you can have one half-aggregation group, so one bucket basically where signatures are put into it and then aggregated into one half-aggregated signature; you can have one full-aggregation bucket, where a bunch of potential signatures are aggregated into one full-aggregated signature; and you can have as many as you want of these opt-outs. But you cannot have two full-aggregated signatures, for example, two full-aggregated groups. And so, waxwing’s question was, “Why not have this as well?” And my answer to it is basically that I don’t really see a good use case for it. For half aggregation, it doesn’t make sense anyway, because since it’s non-interactive; you could just do it anyway. There’s no reason not to do it, basically. Two buckets really don’t make any sense. But with full aggregation, it could maybe make sense, but I don’t think anyone really has come up with a good use case for this. Murch, do you have a comment?

Mark Erhardt: Yeah, I mean if you’re building a transaction with multiple users, so maybe the idea would be that you have two groups of people that want to build a transaction together, and each of the groups wants to aggregate their transactions together and then add them to one transaction. So, a second signature versus just one signature is just 64 bytes’ difference. If there’s a lot of inputs for both of these, they could just make their own transactions in the first place. And otherwise, they’re already collaborating to create a PSBT, sending that around, adding the signatures, finalizing together. So, why wouldn’t they be able to also aggregate the signatures together into a single group? So, I think I haven’t thought that deeply about it, but I’m not sure I see why having two groups would make more sense, if you’re already collaborating to create a transaction together.

Fabian Jahr: Yeah. The only fun part about it, we were musing about this a bit on the mailing list, is that if you would have multiple fully-aggregated groups, then you could half aggregate the signatures of these again, probably; there’s no proof for that. But yeah, I think we want to keep complexity, of course, low. This is already a complicated enough proposal. So, unless somebody has a really good idea of how this could be used, then we should probably rather leave it at that. But going away from complexity, there’s basically the other side that I want to talk about as well, which wasn’t on the mailing list, I think, but I received this feedback in another venue as well. So, there’s also a potential idea to step in the other direction and go simpler than the proposal is currently. And that would be to say, “Okay, we can only either have a full aggregation of the full transaction of all the inputs that are here; or we can have one half aggregation of all of the signatures or inputs that are in here; or nothing, basically, full-opt out, basically”, and that would allow us to save these markers. But we would then basically have no flexibility.

So, in this case, early on when I had the first draft of this BIP, I asked around for some feedback on the value of this kind of flexibility. And people generally said that they would like to have this flexibility for potential more interesting use cases. However, if people strongly advocate for the even simpler version, then I would be very happy to consider it, because for the blockbuster use cases that are just laid out for these consolidation transactions and for payjoin, coinjoin, at least in the plain way that you can imagine, these work as well.

Mike Schmidt: Fabian, I think when people hear, “Draft BIP”, they’re thinking of reading the text on the PR, but there’s other work that you’ve done as part of the PR. Can you talk about secp256k1 lab and what’s in there, and maybe also what other development has been going on around this proposal?

Fabian Jahr: Yeah, I mean personally, I just always feel a lot more secure to look at code than to look at prose text. That just gives me security to see that actually works, what I’m thinking about. So, pretty early on, I started to implement stuff. There was already a half-aggregation PR to secp ZKP pretty early on, which was built by somebody working for Blockstream temporarily. And I ported this to secp and I maintain this PR. There’s a full-aggregation PR to the secp repository, which I have built, which is implementing the DahLIAS protocol. And then, I don’t think I’ve actually opened the PR yet, but there’s a draft branch for the implementation of the CISA transaction-wide proposal in Bitcoin Core. And you mentioned secp lab. So, I haven’t really done anything directly within secp lab, but I’ve used secp lab basically as the dependency to then build on top of the reference implementations in Python, within each of the BIPs. So, that’s a nice way to make it simpler, kind of has turned out to be the standard of similar BIPs in the recent past. And so, I had the initial Python implementations standalone, but then basically put all of them on top of that. And the CISA transaction-wide implementation then pulls in each of these implementations and then builds on top of that.

Mike Schmidt: Excellent. Yeah, I wanted to bring that up because I think listeners may be interested in the BIP text, but there’s also functioning code that potentially listeners would want to play with or do something different with. And so, yeah, I guess call to action for people to jump into that as well. Fabian, anything else you’d say as we wrap up this item?

Fabian Jahr: No. Just very happy to receive further feedback. I know other things have been on people’s minds in the last two weeks, but I’m also very happy. It already came up here earlier in the call. I initially actually thought that when I finally go out and talk about this more publicly, that post-quantum people would but just tell me that I’m an idiot to still work on this obsolete technology. But actually, as Conduition has also said, there’s potentially even ways to potentially have them work together and actually make each other stronger, which is very interesting. And I personally haven’t really spent that much time on post-quantum stuff, I just followed it from the sidelines, but that wasn’t fully possible all the time. But yeah, I’m going to look into this further in the future and explore as well the ideas that we discussed already.

Mark Erhardt: I think there is an interesting synergy there with potentially creating a financial incentive for post-quantum adoption. And since the scriptpath is already excluded from the aggregation anyway, it doesn’t really matter much if there’s post-quantum leaves or EC leaves in the script tree. So, yeah, I hadn’t considered that, but that’s actually an interesting, nice little synergy.

Fabian Jahr: Yeah, I agree.

Mike Schmidt: Fabian, thanks for your time, thanks for your work on these proposals. If you have other things you’re working on, you’re free to drop, but we appreciate your time.

Fabian Jahr: Thanks for having me.

Segwit commitment to post-quantum witness data

Mike Schmidt: Cheers. Next item from our Changing consensus segment titled, “Segwit commitment to post-quantum witness data”. This was, I believe, a Pieter Wuille post as well, and maybe we’ll set the stage here. We don’t have a guest for this one, but we talked about how post-quantum signatures are of larger size, even though there’s been a lot of research to decrease those. And if Bitcoin were to adopt those signatures, they’ll need to live somewhere inside the transactions. And I guess maybe the obvious answer might be to put on a second witness area, the way that segwit added the first one many years ago. But there’s some overhead that Pieter brought up in terms of costs to the community, in terms of being able to deploy that. And I think it really focuses around potentially having a third transaction identifier. So, we have txids, segwit, then you have witness, your wtxids, you have new coinbase commitments, all kinds of things that change in the mining software, P2P logic. And so, juggling a third ID then for every transaction I think is, in Pieter’s mind, a little bit prohibitive or a challenge that should be worth putting some time towards eliminating. Maybe I’ll pause there. Murch?

Mark Erhardt: Yeah, it would just be a lot of extra work. And so, from my superficial understanding of this proposal, just adding the commitment to the witness data instead of committing at the non-witness level to the quantum section, would allow the wtxid to cover the additional data. And that way, we wouldn’t need all of that overhead. We could still continue to do P2P transaction traffic based on wtxids, the witness commitment would still suffice. So, we would still have a new section for the quantum data, but it would be committed to in the witness data. And that way, it would be easier and maybe less work to roll out. I didn’t anticipate it, because Pieter had been saying for a few years that he was going to let other people have their turn with proposing protocol changes and working on it, but I’m pretty happy that Pieter has recently picked up an interest on the whole quantum topic, because he brings a lot of experience to the design of such proposals.

Mike Schmidt: Well, I think he just said it was a shower thought or something. So, yeah, he’s still not involved, he’s just having a shower thought, that’s all. Maybe to elaborate slightly, I think what he’s talking about here, instead of having this new txid, he’s having this idea of styles where style 0 would be today’s segwit, and then style 1 in this brainstorm would be post-quantum data; and then, in theory, you would have more styles, values 2 and above, for future usage. And then there was a note that nodes that don’t understand a certain style could be shown the valid style 0 commitment instead, so un-upgraded nodes can continue to keep working. There was some feedback here from AJ Towns comparing the different styles to distinct authorization weight formulas. And then he also suggested annex-based commitments potentially as well and some potential advantages there.

Mark Erhardt: Yeah, so one of the points is that if we had humongous quantum signatures, we might be interested in having a different discount for the quantum section. Because let’s face it, currently our signatures take 64 bytes, but they only weigh 16 vbytes. And if we moved to a scheme that had maybe 3,000 bytes of signatures and 2,000 bytes of public keys or similar, with 5,000 bytes per input, we would drastically reduce the throughput on the Bitcoin Network. Now, currently, blockspace is a little under-demanded maybe, with feerates being around a 0.25 sat/vB (satoshis per vbyte). But if the quantum data were that expensive and quantum inputs introduced such large outputs, I think we might overshoot, and blockspace demand would go through the roof, or feerates would go through the roof as the blockspace market would be much more competitive.

Mike Schmidt: Yeah, so I think, yeah, maybe to wrap up and riff off of what Murch just said, so what Pieter’s saying, this idea of a style and the approach to doing this is still going to require a soft fork. And you’re still going to have the storage question, like Murch mentioned. You’re still going to have P2P upgrades as part of something like this. But the win that he is getting at is to avoid this new transaction identifier, which has the invasive parts that we mentioned earlier in the discussion. Anything else on this one, Murch or Gustavo? Okay.

Input-triggered transaction expiry

Mike Schmidt: “Input triggered transaction expiry”. Murch, you have a bit of a lead.

Mark Erhardt: Well, so my understanding is that the problem that leads to this proposal is if you have transactions that expire, you could use this expiration to freely relay data across the network. And then, before the transaction actually is eligible or interesting to include in blocks, it would expire and not be allowed; or it would be a free relay vector. So, this proposal is trying to introduce an expiration for transactions that is based on when the parent transaction confirmed, so there would always be some cost to the user of this transaction. And that was roughly what I took out of it.

Mike Schmidt: Murch, the cost being the parent transaction confirming, and thus the fees paid, as opposed to just relaying transactions that don’t have a related parent that is confirmed? Is that the idea?

Mark Erhardt: Yeah, maybe. Honestly, I struggled a bit with this item. Generally, there was a lot of pushback against expire opcodes because of (a) the free relay problem, and (b) it could introduce some hard-to-analyze game theory around juicy transactions being about to expire, and people maybe reorging in order to mine a block that could include a transaction that just expired. Generally, the only form of expiration we have so far is by creating a conflicting transaction that spends one of the inputs, which makes the expiring transaction invalid instead. And yeah, I stared at this one a bit, but this is the best I have for explaining what’s going on here.

Mike Schmidt: I don’t have the newsletter number or podcast number handy, but we did have similar proposals, absolute expiry proposals, like Peter Todd’s OP_EXPIRE, that would make a valid transaction later invalid. You still have the cheap relay of potentially spam, unless policy demands were nearing next block fees. There was some consideration around that when we spoke about that one. Murch, why do we want to have a transaction that expires again, at all? Why are these efforts being put forth at all? What’s the use case?

Mark Erhardt: I guess you kind of want to have the option of things only becoming invalid after some time in order to do transactions that have options such as HTLCs (Hash Time Locked Contracts), where as long as a hash is provided, you can spend it immediately, but after some time, there’s a fallback. If the payment on the LN, or otherwise, doesn’t go through, eventually the sender gets back their money, right? So, similarly with escrows or channel opens or other UTXO-sharing mechanisms, you want to be able to have a transaction where you commit to something happening, but have a way to back out if the other person just drops off the face of the earth. And an expire construction could sort of bring the other side of this, where you explicitly say, “I’m happy to do this, but only to that point. Once that block passes, I’m no longer in on this. You have until then to decide”, or something like that, maybe to give a limited time option for something. But we sort of can, in a roundabout way, do these things already by having the backout transaction be an explicit thing that conflicts and eliminates the first option. There are just some weird dynamics around having the expiration with free relay and potentially weird game theory.

Segregated Data (SegData) BIP draft

Mike Schmidt: I think we can wrap up that item. We’ll move to the last Changing consensus item this week/month, “Segregated data (SegData) BIP draft”. Obviously, we’ve talked a lot as a Bitcoin community over the last few years about people stuffing arbitrary data into the Bitcoin blockchain using a variety of mechanisms, OP_RETURN, witness data, it’s sort of a perennial controversy. This item was from MrHash, who I believe posted to Delving Bitcoin, a soft fork draft, and he took a different angle on this. He says instead of fighting the data we give it, I think people have talked in the past about it, dedicated garbage can being OP_RETURN. Maybe this is a dedicated attic to put this arbitrary data in. So, this would be a separate and prunable part of a block designated for data. And the confusion on my side is what the incentive is to keep it if you’re able to prune it. Murch, I know you brought up some questions on this.

Mark Erhardt: Yeah, let me try to steelman it a little more first. So, the general idea is we know that people will always be able to insert data, because Bitcoin transactions are based on script. Programming languages always have nooks and crannies where you can stuff data in. So, the idea would be if we explicitly create the space where people can put data, they don’t have to play games with it, they just put the data there. And the adoption incentive would be that it would be slightly cheaper than currently-established mechanisms, such as witness data stuffing. So, with the inscription envelope, of course, you have to have the output that commits to the data in the first place. Then, you have an input that fulfills the output commitment and then has an inscription envelope, for example, where it has the data. So, you have the overhead of the additional output and input, and that is slightly inefficient. And then, the inscription data itself is, I think, cut into pieces with OP_PUSHes. So, by having just an OP_DATA_OUTPUT, or whatever it would be called exactly, you would be able to directly write to witness data, or to a section of data that is discounted exactly like witness data by a factor 4. But you would lose the overhead of having an output that commits to it and an input that publishes it, but would just directly commit with an output to, “Here’s a SegData section and you can write whatever data there”.

Now, the way to limit it would be that the SegData counts towards the block weight limit, but on the other hand is not evaluated, because it’s just a blob, so there’s no signatures in it, there’s no validation beyond just a hash that the blob hashes to a specific commitment in the output. But it would count towards the weight limit, which means that these people would pay fees for the blob and would compete for block space for the blob, and thereby be limited in how much data blob they can insert into blocks. The initial construction was proposing that for 100 or 1,000 blocks from the chain tip, every node is required to have the blob data and serve it. And then, once the block falls out of the window at the chain tip, peers or nodes catching up with IBD (Initial Block Download) wouldn’t need to have the blob data, and thereby it would become automatically prunable after that depth. I don’t remember if it was 100 or 1,000 blocks.

Some of the people that responded to this idea pointed out that if eventually it is not required by consensus, it is de facto not required by consensus, because implementers could just choose to ignore it from the get-go. And the proposal was then amended to make the data optional in the first place. So, it would still count towards weight and the nodes that implement this optional data check would check that the data is not too big, or otherwise not accept the transactions. But yeah, so I think the main doubt of reviewers here was if the data is optional, and generally data-embedding doesn’t seem to be super-popular among the Bitcoin ecosystem, except in some NFT-pushing subsegment, would there even be enough nodes that serve this data? Otherwise, why wouldn’t the people that want to embed data into the blockchain just embed it in the witness for a tiny extra cost, and then get full data availability?

Yeah, that’s, I think, roughly where people are hung up on. It’s like, sure, it’s just a tiny, little bit cheaper and it’s sort of the blessed harm reduction. But if the data is not available and it doesn’t actually fulfill the want of the data-embedders, then why would they ever decide to use it? And is that then worth the effort of making a soft fork? Yeah. Any more questions, comments? Or I think otherwise, I think that’s pretty much where the discussion was left off.

Mike Schmidt: Yeah, I think listeners can jump into the thread. I think there was quite a bit of back and forth. I think Murch summarized the takeaways from that back and forth nicely. But if folks are curious about the proposal, jump into that Delving thread and check the back and forth on the comments. That wraps up our Changing consensus segment. We’ll move to Releases and release candidates. We have one this week. I already somewhat spoiled it, but I won’t spoil it further. What do we have, Gustavo?

Gustavo Flores Echaiz: Can you guys hear me well?

Mike Schmidt: Yeah.

Libsecp256k1 0.8.0

Gustavo Flores Echaiz: Perfect. Yes, this week we have one release, libsecp256k1 0.8.0. So, here, we add the new model for silent payments that we discussed, I believe, two episodes ago. That is the main component of this release. But also, a few newsletters ago, precisely in Newsletter #396, we talked about a new API function that allows a user to supply a custom SHA256 compression function at runtime. So, that is also part of this release. And additional optimizations, 64-bit field arithmetic that is improved, that produces signature verification speedups of up to 11% in some builds.

So, also, what I wanted to point at is that we didn’t include it in newsletter, but an important maintenance release from BTCPay Server was announced the day we drafted this newsletter. So, users of BTCPay Server are advised to update to 2.42, particularly if you use LND, because the vulnerability affects LND users within BTCPay Server. So, if anybody’s listening that uses BTCPay Server, please update immediately, particularly if you use LND. Also, I believe that if upgrading is not sufficient, you should also be reviewing your macaroon files, which are the credentials for accessing your LND node, since that vulnerability was around an attacker being able to obtain those credentials in an unauthenticated and unauthorized way. So, you should also consider swapping those credentials in case they were ever obtained by an attacker. Yes, Mike?

Mike Schmidt: I’m giving you the thumbs up.

Gustavo Flores Echaiz: So, we move forward with the next section, Notable code and documentation changes. We’ve got a lot of bug fixes this week. It seems to be that we’re going to have a few weeks like that, considering all the new vulnerabilities that are being exposed.

Bitcoin Core #35501

The first one, Bitcoin Core #35501, isn’t a bug fix. This is a new feature that basically allows the Bitcoin Core wallet to store multiple variants of the same transaction that have the same txid but have different wtxids. So, here, previously the wallet would simply ignore any transaction that had the same txid as one that was already stored, even if it had a different wtxid. The main goal here is to be able to have multiple variants of the same transaction in order to compare them related to if we were going to replace a transaction through, like, a fee bump through RBF, we could look at all the variants of the transaction and choose the one that would have the lowest weight, and that would be the one to get fee bumped. That was one of the motivations. But, Murch, please jump here?

Mark Erhardt: Yeah. How could you ever have a fee bump with a transaction where the txid doesn’t change? I wanted to dig a little bit here. So, imagine you had multiple different ways of spending a P2TR output. For example, you could have a scriptpath output that is a 2-of-3 multisig, which is maybe a little more sizable. But then, after the two participants that can sign for the 2-of-3 multisig sign for that transaction input, the third party comes online and you manage to instead make a keypath spend that uses the MuSig that is stored in the keypath of all three signers. And now, you only have to pay for a keypath input instead of a scriptpath input. And you could do that without changing the txid, just changing the witness data to the single-signature instead of revealing in the input where that script leaf was, the script leaf script, and the 2-of-3 multisig construction and their signatures; you would replace all that with a single MuSig signature. So now, the transaction would have the same txid, the same inputs and outputs, the same fee paid, but the witness data would be smaller and thus the transaction might have sufficiently higher feerate to replace the original.

If that happened previously, I’m not entirely sure, I think that we did propagate transactions with different wtxids and they could replace others. But honestly, don’t nail me down on that. But now, your wallet would be able to store more than one of those in Bitcoin Core.

Gustavo Flores Echaiz: Very interesting. Thank you, Murch, for that extra detail. Well, I was wondering if there are other cases where this happens. For example, if you were to use a high-S signature versus a low-S signature, would that also produce a similar situation where the txid is the same, but the wtxid is different?

Mark Erhardt: Correct. The wtxid is malleable. I think that high-S are not consensus-valid though in segwit. But I’m happy to be corrected in the comments below!

Gustavo Flores Echaiz: Yeah, I’m pretty sure that’s the case for taproot specifically; and in segwit, they’re non-standard but they’re still consensus-valid. So, yeah, the goal of this item is now for the wallet to store all the variants. There’s still one that is chosen as canonical. It is often the one that is confirmed. But if none is confirmed, then it’s the one that contains witness data. And if multiple transactions contain witness data, then it’s the one with the lowest weight. Now, this is also exposed to several RPC commands, gettransaction, listtransactions, and listsinceblock. Those RPC commands now report these variants in a new field called alternate_wtxids.

Core Lightning #9298

So, that’s for the Bitcoin Core repo, and the next items are from Core Lightning (CLN), Eclair, LND, and Rust Bitcoin and BTCPay Server. We begin with Core Lightning #9298. This item is about the advancement to migrating to a new system called bwatch. So, bwatch is an experimental blockchain-watching plugin that moves the block polling and the transaction filtering logic out of lightningd. So, the intention here of bwatch is to move away from an implementation in lightningd that was storing unnecessarily a lot of the blockchain data that was already present in the blockchain node we connect to. Lightningd was simply replicating a lot of that data, storing unnecessarily data. Now instead, lightningd simply tells bwatch, “Can you watch these transactions for me, the scriptPubKeys, and also track these UTXOs, and bwatch will connect to the Bitcoin node and will let the lightningd know when a transaction is found that matches its requirements”. And also, this allows eventually another system could be integrated, since this is now abstracted. Bwatch is simply the first implementation of an external system that is monitoring the blockchain, but the surface could allow for another plugin to play that role instead of bwatch.

So, this PR specifically moves the wallet transaction and the UTXO tracking to this new system, by introducing new tables in bwatch, specifically our_outputs and our_txs. However, these are temporarily mirrored still to lightningd, to the legacy tables. So, for example, if you were to use bwatch and you would like to downgrade back to the previous implementation, you could easily still go back and forth, since all this data is still mirrored to the previous tables. So, this is an experimental feature that requires activation with a specific flag called -experimental-bwatch.

Core Lightning #9353

Next item, still from the CLN repo, #9353. Here, this is a bug fix where previously, sendpay, which is a CLN RPC command for sending a payment, it now returns an RPC error when the combined payload of each hop doesn’t fit the limit that is defined by BOLT4, which basically says that the combined per-hop payload cannot exceed 1,300 bytes. So, previous, it would simply return a null result, and it would later cause the daemon to crash. So now, this is just an error-handling that avoids a potential crash when the combined per-hop payload exceeds the limit that is defined by BOLT4. So, just a simple fix to ensure that the node doesn’t crash.

Eclair #3336

The next item, Eclair #3336. Here, there was an issue where if a peer or a component within the Eclair node duplicated an HTLC settlement message, and that message was added multiple times to the proposed remote commitment changes, then when exchanging commit signature messages with the peer and receiving a signature that didn’t match the remote commitment change state that we had stored that had duplicate messages, then that could lead Eclair to a potential force close of that channel, when it would basically see that there was a mismatch between the signature that it received from its peer and what it stored as remote commitment changes. So now, Eclair simply prevents that duplicate message from updating the state that it has for the remote commitment changes. So, later on, when it exchanges signatures with the peer, there’s no mismatch that was caused from that duplicate message, and then there’s also no force close of that channel. So, here, once again, a small technicality that would lead to an issue. And now, that is fixed to avoid Eclair unnecessarily force closing a channel.

LND #10942

The next item, LND #10942. Here, this is a new feature that LND didn’t have, which is when forwarding an HTLC on specifically a blinded payment path, the encrypted recipient data can identify the next hop using its node ID or its SCID. When forwarding an HTLC on a blind payment path, LND was always expecting that the recipient data would identify the next hop through the SCID. However, CLN uses the next_node_id format, which basically would let a node know, “Hey, this is the node ID”, and the node, LND for example, has to choose a specific channel to forward the HTLC from. So, this is simply an update in the LND implementation to now accept next_node_id on top of short_channel_id. And this enables LND to be interoperable with CLN when forwarding an HTLC on a blinded payment path.

I would also like to specify that LND has implemented blinded paths for a while, but only for BOLT11 payments, and the BOLT12 implementation is right now being built. However, it’s not finalized. But this is a fix that would require once LND ships BOLT12 payments, then it will be interoperable with CLN.

LND #10992

The next item, LND #10992. Here, there’s a new limit that is added when an LND node is just syncing with the chain and sends a message called query_channel_range. This request message is sent to a peer to obtain the channel announcements and synchronize with the state of the LN. However, previously, the bound of the memory used when synchronizing these channel announcement messages was extremely big, which could cause an attacker to send to LND a huge amount of fake channel announcements that could potentially cause an LND node to run out of memory and potentially even crash. So, the attack and the issue wasn’t necessarily identified. This is more a theoretical analysis, at least it seems so from what has been disclosed so far. But now, there’s a new limit, and LND now simply accepts a maximum of 100,000 SCIDs per message, or in aggregate for a single query; it’s the same limit as well.

The reason why this amount of 100,000 was chosen is because currently, the LN has an amount of channels that is lower than that. I believe, when I last checked, it was closer to 60,000 channels. Although it has gone higher in the past, it has never surpassed 100,000. So, it is expected from the discussion in the PR that the LND maintainers would update this limit if it ever came that the LN would have a higher amount of channels than the one it is limited at now. So now, your LND node would simply not even accept a message that has more than a 100 SCIDs in a single.

Rust Bitcoin #6364

Next item, now we get to the Rust Bitcoin repo. So, the first item, #6364, this is a new feature that is added to Rust Bitcoin, where support for encoding and decoding BIP434 messages is now implemented. So, BIP434, as we’ve discussed in Newsletter #386 and #390, is a protocol that defines a specific P2P message, called feature, that allows peers to announce and negotiate supports for new features. So, Rust Bitcoin simply implements the basic message infrastructure, the wiring required for implementing BIP434. Compared to Bitcoin Core’s implementation, this is simply the first phase of that implementation. Bitcoin Core also implemented the negotiation mechanism, where feature has to be sent between version and verack. So, however, in the Rust Bitcoin case, only the encoding and decoding support for this type of message is implemented. And I believe because Rust Bitcoin is simply a library and not specifically a node implementation, that is also part of the reasoning why it has only implemented this level of support.

Rust Bitcoin #6642

Next item, still on the Rust Bitcoin repo, #6642. Here, another bug fix. So, Rust Bitcoin has a specific limit to each transaction witness element, and it caps that limit at 4 MB. That limit, of course, is derived from the fact that a Bitcoin block can never be bigger than 4 MB if it had a four-million-weight-unit block limit. However, Rust Bitcoin will, of course, never accept in the end the witness element that is 4 MB, because there are other rules that cap the transaction size and even the witness element size. But when receiving a transaction from a peer or from an external source, Rust Bitcoin will first run a check that each witness element cannot be bigger than 4 MB. However, when decoding a transaction, the bug was that the limit was only applied for the first witness element. and further witness elements would reset to a default larger limit of 32 MiB. But the point is that the second and the third, and so on, witness elements would have a larger limit and, for example, they could pass higher than 4 MB. And this was still bound to the P2P message limit of 5 MB. So, it was impossible for a witness element to be higher than 5 MB because of the P2P message limit. However, the second witness element could be between 4 and almost 5 MB in size.

The problem was that if an attacker sent us a transaction with a witness element that was between 4 and 5 MB, not the first one, but the ulterior ones, they were not properly caught. And then, it would lead to an inconsistent state that could cause a panic, because some code would simply count the witness element amount, so it would say there’s four witness elements here. But because they were bursting through the expected limit of 4 MB, they were not properly rendered after being decoded. So, that could lead to a panic, and specifically it was noted that it would happen in the case of a taproot spend. So now, Rust Bitcoin simply makes sure that this 4-MB size limit is now applied at each witness element. It never gets dropped after the first element, so that later on after decoding, because it would be accepted during decoding, it wouldn’t lead to the inconsistent state that would then cause the panic. So now, during decoding, we just catch those witness elements that are higher than the limit and simply reject them before going deeper down in the process.

BTCPay Server #7491

So, now we get to the two final items of this newsletter, both from the BTCPay Server repository. So, the first one is a bug fix in the authentication system of the Greenfield API. So, it was observed that an attacker could potentially bypass the 2FA when in the authentication handler of the API, if you had set up specifically time-based one-time passwords (TOTP) for FIDO2 2FA, which is also known and referred to as passkey authentication. That was properly handled. However, an attacker could bypass the TOTP 2FA. There’s another item that I didn’t put here, but now also, basic authentication is now disabled for the first five minutes of the user account creation. So, this is in combination with this. This is item #7492, but it comes together with #7491, where #7491, like I explained, fixes the issue that you could bypass the TOTP for 2FA. But #7492 comes together with it, because it also disables basic authentication, which means email and password, by default five minutes after account creation.

BTCPay Server #7488

And the final item from the BTCPay Server repo and the final item of this list is #7488, which improves signing compatibility with the latest version of the Blockstream Jade, when used with newer HWI versions. Here, the fix is simply to add witness UTXO fields to segwit inputs when the PSBT already contains the corresponding previous transaction in non_witness_utxo. So, this resolves an issue with the Blockstream Jade specifically. And also, there’s another fix where in the user interface, a multisig transaction would appear as pending, even though it had already been properly signed and finalized by all, the signing had been finalized by all parties. So now, the fix makes it so that the signing status doesn’t become stale and properly updates when it has been properly signed. It will display as so instead of remaining pending forever. So, that’s the last item of this list and that completes the Newsletter and the episode.

Mike Schmidt: Thanks Gustavo for walking us through that and also for co-hosting, and thank you, Murch, also for co-hosting. And we want to thank Conduition, Fabian and Ram for joining us on this episode and for you all for listening. Cheers.

Bitcoin Optech Newsletter #417

2026-08-07T00:00:00+00:00

This week’s newsletter describes a draft BIP for relaying stale block tips between peers. Also included are our regular sections summarizing proposals and discussion about changing Bitcoin’s consensus rules, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

● Draft BIP for stale tip relay: Ram and w0xlt posted to the Bitcoin-Dev mailing list about the proposal for an opt-in P2P message for relaying stale tips between peers. Currently, the stale block rate is a difficult metric to monitor, since stale blocks stop propagating as soon as the winning chain is relayed. However, it is a useful signal to check the network health. Changes in the stale block rate may expose validation or relay bottlenecks, network partitions, or selfish mining behavior.

The proposed BIP defines a new message, called staletip, for announcing recent stale chain tips to peers. The message itself 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. A node should only send the message after BIP434 negotiation with its peers (see Newsletter #386).

The authors are waiting for feedback from other developers. In the meantime, a proof of concept for the proposal is already available.

Changing consensus

A monthly section summarizing proposals and discussion about changing Bitcoin’s consensus rules.

● CISA for taproot keypath spends (BIP460): Fabian Jahr posted to the Bitcoin-Dev mailing list a draft of BIP460 (BIPs #2212) for transaction-wide cross-input signature aggregation (CISA) of taproot-style keypath spends. The proposal introduces a new witness version (v2) whose keypath spends mirror BIP341 except that each input’s witness begins with a marker byte selecting half-aggregation (BIP458/BIPs #2205), full-aggregation (BIP459/BIPs #2210), or an explicit opt-out that carries a standard BIP340 schnorr signature. Half-aggregation non-interactively compresses many 64-byte signatures to 32 bytes each plus a single 32-byte aggregate part (see Newsletter #208); full-aggregation reduces them to a single 64-byte aggregate signature with interactive signing (see Newsletter #415). Scriptpath spends follow BIP341/BIP342 unchanged and are not aggregated, preserving the OP_SUCCESS upgrade path. Signatures in the proposed scheme commit to the aggregation mode so aggregation is opt-in: third parties cannot fold an opted-out signature into a half-aggregation group. Jahr notes the witness version collides with BIP360 (P2MR); reviewers (including Mark Erhardt) expect whichever proposal activates first to take the next free version.

Conduition asked how CISA dovetails with post-quantum migration: aggregation needs bare EC public keys for verification, so pairing CISA with P2TRv2 maximizes fee savings (as little as 1 witness byte per full-aggregated input) but inherits P2TRv2’s EC-disabling timing problem, whereas hashing the key (P2MR or P2TRH) costs roughly 32-65 weight units per input and weakens the savings. Jahr replied that the transaction-level marker/group framework should generalize to future aggregatable schemes and that a hash-hidden CISA variant could be specified as a separate output type sharing most of the logic. Adam Gibson (waxwing) questioned the single-group-per-scheme limit when several users each want full-aggregation of only their own inputs inside a shared transaction. Jahr replied that multiple groups remain open if reviewers see concrete use cases.
● Segwit commitment to post-quantum witness data: Pieter Wuille posted to Delving Bitcoin a design for attaching post-quantum witness data without repeating all of segwit’s deployment costs. A naive second witness area would need a new transaction identifier (pqwtxid), a coinbase commitment to those IDs, mining stack changes, and P2P logic tracking three identifiers. Wuille’s alternative commits to each input’s extended witness data from the input’s current witness, so wtxid covers the additional data. A worked-out version introduces per-input witness “styles” (0 = segwit, 1 = pqdata, 2+ for future extensions), each with its own P2P extension and weight function. Unsupported styles can be represented by a valid style-0 commitment for compatibility with unupgraded nodes. Anthony Towns compared styles to distinct authorization weight formulas, suggested annex-based commitments so locktime-like assertions remain available without the additional data, and argued that capacity reserved for post-quantum signatures should stay unusable for ordinary data so pre-Q-day blocks do not bloat toward a larger target. Wuille agreed that introducing a style is still a combined soft fork, storage, and P2P upgrade, but without a new transaction ID.
● PQC output type discussion: Pieter Wuille opened a Delving Bitcoin thread to centralize discussion of post-quantum output types. He tabulated candidates including BIP360 (P2MR), P2TRv2, P2TRH (taproot-like with a hashed output key and public-key recovery, see Newsletter #412), and P2QR (P2MR with EC opcodes disabled from the start), and variations of those. His current preference is to deploy both P2TRv2 (with tripwire/miner lockdown and a hash-based PQC opcode) for easy pre-Q-day migration that keeps today’s fee profile, and a longer-term P2MR-based type with a new witness style so EC and PQC costs can be priced independently after migration. Regtest measurements by jeanpablojp showed BIP360 spends requiring ~96 lines of consensus delta over existing taproot machinery, with a depth-1 schnorr leaf about 32 bytes lighter than the equivalent P2TR scriptpath. Conduition noted that Jahr’s CISA proposal (above) makes P2TRv2+CISA extremely attractive for voluntary migration, but raises the stakes of a later EC-disabling soft fork, and pointed to block-wide PQ-SNARK aggregation of hash-based signatures as a research path that could make post-quantum spends competitive on fees.
● Input-triggered transaction expiry: Josh Doman posted to Delving Bitcoin a construction for expiring HTLCs without free relay, then generalized it in a follow-up on input-triggered transaction expiry. Absolute expiry proposals such as Peter Todd’s OP_EXPIRE make a valid transaction later invalid, enabling cheap relay spam unless policy demands near-next-block fees. Doman’s approach instead expires a spend when the transaction creating the UTXO it’s spending was confirmed too late: if BIP68 nSequence enforces a height-based relative locktime R and bit 21 is set, the input fails validation unless nLockTime is height-based and at least the BIP68 minimum inclusion height. Because a mined parent cannot become invalid without a deep reorg, a once-valid child cannot expire under ordinary progress, eliminating free relay. Use cases include mempool-free HTLC forwarding (preimage monitoring via the chainstate rather than the local mempool, useful for low-bandwidth or Utreexo-style nodes) and pseudo contract-level relative timelocks for LN-Symmetry. Optional companion changes enforce bit 21 in OP_CSV and add a tapscript OP_LOCKTIME introspection opcode so scripts can require a maximum locktime. Anthony Towns compared the idea to coin-height introspection via OP_TX and questioned whether the 100-block minimum delay (chosen to match coinbase maturity and Todd’s proposal) is necessary; Doman later agreed that a much smaller delay may suffice and reframed the primitive as users asserting “now” (input confirmations by nLockTime) in a way that can also raise the cost of deep reorgs post-subsidy.
● Layered quantum recovery of hashed addresses: Shinobi posted to the Bitcoin-Dev mailing list and cross-posted to Delving Bitcoin a layered recovery plan for coins secured by hashed address types (P2PKH, P2SH, P2WPKH, P2WSH, and analogous constructions) if secp256k1 spending is later restricted due to the existence of a cryptographically relevant quantum computer. No single recovery mechanism covers every key-generation method: BIP32 hierarchical proofs (recently demonstrated by Osuntokun) miss non-hierarchical keys; stateful pre-deadline timestamped attestations miss inactive users; and commit-reveal migration fails when public keys are already exposed. Allowing any recovery method to authorize a spend after secp256k1 is disabled would, under the assumption that public keys and internal scriptpaths stay secret, cover essentially all hashed-address holders who still control their keys. To facilitate this in the future, Shinobi suggests wallets use new derivation paths and Electrum-style per-address balance queries to avoid leaking xpubs to service providers. Conduition reframed recovery as authenticating existing knowledge asymmetries that a quantum attacker lacks: hashed scripts and BIP32 seeds are such asymmetries. He stressed that some UTXOs (notably many early P2PK coins) have no such asymmetry, so only pre-deadline action to create one can distinguish their owners from an attacker. He also noted that taproot internal keys can serve as a knowledge asymmetry for P2TR keypath recovery, separate from the hashed-address layering.
● Segregated Data (SegData) BIP draft: MrHash posted to Delving Bitcoin companion BIP drafts for Segregated Data, a soft fork that would add a prunable, script-isolated block region for arbitrary data carriage. Entries would be committed via a coinbase merkle root (BIP141- style), counted at the witness discount, and bound to transactions by unspendable value-zero witness v2 reference outputs excluded from the UTXO set. No opcode may read entry contents, keeping entries prunable and unable to gate spends, and beyond a retention window nodes could validate from the base serialization alone. The goal is to give data that scripts need not evaluate (application blobs, attestations) a structural home so it can leave OP_RETURN and witness stuffing, without changing those existing vectors. Antoine Poinsot and Pieter Wuille argued that if full nodes need not retain the payload to accept a block, the data is not part of Bitcoin consensus in any meaningful sense and is equivalent to paying fees to inflate weight. Mark Erhardt questioned why embedders would prefer reduced availability at the same cost as witness data. After Anthony Towns described reorg risks from depth-dependent presence rules, MrHash pivoted toward consensus checking only committed weight/length with payload validation as policy. The draft remains open; witness version allocation also collides with BIP360 and BIP460 discussions above.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

● Libsecp256k1 0.8.0 is a release of this library for Bitcoin-related cryptographic operations. It adds the BIP352 silent payments module described in Newsletter #415, allows applications to provide hardware-optimized SHA256 compression implementations as described in Newsletter #396, and improves 64-bit field arithmetic, producing signature verification speedups of up to approximately 11% in some GCC and MSVC builds. It also removes the deprecated secp256k1_schnorrsig_sign and secp256k1_context_no_precomp symbols.

Notable code and documentation changes

● Bitcoin Core #35501 updates the wallet to store multiple witness variants of the same transaction. Previously, once the wallet knew a transaction with a given txid, it would generally ignore another transaction with the same txid but a different wtxid. Now, the wallet stores each variant in a separate wtxvariant database record and selects one as canonical. Preference is given to a confirmed variant, otherwise to a variant containing witness data and then to a variant with the lowest weight. The canonical variant remains in the existing tx record. The gettransaction, listtransactions, and listsinceblock RPCs now report noncanonical variants in a new alternate_wtxids field. See Newsletters #193 and #304 for previous references to transactions having the same txid but different wtxids.
● Core Lightning #9298 advances the migration to bwatch, an experimental blockchain-watching plugin intended to move block polling and transaction filtering out of lightningd. This PR moves wallet transaction and UTXO tracking to that system by adding our_outputs and our_txs tables, backfilling them from the existing wallet tables, and switching wallet reads to the new tables. With --experimental-bwatch enabled, the scriptPubKey watches detect when funds are received and the outpoint watches detect when wallet outputs are spent, including handling reorgs. Writes are temporarily mirrored to the legacy outputs and transactions tables to enable users to downgrade without needing to rescan.
● Core Lightning #9353 makes sendpay return an RPC error when the combined per-hop payload for a supplied route cannot fit in the 1,300-byte hop_payloads field of an onion packet defined by BOLT4. Previously, onion construction returned a null result that sendpay passed unchecked to the sending code, causing lightningd to crash. This issue was observed with a 25-hop route generated by a rebalancing plugin. However, the actual route limit depends on the size of the encoded payloads for each hop rather than solely on the number of hops.
● Eclair #3336 prevents duplicate HTLC settlement messages received from a peer from being added multiple times to the proposed remote commitment changes. Previously, a peer or local message queue could deliver the same update_fulfill_htlc, update_fail_htlc, or update_fail_malformed_htlc message more than once, causing Eclair to store duplicate commitment changes and potentially force close the channel when the peers later exchanged commit_sig messages.
● LND #10942 adds support for forwarding an HTLC on a blinded payment path when the encrypted recipient data identifies the next hop using next_node_id rather than short_channel_id (SCID). This issue was observed in a Core Lightning BOLT12 payment, where LND was the introduction node in the receiver’s blinded path. CLN used the BOLT4-permitted next_node_id form, but LND’s HTLC forwarding code required an SCID, resulting in the payment failing. LND now resolves the node id to one of its usable channels with that peer using its existing non-strict forwarding logic, which also supports private and alias channels.
● LND #10992 bounds the memory used when synchronizing channel announcements by limiting the number of short channel IDs (SCIDs) accepted in the BOLT7 reply_channel_range response to a query_channel_range request. Previously, compressed responses could cause LND to decode and buffer an unpredictable number of SCIDs across one or more reply_channel_range messages. Now, LND accepts a maximum of 100,000 SCIDs per message and 100,000 SCIDs in aggregate for a single query.
● Rust Bitcoin #6364 adds P2P encoding and decoding support for BIP434 feature messages (see Newsletters #386 and #390), following Bitcoin Core’s earlier implementation (see Newsletter #410). It adds protocol version 70017, the feature NetworkMessage variant, while enforcing BIP434’s size limits on feature identifiers and data. This update provides the message infrastructure, but does not implement the peer feature negotiation logic.
● Rust Bitcoin #6642 applies a 4 MB size limit to each transaction witness element. This limit is derived from BIP141’s four-million-weight-unit block limit, as a witness element larger than this size would not fit in a valid block. Previously, when decoding a transaction, Rust Bitcoin only applied the limit to the first witness element, resetting to a larger default limit of 32 MiB for subsequent elements. This could allow an oversized element to be accepted during decoding, leaving the witness in an inconsistent state that could cause a panic when later interpreted as a taproot spend. This follows earlier witness-decoding memory-allocation hardening described in Newsletter #410.
● BTCPay Server #7491 fixes a two-factor authentication (2FA) bypass in the Greenfield API authentication handler. While the authentication handler checked for FIDO2 2FA (see Newsletter #146), it did not check for time-based one-time password (TOTP) 2FA. This allowed TOTP-protected accounts to access the API without providing their 2FA. The handler now rejects this form of authentication whenever any second factor is enabled.
● BTCPay Server #7488 improves PSBT signing compatibility by adding witness_utxo to segwit inputs when the PSBT already contains the corresponding previous transaction in non_witness_utxo. This resolves an issue with signing devices such as the Blockstream Jade when used with newer HWI versions, while retaining the existing non_witness_utxo. The PR also fixes an issue with pending multisig transactions whose stored signing status became stale. BTCPay Server now recalculates their signing progress when they are loaded and marks them as Signed when enough signatures are present and the PSBT can be finalized successfully.

Bitcoin Optech Newsletter #416 Recap Podcast

2026-08-04T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Rob Hamilton, PortlandHODL, Chandra Pratap, and fabohax to discuss Newsletter #416.

The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

Download audio

Action items

● Move funds secured by COLDCARD-generated keys (1:07)

News

● Wallets generated by COLDCARD at risk of theft (2:18)
● Disclosure of two DoS vulnerabilities in Core Lightning (36:26)
● Proof of concept for a zero-knowledge proof of reserves (49:54)

Selected Q&A from Bitcoin Stack Exchange

● What is Bitcoin's objective definition of transaction neutrality? (1:03:07)
● Why does BIP110's decentralization benefit not outweigh its impact on transaction neutrality? (1:05:17)
● Why does BIP110 require a 55% signaling threshold if its nodes reject non-signaling blocks? (1:09:46)
● Why use ElligatorSwift encoding in BIP324? (1:17:12)
● Was the OP_SUCCESSx reservation in BIP342 designed with specific opcode families in mind? (1:25:36)
● What is the difference between the long-term feerate and the discard feerate? (1:29:14)
● What is the quickest method for migrating a legacy wallet to a descriptor wallet on a pruned node? (1:32:40)
● Is there historical data on orphan/stale block rates during high-fee periods? (1:36:09)

Releases and release candidates

● BTCPay Server 2.4.1 (1:41:25)
● Eclair 0.14.1 (1:42:14)

Notable code and documentation changes

● Bitcoin Core #34628 (1:44:26)
● Bitcoin Core #28463 (1:49:49)
● Bitcoin Core #32800 (1:54:18)
● Bitcoin Core #34683 (1:56:54)
● Bitcoin Core #33014 (1:58:09)
● Eclair #3325 (1:59:31)
● BOLTs #1346 (2:00:57)
● BOLTs #1344 (2:02:10)
● BOLTs #1343 (2:04:14)

Transcription

Mike Schmidt: Welcome, everyone, to Bitcoin Optech Newsletter #416 Recap. Today, we’ve got a heavy week. We’re going to talk about the action item from the newsletter around COLDCARD; we also have a News item on that, so we’ll just combine those two into one. We’re also going to be talking about some vulnerabilities in Core Lightning (CLN) that have been disclosed; and then, we have a zero-knowledge proof-of-reserves concept idea that we’ll discuss. We also have some questions from our Stack Exchange segment that we do monthly, and Notable code and documentation changes, and one Release. This week, Murch, Gustavo and I are joined by a few guests. We’ll have them introduce themselves. Rob?

Rob Hamilton: Hello. Thank you for having me.

Mike Schmidt: Portland?

PortlandHODL: Thank you for having me.

Mike Schmidt: Chand?

Mark Erhardt: Just to be clear, usually you would say who you are and what you do so people that don’t know who’s on our show know who they’re talking to!

Move funds secured by COLDCARD-generated keys

Rob Hamilton: Murch, I’m sorry, I’m a bit nervous as a long-time listener, first-time caller. I’m a bit starstruck and nervous, and I wish I was able to come on under better circumstances. But my name is Rob Hamilton, I’m the Co-founder and CEO of AnchorWatch. We offer Bitcoin custody and insurance, and recently have been focusing a lot on the fallout of the issues that we are seeing with the COLDCARD. I’m going to start with a public service announcement, that if you have bitcoin on a COLDCARD, you need to immediately work on getting the bitcoin off, especially if it is a single-signature wallet. I just want to start there. And then, in the fallout of that, I have been doing a lot of work in doing cybersecurity research within the Bitcoin open-source ecosystem.

Mark Erhardt: Splendid, thank you. Portland, let’s do you again, too!

PortlandHODL: Thank you. Sorry, same exact reasoning there. Yeah, former MARA, currently working for Rob at AnchorWatch, general Bitcoin contributor and educator on X, or formerly Twitter.

Mike Schmidt: Hax, do you want to introduce yourself?

fabohax: Yeah, hi. I’m from Brazil, working on researching BTC since late 2018, and developing currently a bunch of research on many things.

Wallets generated by COLDCARD at risk of theft

Mike Schmidt: Thank you all for joining. We’re going to jump into the Action and first News item, which are both around COLDCARD. When we published the newsletter, this was sort of a developing thing. I guess it’s still developing, but two folks who have been sort of in the middle of it and sort of helping educate people in the community have been both Rob and Portland. So maybe, Rob, how would you summarize what has happened since, I believe, Thursday?

Rob Hamilton: Certainly. There were initial speculations, I think it may have been Wednesday night, of people saying that their COLDCARD wallets that were single-signatures that had never touched the internet were having funds move. Immediately, when there were multiple credible, concerned allegations around this happening, immediately a bunch of Bitcoin security engineers across this ecosystem started immediately using the latest and greatest AI models to go exactly into the random number generation that was used within the instantiation of keys within the COLDCARD firmware. And it was immediately found that there was a one-line bug which did not invoke the actual RNG (Random Number Generator) generation that was intended, and it was using an insecure subspace of only 232 bits. And because of that, we are in a race against time right now where you have to assume that if you used a COLDCARD and you did not either roll dice to add entropy, did not add a passphrase, or did not create the seed somewhere else and put it into the COLDCARD, that your funds are currently compromised, and you need to make immediate plans to move.

Mike Schmidt: I think when we originally reported, we said, “Hey, the Mk3 is definitely vulnerable”. It looks like there’s signs that other models are also. Can you describe the nuance between them?

Rob Hamilton: I will say that that would actually be a really great thing for Portland, because he has been going deep on the issues, the differences between those firmwares and the additional entropy. There is additional entropy that is being contributed to for the Mk4, Mk5, and the Q models. And, Portland, do you want to take that?

PortlandHODL: Yeah. So basically, the entropy should have come from the True Random Number Generator (TRNG) on the STM32 in all cases. The fallback on the Mk3 devices did not have any additional reseeding, aka adding any randomness to the seed. And as such, that basically, I think, initial number is like 240. I think, Rob, you said 232. But then, you also had the Mk4, 5, and Q. Those had a slightly different path when generating the PRNG (Pseudorandom Number Generator), where it would get reseeded essentially. Same PRNG algorithm, but you’d add a little bit of randomness, 32 bits. And that did come from a TRNG. So, 232 times harder, essentially.

Rob Hamilton: Yeah. I believe from the initial COLDCARD advisory, they said that it may be 72 bits of entropy, but there’s been a lot of analysis done in the fallout of that, that actually that reseeding is not using the full entropy space. And because of that, it could be as low as 40 to 50 bits of entropy. Is that right?

PortlandHODL: Basically, and then also, the PRNG values it pulls from a couple of parts in the chip that are not as random as initially hoped. They’re different timers. It’s pretty easy to guess some of these values or ranges, the different UID, etc. As the attack continues, the attackers can optimize based on the wallets they’ve scanned and found to go like, “Okay, this is my range, it’ll keep getting more and more compressed that I need to search through”. But yeah, essentially Rob is correct that Mk3s are like, it’s gotta happen, like now or yesterday, and Mk4s, it’s still like, get your funds off of those devices to a new seed generated by not the COLDCARD with that current firmware.

Rob Hamilton: Yeah. As just an observation, someone yesterday, this would be about 18 hours ago, reached out to me saying that they had Bitcoin left on an Mk4 that had no dice rolls, no additional entropy, and they were able to recover their funds. So, there is a window right now where hackers have not brute-forced the entire search space. So, the urgency is now. There are multiple credible reports at this point that low-entropy passphrases, one or two words, are already being cracked, which means that they are quickly expanding the entire search set of all plausible entropy that’s built on top of. Just since this is Bitcoin Optech, the COLDCARD used the BIP39 standard, which allowed you to provide an additional, what was commonly called a 25th word. So, you could have your 24 words and you could add a passphrase of alphanumeric special characters to be able to add additional entropy on top of that base phrase. That additional entropy at the moment from a passphrase is what is protecting your money. The hackers know your original 12, 24 seed words. And because of that, your entire security now is relying on whatever your passphrase was. And most people may not be aware of how passphrases interplay with entropy, but it takes a lot more than you think to be able to have a truly secure passphrase.

Mike Schmidt: I’ve seen a lot of reports that people are treating that as a PIN, right, or I’ve seen a bunch of four-digit PINs as the passphrase, right? Sorry, Portland.

Mark Erhardt: Yeah. I mean, putting it in manually in order to use the wallet probably limits, in practice, how long these passphrases are, because nobody wants to sit there and type for ten minutes and then do it three times to get it right. So, yes, right now, your wallet, if you have an Mk3 with the non-dice roll version, it’s just protected by a password that is trivial to crack probably.

Rob Hamilton: One quick thought. The COLDCARD had two different ways of using dice rolls. You either could entirely derive dice rolls from genesis with a clean slate of entropy that you would be able to cross-verify if you wished. And they also had a method where you were able to get an original, what we now know as an insecure seed phrase, and then you would be able to roll dice to specifically add entropy on top of that. I want to go to Portland. I know, at this point at least, the Block engineering team, James O’Beirne and Portland now, have all done extensive reviews of that firmware to verify that if you did the dice rolls, it’s correct. But what I want to caution people, as I’ve talked to multiple at this point, a lot of people are sure they’ve rolled dice when they ended up not having, and people who maybe did not realize, “Oh, I actually did roll dice, I just forgot about it”.

So, unless you have very clear, explicit memory that you did roll dice – and 50 dice rolls is 128 bits of entropy, 100 is 256 approximate bits of entropy – if you did less than that, you are insecure and you need to treat as if your funds will inevitably be stolen, you need to act with urgency. Portland, did you want to go into any of your analysis with the dice roll?

PortlandHODL: Yeah, so basically I did a complete trace of the most recent, and a couple of other COLDCARD firmwares, through a harness and their simulator. So essentially, what you do is you put these things, these firmwares, in a box after verifying that the deterministic build matches the same firmware that was distributed by Coinkite that would have been installed in these devices. And then, you basically trace the function calls. And I did the traces as such. The inputs were shown, so the arguments were shown and the results. And the dice-roll functionality does exactly what’s expected. It keeps filling up this digest, keeps moving through step-by-step, essentially concatenating every dice roll 1, 2, 6, 5, 4, etc, until you are done, and you’ll get the resultant hash of that string. So, if you did 100 dice rolls, you will have 256 bits of effective entropy. So, that was kind of my statement is that, yeah, the people that are affected by this would have been individuals without a passphrase, without additional dice rolls, or without using the complete dice-roll method that relied purely on the RNG of the COLDCARD. That’s when essentially, you click ‘new seed’ and it just gives you the seed. Those are the ones affected.

Mike Schmidt: Was there an opportunity, through any of the hardware and software or firmware versions, that you could add some dice rolls, but not all 50 or 99/100?

PortlandHODL: Yes. This was an identified issue with previous COLDCARD firmware that’s not related to the current issue, where in theory you could roll a single die and create a seed phrase. Those funds have been swept years ago. It provides warning flags now if you were to use less than sufficient entropy, I believe 50. It will yell at you to say that you can do this, but you should not keep money on it. I believe that’s the case, I haven’t done that recently.

Rob Hamilton: Yeah, it will yell at you. And if you use a number more than a specific number of times, I think it’s like 30 times, it will let you know, like, “Hey, you’ve used the number ‘1’ 30 times out of 100. It’s probably not random”. And then another note is they never capped the amount of dice rolls. So, you could keep rolling essentially forever.

PortlandHODL: But what Rob’s talking about is essentially, if you used low-entropy wallets, like you rolled three dice and went, “Okay, I’m done, that’s going to be my seed”, at that point, those wallets were already known, the addresses predetermined to scan and take the money from those. So, you would have known within seconds if this had happened to you. So, it’s not like it’s probably a latent thing where it’s like, “Oh, yeah, I just happen to have this wallet and now it’s going to get attacked”.

Mike Schmidt: If someone is affected in some way by one of these models and combinations with firmware, and they just have the COLDCARD, what is your personal recommendation of what they do? Is it to use the COLDCARD latest firmware? Like, obviously, you don’t want to tell everybody what to do, but what is the current thinking around people in that scenario?

PortlandHODL: I’m going to defer responsibility hugely on this one as everybody’s situation is different. In the current state, I’ve noticed multiple COLDCARDs during the firmware update process ‘bricking’. As such, I don’t personally think it’s a great idea to be updating the firmware. So, this is in the situation, like you said, you only have a COLDCARD on you and, yeah, if you wanted to essentially move your funds, you would need to get a new seed phrase on that COLDCARD with the dice rolls. So, that is fine, you can do that, or you’re going to have to end up finding a hot wallet, a collaborative custodian, or exchange to get your money off onto. Rob, please correct me on any of my statements if I’m wrong here.

Rob Hamilton: Sorry, I’m multitasking, so I did not hear anything you said.

Mike Schmidt: Maybe one important thing to note, as people are thinking about this, there have been reports and even if they’re not true, you can imagine people are being somewhat panicked about these transfers. They’re transferring it, and as you can imagine, the spammers and scammers are high, you know, fake versions of Wasabi Wallet, fake versions of other wallets are out there. And so, I guess just execute swiftly, but calmly, right, whatever your plan is.

PortlandHODL: The one thing I’ve said is, this is a general term outside of this, but slow is smooth and smooth is fast. While there is immense urgency and you need to act immediately, you need to be able to take a breath and think very calmly. And it may help you to write down a high-level plan of those steps, think about those steps, ask a friend if those steps make sense before you actually do something, because moments of panic like this are when things can go wrong.

Mark Erhardt: Yeah, we’ve had a few reports of people rushing to address this and then, maybe not even having been that insecure before, sending their funds to a scam wallet or otherwise insecure situation and losing funds they might not have lost if they didn’t act.

PortlandHODL: I will say a lot of these scams are claiming to be the official COLDCARD wallet. COLDCARD never maintained a software wallet. There is no COLDCARD software wallet that you use to put in your seed phrase or anything; that does not exist.

Mark Erhardt: Maybe one more option, I don’t think anyone has mentioned it yet. You can also, if you have an old laptop lying around, you can install a software wallet on that old laptop, turn off Wi-Fi, generate a new wallet and keys, and send to those. And software wallets should, well, unless you’re aware of some breach in a software wallet, that should be a good enough short-term solution, especially if it’s air-gapped.

PortlandHODL: We spend a lot of time in Bitcoin talking about self-custody best practices. This is a ‘break glass in case of emergency’ exception to that rule, because someone now has your seed phrase. So, your model is not, “I have a secret and that secret’s there”. You are infinitely safer at the moment with your money on a software wallet and, like, a laptop that you just turn off the Wi-Fi on, than leaving it on the COLDCARD. Just to be very clear, all of the assumptions and the things that we talk about when it relates to best practices are assuming that you’re starting with a secure key. You currently do not have a secure key. So, all of those rules, like those models that we talk about, are out the window.

Mark Erhardt: Can you just be made careful what you download.

PortlandHODL: Yes, be very careful.

Mark Erhardt: Because in many app stores, there is, especially right now, a bunch of people propagating scam wallets. So, check from the project’s website for the download link, if you can verify the signature on the software or at least double check and triple check.

Rob Hamilton: The App Store does not guarantee that a wallet is authentic. That’s where I’m noticing a lot of these are coming from. The Wasabi was a labeled app on the Apple App Store. People just downloaded it thinking it was legitimate completely. They got rugged instantly.

Mike Schmidt: Can we touch briefly on multisig and why that’s maybe a concern, but maybe not a concern, depending on the setup?

Rob Hamilton: Yes. So, I went through a very detailed analysis. it’s my pinned tweet at the moment, if you want to read the entire thing. The high-level summary here is that the attackers at the moment are hitting the low-hanging fruit of the single-signature keys. You have to understand though, if you used only COLDCARDs, a 1-of-2, a 2-of-2, a 2-of-3, 3-of-5, the entire universe of those things, and you did not use entropy on all of them, you are in a position where the attacker inevitably will be able to get your money. If any of those keys had any sort of seed or key that was unrelated to this, or you used entropy or did not come in the COLDCARD, you are able to be safe if, with some asterisks, if you’ve not reused addresses. If you’ve reused addresses, you will be vulnerable to an attacker being able to scan the entire Bitcoin blockchain to be able to see a collision of all of their keys. And just to explain at a high level very quickly, once they have all of your seed phrases that are generated within the universe of this, they will be able to go and get the universe of all of the public keys that are used to call the common derivation paths. And with that, they will be able to scan the entire Bitcoin blockchain and understand the entire universe of any public key that’s ever been tied to a COLDCARD on the network that was generated via this method, and they will be able to understand, once they have single keys and get all the single-signature low hanging fruit, they will be able to start working on the combinatorics of multi signatures.

So, let’s say you have a 2-of-3 and they were all COLDCARDs, they will be able to see, “Oh, wait a second, I see all three of these keys on the blockchain I have the private keys to. That means that this money is moving around and I can pop it”. And what will happen if you’ve reused addresses, they will be able to move that funds without your permission, because they will see all of the public keys to construct the redemption script to be able to move your money off the platform. And if you have not reused addresses, and you are to broadcast, an attacker can hypothetically RBF and steal your money. So, a lot of people have been using MARA Slipstream. I haven’t kept on track on the latest, maybe you have, Portland, on the amount of bitcoin and the number of transactions?

PortlandHODL: It’s approximately 3,500 bitcoin. I don’t know the number of transactions.

Mike Schmidt: Portland, do you want to maybe quickly describe Slipstream for people?

PortlandHODL: Yeah, essentially, Slipstream is a way to get a transaction directly into MARA’s mempool and mined into a block. The effect of this is that the rest of the network will not see your multisig, and there’s some assumptions I’ll go into after, but your multisig will basically appear as if it were just mined into a block. That’s the first time mempool.space will see it. And thus, Rob’s point about the attacker could see like, “Oh, I have these things in my collection. Let’s put them together to RBF the money into my possession”, that becomes, this is my caveat, impossible unless Marathon themselves, or there is a fundamental flaw in Slipstream, that allows somebody to view the transactions in their mempool. But so far, it’s provided one of the best options for people with multisigs, that have not exposed their pubkeys, to basically move their money, I’m going to give a really candid answer, over five hours basically, mine about six, five, six blocks a day. And yeah, in five hours, it just shows up in a block and then your funds are SAFU. So, it’s pretty nice.

Then there are quite a few API or service providers now onchain that are directly now tapping into the API, and offering this as a service to their customers and letting their customers know, “Hey, you haven’t spent from this, this is an option. You can use this”. So, but yeah, avoids a lot of the problems Rob mentioned for multisigs that have not been spent from. If you have spent from it, am I correct, Rob, it just goes in the mempool?

Rob Hamilton: If you reuse the address. That’s the biggest differentiator.

Mark Erhardt: Not just reuse the address. I wanted to restate what Rob said, because I don’t think it hurts to explain it twice. So, please bear with me, even if I’m saying stuff Rob already said.

Rob Hamilton: Don’t worry about it.

Mark Erhardt: So, a multisig setup is derived from three or more keys. And usually, the individual output scripts are composed of the same step in the derivation of the keychain. So, you have maybe three keychains, A, B, and C, and the first output script or address will be the first element in each of those keychains; the second element from each keychain will be composed into the second output script; the third will be composed into the third output script, and so on. So, if an attacker sees any of your addresses being spent, they learn the output script that was hashed and how it is satisfied on the input side. And if they identify any of those keys, they can tell that it is the same derivation chain of what they have in their derived keys, in the compromised keys. And this is how they can recompose your multisig wallet and can take your funds.

So, as Rob said, especially if the wallet is completely composed of COLDCARD keys, they can just combine those, even if you never spent from the wallet, they can just try ABC, ACB, BAC, and for the whole set of keys that they generated. But if you spend onchain, they explicitly are seeing which keys are being combined. And in that case, it’s even enough, if you have a 2-of-3 multisig and two of those keys are COLDCARD keys, because now that they see the public keys, they know what the third public key is, at least for that exact address, but they can’t derive the next public key. So, they can’t take other UTXOs, but they can take UTXOs from reused addresses, even if they only have the quorum. So, if they have two out of the three in a 2-of-3, they can take reused addresses. I just wanted to stress that.

Mike Schmidt: I was going to solicit, on this particular set of COLDCARD issues, if there was anything else you think that the audience should be aware of.

PortlandHODL: I don’t have anything else to add at this time.

Rob Hamilton: I would say just going through the full, I’m looking at my pinned tweet for the hyper, just quick summary. We already went through the different ways you can be mitigated. Just again, for emphasis and repeating, it is either rolling dice, either adding to an existing seed phrase as additional entropy, or by in whole, entirely, doing 100 rolls, totally skip that path of the compromised entropy, so you are mitigated there. But I would emphasize that a lot of people aren’t sure, if these wallets are set over five years ago, they may not exactly remember the exact ritual they did to create these and they need to be very certain. And so, I would still urge caution regardless. If you have a passphrase with sufficient entropy, that is okay. But that’s 12 BIP39 words to have 128 bits of entropy, or 10 English words in the common language, 25 mixed upper and lowercase letters or 20 ASCII characters, right, so that’s 128 bits of entropy. If you’ve done less than that, you are not secure at the moment to varying degrees, and you need to be understanding of that and making plans to upgrade. Just to say, if you used 11 words instead of 12, you’re not getting on a plane this moment to go across the world, but you need to be very sure how everything’s set up and you need to understand, for your own risk measurement, how far off you are of secure and how you need to make your own plans.

Also, if you did external entropy, hypothetically, if you derived a seed phrase that was entirely outside the wallet, including if you use Sparrow on desktop, and then you just loaded it into the COLDCARD, you are not impacted by this issue, right? So, there’s an entire, just as a clarification here, that the COLDCARD and from the initial review that we’ve done for everyone, I think there’ll be more understandings and realizing. But as it relates to this specific catastrophic issue, that is not impacted. The last thing I’m just looking for. If you have a minority, let’s just say hypothetically, let’s say you have a 2-of-3, and let’s say you have one COLDCARD, a ledger, and a Trezor, your one card is now compromised. So, I would treat this as a normal key rotation, so if it were gotten lost or destroyed and you have to do a rotation, you don’t have to do that at this exact moment. But that would be just what I would emphasize, making sure you have a plan to send those funds somewhere, use your friend network, talk to people, don’t urgently do anything that may cause a mistake. And I think that’s a good, just high-level summary of the breaking news we have, Portland.

PortlandHODL: Another note I’ve been dealing with is a lot of people have been asking specifically, like, “Hey, I’ve imported my seed from Mk3 to Mk4. Or just ensure you remember if you’ve done this process, if you’ve used the seed from the Mk3, you’re still compromised, even if you’ve moved that seed to any other device.

Mark Erhardt: Oh, that reminds me also. So, there has been a firmware update issued by COLDCARD. If you just update your COLDCARD, you do not become secure. The matter is what firmware was used to generate the seed. So, just upgrading the firmware does not help. You will need to move your funds, you will need to generate a new seed, and yes, you can probably use the new firmware with your COLDCARD to generate a new seed, but just moving to the new firmware is insufficient.

Mike Schmidt: Maybe one other note, and maybe it’s obvious, but if you have a sort of degrading multisig setup, you may run into eventually situations that have been outlined here as well, especially if you fall back to one of these compromised COLDCARDs as your single key and you broadcast, right?

Mark Erhardt: Only if you’ve used it before. I think that’s probably fairly safe. But yeah, if you use a COLDCARD in your wallet setup in some manner, you should think about whether you need to move. And if you’re not sure, you should move.

PortlandHODL: In terms of the COLDCARD, this is to anybody who has already got rugged, I would not, in my opinion, suggest destroying the device just because you think it’s worthless or throwing it away or whatever. Because of the fact that the random entropy came from the physical chip on the card, so there is, in some potential universe, like, I’m not saying it would happen, but you could use that as potentially added verification to anybody in the chance of recovery. Like, “Hey, I can prove that this COLDCARD would have generated this seed potentially”.

Rob Hamilton: I will say, I have heard of it, I do not know details, but I have heard pretty reliable, confirmed sourcing at this point that there are white-hat hackers right now who are doing this. I’m not going to speak to the ethical implications of that, but for awareness, there is some subset of funds that are plausibly being swept at the moment for those purposes. And that is part of what Portland is saying. I think there’s a longer conversation around the ethics and the practicality of doing that. But in the event, you would be able to have a provable chain of custody, because the UID on the STM32 is seared into the chip, and that is what is the contributory entropy that was used to be able to make your insecure seed phrase. So, there would be a physical, provable chained custody link event to be able to show that provenance, just to explain the full details of what you’re talking about of holding on to your COLDCARD.

Mark Erhardt: Let me say that again. There is a number on your chip that was used to generate your wallet. Keep your wallet, even if you’re not going to use it, probably put a sticker on it, “Don’t use”, or whatever, if you don’t want to use it anymore. But keep it in order to be able to prove that you had the chip that was used to generate your wallet, because it might either, via white hats hacking some remaining wallets and taking the funds, or if law enforcement picks up the hacker early enough and takes the funds, there might be a way to get back some funds. And having the physical COLDCARD device may help you prove that it was your funds.

PortlandHODL: So, there’s another component to this as well that the number of combinations that this hardware ID turned into, there’s like a 1 in roughly 65,535 chance that you would match the same ID as another COLDCARD potentially. So, they’re not completely unique, but they’re much more unique than they all use the same. And the other thing too is the reason why the firmware update becomes a problem is because if the firmware update fails and you break the device, the device itself has been fused off. And what that means is if you break the device, you can’t plug in this little cable to it to pull that UID off for proof any longer. You’ve essentially, at that point, forced yourself into going to like a laboratory to be able to get them to kind of decap the chip potentially, and then get your UID to do any of this proof. So, if you are on a COLDCARD Mk3 or 4 that’s already been rugged, just put it away and just hold on to it as evidence.

Mike Schmidt: There’s one thing that I want to just touch on before we wrap this up, separate but related. And we have Rob here, so I want to have Rob talk about what’s going on. There’s this flurry of activity online right now about vulnerability discovery. Can you explain what’s going on and why it’s maybe related to what happened with the COLDCARD hack, and all that?

Rob Hamilton: Yes. So, this is an ongoing developing situation. So, for the sake of abundance of caution, I will be vague in certain spots, to not over communicate things. But what I’d already shared was that when this vulnerability was happening, a lot of people, including myself, started looking at the firmware exactly where this issue hypothetically would appear. And in my anecdotal experience, if you use the Anthropic, it wouldn’t help, it would actually downgrade you off Fable and put you on Opus, you wouldn’t really be able to do anything. Codex was pretty good, like OpenAI. If you really get the prompt right, maybe it’ll work, but you have to coax it a bit. If you use Kimi K3, it instantly one-shots and finds the problem. So, I don’t think it’s a coincidence that on Monday of last week, the Kimi K3 model went fully open weights, where anyone could run this model anywhere in the world; and then by Wednesday night, this hack was underway. There’s no proof of this. It is just, I think, a very strong suspicion at this point, seeing how this model behaves so differently than anyone I’ve seen before, in being able to just look at an open-source code base. And I could just say, “Give me a list of vulnerabilities”, and it just provides them and says, “Here you go”. And so, there’s been a lot of work being done right now and trying to understand how we could do harm reduction across the rest of the ecosystem and being able to leverage this. I’m not sure if anyone had specific questions around that.

Mike Schmidt: No, I think that’s a great summary. Yes, people are doing this; Rob, you are doing this.

Rob Hamilton: Many people are. Yeah, Portland is doing it. If you want me to, I’ll read Calle’s tweet. We’ve been doing somewhat of a baton relay between where we are in the world, and just one person starts, next person goes. He said, “Red teaming Bitcoin: we’ve written multiple harnesses and we’re launching a huge wave of reviews across many core Bitcoin projects, crypto libraries, wallets, and infrastructure; the situation is extremely bad; we’re averaging in order”, this is Calle’s tweet, “we’re averaging in order of one critical exploit per hour per person; we’ve reported critical vulnerabilities several projects in the past 12 hours; thankfully, this is a very expensive exercise, we’re burning 10,000 tokens a day in doing it; you can donate”. Send Calle a DM if you want to do donations. OpenSats is offering to take up the bill. I have many other people within the Bitcoin ecosystem that are offering to pay for this. For right now, we don’t immediately need the money, but in the fallout and aftermath of this, we’ll handle that and have those conversations. And Calle thanks, Kimi K3 and being able to provide us with the accounts and uncensored intelligence to be able to fight back.

There’s a very sad asymmetry at the moment where white-hat actors are one step behind. And I’m not a policy person, but this is something I’m now directly seeing on the front lines. And what we’re trying to do now is fight fire with fire and start being on even footing.

PortlandHODL: My suggestion would be to anybody that custodies funds through software that they run or are responsible for, is to adversarially prompt Kimi K3 to like, “Hey, how can I break this software? What kind of vulnerabilities exist?” Like, just do it.

Rob Hamilton: Every maintainer of software in the Bitcoin ecosystem right now needs to start aggressively going through their codebase. Reach out to someone you know that can get a hold of myself or Calle to be able to start doing proactive scans. During this call, I’ve been handing off vulnerability disclosures to multiple open-source projects within the Bitcoin ecosystem. We’ve already scanned at least 150. What we’re seeing is that every person is able to apply their subdomain expertise to be able to get more efficiency out of it, to be able to get even more insight. And this is a rapidly evolving situation. And so, everyone right now, if you are maintaining any sort of load-bearing Bitcoin infrastructure, get a hold of someone that can be able to get read in on this. We have multiple people that are peer-reviewing the initial vulnerability reports to get credibility and to refine them more, to make sure that we’re respecting the time of maintainers. But given the circumstance of everything, we’re all acting out of an abundance of caution and proactively flagging and tracking down people to be able to make sure everyone’s able to get a jump start on this and move as fast as possible. Yes, Murch?

Mark Erhardt: Also, just a reminder, tweets are not responsible disclosures. So, if you’re finding an issue, contact the maintainers, don’t post it on Twitter like a moron.

Rob Hamilton: Absolutely. Yeah, we are working on a very tight web of trust at the moment with people that we know and can vouch for, that are handling the entire chain of multiple agent chains. This is an evolving, emerging thing, but it is quite fascinating. I can run a scan on something and get two mediums, and Portland can run a scan on something because he understands the software more and get crits that are confirmed. So, this is a rapidly evolving thing that we’re all trying to kind of massively coordinate all of our different domain expertises, to be able to do the initial scans, cross-verify being able to build proof of concepts that are provable lines of code that you’ll be able to replicate and show and kind of build it. I think there’s going to be a massive, massive amount of learnings from this and a shared knowledge that we’ll be able to use going forward. It’s a little bit too early to know the exact form factor of what that will take.

But right now, just acting with urgency, if you or someone you know maintains critical Bitcoin infrastructure or maintains any Bitcoin software that is either responsible for the management of Bitcoin private keys or the construction of Bitcoin transactions, you need to get a hold of someone and get plugged in to understand what’s going on right now.

Mike Schmidt: Well, we will let both of you get back to that important and timely work. We appreciate your time jumping on. Thanks, Portland; thanks, Rob.

PortlandHODL: Thank you for having us.

Disclosure of two DoS vulnerabilities in Core Lightning

Mike Schmidt: Cheers. We will jump from vulnerability to two more vulnerabilities that we’ll be discussing, “Disclosure of two DoS vulnerabilities in Core Lightning. Chand, you’re back with us again today. You were on with us in #407, I believe. We highlighted your work in Newsletter #407, and I think you came on for Podcast #407. But we want to talk about these two new vulnerabilities that you responsibly disclosed. It looks like they’re both around memory exhaustion, DoS bugs. Why don’t you walk us through the two bugs in your own words?

Chandra Pratap: Right, yeah. First of all, thanks for having me. Just to introduce myself briefly, I’m Chandra, I’m a grad student of mathematics at NIT Surat, India. I am a Summer of Bitcoin 2025 alum where I worked on fuzzing the LN, specifically CLN. And this time around, I’m again participating in Summer of Bitcoin with Smite, which is a snapshot-fuzzing framework for the LN. And these two vulnerabilities were found with my previous stint with CLN, where I was improving the fuzz testing suite for CLN, and I added a fuzz target for the gossip daemon. So, CLN uses a multi-daemon architecture where the master daemon is the Lightning daemon. And it accepts messages from the peers and hands them off to the correct daemon that’s responsible for handing these messages. The opening channel process is handed off to the opening daemon; the gossip messages are handed off to the gossip daemon, connect them, and there’s a bunch of similar daemons. This class of vulnerability, these two vulnerabilities take place in the gossip daemon specifically. Well, one takes place in the connect daemon, which is basically the glue between the Lightning daemon and the gossip daemon. And the second vulnerability takes place in the gossip daemon, the actual daemon responsible for parsing gossip themselves.

The first vulnerability, the one in the connect daemon, it was disclosed quite a bit earlier. And what it is, is basically a memory exhaustion DoS attack, in which the remote attacker can basically reliably crash any publicly-accessible CLN node by sending a certain class of messages. Specifically, it’s the channel_update gossip message in this case. So, what happens is whenever a peer sends you a large number of channel_update messages for a channel with channel announcement message the victim node hasn’t seen yet, what the victim node tries to do is it tries to cache these messages so that it can get up to speed with the channel’s current status when the channel announcement for this said undiscovered channel comes in later. It’s kind of like an optimization process. But what was going wrong was connect daemon actually, while caching these messages, there’s no upper limit. So, any attacker, if they send a flood of gossip messages, keep on sending them, each message takes around, I think it was 48 bytes or so of memory, and the memory consumption keeps piling up. You keep sending these channel_update messages, you don’t need any on chain relationship with the victim node, because gossip messages follow a gossip protocol, you don’t need any type of relationship. So, you can basically send fake short channel IDs. And we can keep sending these messages, the connect daemon is going to keep querying them, and ultimately, your node is going to run off memory.

This class of vulnerability is particularly bad because it affects your system as a whole as a computing system. For me personally, when I was developing the attack program for the verification of this vulnerability, on my 10-GB virtual machine, I was able to get the CLN node that was under attack to consume around 9 GB of memory. At that point, the OS stepped in. I mean, it was a complete system freeze. I had to restart my system to get it to actually start working again. So, that was pretty bad.

Mike Schmidt: So, that first one, it’s an unbounded queue that could be added to by any of your connections on the P2P network. So, the fix is then bounding the queue?

Chandra Pratap: Yes, the fix was pretty simple. I responsibly disclosed it to Rusty, who is the maintainer for CLN. He told me the fix was to cap the queue, which was decided to be half a million, 500,000. At that point, the connect daemon will start dropping gossip messages. That was apparently a workable fix, and that’s the current state of that vulnerability.

The second one is actually particularly sad, because how I discovered this vulnerability was basically I took the attack program from the first vulnerability, I applied the patch, the supposed patch that was supposed to fix this memory exhaustion issue of the first vulnerability, and I just ran the attack program again. I made no changes, no changes to the logic or anything, and it happened to find the second vulnerability. And if anyone from the CLN team would have bothered to actually run the attack program, they would have found it themselves and maybe get it patched earlier. But I had to discover it and disclose it. It’s kind of nice that Rusty was working on a garbage collector for the gossip map where this vulnerability actually takes place, and that fixed the issue. But yeah, it’s a bad look on the security infrastructure of the LN as it stands now.

To talk about the internals of how this vulnerability works, it basically does the same, thing sends a flood of gossip messages, channel_update messages, and the connect daemon now hands off these messages to the gossip daemon, which is actually responsible for processing these gossip messages. And what the gossip daemon does is it maintains an internal map, an integer map of short channel IDs in these channel_update messages. And storing these short channel IDs, they take up some memory. It’s shorter than what the queue thing was from the first vulnerability, but it’s still non-trivial. And you keep sending enough of them, you can get the gossip daemon to balloon up in memory usage and ultimately your node will crash as well. I was able to also verify that this vulnerability also caused a swap death on my system. So, yeah, that was particularly bad. And yeah, I think we’ve talked about the fix already. Rusty was already working on a garbage collector for these internal maps, and that apparently fixed the issue.

Mark Erhardt: So, your first vulnerability was filling up the gossip messages, and the second vulnerability was mapping the channel IDs. And that was also unbounded. And in both cases, just creating a huge amount of gossip messages caused a crash in the node. So, basically, after the first unbounded storage was capped, there was a second one found that could also overflow or not overflow, get you into swapping and crash your node.

Chandra Pratap: Yeah, that’s about it.

Mike Schmidt: Chand, talk a little bit about the fuzzing framework that you mentioned that you’re working on that’s being developed. Is it running now? Talk a little bit about it.

Chandra Pratap: Yeah, so currently I’m working on Smite, which is Matt Morehouse. You’ve mentioned him already. He’s a vulnerability researcher. I think he works with OpenSats now. And he’s been involved with CLN Security for some time now. He’s the maintainer, and we’ve been working on Smite, which is a snapshot-fuzzing framework for the LN. So, the problem with the current state of LN security is that they all manage their independent set of fuzz targets. And while that’s nice, it’s very, I guess, spread and not uniform across the whole LN. So, what we want to do instead now is develop a generalized framework that we can basically hook any Lightning implementation to, and we can basically act as a malicious peer. The fuzzer acts as a malicious peer, sending a sequence of messages to any Lightning implementation, the one that we’re hooking into, and tries to find vulnerabilities in those.

This one, other than the fact that the approach is generalizable and you can hook multiple Lightning implementations into the framework. What’s nice about it is it uses, if you know about Fuzzamoto, that does defines a mini program for Bitcoin messages that you can send over the network. And that’s what we’re trying to replicate with Smite IR, which also defines a mini language in which you can describe a sequence of messages that you can send to a Lightning node. So, we have operations like send channel update, send commitment message, receive commitment message. And the fuzzer, instead of trying to send a message and see if the parser crashes, it goes through the sequence of messages and actively processes these messages to carry out basically a simulation of what an attacker would do if a vulnerability existed for those sequence of messages. And that’s how we’re trying to actually improve upon the idea. It has lots of inspiration from Fuzzamoto and syzkaller, which is the fuzzer for Linux kernel. It draws a lot of inspiration from that in trying to find vulnerabilities. We’ve been successful so far. I think we found quite some vulnerabilities. They’re not disclosed at the moment, we’ve only recently reported them, but we’ve had quite some success with the fuzzer already.

Mike Schmidt: Maybe just to contrast briefly. So, when we were talking with Rob and Portland and some of what they were doing, towards the end of our conversation, about having large language models or AIs reason about a certain codebase and try to figure out if there’s an issue that way, what Chand and what Fuzzamoto and fuzzing is working on is a little bit different. You can kind of give hints to a fuzzer about the structure of certain messages, and then sort of have the fuzzer grind away doing quasi random inputs in different orderings to try to find vulnerabilities that way. So, two approaches to the same goal, which would be to discover vulnerabilities and report them responsibly, as Chand has done here. Chand, anything else for folks? If people are saying, “Hey, it seems important to be doing this kind of work this day and age in Bitcoin, like the Smite thing sounds interesting”, where would you point them to?

Chandra Pratap: If you’re interested in getting involved with security work, Smite is actually a pretty good point. We have a lot of initial work that we need to do. It’s a very open community, you’re always welcome to contribute. And even if you’re not interested in working on LN Security, Fuzzamoto, and there’s a whole lot of fuzzer and security tools developed for the main Bitcoin ecosystem as well. So, I believe personally that fuzzing is actually a pretty good starting point to get into the whole world of Bitcoin and Lightning security. That’s how I was introduced to the community. I’ve been a part of it so far now, and it’s something that anyone can pick up because it’s a really simple concept. You’re basically trying to feed malformed messages to an API and see if it breaks. That’s ultimately all it boils down to. You can build on top of that, there’s various techniques. It’s a very hot area of research. But ultimately, I think it’s a pretty sweet point if you’re trying to get into this type of research. And yeah, there are a bunch of fuzzers for the LN, for a lot of implementations across various languages. So, someone that’s trying to get into security in general, I think fuzzing is a very good starting point.

Mark Erhardt: One follow-up question. So, we’ve talked a lot about the big infrastructure projects, like CLN or Bitcoin Core being fuzzed. We have fuzzing at the internal level, sort of expanding on unit testing, but we also have this fuzzing from the outside, treating the software as a black box and using the external interfaces to put in data. Now I’m wondering, these bigger projects obviously are very important and it’s great that they are being covered. Would this project also be able to be applied to smaller implementations? Would maybe Lightning wallets, mobile wallets, or other interfaces be able to write support to be plugged into Smite and be able to benefit from it that way?

Chandra Pratap: Smite supports Lightning implementations, so it doesn’t matter the size. If it is a full-fledged Lightning implementation, it can definitely be plugged into Smite for wallets and other stuff. We don’t support that as of now. Our core focus is Lightning implementations and as of now, we’re supporting the four major Lightning implementations which is Eclair, which is written in Scala; CLN, which is written in C; LN daemon, which is written in Golang; and LDK, which is written in Rust.

Mark Erhardt: Awesome, thank you.

Mike Schmidt: Chand, thanks for your work on this, responsibly disclosing, and work on Smite, and also joining to describe it all to us today. We appreciate it.

Chandra Pratap: Right, thanks everyone.

Mike Schmidt: Cheers.

Chandra Pratap: Bye.

Proof of concept for a zero-knowledge proof of reserves

Mike Schmidt: In our last News item for this week, “Proof of concept for zero-knowledge proof of reserves”. And hax, you posted about an idea for a proof-of-reserve system using zero-knowledge. Maybe we’ll define proof of reserves really quickly. It’s how an individual or an exchange, for example, could demonstrate that they hold the bitcoin that they claim to. In fact, I think even just the other day, River did their proof of reserves to try to articulate to their users and the broader Bitcoin community that they hold the Bitcoins that they say they hold. Hax, I’m curious as to what are the downsides of that, maybe not that exact approach, but traditional proof of reserves and how would a zero-knowledge proof-of-reserve system work, and have what advantages?

fabohax: Yeah, well, there’s many challenges yet for applying zero-knowledge proofs (ZKPs) into the Bitcoin Network, mostly because we have to prove on the chain what is the relationship between the user and it. And yes, I was struggling with this, but anyways, it’s worth to keep searching. There’s a lot of privacy issues. So, a couple of years I was checking into ZKPs, talking with many other cryptographers also learning about it. Yeah, this is kind of the process.

Mike Schmidt: And so, what can zero-knowledge bring to proof of reserves specifically? I think we’ve had folks on the show talking about other zero-knowledge ideas and how you could apply it, but maybe walk us through what I think you’re calling here ‘proof-of-hodl’.

fabohax: Yeah, I was doing this because we’re doing spaces on X and I was reading a paper about accumulators, batch proofs, etc, about the potential solution of cross-chain swaps between Bitcoin and other chains that could be very like blinded, people could just exchange their bitcoin for other stuff. But what’s interesting is how the ZKPs were into, and thinking how there is no primitive, we have to really prove ownerships. So, I was making this idea, crafting out. So, what is basically a zkPoH (zero-knowledge proof-of-hodl) is a kind of experimental proof of concept. So, for proving you hold bitcoins, you get a snapshot of the specific UTXOs that has the satoshis within the transactions. And with the circuits, with Noir, we have the availability for proving that there was a membership onto that snapshot. But currently, we don’t have a proof that it belongs really to the chain. So, I was, in this day, realizing that we could use a trusted execution environment that can be relayed, it can be audited, and kind of generate proofs for users and have a signature into. And so, we can ensure that the actual proofs were made with a relay process.

Mark Erhardt: I commented on your Delving thread, and maybe I’ll try to summarize a little bit of what I understood and you could correct me. So, this is an early proof of concept for a zero-knowledge proof that proves that someone has access to at least 1 bitcoin, in this case, and you can cover up to 4 UTXOs. The idea is that you can prove that a set of UTXOs amounts to at least 1 bitcoin. The verifier does not learn more than that it is above a certain amount, the verifier doesn’t learn which UTXOs you’re proving for, and this would enable someone to prove that they have at least some certain amount of bitcoin. Future work, I think, currently still includes proving that you can sign for the UTXOs. So, you can lay claim to certain UTXOs, but the initial proof of concept that you have so far does make the prover commit or bind their proof to some specific UTXOs, but doesn’t prove that you can sign for them. Did I get it so far right?

fabohax: Yeah, yeah. Record on the circuit, that’s proof that you did the snapshot. So, everyone can make a snapshot from there. But, anyways, that’s just the current challenge right now.

Mark Erhardt: Right. So, I was curious. You specifically mentioned that you can do it for up to four UTXOs so far. Would it be feasible to scale this up to a larger number of UTXOs?

fabohax: Yeah, sure. It’s kind of a number, but it requires much more computations. ZKPs, that’s another challenge that is a kind of – well, there are other implementations, but, anyways, it’s pretty early, super-early.

Mark Erhardt: Right. So, the idea would be in the future that that would be more scalable, maybe that someone finds more speed ups. And then, you said you could use potentially a trusted execution environment to make sure that the prover can actually sign for the UTXOs that they commit to. So, what are the next steps for you, or what are your calls to action for the audience?

fabohax: Call to action, mostly to keep engaging with the Delving Bitcoin. I found that there is a pretty okay community there. There was already research on the matter. I was surprised too, because I was just generally searching. ZKPs probably are part of the next generation of privacy Bitcoin; it deserves a look at. So, yeah, I think if we have a collective think of it, it will be super-nice.

Mike Schmidt: Murch and hax, maybe a question for either or both of you. It sounds like the value here is that certain UTXOs are not identified, which I think is sort of the privacy angle here. But I’m just thinking, in a fleshed-out version, let’s assume you can do any number of UTXOs performantly and you could prove that you could spend those UTXOs in some way, let’s just assume those are both in place. I guess maybe this is just adversarial thinking, but it would seem like somebody with a large pool of bitcoins could just charge for attestations at certain amounts, right? And so, if I’m in exchange and I’m in big trouble but I want to show a proof-of-reserve number, I go to somebody who has these bitcoins and I pay them maybe a lot of money, but not nearly as much as the money that I don’t have in reserves, and I want to keep my scheme going, I guess that’s the downside just of the privacy element of this, right?

fabohax: Sure, we could search for latency on that, we could ask for a, you know, like a heartbeat you can prove it anytime, right, if you are looking for loans or something like that. I think that there will be further research on that for sure.

Mark Erhardt: Oh, so the proof is tied to a specific height in the blockchain, right? So, if someone wanted to make a convincing proof, you could just anytime hit their API and retrieve a proof, and then it would create a new proof for the current block height. Is that what you’re saying?

fabohax: Yeah, that would be heavy to rely, yeah.

Mark Erhardt: I mean, it would probably come at a later block height because it takes some time to compute, and there might be a limit how often the service offers to do this. So, it sounds like you could maybe implement it in ways that are more convincing concerning the problem that Mike states, where other people can sign that since these UTXOs are unattested to and not revealed, basically if the proof is transitive, you only have a proof that someone has a certain amount of bitcoin. And that, of course, is not quite what we were going for. I also quickly wanted to compare this to two other things that exist. So, there’s BIP322, the generic signed message format, which also has a proof-of-funds scheme in it. In that case, you explicitly sign with some set of UTXOs. You create a transaction that has a fake input, but the other inputs you create actual signatures for. And in that case, you prove that you have a certain set of UTXOs and can spend them. But of course, in either of these cases, nothing prevents you from moving the UTXOs later, and then not holding the UTXOs that you signed with. And in the ZK proof, of course, not only could you move the funds, but you could reuse the same UTXOs to make multiple proofs in parallel.

Then, there is another one, I think it’s BIP46, let me pull it up briefly, which is the Chris Belcher’s proof of funds. The name currently eludes me. Yeah, the timelocked fidelity bonds. It was BIP46. So, in that case, you actually lock up funds for a certain time, and you make a proof that these funds were locked up by you and you can’t spend them for, I don’t know, like a year. And then, you can use them as a proof of funds that you have locked-up funds, and that gives you some sort of credibility. Just sort of as related work, I wanted to mention these two concepts.

fabohax: Yeah, yeah, the current summation. So, I wanted to point out, because there’s another need of proving that you have a latency of ownership, right? We have to make another proof of, like, a timelock. The data would be there, and just another proof. But, anyways, this trusted environment execution will be able to make the proofs for various kinds of. You also have to prove that you have the address or you did a transaction, etc. So, there are many proofs that the environment can generate.

Mike Schmidt: I think we covered that one pretty good. Hax, we appreciate your time and hanging on through the first half of this newsletter to walk us through that.

fabohax: Thanks for having me.

Mike Schmidt: Cheers, yeah, have a good day.

Mark Erhardt: Yeah, and thanks for working on this.

What is Bitcoin’s objective definition of transaction neutrality?

Mike Schmidt: Yeah. We have our monthly Q&A from the Stack Exchange, and we had a flurry of activity this month to cover. “What is Bitcoin’s objective definition of transaction neutrality?” This is obviously a squishy question, Murch, but Ava attempted to answer saying, “It’s whether a change prevents anyone from continuing to use Bitcoin as they already do”. And then, the examples there would be previously spendable scripts unspendable, or breaking a protocol that’s being developed or relied upon. But even that is a bit sketchy, right? Because basically when you’re soft forking, you’re sort of taking some of that out to some degree, if you’re messing with transaction-related items. So, Murch, maybe you could comment on Ava’s thoughts, but do you have a thought on this?

Mark Erhardt: I mean, I don’t know if Bitcoin has an objective definition for transaction neutrality, and especially one that all of the Bitcoin ecosystem aligns, or whatever you want to call it, the community agrees on. But yeah, soft forks always forbid something that was possible before. The question is whether that impacts someone. And if something is being forbidden that wasn’t being used by anyone, Ava argues that this could be called a neutral change. So, changes that do impact people that have been using something would not be considered a neutral change. And just to be clear, there were some discussions in the comments underneath that not all changes to Bitcoin have to be neutral. So, for example, changes could propose a non-neutral change, but then, of course, the discussion would be whether the change is worth it and what we’re trying to achieve and a cost-benefit analysis. Generally, a non-neutral change would probably cause a lot more discussion than a neutral change.

Why does BIP110’s decentralization benefit not outweigh its impact on transaction neutrality?

Mike Schmidt: Next question, totally unrelated, “Why doesn’t BIP110’s decentralization benefit outweigh its impact on transaction neutrality?” This was answered by Pieter Wuille. I guess the crux of Peter’s answer is that even if you invalidated data-carrying transactions or patterns that would match that, it wouldn’t actually reduce node costs. He gives a few different reasons for that, noting the block weight limit is already in place; that actually, the folks that are using data storage are using the cheapest for certain node resource costs; and that even if you did outlaw those patterns of data embedding, that they would be replaced by other styles or other transactions, or they would just be replaced with, I guess, regular Bitcoin monetary transfer transactions. So, Murch, do you have thoughts on this? Obviously, there are a few different node resources that are in question here. And I think large data-embedding transactions take up more space than would probably be otherwise used by monetary-only transactions or normal transactions. But they’re also easier on validation or verification, right? Do you have some thoughts on the nuance here?

Mark Erhardt: Yeah, this is a very common meme that is being espoused by 110 proponents, especially that through the spam wave, the IBD (Initial Block Download) has gotten way slower. So, there is probably some effect by the UTXO set having become bigger, but I think the effect is overstated. There’s also been a ton of improvements to IBD in Bitcoin Core, well, there were improvements in 29, 30 31. There’s a batch more improvements coming in 32 too that I think are going to make IBD again at least 33% faster. Regarding the limit, the blockchain cannot grow more than the block weight limit restricts it to. So, the blockchain is restricted to linear growth. This limit has been the same since segwit activated in 2017. Obviously, these new data-embedding schemes that have been invented since then, with the inscription envelope, are making more use of the witness section to contribute to the data. So, their overall data insertions have a lower weight per byte. But also, as you said, a lot of that data does not have any opcodes. They are completely inert in the sense of transaction activity. They’re very cheap to validate. I think that BitMEX research had an article where they researched whether or not IBD was slower for those blocks specifically that had a lot of data embedding. And they found that actually, these blocks, while bigger in data footprint, are cheaper to validate and faster to validate.

So, yeah, data embedding is, I think, especially in the context of the last week, I feel vindicated with saying that data embedding is not nearly as big of an issue as many other things we could be spending time on. And I think we’re, well, sorry for tooting our own horn, but I think dismissing this as an issue that we want to spend our time on, our very limited time on, is correct and continues to be correct. I think we have way bigger issues, like security, and we should spend more time on that than discussing spam and BIP110.

Why does BIP110 require a 55% signaling threshold if its nodes reject non-signaling blocks?

Mike Schmidt: Well, that I guess leads to the next question and whether the community agrees with your assessment, Murch, which is, “Why does BIP110 require a 55% signaling threshold if its nodes reject nonsignaling blocks anyway”. Vojtěch answered this. He explained the two different phases, one being the 55% threshold applying to the voluntary minor signaling portion or phase, which happens before the mandatory signaling period begins. This is a timely question, of course, because I guess it’s not possible now to hit the 55% threshold for BIP110. And so, to your point earlier, Murch, it does seem like at least the community writ large has discounted the concern that BIP110 is attempting to address for a variety of reasons, and we move from that phase to the minor signaling phase, where essentially it is required by the implementation of the BIP110 software that the blocks would be signaling after that particular mandatory block height is reached.

Mark Erhardt: Right. So, the activation style proposed for the deployment of BIP110 has two phases. One is the minor activated soft fork portion. So, it was using a paradigm that had been used successfully by a number of other soft forks, where if a sufficient number of miners signal readiness to enforce the new rules, there would be a lock-in; and after one difficulty period of lock-in, the new rules would start taking effect. The idea here is that if more than half of the hashrate actually enforces new rules, a soft fork is stable and coalesces on the new rules, because any blocks that do not adhere to the new rules would be rejected by the majority of the hashrate and reorged out eventually. So, there might still be a short chain split where a non-upgraded node would create a block that doesn’t adhere to the rules. But if the majority of the hashrate enforces the new rules, it would eventually be reorged out and the whole network would coalesce on this soft fork.

The percentage that was required for activation in prior soft forks was much higher usually. BIP9 proposed 95% at first. Taproot reduced it to 90% after segwit was struggling so long to get 95% of the hashrate. The other part is the mandatory signaling phase. So, after this phase where for a number of signaling periods or difficulty periods, and a majority of the hashrate could lock in the changes to activate early, the BIP110 deployment additionally has a mandatory signaling. So, it has a flag-day activation essentially, where even if the miners do not support the change with the majority of the hashrate, it will force activation. BIP110 was immediately proposed, as in, “Okay, we can do this the easy way where you agree with us, or we can do it my way where we do it anyway at a specific height”. So, this block height is coming up, currently predicted to fall on Saturday, four days from now. And at that point essentially, the BIP110 nodes are going to start a soft fork by themselves where they only affect the header of blocks.

So, the mandatory signaling can be thought of as a soft fork in the sense that they will start rejecting any blocks that do not signal the bit in the block header and the version field. They do not enforce the rules that they’re trying to enforce with the soft fork yet. So, rules for transactions are not changed yet, only the rules for block headers are changed. And now, BIP110 nodes will require every single block from a specific height to signal for activation. This mandatory signaling then will cause the chain to achieve the 55% activation threshold, and then the lock-in phase would follow, where one difficulty period of blocks would have no encumbrance at all, and then the BIP110 rules would activate. Currently, the hashrate that is signaling support and readiness for activation is under 3%. They’ve really picked up the support in this difficulty period. So, they recently had a total number of 110 blocks that signaled. 110 blocks, if they had all happened in a single difficulty period, would be about 5.5% of that difficulty period. So, I think it is safe to say that at least from hashrate’s side, there is very little to no support for this change, and it’s a pipe dream to expect that suddenly on Saturday, 100% of the hashrate will flip and start signaling for this soft fork, especially with people having their mind on a much more important issue.

So, it’s very timely that today I see that one of the leading BIP110 proponents announced that he is rebasing the PoW-change hard fork that Luke had prepared, I don’t know, over ten years ago; it looks like while also, out of one side of their mouth, claiming that there is no opposition to their soft fork and it has consensus and it’s happening. They’re now working on a PoW-change hard fork to fork away from Bitcoin proper by changing the mining algorithm. So, while the public messaging is claiming that everybody is going along with BIP110, they do apparently understand the technical details well enough that they see the writing on the horizon and are working on a PoW change. So, I think 110 will be a funny but clear respite from the more dire news this week on Saturday, as we see BIP110 proponents sail away on their forked coin.

Why use ElligatorSwift encoding in BIP324?

Mike Schmidt: Interesting development, Murch, I hadn’t seen that. Okay, wow. All right, let’s move along with the Stack Exchange, “Why use ElligatorSwift encoding in BIP324?” BIP324, as a reminder for listeners, is the encrypted transport between nodes, so you’re communicating encrypted as opposed to plain text, which is the previous way that nodes would communicate with one another. And Pieter Wuille actually answered this. Oh, sorry, Murch?

Mark Erhardt: I was just looking at my notes and I had a very funny little fact that I wanted to add. Can I go back to the 55% signaling threshold?

Mike Schmidt: All right, Murch is going to make a joke. Let’s do it. You’re interrupting Pieter Wuille in this very serious engineering work for it!

Mark Erhardt: I was looking at BIP8 yesterday and I realized that BIP8, during the mandatory signaling phase, only requires a threshold of the blocks to signal. So actually, instead of requiring it from all blocks, the old soft fork proposal, that one of the co-authors was Luke, only required the threshold to signal. So, only about half of the blocks would be required and it would only reject some blocks, and it would have been way safer to try to activate that way, because it would have allowed for some stragglers with the upgrading. But for some reason, the people that designed BIP110 did not really look at existing BIPs that solved the same problem previously and did not consider this.

Mike Schmidt: Murch, you mentioned the hard fork thing, and now we’re back on this topic. Now I have a question for you.

Mark Erhardt: All right, sorry.

Mike Schmidt: If BIP110, let’s assume they get zero blocks come Saturday, just for whatever reason, the 2% becomes zero, people are worried that it didn’t hit 100% or whatever, and they stop their mining, and the chain doesn’t advance, the PoW change is put in and deployed to those users, and you have this new chain. I guess that soft fork never activated because it didn’t even get to one block, but it also didn’t get to, I guess, technically the activation phase either. So, all of that together would equal just a hard fork then, right? There actually wouldn’t have been a soft fork and then a hard fork fork; is that right?

Mark Erhardt: Well, currently it would look strange if they didn’t get any blocks at all, but I would expect that the Bitcoin chain tip, or sorry, the non BIP110, the default chain tip would advance about 39 times faster. Yeah, so we would probably see a lot of blocks on the non-signaling chain just charging ahead, and then maybe we would see a couple of blocks on the BIP110 chain. However, miners are paying for their mining and they constantly pay for the electricity. So, if there is a number of blocks that don’t signal, miners very well might reconsider. So, rolling out a hard fork on short notice is going to be quite the adventurous project as well. Obviously, nobody will follow a hard fork unless they upgrade the software. They would, at best, be guessing how many people go along with it. And then, they would additionally require people to first upgrade their software in order to even consider the hard fork change. So, it will be a very strange situation where their chain tip is probably not advancing more than one or two blocks per day, maybe three at most. And then, they’re also trying to rally the supporters of BIP110 to do a much bigger change to actually hard fork away from the main Bitcoin chain and roll out software upgrades.

I was looking at the listening node population recently, and a solid portion of Knots nodes and even BIP110 nodes were still running the old version, and they had a consensus change in one of the upgrades. So, even among the nodes that support BIP110, the listening nodes, not all of them are running the latest version. So, trying to roll out a hard fork in maybe under a week or under two weeks, well, I don’t know, doesn’t sound all that promising to me. And meanwhile, they basically will have block space for under three blocks per day to get all of their transactions in. So, I don’t know, that seems extremely discouraging. So, I would think that many people at that point would say, “Yeah, this is not happening”, even if they were in support before.

Mike Schmidt: Okay, back to ElligatorSwift and BIP324. And Pieter explained that encoding the handshake’s public keys as uniformly random bytes makes the entire v2 transport or BIP324 communication byte stream look pseudorandom. Obviously, there’s benefits to having this encrypted, but there’s also benefits to having it look pseudorandom, one of which I don’t think is being taken advantage of is you can send decoy messages, you can also have this traffic look like it’s behaving like other protocols potentially. Anything else advantageous or notable about ElligatorSwift?

Mark Erhardt: Yeah, so ElligatorSwift is used to make the bytestream look pseudorandom. So, it just is fairly indistinguishable, except by looking pseudorandom. It would make it a lot harder for intermediate nodes to filter this traffic, right? They’re just seeing some pseudorandom bytes flow by, and there isn’t explicit strings to filter for, “Oh, if this message part comes along, there’s a Bitcoin node, and I’m going to drop the traffic”, or anything like that. Being pseudorandom means that it would be much more involved to write a filter for dropping those packages. And yeah, it would make it easier to potentially, in the future, make Bitcoin traffic mimic other protocols, parrot the behavior of other software. So, maybe just to be clear, BIP324, the v2 transport, in the first handshake, very briefly, it is visible what’s happening. But then, after that, even for future key rotations and so forth, all of the traffic is encrypted and looks pseudorandom. And yeah, it is currently easy to man-in-the-middle if an active attacker were trying to do so, because it is encrypted but not authenticated. So, a man-in-the-middle attacker would be able to run a Bitcoin node that speaks the protocol, decode what comes from one side, and re-encode it for the recipient on the other side.

So, this is not a perfect solution for when someone is actually running infrastructure to man-in-the-middle, but it makes it much more expensive to track what’s going on if you’re not actively attacking, but only passively listening. So, passive listeners will now only see bytestream soup and, well, they might see, “Oh, a new Bitcoin block was found, so probably this burst of traffic is a Bitcoin block being announced”, so traffic analysis would still identify that people are running Bitcoin nodes potentially, but it takes a lot more effort for servers along the way or internet nodes to determine what traffic is going on there.

Was the OP_SUCCESSx reservation in BIP342 designed with specific opcode families in mind?

Mike Schmidt: Next question from the Stack Exchange, “Was the OP_SUCCESSx reservation in BIP342 designed with specific opcode families in mind?” So, Murch, you answered this, so maybe you should answer this.

Mark Erhardt: Sure. To my knowledge, people did not have specific opcodes in mind that they wanted to add. If they did, they haven’t told me. But generally, the OP_SUCCESS upgrade path is much more elegant than the one that we had before, which was OP_NOP. OP_NOP stands for ‘no operation’, and no operation means that an opcode is just not doing anything, it’s inert, it doesn’t make any changes, it’s just popped off the stack and nothing happens. So, what we can do with OP_NOPs are upgrades that do not change the stack. So, for example, if there were a new signature validation opcode, we could read the signature from the stack and we could read the message from the stack, or whatever is being signed and the public key, and we could have a result. So, for example, we could fail if the signature is not correct, but we can’t pop the public keys and signatures off the stack as we consume them, because now, if an old node were processing the OP_NOP as an OP_NOP where nothing happens, and a new node was processing the OP_NOP and it changes the stack and now there’s a different state in the validation of the transaction, that would be a hard fork.

With OP_SUCCESS, they work differently in that even if they’re not executed, just by being present in a script, they always make the script succeed. So, an old node that would process a script that includes an OP_SUCCESS will see, “Oh, there’s an OP_SUCCESS here. I succeed. I don’t have to do anything else”. And a new node that can interpret the new meaning of the OP_SUCCESS opcode that now has, I don’t know, maybe a covenant meaning or a signature check, can do whatever they want with the stack, can put new elements on the stack, can pop off things from the stack. And it is now a pure restriction on what was previously allowed, where it doesn’t change how it is evaluated by someone between a successful use of the new opcode, and a successful interpretation of the OP_SUCCESS that had no meaning.

So, while I don’t know of any specific upgrades that were in mind, OP_SUCCESS just makes it way easier to introduce new behavior with new opcodes, and it is much more powerful than OP_NOP. And OP_NOP also only appears in legacy script. So, we’re trying not to use legacy script too much anymore anyway. OP_SUCCESS is only present in tapscript, so it’s an upgrade for P2TR and maybe other output types that would use tapscript in the future. So, I guess, did I answer the question?

What is the difference between the long-term feerate and the discard feerate?

Mike Schmidt: Yeah, you did, wonderfully. And there’s another one that you’ve answered, which is the next question, “What is the difference between the long-term feerate and the discard feerate? Yeah, so the discard fee rate is used to calculate dust limits. The dust limit in Bitcoin Core is only a policy, so it’s implementation- and project-specific. But Bitcoin Core’s dust limit is calculated from, by default, 3 sats/vB (satoshis per vbyte). And if you spend more than one-third of the value of an output on the output script and input script that would spend it, we consider it dust. That’s how it’s calculated. The discard fee rate became configurable, I don’t know, several versions back. So, if people want to accept outputs with smaller amounts, they can set a lower discard feerate, and then their Bitcoin Core node would calculate lower dust limits. I do not recommend that. I think even though the feerates have been dropped recently, small outputs in payment outputs are still kind of iffy and we shouldn’t facilitate that. But of course, if a ton of people started doing it, it would be hard to block that, just as we learned with low feerates and large OP_RETURNs in the last couple of years.

The long-term feerate estimate is something else. The long-term feerate estimate is a guess on what might be a lower-bound feerate that you would reasonably be able to expect to make a transaction at in the future. So, even if the demand for blockspace gets very high, you probably will be able to make a transaction at 10 sats/vB once per week or so. This is a guest number that yours truly pulled out of his arse. We use that in Bitcoin Core for coin selection. And it is just some guess to where we switch from consolidatory behavior to thrifty behavior. So, above the long-term feerate estimate, we try to build the smallest possible transaction, and are thrifty with our blockspace; below the long-term term feerate estimate, we build transactions that may be more consolidatory and use some extra inputs in order to reduce our UTXO pool. And you can also configure this value if you think that 10 sats/vB is too high to have consolidatory behavior right now. Well, I’ve been thinking about maybe reducing it, because feerates have been much lower than 10 sats/vB. But not too long ago, two years ago, more than 10 sats/vB were quite common actually. So, anyway, Yancy found here a small bug in a fuzz test where a value could be fuzzed better.

What is the quickest method for migrating a legacy wallet to a descriptor wallet on a pruned node?

Mike Schmidt: Next question from the Stack Exchange, “What is the quickest method for migrating a legacy wallet to a descriptor wallet on a pruned node? And Pol answered this one and he explained sort of the core issue with the way things worked previously, which was when you executed a wallet migration, there would also be an attempt then to load that migrated wallet, which if you have a pruned node and depending on the timing and birthday of the wallet, could cause an issue currently. Yeah, go ahead, Murch.

Mark Erhardt: Maybe start from the other side. If you have a pruned node that has progressed past the height at which a wallet was last loaded, the wallet is outdated and your node doesn’t have the information to catch it up to the current chain state. Now, if you’re running a pruned node that currently doesn’t have the wallet loaded, and then you import that wallet and it is of the old format, it would suggest that you need to migrate the wallet. But then, it wouldn’t be able to load the wallet because it doesn’t have the blockchain information to catch it up. So, what it would do, I think it throws an error, although another option would be that it just starts resyncing the blockchain from scratch in order to get back out the old blocks. A potential improvement here would be that instead of going back the entire history and doing a whole new sync, it could, for example, use compact client-side block filters to get just the table of content of those blocks, and test against those whether there’s any transactions that are relevant to the wallet, and just sync the wallet against the compact block filters for the missing height, instead of doing a whole new IBD.

But if you just want to convert a legacy wallet to a descriptor wallet and you have a pruned node at hand that doesn’t have the correct chain, or has already discarded a part of the chain that you would need to bring it up to date, you can use a future argument on the migrate wallet call, which is the load_wallet argument, and just say, “Don’t load this wallet after migrating it”. Unfortunately, this is not released yet. This will come with v32. And if you really, really need to do it right now, you could run the development branch, although I would say be careful, make backups. Always make backups before migrating.

Mike Schmidt: And we did cover that option value edition in Newsletter #412, and we talked about it in Podcast #412. That was Bitcoin Core #35266, as Murch mentioned, also expected in v32 in the coming months.

Is there historical data on orphan/stale block rates during high-fee periods?

Last question from the Stack Exchange, “Is there historical data on orphan/stale block rates during high-fee periods?” And BNOC contributor, 0xB10C points to the stale-blocks dataset, and that’s maintained by the bitcoin-data project that he is a contributor to. It charts stale block rates over time and also provides raw data for deriving your own custom metrics. Yeah, so that’s interesting. Murch, you can comment on that, but you may also want to comment on this idea of parsing around P2P messages pointing out stale blocks or stale tips, I guess.

Mark Erhardt: Right. So, there is a project that collects stale blocks. People have been interested in stale blocks for a long time, because we spend a lot of time improving block propagation in order to reduce the stale block rate, because high latency between mining pools benefits larger mining pools disproportionately. So, the lower the latency is for blocks propagating on a network, the more fair it is for miners, and especially smaller miners, to participate in mining. There is currently a proposal, I think AJ proposed it first, to propagate stale chain tips if we see them on the network. The idea here is when someone finds a block that might have been a little later than a previous block at the same height, so there’s two competing blocks at the same height, it would be useful for people looking into stale chain tips and researching that, or to discover when people are doing selfish mining, or when people are forking off on their own chain tip, 50 blocks behind the chain tip, it would be useful for nodes to be aware of this chain split.

So, AJ proposed a stale chain tip propagation BIP, and full disclosure, two of my colleagues have been proposing and working on an implementation of that. So, there’s currently an open email thread, I think, maybe not a BIP yet, to propose that nodes forward stale chain tips and competing chain tips. The other context is that in May, we had a two-block reorg for the first time in over ten years. I think we haven’t had a two-block reorg, or two-block or longer, since the March 2013 accidental hard fork due to database format change.

Mike Schmidt: Wow, that long?

Mark Erhardt: Yes. So, a two-block reorg is uncommon, very uncommon. The one in May was due to Foundry finding a block right after someone else did, and then while they were working on their own chain tip, as is legitimate, they found another block right after the second block was found on the other chain tip. So, there were two blocks found just seconds after the competing chain tip was advanced. And nobody saw those blocks because we did not propagate stale chain tips. When a node has a chain tip for the for a height already, they will stick to that chain tip until it is exceeded. So, if someone else extends a chain tip past a height, it has more total work and then they will switch to it. They will reorganize to the best chain tip. But if there is a second chain tip announced at the same height, it will not propagate. Nodes that it is announced to will get that chain tip and store it, but they will not forward it, because it’s not their best trained tip.

So, the proposal here is since blocks are always encumbered with PoW, they are very hard to fake, we can safely forward this information to make the network aware that they are competing chain tips. And that is what my colleagues are proposing.

Mike Schmidt: Thanks for that color, Murch. That wraps up the News, Alert, and Stack Exchange segments for this newsletter. Gustavo’s here, who helped us with the Releases and Notable codes, and will take over. Hey, Gustavo.

BTCPay Server 2.4.1

Gustavo Flores Echaiz: Hey, guys, perfect. So, this week we have two releases. Both are maintenance releases. The first one comes from the BTCPay Server repo. So, here, v2.4.1 adds a feature we talked about, I believe last week, about enabling users to add BIP329 wallet label imports. So, that is a new feature. But mostly, besides that, it’s just a bunch of fixes related to integrations. BTCPay Server has a ton of different integrations, so a lot of fixes around that, specifically, those that come out are Boltcard, LNDHub. So, if you use one of those, you should take a look at the related fixes. But just a small release overall and mostly maintenance-focused.

Eclair 0.14.1

The next one, Eclair 0.14.1 is also a maintenance release. Here, the new requirement is that you now need to run Bitcoin Core v31 with Eclair, so that is now a new requirement. And the main bug fix here is that a new feature that was introduced a few weeks ago in Eclair, which basically allowed a recipient to pay for the routing fee of the sender, so the sender could delegate the payment of the fee to the recipient, there was a clash between that feature implemented in BOLT12 payments and multipath payments. So, the bug was that for each part of the payment, let’s say there’s three parts, the sender could basically bill to the receiver the full fee of the whole payment but on each part. So basically, the receiver could pay three times more the fee if the payment was split into three parts. So, quite a serious bug. So, this feature was simply disabled. This feature, called blinded-path fee discount, was simply disabled for BOLT12 while they figure out a better way to ship it to not have this conflict with multipath payments. Yes, Murch?

Mark Erhardt: A very small comment. You said that it requires Bitcoin Core 31. I assume that it requires at least Bitcoin Core 31 and later versions are probably fine.

Gustavo Flores Echaiz: Exactly. Thank you, Murch. So, yeah, there’s also a bunch of other changes. So, if anyone’s curious, they can look at the release notes. So, those are the two Releases of this week.

Bitcoin Core #34628

Next, in the notable code and documentation changes, we’ve got quite a heavy week. We’ve got about five different items from the Bitcoin Core repo. So, the first one, #34628, this one is about relay backlogs. So, when a node is going to relay transactions to its peers, it has backlogs of those transactions and they can just go out at a certain rate. If, let’s say, your node receives 1,000 transactions, you’re not going to broadcast those 1,000 transactions without any limits. There’s a certain size of how many initial transactions you’re going to broadcast. And then, once you reach that cap, then that queue will relay credits, they’re going to update to a certain rate, for example 14 transactions a second. Once you’ve relayed a certain number of transactions, those relay credits will update to a certain rate. Yes, Murch?

Mark Erhardt: I would like to jump in. I very briefly looked at it, but from what I understand, there are two important changes here. One is, so a few years ago, we had an issue where, I think it was during the initial ordinals craze, suddenly there were huge bursts of transactions being pushed to the network. And because they would all get queued by Bitcoin nodes to forward to their peers, and Bitcoin assumed that nobody would ever have to broadcast more than seven transactions per second to their peers, and this huge burst of transaction submissions exceeded that by far, these queues would grow faster than they would be flushed or processed. And then, I think before announcing a transaction to a peer, it would always sort them to have the highest mining score transactions, the highest effective feerate transactions at the top, and then pick like the crème de la crème and forward those first so that they would get propagated around the network the quickest. And as the queue was growing so quickly, sorting the queue over and over again turned out to be basically a DoS vector, and lower-resource nodes would keel over. So, the first solution to that was to just allow sending more quickly, and I think if it grew too quickly, to just throw away some transactions. Transaction propagation is best effort, we do not guarantee that transactions are actually forwarded, we only guarantee block propagation.

So, this is a more comprehensive fix to the same issue, from what I understand. We now queue everything into one global queue instead of having a queue for every peer. So, instead of having the entire mempool queued up to be relayed potentially to every peer, we have one central queue where we just keep what are the best transactions. And then, from the top of that, we feed into personal queues for each peer, where we now have smaller limits. And in the main queue, we have sort of a bucket system, a leaky bucket. As you fill the bucket, it keeps flowing out. The flow rate is limited. If the bucket gets too full, we probably start discarding stuff. But yeah, that’s what the whole credit system and token terminology there refers to. You have a bucket with, I don’t know, a few holes. So, it can only outflow with a steady rate, and there is a bit of a buffer how much can be in the bucket or not.

Gustavo Flores Echaiz: Yeah, that’s exactly what this is about. Just to be precise, there’s actually two backlogs, two global backlogs, one for inbound peers and one for outbound peers. And also, yes, once these transactions get selected for relay to peers, they do enter then small per-peer queues, mostly related to privacy benefits for you as a node. And yeah, I think also the issue before was the duplicate storage. So, yeah, sorting was a big issue, but also you were duplicating storage by having multiple per-peer queues. And now you have global ones, so you reduce considerably storage. And also, you can look at Newsletter #324 if you want to know more about the CPU issue that was related to the first implementation of this. But in the PR of item #34628, in the PR description, it points out to another issue, in February 2026, which we didn’t cover in Bitcoin Optech, called the Runestone surge. So, a similar issue related to mostly CPU exhaustion issues. So, this also fixes that problem.

Bitcoin Core #28463

Next item, #28463. Here, Bitcoin Core simply increases the default maximum number of connections from 125 to 200. So, that is the first change. The second change is a new option, which has a default of 50, called -inboundrelaypercent. What this defines is the maximum percentage of inbound slots for transaction-relaying peers, which means that let’s say now there’s 200 default maximum number of connections, by default 11 are attributed to outbound peers, which means 189 slots for inbound connections. But with this new setting of 50% for inbound relay percent for transaction-relaying peers, means at most 94 of those slots can be occupied by transaction-relaying peers, which means the rest is for block-only inbound peers. And the point of this PR is mostly to later add a follow-up PR that would increase the amount of outbound slots, but for blocks-only outbound peers. So, with a follow-up PR, the goal is to add those outbound peers that are blocks only, and the point here is to improve resistance to eclipse attacks.

Mark Erhardt: There’s two things here to mention. One is people might remember Erlay as the idea of how to improve or decrease bandwidth use with more peers. The idea was to synchronize what people would be announcing to each other, and then reduce the traffic necessary to keep transaction-relaying peers synchronized up. And out of that discussion, people also considered what exactly they were trying to achieve here. And one of the main things that we want to achieve with more peer connections is to make nodes more resistant to eclipse attacks. Block-only connections actually are very important in that regard. They are very hard to recognize by surveillance that are trying to guess the topology of nodes, because block-only peers only announce blocks to each other, so there is no chatter for all of the transactions. And also, if a peer already has a block, the announcement is very cheap. It’s just the block header, the 80 bytes.

So, out of the Erlay discussion, my understanding is that this idea that, “Why don’t we just massively increase the number of block-only connections, because it’s very cheap in traffic and it gets us a lot of the protection against eclipse attacks?” so if we have a lot more block-only connections, peers would announce to each other when they have found a block, and it would be way easier to have at least one peer that tells you about an honest blockchain if you have 100 more block-only peers. So, the idea here is probably to add maybe ten more block-only connections that we make outbound. I don’t know, just guessing, and we allow a lot more inbound block-only connections. So, if there are more nodes out there, especially non-listening nodes that can’t have inbound connections, they’re currently limited to their eight peers with which they trade transactions, their two peers that do block only, and then one feeler connection. And for nodes that are not listening, learning about the best chain tip is a lot more precarious. If eight of their peers or ten of their peers are sybilled, they are eclipsed, if they had ten more blocks-only connections outbound, that would make them a lot safer.

Bitcoin Core #32800

Gustavo Flores Echaiz: Thank you, Murch. Next item, Bitcoin Core #32800. Here, we’re now defining on several mempool RPC commands. Different fields now define different measures that are for transaction virtual size. So, there’s the BIP141 segwit virtual transaction size measure, but there’s also another thing that Bitcoin Core defines as transaction size, which is something related to how the mempool calculates transaction size. So, there’s this setting -bytespersigop operation. So, this setting, you basically define how many virtual bytes does each signature operation require, because each signature operation has a computational cost to your node to verify. So, basically, the mempool, when measuring transaction sizes, doesn’t just consider the virtual size, but also considers the computational cost that validating each transaction that has signature operations will have on the node. So now, this item basically introduces new fields for both the BIP141 transaction size, and policy-adjusted transaction size, as defined by the option -bytespersigop. So, this is added in a bunch of mempool RPC commands, but these two fields are now split into a bunch of RPC commands that already had the field, but it was a bit confusing which field was exactly defined. It was documented as the BIP141 virtual size, but actually contained the policy-adjusted value.

So now, there are two fields. The previous field, just called vsize, is kept, but is actually marked as deprecated. And some other commands now have those fields as well, such as getrawtransaction now reports vsize_adjusted when the transaction is in the mempool only. And the verbose output of getorphantxs also adds the explicit vsize_bip141 field.

Bitcoin Core #34683

So, next item, Bitcoin Core #34683. Here, an automatically generated description of the RPC interface is added for the protocol OpenRPC 1.4.1, which is a standard to define or to document RPC commands, also described as a standard programming language agnostic interface description for JSON RPC 2.0 APIs. So now, every Bitcoin Core node, when compiling, will generate at runtime from the RPCHelpMan metadata for all registered RPCs, will generate an open RPC description of the RPC interface. And there’s two new RPC Methods: one, rpc.discover, which returns the public interface; while getopenrpcinfo can optionally include all the hidden commands and the arguments as well. So, I’m guessing this is also very helpful for LLM models to read, in real time, the RPC commands of a specific Bitcoin Core node version.

Bitcoin Core #33014

The next item is a bug fix in Bitcoin Core, item #33014. This fixes how descriptorprocesspsbt, which is an RPC command that was documented as added in Newsletter #253, can be used to update an RPC with information that will help it later be signed or finalized. The problem here was that descriptorprocesspsbt was marking the PSBT as complete without properly checking if the signatures were valid inside the script fields. So, the RPC only checked for the presence of the final scripts, didn’t check if the signatures that were present were valid, would mark the PSBT as complete; but later, when transaction extraction would happen, that’s when an error would get returned. So now, this RPC is updated to verify every input, verify every signature before reporting completion, and simply return that it’s not complete if it has an invalid signature, instead of returning as complete.

Eclair #3325

Now, we get into the Eclair repository followed by 3 BOLTs items. So, Eclair #3325, here, Eclair now accepts BOLT12 invoice onion messages that include a reply_path. And a reply_path is something that a payee attaches to an invoice so that the payer can return an invoice error if it considers the invoice invalid. So, if I send an invoice to a payer, they can basically return to me that they consider that this invoice was invalid. So, we covered in Newsletter #321 that LDK added support for introducing reply_path in BOLT12 invoice onion messages, and this was causing some incompatibility issues with Eclair. So now, Eclair has updated its BOLT12 implementation to accept, not necessarily allow users to create, but to accept BOLT12 invoices that include reply_path in their onion messages.

BOLTs #1346

So, now we jump into the BOLTs section. We have three updates to the BOLTs repository, which defines the protocol for the LN. The first one is a new protocol, called BOLT12 payer proofs. We talked briefly about this in Newsletter #405, because CLN took a step in advance and actually implemented an experimental version for BOLT12 payer proofs. So, what BOLT12 payer proofs is, is a receipt format that basically allows a payer to prove that they paid an invoice using not only the payment preimage, but also the invoicing node’s signatures, so the recipient’s node signature, and also the payer signatures from the invoice request, which basically allows a payer to prove to a recipient, or to someone else, that he has successfully completed the payment of a BOLT12 invoice. So, CLN, like I said, is the only one that has implemented this, but probably an experimental version. So, we should probably expect CLN to update its implementation now that the BOLTs repository has included a final version for the BOLT12 payer proofs protocol.

BOLTs #1344

The next item is BOLTs #1344. Here, the protocol called attributable failures, which allows a node to basically know where an error message got corrupted, for example, if I make a payment and it fails at a specific node, I’m going to get an error message back, but a node in the way could sabotage that message, attributable failures allow us to identify approximately the node that would sabotage the message that was being returned to me as the payer. So now, BOLTs #1344 extends this protocol not only to failed payments, but also to successful payments. So, it adds a new optional message, called fulfillment_payload to the update_fulfill_htlc message, which is what I get back when an HTLC (Hash Time Locked Contract) payment has been successful, or also known as the message that returns the payment preimage and settles an HTLC.

So, this field is defined, but the PR establishes the transport mechanism for success-related data. However, it doesn’t standardize any specific message or any specific application. However, the PR description says that one motivating use case is proof of payments for spontaneous payments, also called keysend payments, where the sender picks the preimage so it cannot serve as proof. So, yeah, so this is just a system, a transport mechanism that extends the attributable failures protocol to success payments as well, but doesn’t specifically define any application. It just creates the transport mechanism for it.

BOLTs #1343

And finally, the last item of this section in this newsletter, BOLTs #1343. Here, a new feature bit, or a new option, is added, called option_onion_message_only_channels, which basically allows a node to signal to its peers that it only accepts onion messages from channel peers, or to signal it to the whole LN. So, I’m suspecting that the motivation here is that in Newsletter #409, we covered that LDK stopped using remote introduction nodes for BOLT12 blinded message paths, because LND would simply accept onion messages from channel peers. So, LDK had to adjust its internal implementation to ensure that it would always be compatible with how LND had implemented the onion message protocol. So now, this new feature bit, or option, would allow an LND node to basically indicate to an LDK node, or just the global LN as a whole, that it only accepts onion messages from channel peers. So, with this option, LDK can simply go back to its previous implementation, where it was using remote introduction nodes for BOLT12 blinded message paths, and basically ensure that it checks if an LND node or if another node simply accepts onion messages from channel peers, in order to not use them to forward onion messages.

So, this new option allows those LND nodes, but any node, to now advertise that it only accepts onion messages from channel peers. However, a node can, even if it accepts messages from peers without channels, it can still rate-limit or drop them, which has been a whole question for implementing onion messages in all of these different Lightning implementations. So, that is the final item and completes the section and it completes this episode. Thank you.

Mike Schmidt: Thanks, Gustavo, and thanks for co-hosting. Murch, thank you also for co-hosting, and we want to thank Rob, Portland, Chand, and hax for joining us earlier, and for you all for listening. We’ll hear you next week.

Bitcoin Optech Newsletter #416

2026-07-31T00:00:00+00:00

This week’s newsletter warns about a severe vulnerability affecting wallets generated by COLDCARD signing devices, summarizes the disclosure of two denial-of-service vulnerabilities in Core Lightning, and describes a proof of concept for a zero-knowledge proof of reserves. Also included are our regular sections with selected questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

Action items

● Move funds secured by COLDCARD-generated keys: if you used a COLDCARD Mk3 to generate a wallet, any funds received by that wallet are at risk of theft and should be carefully moved to an unaffected wallet as soon as possible. Wallets generated by other COLDCARD models may also be affected. See the News section below for details.

News

● Wallets generated by COLDCARD at risk of theft: On 30 July 2026, some Bitcoin users discovered that funds from their COLDCARD wallets had been stolen in a series of unexpected transactions on 29 July. Over the course of the day, a bug was identified in the firmware of the COLDCARD Mk3 that causes wallets to be generated with insufficient entropy. As of this writing, estimated losses exceed 1,000 BTC, a figure that may continue to rise as the situation develops.

A security advisory by Coinkite identified wallets generated by COLDCARD Mk3 using firmware version 4.0.1 (March 2021) or later, including the latest released version, as vulnerable to theft, unless the seed was created with sufficient externally generated entropy (such as 50 or more private dice rolls) or the wallet was additionally encumbered with a strong passphrase. The advisory also identifies seeds generated by Mk4 and Mk5 firmware before version 5.6.0 and Q firmware before version 1.5.0Q as affected.

In a follow-up technical backgrounder, Coinkite attributes the bug to a 2021 code change that unintentionally routed seed generation to a software PRNG, initialized from predictable device-unique values, instead of the device’s hardware RNG. Seeds generated by an affected Mk3 without supplemental dice rolls have roughly 40 bits of effective entropy instead of the intended 128. Seeds from affected Mk4, Mk5, and Q devices are harder to attack because output from a secure element is also mixed in, although an analysis by Block, performed with anonymous researchers and disclosed in coordination with Coinkite, found that only 32 bits of that entropy reach the PRNG state, leaving those seeds still well below the intended security level.

Several developers were able to immediately reproduce the attack with the assistance of frontier AI models, so the vulnerability should be assumed to be under active exploitation. Block’s analysis additionally identifies the older COLDCARD Mk2 running 4.x firmware as affected to the same degree as the Mk3, and notes that other randomly generated secrets, such as paper-wallet private keys and ephemeral seeds, are also affected.

This is an evolving situation, and additional information is likely to emerge after this newsletter’s publication. Readers should monitor Coinkite’s blog and other sources for updates. Bitcoin Optech recommends that COLDCARD users whose wallets may be affected move their funds carefully to an unaffected wallet as soon as possible. Seeds generated on an affected device without supplemental dice rolls should be treated as compromised. Users of Mk4, Mk5, and Q devices should upgrade to fixed firmware before generating any new wallets. Upgrading alone does not make an existing seed safe.
● Disclosure of two DoS vulnerabilities in Core Lightning: Chandra Pratap posted to Delving Bitcoin about two denial-of-service (DoS) vulnerabilities he found in Core Lightning during his internship for the Summer of Bitcoin program. Specifically, these vulnerabilities would have allowed an attacker to crash a node by exhausting its memory. The bugs are related to the gossipd daemon state machine, in particular to its interface with the connectd daemon. Pratap was able to find the vulnerabilities thanks to his work on a new fuzz target, fuzz-gossipd-connectd, which aims to test the robustness of the communication between the two modules.

The first vulnerability was related to the inter-daemon message queue, shared between the two daemons, whose goal is to store all the channel_update messages arriving from the network. An attacker would have been able to flood the node with messages, causing the internal queue to grow indefinitely and leading to the consumption of all the available RAM. The bug was simply fixed in Core Lightning #8376 by allowing the queue to drop messages, adding a cutoff point at 500,000 messages.

The second vulnerability was found while trying to fix the first one. In particular, this was related to the internal map used to track unknown short channel IDs (SCIDs) to query peers for possible missing channels. An attacker would have been able to flood the node with fake SCIDs, causing an ever-increasing memory consumption. Although the bug had not been previously reported, Rusty Russell was already working on a patch in Core Lightning #8903, which introduced an improved garbage collection mechanism for the internal map.
● Proof of concept for a zero-knowledge proof of reserves: fabohax posted about zkPoH (“zero-knowledge proof-of-hodl”), a proof of concept for a non-custodial proof of reserves system for Bitcoin. The prototype allows a user to prove that they control a set of UTXOs, whose combined value is at least 100,000,000 sats (1 BTC), without revealing any further information.

The proof of concept takes as input a UTXO snapshot generated off-chain, which is then committed into a merkle tree, whose root becomes the public commitment. The prover selects up to four UTXOs from the snapshot and generates the witness input for the Noir circuit, which verifies that the chosen UTXOs actually belong to the snapshot, the merkle paths are valid, and the sum of the selected UTXOs is at least the required amount. The verifier only learns that the prover satisfies the 100,000,000 sats requirement.

As of this writing, an explicit ownership binding step is not available in the proof of concept. This means that there is no way to prove that the chosen UTXOs actually belong to the prover. The author is currently working on adding this feature, either through an off-circuit ownership check or directly inside it. The prototype is currently available in a dedicated repository.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

● What is Bitcoin’s objective definition of transaction neutrality? Ava Chow frames neutrality as whether a change prevents anyone from continuing to use Bitcoin as they already do, such as making previously spendable scripts unspendable or breaking a deployed protocol.
● Why does BIP110’s decentralization benefit not outweigh its impact on transaction neutrality? Pieter Wuille argues that invalidating data-carrying transaction patterns would not reduce node costs because the block weight limit already bounds resource usage, data storage bytes are among the cheapest to process, and outlawed patterns would simply be replaced by other transactions.
● Why does BIP110 require a 55% signaling threshold if its nodes reject non-signaling blocks? Vojtěch Strnad explains that the threshold applies to voluntary miner signaling before the mandatory signaling period begins (see Newsletter #392). An early lock-in indicates wider buy-in and can activate the soft fork sooner, but once mandatory signaling begins, enforcing nodes discard non-signaling blocks.
● Why use ElligatorSwift encoding in BIP324? Pieter Wuille explains that encoding the handshake’s public keys as uniformly random bytes makes the entire v2 transport bytestream pseudorandom, preventing identification by pattern matching and forcing a censoring firewall to either mount a full man-in-the-middle attack or operate an allowlist. It can also make it easier to mimic other protocols.
● Was the OP_SUCCESSx reservation in BIP342 designed with specific opcode families in mind? Murch describes the OP_SUCCESS opcodes as generic upgrade hooks. Since any OP_SUCCESS makes a tapscript unconditionally valid, a future soft fork can redefine one with more restrictive behavior, including stack manipulation that redefined OP_NOP opcodes could never perform.
● What is the difference between the long-term feerate and the discard feerate? Murch clarifies that the two are not interchangeable. The discard feerate sets the dust limits below which a potential change output’s value is given to fees, while the long-term feerate sets the wallet’s boundary between consolidatory and thrifty coin selection.
● What is the quickest method for migrating a legacy wallet to a descriptor wallet on a pruned node? Pol Espinasa explains that migration attempts to load the migrated wallet, which fails on a node pruned below the wallet’s birthday. Bitcoin Core #35266 (see Newsletter #412), expected in version 32.0, allows migrating without loading the wallet, although loading the migrated descriptor wallet will still require a node with the relevant blocks.
● Is there historical data on orphan/stale block rates during high-fee periods? 0xB10C points to the stale-blocks dataset maintained by the bitcoin-data project, which charts the stale block rate over time and provides the raw data for deriving custom metrics.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

● BTCPay Server 2.4.1 is a maintenance release for this self-hosted payment processor. It adds BIP329 wallet label imports (see Newsletter #415), editable invoice comments, and several other improvements and bug fixes.
● Eclair 0.14.1 is a maintenance release for this LN node implementation. It now requires Bitcoin Core 31.x, disables an experimental BOLT12 blinded-path fee discount that did not correctly work with multipath payments, and includes several bug fixes and performance improvements. Operators using custom offer-handler plugins should review the release notes.

Notable code and documentation changes

● Bitcoin Core #34628 replaces independent per-peer transaction relay backlogs with global inbound and outbound backlogs controlled by count and serialized size token buckets. This reduces duplicate storage and sorting across peers, which contributed to a CPU exhaustion problem (see Newsletter #324). Relay credit starts at 420 transaction tokens and 12 MB, replenishing at a rate of 14 transactions and 20 kB/s for the inbound peer backlog. The count balance is capped at 420 tokens, while the size balance can accumulate up to 50 MB. The outbound refill rate retains the 2.5-times multiplier described in Newsletter #373. When relay demand exceeds available credit, transactions are prioritized by mining score while respecting dependencies. Selected transactions then enter small, randomized, per-peer queues. New getnetworkinfo fields expose each backlog and its token balances, and the debug-only -txsendrate option allows testing different count rates.
● Bitcoin Core #28463 increases the default maximum number of connections from 125 to 200 and adds the -inboundrelaypercent option (default 50), which sets the maximum percentage of inbound slots that transaction-relaying peers can occupy. With eleven outbound slots by default, 189 slots remain available for inbound connections, of which at most 94 may be occupied by transaction-relaying peers under the default setting. This limit is enforced after a peer announces its relay preference and is rechecked if the peer later enables transaction relay using BIP37 messages. This reserves capacity for low-bandwidth block relay and prepares for the addition of more outbound block-relay-only connections, to improve resistance to eclipse attacks.
● Bitcoin Core #32800 adds explicit BIP141 and policy-adjusted transaction size fields to several RPCs. vsize_bip141 reports the virtual size calculated from the transaction’s weight, while vsize_adjusted reports the greater of that value or the size implied by the transaction’s sigops cost under the configured -bytespersigop policy. The adjusted value is used for mempool policy and block template feerate calculations. getmempoolentry, verbose getrawmempool, testmempoolaccept, and submitpackage now report both fields. The existing vsize field, which was documented as the BIP141 virtual size but actually contained the policy-adjusted value, is retained but marked as deprecated. Additionally, getrawtransaction reports vsize_adjusted when the transaction is in the mempool, while its existing vsize remains the BIP141 value. The verbose output of getorphantxs also adds the explicit vsize_bip141 field.
● Bitcoin Core #34683 adds an automatically generated OpenRPC 1.4.1 description of the RPC interface. The new rpc.discover RPC returns the public interface, while getopenrpcinfo can optionally include hidden commands and arguments. The document is generated at runtime from the RPCHelpMan metadata for all registered RPCs, and describes method parameters, required and default values, result shapes, and other interface details.
● Bitcoin Core #33014 fixes how descriptorprocesspsbt (see Newsletter #253) handles a PSBT whose finalized script fields are populated but contain invalid signatures. Previously, the RPC only checked for the presence of final scripts, marked the PSBT as complete, and returned an internal error when transaction extraction failed. Now, it verifies every input before reporting completion, so a PSBT with an invalid signature returns complete: false without a serialized transaction in the hex field.
● Eclair #3325 accepts BOLT12 invoice onion messages that include a reply_path. A payee can attach a blinded reply path to an invoice so that the payer can return an invoice_error if it considers the invoice invalid. Eclair previously rejected this combination, causing interoperability problems with LDK, which added reply paths to invoices (see Newsletter #321).
● BOLTs #1346 specifies BOLT12 payer proofs, a receipt format that allows a payer to prove they paid an invoice using the payment preimage, the invoicing node’s signature, and a payer signature from invreq_payer_id, while allowing selected invoice fields to be omitted for privacy. The specification assigns the lnp human-readable prefix and adds generation and verification test vectors. Core Lightning experimentally implemented an earlier draft (see Newsletter #405).
● BOLTs #1344 extends the attributable failures protocol to successful payments by adding an optional fulfillment_payload to update_fulfill_htlc, the message that returns the payment preimage and settles an HTLC. Only a padding field is defined, so the PR establishes transport for future success-related data, such as signed keysend receipts, without yet standardizing any application.
● BOLTs #1343 adds the option_onion_messages_only_channels feature bit for nodes that only accept onion messages from channel peers. Nodes that do not advertise this feature should accept onion messages from peers without channels, though they may still rate-limit or drop them. This feature allows senders to avoid relay paths that are known to fail while enabling operators to reduce their exposure to denial-of-service attacks. See Newsletter #409 for an LDK workaround that addresses LND’s behavior of receiving but not forwarding onion messages from non-channel peers.

Bitcoin Optech Newsletter #415 Recap Podcast

2026-07-28T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Fabian Jahr, Kruw, and Mojo to discuss Newsletter #415.

The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

Download audio

News

● Draft BIP for full aggregation of BIP340 signatures (1:32)

Changes to services and client software

● Wasabi Wallet 2.8.0 released (33:11)
● Coinswap v0.2.2 released (46:08)
● Go secp256k1 library announced (1:08:38)
● ASMap dashboard announced (21:06)
● Wavelength alpha released (1:10:01)

Releases and release candidates

● Core Lightning v26.06.6 (1:13:06)
● Bitcoin Inquisition 29.4 (1:16:03)

Notable code and documentation changes

● Bitcoin Core #35215 (1:17:11)
● Bitcoin Core #35766 (1:21:16)
● BIPs #2075 (1:22:44)
● BIPs #2204 (1:25:46)
● Core Lightning #8935 (1:28:43)
● Core Lightning #9324 (1:33:14)
● libsecp256k1 #1765 (1:35:16)
● Rust Bitcoin #6317 (1:41:46)
● BTCPay Server #7457 (1:44:10)
● BLIPs #71 (1:46:24)

Transcription

transcription coming soon

Bitcoin Optech Newsletter #415

2026-07-24T00:00:00+00:00

This week’s newsletter describes a draft BIP for full aggregation of BIP340 signatures. Also included are our regular sections describing recent changes to services and client software, announcing new releases and release candidates, and summarizing notable changes to popular Bitcoin infrastructure software.

News

● Draft BIP for full aggregation of BIP340 signatures: Fabian Jahr posted to the Bitcoin-Dev mailing list about a new draft BIP for full aggregation of BIP340 schnorr signatures, a standard for the DahLIAS aggregate signature scheme (see Newsletter #351), which describes a process to combine a collection of signatures into a single aggregate one, with a size of only 64 bytes, regardless of the number of signers. However, the described protocol is interactive and requires cooperation among all the signers and involves the presence of an untrusted coordinator to reduce communication complexity. The coordinator role can be taken by any of the signers participating in the process.

The process is divided into two rounds:
1. Each signer starts the signing session by computing a secret nonce (secnonce) and a public nonce (pubnonce). pubnonce is sent to the coordinator, which aggregates them (aggnonce) and sends the result back to signers, together with other pieces of information.
2. Each signer computes a partial signature using the secret key, secnonce, the message to sign, and the information provided. Partial signatures are then sent to the coordinator, which aggregates them in a single 64-byte signature.
According to Jahr, one of the possible applications of the proposal would be cross-input signature aggregation (CISA), a change to Bitcoin consensus that would reduce size and thus on-chain fees of multi-input transactions. However, the author specified that the consensus change is outside the scope of this BIP.

The draft BIP, which is now referred to as BIP459, is currently being discussed in BIPs #2210 and the proposal is gathering feedback from the community.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

● Wasabi Wallet 2.8.0 released: Wasabi Wallet 2.8.0 downloads compact block filters directly from the P2P network, removing the previously required centralized backend server. The release also adds the ability to pay recipients directly within a coinjoin, support for feerates below 1 sat/vbyte, and payment batching, among other features.
● Coinswap v0.2.2 released: Coinswap v0.2.2 adds multi-transaction swaps, deniability proofs, and marketplace improvements to its coinswap protocol implementation (see Newsletter #338). The release also includes fixes for findings from a security audit performed using Loupe, Spiral’s open source, AI-powered security scanner.
● Go secp256k1 library announced: Allocz announced a Go library that uses libsecp256k1 bindings when C interoperability is enabled and falls back to a pure-Go implementation otherwise, preserving Go’s cross-compilation capability. The author reports ECDSA and schnorr signature verification times drop 70% compared to the pure-Go implementation.
● ASMap dashboard announced: Joris Strakeljahn announced an ASMap dashboard that tracks the history of ASMap data releases (see Newsletter #394), including how much address space shifts between operators from release to release and how well each release covers actually observed Bitcoin nodes as the data ages.
● Wavelength alpha released: Lightning Labs announced an alpha version of Wavelength, a toolkit for adding self-custodial payments to applications. It pays and receives BOLT11 LN invoices, and batches off-chain transfers using an Ark-like settlement layer, without requiring users to manage their own channels. The alpha is available on signet and testnet.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

● Core Lightning v26.06.6 is a maintenance release of this LN node implementation. It updates the bundled pyln-proto library’s coincurve dependency to fix Python build environments and adds a check that rejects any channel reusing the funding outpoint of an existing channel.
● Bitcoin Inquisition 29.4 is a release of this signet full node designed for experimenting with proposed soft forks and other major protocol changes. Based on Bitcoin Core 29.4, it adds activation of BIP446 (OP_TEMPLATEHASH), a proposed tapscript opcode that pushes a hash of the spending transaction onto the stack (see Newsletter #365), to its existing set of experimentally-activated soft-fork proposals.

Notable code and documentation changes

● Bitcoin Core #35215 speeds up lookups in the in-memory UTXO cache (CCoinsMap) by replacing SipHash-2-4, the function used to hash its COutPoint keys, with a faster, purpose-built SipHash variant, SipHasher13UJ. Each coin is looked up by a key that combines its txid and output number, and every lookup runs that key through a hash function. SipHash-2-4 digests a coin’s 32-byte txid in four separate 64-bit pieces, so hashing one outpoint runs 14 internal rounds. SipHasher13UJ instead takes in the whole txid in one 256-bit step and does fewer rounds, cutting that to five. The author reports roughly double the hashing throughput in isolated benchmarks and about a 5% reduction in one chainstate-reindex run.
● Bitcoin Core #35766 enables BIP324 v2 p2p transport by default when first connecting to addresses from DNS seeds and the compiled-in fixed seeds. Experimental support for BIP324 shipped in Bitcoin Core 26.0 and was enabled by default in 27.0. Since these seed mechanisms provide addresses without service flags, Bitcoin Core previously treated the peers as v1 only and a node’s earliest automatic connections never attempted encrypted transport. The new SeedsAssumedServiceFlags() function now assumes NODE_P2P_V2 for those addresses. If this assumption is incorrect for a given peer, the node simply reconnects using v1. Connections made through the -seednode option and address fetching already attempt v2 by default.
● BIPs #2075 clarifies BIP174’s description of how PSBTs are combined. The specification had asserted that combining independently updated PSBTs is unconditionally order-independent, but this only holds when the participants add distinct fields. When two PSBTs contain the same key with different values, a combiner may pick either value or refuse to combine, so the specification now notes that in this case the result is not commutative.
● BIPs #2204 updates the draft BIP440 and BIP441 Great Script Restoration specifications (see Newsletter #400). It introduces wordspan notation, which rounds up the byte length of a stack element to the next eight-byte boundary, and reworks numerous operation cost formulas so that operations that process data in 64-bit words are charged by wordspan while those that work on the exact bytes stay costed by length. The update also corrects the definition of OP_RIGHT and clarifies costs and range checks for several other opcodes.
● Core Lightning #8935 fixes a bug that could cause a node to repeatedly RBF a transaction, even after a replacement had already confirmed. CLN stores pending transactions in an outgoing_tx_map keyed by the original txid, but it replaces the transaction object with each higher-fee version without changing the key. The per-block rebroadcast_txs() loop checked for confirmation using the stale original txid, which was never mined, so it kept invoking the rebroadcast and replacement logic even though the latest transaction had confirmed. Since the txid serves as the hash-table key and cannot be updated in place, the loop now computes the current transaction’s txid with each iteration and uses it for confirmation checks.
● Core Lightning #9324 fixes a Renepay regression (see Newsletter #263) present since v26.04 that built HTLCs with CLTV expiries roughly one block height too far in the future. Renepay’s route data already incorporated the current block height into each hop’s CLTV value, but route_sendpay_request() added the block height a second time when passing the route to sendpay, roughly doubling the expiry. Forwarding nodes could then reject the onion with expiry_too_far.
● libsecp256k1 #1765 adds an optional silentpayments module that implements the elliptic-curve operations defined by BIP352 silent payments. For senders, one function combines the sender’s input private keys, the transaction’s lowest outpoint, and the recipient’s published scan and spend public keys to derive the output keys that the transaction should pay. For receivers, full-node scanning detects which of a transaction’s outputs belong to the recipient and returns the tweaks needed to spend them, working from only the recipient’s scan secret key and spend public key so the spend private key can stay offline. Separate functions manage labels, an optional BIP352 feature that lets recipients derive distinguishable variants of their address to tell incoming payments apart and flag their own change. Light client scanning support was deferred to a later PR.
● Rust Bitcoin #6317 updates its compact block relay decoding to reject sendcmpct messages whose boolean announcement field is not exactly 0 or 1, as required by BIP152. Previously, Rust Bitcoin decoded the field with a non-zero test, accepting any non-zero value as true (high-bandwidth mode). This PR mirrors the hardening equivalent in Bitcoin Core (see Newsletter #412).
● BTCPay Server #7457 adds the ability to import wallet labels in BIP329 JSON Lines format, complementing the existing export functionality. Previously labels were effectively lost when moving to another server, and label files produced by BIP329-aware wallets such as Sparrow or Envoy could not be loaded at all. The importer reads the format’s tx, addr, and output records and maps them to BTCPay’s transaction, address, and UTXO objects, skipping any records it can’t apply.
● BLIPs #71 adds a dnssec_error response to BLIP32, the protocol that resolves BIP353 human-readable payment names by carrying DNSSEC queries and proofs over Lightning onion messages (see Newsletter #306). Previously the protocol only defined dnssec_query and dnssec_proof, so resolvers that could not respond had no standardized way to indicate this to the requester, who would continue to wait. The new final-hop TLV (type 65550) echoes the queried domain_name and includes a definitely_unresolvable boolean that a resolver should set for terminal failures, such as NXDOMAIN or an unsigned name, and not set for other, possibly transient failures.

Bitcoin Optech Newsletter #414 Recap Podcast

2026-07-21T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Keagan McClelland and Andrew Toth to discuss Newsletter #414.

The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

Download audio

News

● Formal verification of the Bitcoin protocol (1:11)

Releases and release candidates

● Bitcoin Core 30.3 (39:42)
● Bitcoin Core 29.4 (39:43)

Notable code and documentation changes

● Bitcoin Core #35295 (52:43)
● Bitcoin Core #34897 (1:13:54)
● Bitcoin Core #35406 (1:16:13)
● Bitcoin Core #35380 (1:21:36)
● Bitcoin Core #35568 (1:07:36)
● Bitcoin Core #34538 (1:23:43)
● BIPs #2208 (1:25:52)
● LND #10962 (1:27:27)
● LND #10897 (1:30:12)
● BINANAs #21 (1:31:34)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #414 Recap. Today, were going to talk about a new project that’s applying formal verification techniques to the Bitcoin protocol; we have two Releases to Bitcoin Core, they’re maintenance releases that we’re going to jump into; and then we have Notable code and documentation changes, including some IBD speedup work that we have a guest on to talk about as well. This week, Murch, Gustavo and I are joined by a couple of special guests. We’ll have them introduce themselves briefly. Keagan?

Keagan McClelland: Hello, hi, my name’s Keagan, I have a background in some layer 2 development, including Lightning and some BitVM stuff. And I’ll be talking about some of the formal verification techniques that were aforementioned as we get into it.

Mike Schmidt: Great, thanks for joining. Andrew?

Andrew Toth: Hi, I’m Andrew, I work for Exodus doing Bitcoin stuff, and I’m sponsored by OpenSats to do open-source Bitcoin stuff. And I’ve been working on Bitcoin Core for a number of years now.

Formal verification of the Bitcoin protocol

Mike Schmidt: Awesome. Thank you both for joining us. We’ll jump into our first and only news item titled, “Formal verification of the Bitcoin protocol”. Keagan, you posted the Bitcoin-Dev mailing list, and I believe Delving Bitcoin as well, about your project to bring a formal verification approach to the Bitcoin protocol. You posted about btc-verified or is that Bitcoin-verified?

Keagan McClelland: That is, yeah, I mean I’ve actually not really ever said it out loud, so candidly I’m not sure how you’re supposed to say it, so you guys can decide and there’s no way that’s wrong!

Mike Schmidt: So, btc-verified is written in Lean4, and so we’ve thrown out a few things here. We have the Lean4, we have the btc-verified project, we have this idea of formal verification of the Bitcoin protocol. Keagan, maybe you can give us your perspective. What is formal verification and what can it do for Bitcoin and the Bitcoin protocol? Maybe we can start there and then we can get into your project, which is motivated, I assume, by the answer to that question.

Keagan McClelland: Yeah, okay. So, maybe the best way to start the conversation is, let’s talk about what formal verification is. So, for the audience members who have written code before, some of this will be familiar. But when you write software, there’s a whole spectrum of things to choose from in terms of programming languages and styles. But when we write software, there’s the code that actually executes and does the computations, but then there’s also the set of things that you need to do to ensure that your software is correct. Any working software engineer has experience writing tests of some kind, whether they’re unit tests or otherwise. And then, depending on which sort of discipline you come from with respect to software and engineering, you may also have experience with type systems. So, like I said, there’s a spectrum. It goes from, on one end, you have dynamically-typed languages, such as JavaScript, Ruby, Python, etc. And then, what most people in the Bitcoin space will have some kind of experience with is something like a statically-typed imperative Language, like C, C++ or the canonical ones in this space, because that’s what Core is written in. But it’s things like Go are included in there, Java would be included in there. There are certain features of those programming languages, and Rust is the other major one that people would recognize, that fit into that category.

There’s a number of differences between those sets that I was talking about, but the main difference between those clusters is that they have this notion of static typing. Now, when type systems were first invented, they were things that were there to help the compiler decide how to lay out your code in the silicon. And when the type systems started to improve, they started to take on a different shape that made them have a different role completely after that. Where do I want to go from here? All right, anyone who has written programs in statically-typed languages knows that there are certain entire classes of tests that don’t even make sense to write anymore. For instance, if you’re writing in C++ and you write a function, and that function takes a number of arguments, you don’t need to write that say, “Well, if I parse a string into a function that expects a number”, I don’t have to check that the function appropriately returns an error or returns some null value that would denote that you’ve misused the API, because the compiler statically rules out the possibility of misusing the API in that way. And so, as a result, you start to learn that these types can be used to enforce certain invariants about your code that might otherwise not be enforceable, or it might require a different layer of work, ie testing, to ensure that they are enforceable.

In that case, there’s a question about just how far can we take those ideas, right? If you could start to write arbitrary types that represent certain ideas, and that the ways that you can enforce those invariants can get arbitrarily good – sorry, I’m losing the thread here. Let me start this explanation over. Once you realize that static types can rule out certain invariants, there are certain things that you can do to try to encode the invariants that you might want from your software into these types. And if you’ve ever gotten to use something like Rust, you’ll notice that there is a feature within Rust that might differentiate from, like, old-style C++ or Go, where you can essentially take two types and mash them together in two different ways. You can mash them together either as a product type, where you can say I have some type A and some type B, and I can say that I have a new type C that is both of those things. This is present in pretty much any programming language you can think of. But there’s another feature that you might want, which is that I might have this other sort of glue type that I might want that says I can either have type A or type B. And when you have that feature, there’s all sorts of new things that you can enforce at compile time that you couldn’t enforce before when you didn’t have that feature.

So, when you start to introduce these ideas, you start to realize that these type systems vary in how much power they have, and the power that they allow you to encode invariants. And so, there’s a question that comes about there, which is if we assume that there’s any stratification or hierarchy between these programming languages in terms of what they can encode, is there a logical endpoint? Is there some type system, some master type system, that gives us the ability to encode everything? And when you start to ask that question, and thankfully many, many researchers before us have done a lot of this work, there is, I don’t want to say it’s the best possible one, but it’s the one that is rooted most deeply in formal logic, which means that any truth claim that you can make about a program, whether it behaves in some way or not, can be encoded in these type systems if they have something like a dependent type theory. So, interactive theorem provers, of which Lean4 is one, they have this dependent type theory that they’re based on. And when you have that, then you can start to ask and answer a lot more deep questions about whether or not the software behaves properly. If you don’t have a facility like this, you’re essentially relegated to certain testing strategies that range all the way up from unit testing to something maybe like property testing.

So, a property test is where you might write a function and you might say, “Well, I don’t want to give specific example numbers or example inputs to the function and just test it against known outputs, I want to be able to say the invariant in a little bit more general way”. The example that’s very easy to understand is, if I have some function that computes addition, A plus B, an example might be 3 plus 5 equals 8. And I can write a test that says that. But one of the important properties you might expect out of addition is that it commutes. So, A plus B equals B plus A for all A. And so, you might write a test harness that generates random numbers, and then sort of does those two separate computations and ensures that they match. Now, even if you go through property testing, you are still limited by only checking the points at which you sample. And in a lot of cases, this is really good. But it’d be better if we could prove that our implementation, A plus B equals B plus A, for any possible A and B, not just the 100 or 1,000 inputs at random that we chose to test it with, but for any possible one.

This type of reasoning is not really possible in something like C++, yet it’s still really useful to do when the stakes of a project or the cost of failure is extremely high. And I don’t think I need to convince bitcoiners that taking this high-security, no-failures-allowed mindset is generally a good thing. Now, granted, we live in a real world where efforts are finite and we have to choose where they’re most effectively directed. But in principle, the value proposition makes a lot of sense, especially as the network capitalizes to greater and greater heights.

Now, there might be a question that arises that was just like, “Why haven’t we done this before? Is this technology new? Is it just that nobody’s thought it was worth it?” And the answer is a little bit varied, which is that even within the cryptographic ecosystem, we’ve used proof assistant, like I think Blockstream came out with Simplicity, and Simplicity was a programming language for smart contracting that sort of had a design goal of being easily formally verifiable. And the way that they chose to do that formal verification inside the Simplicity ecosystem was with a proof assistant called Coq, or it’s now been renamed to Rocq, but you’ll see both names in the literature, depending on what era you’re looking in. Now, why not write all of Bitcoin in this? And there’s a few different reasons. Number one, which is that they have different design goals. The programming languages that are proof assistants are designed to convey greater understanding of not only the implementation, but the derivative properties we might expect from them. But it’s not necessarily geared towards making efficient software that you can run in silicon on low-memory or low-CPU hardware, etc. And so, as a result, these programming languages, like anything else, they kind of niche down into where they’re most useful.

So, you can also ask the question like, “Why haven’t we done something this before in Bitcoin?” And I would argue that the biggest thing, and this is what’s most exciting about this moment in history, with all of the LLMs and stuff that are coming out, which is that in order to be able to do this type of proofs, like engineering on Bitcoin, you would first need people who are well-educated enough in the theory to be able to do it at all, which is a very, very small subset of the population of programmers. Not because, I mean it is both genuinely hard and so it requires a lot of rigorous intellectual thinking, but there are plenty of people in the Bitcoin ecosystem, especially the people who work on Core protocol dev, who I think have a level of mathematical and reasoning maturity that they would be able to do this. But also, that any work that you do towards this end is work that’s not being dedicated towards actually making software work. So, in the early days of Bitcoin’s history, the marginal value of allocating your efforts towards making Bitcoin more useful were far better spent there than in maybe the time we find ourselves in now, which is that maybe Bitcoin – I’m not going to try to take positions on whether Bitcoin is sort of complete or not with respect to features or protocol stuff, etc. But you can argue that 17 years into its operation, it would be a good idea for it to allocate more towards security and protection of what is already there than to add incrementally new stuff. But we’ll find in a second that these two goals are actually not strictly competitive. In fact, the more that we can do, like reason about the security of the protocol, actually gives us the confidence to be able to change things without breaking other things.

Then, the last piece is that even for the people who have been widely educated in the subject, or deeply educated, sorry, in the subject of formal methods, the actual effort to get anything of significance done was insane, right? When I give you the example of A plus B equals B plus A, for someone who knows what they’re doing and doesn’t already know the answer, that might take them an hour to prove. This is a fact that every elementary schooler is taught and accepts and they’re fluent in its use, and it still takes someone who knows what they’re doing a decent amount of time if they don’t already know the answer. And so, this is where the LLM stuff gets really, really interesting. And that’s because I think that LLMs are uniquely suited to the proof side of this work. Some of the things that you’ve seen kind of going around Twitter, or just as the industry collectively understands what LLMs are good at and what they’re not, is that for people who can accurately specify what correct means and have a good level of precision in saying what that is, having the taste to be able to decide what that is, the output that they get from LLMs is quite good. If they don’t have that ability, that’s where you get slop. And this is either because you weren’t sufficiently specific, and maybe the lack of specificity has something to do with the clarity with which you speak the language to Claude and define what you want; or it comes from a lack of clarity of mind, where you don’t actually know what it is that you want, and that’s why you didn’t say it to begin with. Murch?

Mark Erhardt: I mean, that is just a skill that generally translates, right? In order to assess whether somebody knows what they’re talking about, you need to have a certain acumen in the topic in order to assess the quality of what they’re saying. So, really, the skill to assess whether the output of an LLM is useful is, you would be able to do it yourself, or if you would be able to do it yourself, you are much more capable at assessing and leveraging the LLM. I think it was AJ Towns, I saw a tweet yesterday, in the context of how only software engineers are not upset that their jobs are being automated. And his take was, “Well, gee, why are lumberjacks upset that they’re only being handed chainsaws?” So, yes, for programmers who have been all their professional life trying to express formally what exactly is happening in a program, it’s not such a big change in pace to very precisely instruct a very hardworking, but not very smart agent, to do your work for you, so we get huge leverage on our work.

Keagan McClelland: Exactly, yeah. And so, what’s even more interesting than that, or sorry, not even more interesting, but it kind of builds on that, is that for most programming languages, it’s true that if I have a function that I’m trying to write that’s supposed to do a certain thing and we can agree what it’s supposed to do, I can write three or four different copies of the code and there’s still some ordering of what might be better or worse between those four different implementations. And we can kind of maybe disagree about which ones are better, but this ordering can form because we have different values, because not all of what is correct in what the function does is purely expressed in terms of its “correctness”. There’s other things at play, like performance characteristics, whether or not something is readable or not, and these things matter.

But in proof engineering, it’s actually a little bit different, where if you have a certain claim, and I’ll try to give more examples so that people can grab onto something concrete. Let’s say that these two functions are inverses of each other, so that for any input, if I run it through one and then I run it through the other, I get the original input back. So, encoding and decoding serialization on the wire is a great example of this. You might be able to write different encoders and serializers that have different performance characteristics, but by and large, if you can prove that they’re inverses of each other, and you have four different proofs that take different approaches to proving this fact, all four of those proofs are essentially equivalent. In math, where proofs were much more common before, proofs had two roles. They were both trying to prove that the conjecture was correct, but then also, very often in finding a proof of that conjecture, you would reveal deep insights about the field.

Formal verification is slightly different in that that second one, we don’t really care that much about. We only care, does the software do the thing that we think it does? And how you get there doesn’t matter so much. So, this is what’s really nice, is that because the proofs are very easily checked, in that there’s a very mechanical, dumb, no-AI process for checking whether or not a proof actually proves the claim that has been presented, and because we don’t care about how it gets there, once we have that specification for what correct means, we can turn the LLM loose on it. And as long as it passes this very small check, very dumb code that actually verifies the proof, we can just be on our merry way. And then, not only that, but the future of this I think is actually substantially better than it is today. And that is because the reason LLM coding agents have gotten so good in the last year is primarily due to reinforcement learning. So, what reinforcement learning is, is that you set up an agent in a harness, you give it a task, and you give it some sort of criteria that it can use to evaluate whether or not it’s correct. And depending on that process, it’ll try, it’ll evaluate, and then it’ll try again until it actually gets there.

What’s very nice about proof assistants is that they have a very narrow specification for what is correct. They give you a language for being ultra precise of exactly what correct is in ways that Python says it does not. And as a result, it means that the reinforcement learning harness can converge, not just in terms of the agent trying things on your computer as it’s coding, but even in the training environment, it will start to be able to climb the slope of improvement much, much faster than it will in Python. And so, per unit data that gets generated, proof assistants or LLM coding agents will learn faster how to get good at Lean than they will learn at Python. So, even though Python’s training corpus is much, much larger, it’ll actually probably get better at writing stuff like Lean faster.

Mark Erhardt: Yeah, so one of the interesting things is once you have an implementation that you know to be correct, you can compare that another implementation behaves exactly the same way in all of the edge cases. So, while the proof code may be very inefficient, it will be efficient enough to run a few tests on it. And if you, for example, have a fuzz harness that you have been training on Bitcoin Core, which is a pseudo random way of finding all the edge cases in a piece of code, you could turn loose all of those fuzzed test cases on the prover, and/or have an LLM generate all those test cases in some other way that can be consumed both by the formally verified software and the underlying system you want to check against. And you can turn this into sort of a correctness harness.

Keagan McClelland: Exactly. And so, I don’t know kind of where you want to take this conversation. I could talk about this endlessly and I know I’ve been talking quite a lot just myself already. So, maybe I want to turn it over to you guys, and we can talk kind of whichever direction you guys want to go with it.

Mike Schmidt: I had a low-level question, which I think you answered in a high-level question. The low-level question, it sounds like it’s solved by LLMs, but Brink had on Russell O’Connor early maybe last year to talk about, I mean he put out a paper on, I think it was a formal verification paper on safegcd. And then, he walked us through an example in video chat like this, of doing formal verification of a multiplication function in libsecp, and it was an absurd amount of artifacts. So, my first question was that, like how are you going to do that for the Bitcoin protocol? But it sounds like the answer is use those same or similar types of tools which I think he mentioned, Rocq and C, LightGen, or something, and you use those similar tools but you’re using it with LLMs who are maybe good at this with the proper person guiding them; is that right?

Keagan McClelland: Yeah, and I will say this. As I’m working on btc-verified, there’s a whole range of things that people can do when vibe coding right? And I have a very high-touch approach to vibe coding. So, I’ll maybe give a very large prompt to Claude or Codex, or I haven’t really tried Grok lately, but about my preferences and how I want to structure things, which is just informed by my own sort of intuition and taste and experience. And then, it will generate something in terms of a specification, and then it’ll generate the proofs for it as well. I don’t look at the proofs at all, but I’m very, very nitpicky about the specifications, (a) for correctness, but also (b) because there’s different ways to structure it such that it fits nicely together and we can build up this hierarchy of understanding; but also, just to make sure that things aren’t being duplicated and that there aren’t subtle errors in the way that the specification is written. Because even if the proof checks out and you’ve proven that the code meets the spec, if the spec itself doesn’t match reality, then you haven’t really gotten anywhere.

But what it does do is it very much compresses the surface area of attention. So, when someone reviews Bitcoin Core, not only do they have to review the overall architectural structure of whatever code goes into the codebase, but they also have to review whether or not the implementation actually satisfies the conditions. Now, good engineers will oftentimes write high-quality tests, and their tests will ideally be something that is invariant-driven as opposed to example-driven. I’m actually a firm believer that example-driven tests are a way to produce false confidence, where if you know that 3 plus 5 equals 8 and that’s the only test you write, then there’s a million ways you could write the addition function that just happened to accidentally get that one correct. And even if you have a handful of those, the more examples you put in there, the more likely it is that you’ll get the right answer even from examples. But then, the funny thing is that as you start to do that, you just approach an invariant-style test anyway, and so all these proofs and the theorems really, but the equivalent in formal verification of a test is a theorem. So, what you would write is like, for all transactions, that if we decode them after encoding them, we get the same exact transaction back and vice versa.

So, once you have that invariant, that variant’s also much more interesting and much more elucidating in terms of how the protocol works, because I could give you a bunch of tests and someone could squint at the test and be like, “How do I know this test is right”. With 3 plus 5 equals 8, it’s easy for anyone to see. But even for really, really experienced engineers who know the Bitcoin protocol forwards and backwards, if I give you an example test like, “Hey, this secp signature using this nonce over this transaction is this thing,” no person could look at that and be like, “Yeah, that test is right”. But you could absolutely look at a test that says like, if you have a same transaction, use two nonces, you should get two different signatures. Almost anyone who knows cryptography should be able to express that invariant, look at the test, and see that the test is actually testing that. And then, whichever values you use is actually irrelevant. And so, it just takes it to the natural extreme here.

Mike Schmidt: The big-picture question is okay, so what do we do? What’s going to come out of btc-verified? I mean, obviously there’s a lot of Core-based nodes on the network. And so, what does btc-verified look like? And then, how does that impact the practical composition of the network?

Keagan McClelland: So, it’s actually really important to say that I personally, at least in the near future, do not believe that people will run nodes that are btc-verified. Now, maybe that’ll come about one day, but there are a lot of hoops we have to get through first. And I think that this is not a project that has no value if we stop short of that. So, the first thing really is that right now, the Bitcoin development process has a rotating set of contributors, and it has a very imprecise way of talking about how changes happen. If you have an idea for how to improve the Bitcoin protocol or the codebase, you will go to the forums or you’ll go to the GitHub repository, you’ll open an issue, there’ll be debates there, and those debates will take place in nominally English. And depending on the thread, it might be a very high-quality English debate, or it might be a very low-quality one. But the bottom line is that there’s a lot of imprecision in it. And this is important, it’s useful, but there’s still a lot to be desired there. Moreover, when those debates get settled, we don’t have a sort of referenceable artifact afterwards that says, “Hey, actually, when these two people argued it out, we actually discovered this important truth about the protocol that is worth remembering and stating concisely”.

So, btc-verified has the potential in this case to essentially be this living body of knowledge about the protocol that never actually runs on silicon. We may very well continue in a world into the future where everybody’s running Core or some fork of Core, and this might not be run by anyone. But still, it will produce this compounding proof capital that helps crystallize our understanding of what Bitcoin is, all the different paths that we could go down that are wrong, and why they’re wrong, and have ways to point to the artifacts from that and say, “Hey, this is why we didn’t do that”. Because right now, if a new contributor comes to the forums and asks a question that’s already been asked, maybe Greg Maxwell is patient enough to answer it with a really nice, coherent essay that someone can reference after, and he’s doing God’s work when he does that. But that isn’t always what happens. There are some times where people just get dismissed and they’re like, “Yeah, we talked about this before. Shut up and go away”. And that’s not satisfying for the person who comes in, right? It’d be nice if they could get a citable reason, because then at least, this person, in a lot of cases, maybe there’s spam, but sometimes, a lot of times, people are coming in with good intentions, and they’re just naïve and new. And it’d be nice if their interaction with that process generated knowledge within themselves that they could come back in a future iteration and contribute to the protocol again, especially since people don’t want to do this forever, presumably; maybe they do, they don’t. But it’d be nice if we didn’t lose a lot when people decided that they’re kind of “retiring” from Bitcoin protocol development.

Then, because of that structure, that structure is also amenable to evaluating potential changes. So, if we have a complete description of how the protocol behaves now, and we want to change something about it, it’d be nice to know all of the theorems that no longer hold, or all of the ones that do hold, and ask whether or not we’re okay with those things. And that’s just on the protocol side. From there, you can ask questions about whether or not the actual implementations within Bitcoin Core or btcd, or pick your favorite implementation, actually satisfy these more abstract properties that we as users come to expect out of the protocol. One of the canonical examples here is that everyone knows there’s only 21 million Bitcoin, right? But how? Why is that true? There’s nowhere in the code where you can find the constant, 21 million. Maybe you can in documentation. And there’s that famous equation that does the summation over all of the halving epics that gets you there. But even that equation doesn’t exist anywhere in the Bitcoin codebase. It’s a derivative property of the way that the code is written. And so, btc-verified is very amenable to that type of analysis. If you have the way that a thing is written, like the emission schedule of block subsidy, you can say, “Here’s a theorem. For all time, there will never be more than 21 million Bitcoin. And, oh, by the way, here’s the proof”, and that proof is then anchored in the actual algorithms that actually run in Bitcoin Core.

Mike Schmidt: You mentioned some other projects, I think, doing something similar, and if you didn’t, we can bring up Hornet, who we had Toby on, are you familiar with Hornet node and what he’s been working on there?

Keagan McClelland: Hornet has been brought to my attention recently. I will say this. The Hornet sits kind of on the spectrum between btc-verified and what Bitcoin Core is doing. Right now, the consensus rules are written in C++, like normal, executable, software-engineering, battle-tested C++, but that does not make them amenable to legibility. So, if you were to open up the consensus module within Bitcoin Core, it would still require some knowledge, experience, skill, etc, in order to be able to make heads or tails of what those consensus rules are actually saying. Now, things have improved significantly over the course of Bitcoin’s lifetime. The quality of them now is much better than they were maybe ten years ago. But the reality is, it’s still written for the purposes of execution and not for the purposes of understanding. My understanding of what the Hornet Node project is – you said Toby – my understanding of what that is, is that it’s a DSL domain-specific language written in the C++ ecosystem that allows you to express these consensus rules in a much more easily-readable-to-the-average-person way, such that then they get compiled, I mean it is technically a compiler chain within the C++ ecosystem, then translates it down into what actually executes. But the problem is, is that it’s still limited to what C++ is capable of, which is not a full dependent type theory. And as far as I understand it, my skimming of the archive paper that was put out that was about Hornet Node, is that it does not actually make any attempt to put a dependent type theory into this language.

So, there’s still a very, very large number of invariants that you might want to express about it that you cannot, because you do not have things existential quantification or event, to a lesser extent, you can’t move terms and types between each other, which is a really important part of proving properties about code. But it’s a lot better than what Core has shipped today in terms of this ability to understand and test and verify things. It’s also worth noting that I would really to see this, and maybe this is a failure on my own part, but I have not seen actual source code for Hornet Node. I’ve seen the paper and the associated website. But it’s rather strange to me that something that purports to try to increase legibility and verifiability doesn’t have source code published. But maybe it’s forthcoming, or maybe I just failed to see it, but I couldn’t find it when googling it last week.

Mike Schmidt: Maybe I’ll connect you and Toby if you’re interested, but I definitely want to make sure that Murch or Gustavo or Andrew can also ask some questions as well. Anything else, fellas? Okay, Keags, people are interested, they’re listening right now, what do you want them to do? How can they take the next step and help you or contribute in some way? What’s the call to action?

Keagan McClelland: So, I’d say if you’re interested in formal methods and applying them to Bitcoin, definitely take a look at the GitHub repository. I have tried to be very aggressive in putting the roadmap into the issues and milestones about how I’m doing this. I will request a little bit of patience because I think it’s still early in the project, and so certain architectural decisions about essentially separating computational artifacts from mathematical artifacts is still really important. And naming things such that we don’t have – like, part of the goal of the project is to make it very clear and consistent how we understand the protocol. And so, there is, like, for PRs that have gotten external contributions already, and I have nitpicked them a little bit, so I promise it’s not because I hate your code, it’s just I want this to be a durable, living artifact that can help increase the institutional knowledge of the Bitcoin protocol development process. And otherwise, I would say if you’re not well versed in formal methods at all, but you’re still interested, definitely come and check it out and take a look, because I don’t think that there’s been a better time to try to get into that space than now, especially because of that major cost reduction from LLMs. And like I said, that cost reduction is one of the more uniquely free cost reductions in all of software engineering.

Mike Schmidt: Keagan, thank you for taking the time and joining us today. We appreciate it.

Keagan McClelland: Yeah, thank you for having me on.

Bitcoin Core 30.3

Bitcoin Core 29.4

Mike Schmidt: You’re free to hang on or you’re free to move on if you have other things to do. We’re going to jump to the Releases and release candidates segment this week. We have two, and we’re in luck, because they’re both Bitcoin Core PRs. We have Murch here, we have Gustavo, who authored the segment, and we have Andrew, Core developer and also contributor to some of what went in here. So, Andrew, you volunteered to help walk us through this. Take us where you want.

Andrew Toth: Yeah, sure. So, so there’s a Notable change in these two releases, and it also was a change that was in 31, the point release that was covered last week, which is a bug that would overwrite the chainstate repeatedly and cause a lot of unnecessary disk I/O. And so, I worked on fixing this, and so I can speak to the bug and give a little background about how it came to be. So, I want to say that this was a longstanding issue before even version 29. It just wasn’t as severe. So, in previous releases, there were issues. Well, there was an issue in the Bitcoin GitHub from a user frustrated about database compactions occurring every time the node was started. And then, there were other users who were experiencing this. It was being investigated, but the root cause wasn’t determined yet. And looking back, the issue was that every time the node was stopped, the chainstate was flushed, so a small file was written to the chainstate database. And then on startup, when we verify the chainstate, we read, I think, six blocks and connect them. And that caused a lot of reads that happened on the chainstate directory. And so, that last file that was written on shutdown gets compacted. And so, this was an annoyance, but it wasn’t really a severe bug. Yeah, go ahead, Murch.

Mark Erhardt: Sorry, what does it mean, “This small file got compacted?” You said there was a lot of disk I/O. If it was only a small file, what was actually happening here that made it a lot of disk I/O?

Andrew Toth: So, the LevelDB works by having levels. That’s why it’s called LevelDB. And the levels are a tree. So, the top level is the latest written entries. And then, as these files either get too big or they used to get read a lot, they would be compacted to a lower level. Each level has ten times as much space. And so, when we look up something from LevelDB, it first starts reading for entries at the top level, and then it finds the direction to take to the next level, and it keeps going down the tree until it finds the file it needs. And so, when we flush the chainstate, we are writing the diff of everything that happened in the UTXO cache. So, any transactions that were connected in recent blocks will erase UTXOs and create new UTXOs. And that change exists in the cache only until we write that to disk. And when we do a chainstate flush, which is on shutdown or previously, every 24 hours, we would write that as a file to the chainstate database, and that would be a small file.

So, this wasn’t really a huge issue before, because I was going to say, in v29, we made this problem worse, because we made a change to the LevelDB default file size. We increased it from 2 MB to 32 MB. And this was done for the purposes of speeding up IBD (Initial Block Download) and index syncing. And so, you can see in Lawrence’s charts, there’s a big drop from 20 to 29 in IBD speed, well, drop meaning less time.

Mark Erhardt: Drop in time, a speed up, yes!

Andrew Toth: And so, there’s a big speed up in v29. This is primarily due to this one line change, where we changed the LevelDB file size. But that had a side effect, right? So, now all the files are 32 MB. So, if a small file is being compacted in the chainstate database, every entry is random, right, because they’re SHA256 hashes, they’re txids and a vout. And so, a small file in this database would have keys in pretty much every other file in that database. So, if it’s compacted, each entry has to find its corresponding file in the lower levels, and those entire files get rewritten.

Mark Erhardt: Right. So, basically, our intermediate solution is to put a stack of documents on the file cabinet. And then, when we find that we are looking up a lot of stuff all the time, we actually put it in the hanging folders in the file cabinet. And if we have a bigger stack, we have to touch a lot more drawers in the filing cabinet.

Andrew Toth: Yeah, so each file, though, would have a bunch of stuff in it and if you were going to take one file from the top and put it in, you would have to actually take all those papers out and put them all into a new folder, right? You couldn’t just stick one into the folder, you have to rewrite that whole file. And so, previously, those folders were smaller. And so, if you had five pages, you’d only pick five small files and rewrite those. Now, these lower folders are much wider. So, they pretty much take up, if you have five pages, they would take up all five of those and you’d have to re-put in five new ones. It’s a great analogy, Murch, thanks.

Mark Erhardt: So, our stack got 16 times the size and the drawers got 16 times the size. So, if we open a drawer and have to reorganize the whole drawer, it affects 16 times the data, so probably 250 times, or something, the data touched?

Andrew Toth: Yeah. I mean, so right now, every time we did a compaction, it would be about 15 GB of read and write. I’m not sure before, I haven’t really measured what it was before, but it wasn’t noticeable before; I’ll get to why I didn’t notice it before. So, in theory, because our files are now 32 MBs, that first file that’s on top of the file drawer, we should be able to fit 16 times more data before we have to then take that and put it down. The issue is LevelDB has this feature, called seek compaction, which is if you are just reading from this folder, if you read enough times from it, you have to compact it before it’s full, which is an anti-feature in my opinion. And so, what happened was, in v29, every 24 hours when we would write that small file when we flushed our chainstate, we would then get lots of reads immediately after on the top file, because every mempool transaction that comes in, we have to look up the UTXOs they’re spending. And that causes a read on the first file as it goes to find its other files; they’ll always hit the first file. And that exhausts the read budget on that folder and would cause it to compact.

Then, in v30, this got even worse, because now we write a small file every hour instead of every 24 hours. And so, when I was making that change to write every hour, I did I/O measurements on seeing if this was an issue. But the measurements I did was before that change of file size was merged. So, that’s some learning we can do to make sure that we remeasures things that right before we’re merging or before the release goes out. So, this wasn’t really reported by anyone until v31, and then we got a slew of reports that there’s hundreds of gigabytes of disk I/O happening. And this led us to discover that it was seek compaction. And so, the fix there was to just disable seek compaction in LevelDB, and now we’ve backported that to v31, 30 and 29.

Mark Erhardt: Right, so it had been a great focus in the last few versions to improve IBD. And as it goes, when multiple people focus on working on the same sort of area, changes synergize or maybe affect each other. So, in this case, specifically, the one thing that was introduced was we used to only flush the UTXO state every 24 hours, but you improved that by allowing it to be flushed every hour, which means if, for example, a node crashes, it will not lose as much progress. And you also introduced that the cache was kept hot, or warm, I should say. So, only the, is it the dirty UTXOs are being written out, whereas the ones that were just loaded and not changed, they’re kept in the cache unless the cache is full. Only when the cache is full, we flush it completely to disk. If the cache has only been sitting for an hour, we write out all the changed UTXOs to the chainstate database, but we keep the ones that were just loaded. So, this meant that the UTXO cache would fill up less often, and we would lose less progress if the node happened to crash. But then, in combination with making the file size bigger in level DB, you ended up having the flushes much more often, the files getting sorted into the cabinet much more often, and touching way more off the cabinet at the same time. And now, suddenly we got a lot of disk I/O as LevelDB basically got rewritten, what, every hour?

Andrew Toth: Yeah. I mean, so the main issue was that LevelDB has this anti-feature called seek compaction. And without that, it would never have rewritten, because we could still write every hour and it wouldn’t compact until that file gets full to 32 MBs, right? With seek compaction, as soon as we put a new file there, all the mempool transactions would read it and it would cause it to flush way too prematurely.

Mark Erhardt: So, in sum, we got a few new features that make IBD faster. And now that they’ve been out in the wild, we’ve also found out a couple of the bumpy corners and padded them. Maybe this is a good point to lead over a little bit. Oh, maybe one more word. So, we talked about Bitcoin Core 31.1 released last week, and I bumbled through trying to explain the chainstate issue that Andrew just explained. So, that was what I was trying to say. And other than that, basically, these are the three currently active major branches: 29, 30, and

So, all these bug fixes and improvements have been backported as appropriate to the major branches. If you’re, for example, trying to stay on major v29 for some reason, you can get all the new features or fixes by upgrading to 29.4 – sorry, not all the new features, just the fixes. The features are only released in major.

Bitcoin Core #35295

So, how about we use that as a lead over to another improvement to IBD in our Notable code and documentation changes segment? So, we mostly invited you for this one, which is Bitcoin Core #35295, and you’ve been working on this for almost two years. I see that there have been over roughly, well, around 1,000 or so review comments, maybe even more, because it was split up over several different PRs after a while. So, you’ve made a major improvement on how we load UTXOs from the disk when we validate blocks. How about you take us a little bit through that?

Andrew Toth: Sure, yeah. So, you were touching on that too when you mentioned that we keep the cache hot now over flushes. So, that was a big improvement, primarily that was initially done to keep the cache hot over steady state, right? So, every 24 hours, we would flush the cache. And then, right after we had flushed the cache, new blocks coming in would be connected slowly. But then, that was a segue to then keeping the cache hot for pruning flushes, which improved IDB for pruning. And really, keeping the cache hot means that anything in the cache, when another block comes and spends it, we don’t have to read that from disk because it’s in our cache. But still, especially in the blocks 800,000 to 900,000, the cache gets too big too quickly, there’s lots of new UTXOs being created. And so, the cache flushes, and now we have to read them again. And so, this change is a speedup to how we repopulate the cache before we read a new block. So, it improves IBD quite a bit, especially on certain systems with high-latency disk.

Also, it improves it on steady state. So, if your cache flushes during steady state, you will now see faster block connection from new miners who produce blocks. And that has a second-order improvement to block propagation too, because if you send a compact block message after you get it, before you validate the block, if your peer has some transactions missing from that compact block, it can’t reconstruct it, it will ask you for those transactions. If you’re still validating that block, it will have to wait for you to finish validating the block before you can respond. And then, that has a cascade effect of how the block could propagate. So, we should see a lot of improvement from this change.

So, the main mechanism here is that when we get a new block, we have to validate it. We don’t know yet if it’s good or not. So, we do some checks that are stateless checks. So, we can check that it’s within the right size limits, the merkle branches are correct, the PoW is correct. But then, we actually have to measure it or validate it with the current chainstate, the current UTXO. So, we have to know that every transaction is spending valid UTXOs, that they exist, they’re not double-spending any UTXOs, and that their UTXOs are being spent correctly, like they’re not forging signatures or anything. And so, to do this, we have to look up all these UTXOs from the chainstate. And we have a cache of UTXOs, but if the UTXO is not in the cache, we have to go to disk and look it up.

So, before this changed, the way the validation code would work is it would go through every transaction’s inputs one by one and look up the UTXO. So, first we go to the cache. If it’s on the cache, it would wait for the lookup to the disk, and then puts that back into the cache, and then gives it to the validation code. And the validation code is waiting for this whole lookup for every input in a row. So then, we’ll do the next input, wait for the lookup, the third input, wait for the lookup. And all this waiting for the lookups stacks up, and certain systems especially would dominate the validation time, just the waiting on these lookups. So, what this change does, it does these lookups much more efficiently. So, we already have this block and we know, even if it’s not valid, we know what inputs the validation code is going to want to look up, because we have the block. So, we use that information to kick off these worker threads to then look up all these UTXOs in the background, and multiple threads at a time. So, we can be looking up eight at a time instead of just one at a time. But also now, this unblocks the validation so that it doesn’t have to wait for that single read. It’s just going to get the UTXO that was already fetched by one of the workers, and then continue validating as the workers are also then fetching the later UTXOs. And so, this parallelization greatly speeds up IBD and block validation in general.

Mark Erhardt: Right, so in steady state when we’re at the chain tip, we generally hear about a lot of the unconfirmed transactions that are floating around in the mempool. When we see transactions, we look up the UTXOs their inputs are spending, and we validate the transaction and cache that validation. Then, when a compact block announcement comes in, which is sort of the recipe how to recompile the block or how to rebuild the block from the mempool and other information we have, we can just look at our mempool and see what is cached there already and very quickly validate the block. For any of the transactions that we haven’t seen before, we have to go to disk and look up the UTXOs. And this is where Andrew’s improvement comes in. Instead of looking for one UTXO that you’re missing and coming back and looking for the next UTXO, and so forth, ping-ponging back and forth, we now, you said, up to eight threads take just a list of things to look up and, well, up to eight things to look up in parallel, and fetch all of them and put them in the cache while the validation thread itself doesn’t have to look it up if it’s in the cache already.

So, basically, there’s a clerk introduced at the start of the block that just takes a list of all the inputs that will appear in the block, and start sending his helpers off to pick up all the UTXOs and put them in the cache already. Whereas the validation thread starts at the top of the block and just goes through the transactions, but the helpers have probably already scurried and gotten the UTXOs. And now, in the steady state, where we’re at the chain tip, where we see the unconfirmed transactions often before the block arrives, there’s very few transactions generally that we haven’t seen when the block comes in. But during IBD, you do not have a mempool, you do not see transactions before they arrive. So, for every block that arrives, and we’re trying to do one per second or more, you have to get something like up to 7,000 UTXOs. Well, I think the biggest block had over 20,000 UTXOs, but generally we have something around maybe 6,000 to 7,000 UTXOs that are being spent in a block. And as you go through IBD and don’t have a mempool, you have to fetch all of these from all different heights in the blockchain, mostly recent UTXOs, but not necessarily. And this is greatly sped up by just taking attendance first and sending off people to fetch everyone to stand ready instead of ping-ponging between the validation thread and picking up from the UTXO database. Okay, sorry, dumbing it down a little bit and recapping.

Andrew Toth: Yeah, that’s great. So, for steady state, I know, Murch, we had a little conversation in the GitHub PR about this as well. So, yeah, usually you have these transactions in the mempool and then you won’t have to look them up from the disk. So, this change doesn’t have a dramatic effect. It still does, because you’re doing some hashing work to look up these transactions from the cache in the background, so it speeds it up a little bit. But one instance where it does have a dramatic effect is if you fill up your DB cache and then it has to empty, that doesn’t mean your mempool gets cleared. So, a block will come in, you’ll find all these transactions in the mempool, and then when you go to validate the block that you’ve reconstructed, all those values will be erased from the DB cache. And so, I was seeing really bad block times when the cache was cleared. And so, if I was running on an AWS EBS volume, EC2 EBS volume, they have about one-millisecond latency. And so, you have, like, 10,000 inputs, that’s 10 seconds of just looking up blocks. So, sometimes block speed at tip would degrade to 10 seconds. And so, this change helps in this worst-case scenario to really help speed up block validation.

Mark Erhardt: Right, yeah. So, sometimes miners just stuff a block full of transactions that you haven’t seen before. And in that case, you’re basically in the same scenario as in IBD, where you haven’t seen anything and you have to just load very quickly; or if your cache is empty.

Andrew Toth: But also, not just if you haven’t seen them, but if miners are mining non-standard stuff. Or, like, you’re on a different policy than the miners.

Mark Erhardt: Right. You can also put that on yourself that you don’t see them, but you still haven’t seen them, right!

Andrew Toth: Yes!

Mike Schmidt: Andrew, what are the headline numbers here in terms of performance?

Andrew Toth: I mean, it varies depending on your system a lot, but we haven’t seen any system that was less than, I think, 50% faster. And for network-connected storage like I was experimenting with, if you’re running on AWS, I saw up to three times faster IBD. So, it ranges, I think, typically about 35% if you’re running on a laptop or something.

Mike Schmidt: Very cool. Nice work, Andrew. Awesome.

Andrew Toth: Thank you.

Mike Schmidt: Murch or Gustavo, I just want to close out the Releases. Was there anything else that we should note from the Releases? I know we dug in on the chainstate discussion.

Gustavo Flores Echaiz: I think another important item from both releases is the inclusion of the PR #35209, which was a fix to the CVE bug found in CVE-2024-52911. I believe these are the first maintenance releases to include this in 29 and 30. So, this was initially covertly fixed in v29, and then there was a cleaner fix that has been shipped in these two maintenance releases as well. So, those are the two main items of these releases. Also, 30.3 has additional items related to PSBT and miniscript, but they’re all quite minor. 29.4 almost has these only two items. It does have other things that are way, way less minor, but anyways, listeners can check out the release notes for further details. But what Andrew’s explained was the main objective of these main releases.

Mike Schmidt: Great.

Mark Erhardt: Sorry, could you remind us what the CVE was that was fixed? I didn’t get that from our newsletter.

Gustavo Flores Echaiz: Yeah. So, this was something we covered a while back. It’s CVE-2024-52911, which was an issue that was fixed initially covertly, and then this fix was a clean fix. So, give me just a second to pull from the previous newsletter to remind me.

Mike Schmidt: Correct lifetime of precomputed transaction data.

Gustavo Flores Echaiz: Yeah, so in Newsletter #405, we covered the PR #35209, which was addressing the root cause of this issue. It was now constructing the txsdata vector before the CCheckQueueControl object, because what it says is that, “C++ destroys local objects in reverse construction order”. And now, we were ensuring that the script check queue was completed before the precomputed transaction data, referenced by the queued CScriptCheck, was destroyed. And this also was referenced in Newsletter #333, when the covered fix was shipped. But the CVE issue was simply covered in Newsletter #405, and the full-on fix was also included in that item. So, yeah, so #405 is where all the details are.

Mark Erhardt: All right. I think this was the one where you could build an attack block that had to have very specific transaction data in it that could cause you to have the transaction dereference before you try to read from it. And then it would crash, or could crash, because of undefined behavior. Is that the one?

Gustavo Flores Echaiz: Yeah. So, basically, it says, “Script Interpreter Remote Crash disclosure, a vulnerability affecting versions of Bitcoin Core after version 0.14.0 and before 29.0. Validating a specially-crafted block could cause the node to access previously freed memory”. And yeah, so it’s exactly what you described.

Mark Erhardt: All right, thank you for the reminder.

Mike Schmidt: Gustavo, do you want to pick up where we left off on the Notable code items?

Gustavo Flores Echaiz: Yes, certainly.

Mark Erhardt: Do we have one more for Andrew?

Bitcoin Core #35568

Gustavo Flores Echaiz: Yeah, there is one more for Andrew. So, maybe we can just skip to that one directly, which is #35568. It was disabling Bloom filters to optimize disk usage in the txospenderindex. So maybe, Andrew, you want to give us the details on that one?

Andrew Toth: Yeah, sure. So, that’s another LevelDB optimization. So, txospenderindex is a new index that was released in 31 that lets you look up the transaction that spends your output, I think. And it’s a fairly beefy database, right, it was almost 100 GB on disk. And the way it reads values though is a lot different than other indexes. So, it was using an iterator to look up a prefix of the outpoint that was being spent. And it would seek to that prefix, and then it would try and read that prefix. And if that prefix was a false positive, it could just iterate to the next prefix. This lets us store that data efficiently. But the thing about that is that it doesn’t need to use the Bloom filters. So, Bloom filter, for those who don’t know, is a data structure that lets you efficiently query if a value is not in a set. So, if you look up, “Is this value in a set?” You can 100% guarantee if it says no, then you can move on, because that item is not in that set. If it says maybe, then there’s a high chance that that entry is in the set. But then, depending on how you configure it, I think in our DB, we have about a 1% false positive rate, so you always have to check if it’s in there. It might not be in there, you might be getting a false positive. But the point is that you can move on if it’s not in there.

So, these Bloom filters are used in all our LevelDB, or they were used in our LevelDB databases, to allow point reads to be able to skip files. Like we were talking, there’s a tree of files, right? And if you are looking up an exact file, you have to go through each file in the tree until you find the correct one. And you would have to actually go through each file and look at all of them to see if it’s not in there. But with Bloom filters on each file folder, you can just consult the Bloom filter and know definitely, if that file is not in this folder, we can just skip it and not have to do any reading and move on. And this is great for the chainstate database, because we’re looking up exact UTXOs. But for this case of the txospenderindex, we are just seeking with an iterator. So, because we’re looking up a shared prefix and we have to look up anything greater than that prefix, that’s how the seeking works. A Bloom filter doesn’t know anything about the set that’s in there, whether anything is greater than or less than a key. It just knows, “Is this particular specific, exact key in there or not?” So, we can’t use that Bloom filter construct for this type of read pattern.

So, creating these Bloom filters for every folder is work, and it’s also data on disk that we have to store for that folder. So, by disabling the Bloom filter, if we’re not needing it, we save both time and disk space for this database.

Gustavo Flores Echaiz: And if I understand correctly, these filters were inherited in this new index because they’re also used in other indexes, but then it was realized that it wasn’t necessary to be included here?

Andrew Toth: Yeah, that’s exactly right. So, by default, we put this Bloom filter on all our databases. And so, now the way this PR worked, it made putting that Bloom filter an option. So, in the future, we can reevaluate our other database usage as well and remove this Bloom filter if it makes sense to do so. But in this case, it’s also backwards-compatible. So, if you already created your txospender database and you upgrade, you won’t have to do anything. You will still keep those Bloom filters existing, but you won’t use them. So, if you want to reap these space savings, you need to delete and re-index, and that’s an option that users will have in v32.

Mark Erhardt: Let me try to sum it up as I understood it. So, basically, we have something called a Bloom filter for our databases and Bloom filters enable us to know for sure if something is not in a drawer, but we might sometimes get a false positive. So, we always get true negatives, but sometimes false positives; you said 1% right? And this Bloom filter enables us to rule out drawers or folders if we’re looking for a very specific file. But when we’re looking for all files that start with the letter A, we can’t use it because we can’t feed a prefix into the Bloom filter and rule out things. So, we weren’t actually using the Bloom filters at all in this case, and they were just obsolete. So, deleting them makes it faster to run the index creation and it makes the index smaller. And in this particular case, we were not using them at all because they weren’t useful.

Bitcoin Core #34897

Gustavo Flores Echaiz: Thank you, Murch and Andrew. So, the next item, we go back into the regular order. The next item was Bitcoin Core #34897. So, here, an issue was found where an index, such as coinstatsindex could get further ahead to the UTXO state that had been flushed to disk. So, in an unclean shutdown, this could cause the index to be ahead of the chainstate’s latest flush, and it would create an inconsistency between the two databases. And this was particularly a problem for coinstatsindex, which MuHash state to roll it back requires reprocessing the corresponding blocks, or the corresponding UTXOs that had been lost and had not properly been flushed to disk. And this occurs because the finalized digest that is produced per height, the per-height record in the coinstatsindex, is a SHA256 32-byte hash of the live accumulator of each height. So, you do have the live accumulator of the current height, which means all the stats of the UTXO chainstate database, so how many UTXOs are active, and so on. But if you wanted to roll back this database to the tip where the chainstate had been flushed to disk, you would require those blocks that were not safe to block, because simply you cannot revert a hash without its previous data.

So now, the fix is for Bitcoin Core to always ensure that an index, such as coinstatsindex, will never get ahead of the chainstate’s last durable UTXO flush by skipping a commit, unless the index tip is an ancestor of the last flushed chainstate block. And yeah, that’s it. Anybody want to add any context here?

Bitcoin Core #35406

We move on with the Bitcoin Core item #35406. So, here, a new limit is added to the private broadcast feature, which we covered in Newsletter #409, which allows you to choose a short-term circuit or a short-term connection to broadcast a transaction with a different identity, also called the private transaction broadcast. So, this feature has a tracking queue, which are the transactions that have been broadcast to one peer only in this short-term connection, and were waiting for our other peers to send us back that transaction, and that would allow us to prove that it was properly broadcasted. This is the tracking queue, these transactions remain here until they are received to our node by another peer. However, the issue here was that if you would have policy differences with the peer you are sending this transaction to, then he would never relay it onto other peers and onto the network, and you would simply never get it back. So, you could potentially have an unlimited tracking queue that would consume an enormous amount of resources. And here, there’s a cap to 10,000 transactions in this tracking queue. Yes, Murch?

Mark Erhardt: I wanted to add a little context on this number and how we submit transactions via private broadcast, and I think Andrew has also looked at this quite a bit. So, Andrew, chime in, please, if you have anything to add. So, private broadcast is a new feature that we added in 31. It’s basically the idea that instead of offering a new transaction to all of our peers, we pick one node in the network, teleport our transaction just to them, and see whether it comes back to us via the open network. So, we make a Tor connection and just connect to one peer that we haven’t made a connection to before and say, “Hey, I have a transaction for you. You got it? Okay, bye”. And so, the idea is that this other peer, hopefully, or this random node in the network, takes this transaction, puts it in their mempool, propagates it to all their peers, and this removes the IP address of the original sender from the transaction, or disassociates them. So, surveillance that have lots of connections in the network will not actually see the node that originated a transaction as the first one propagating it to its peers.

If the first person that we send it to doesn’t forward it and it never comes back to us, we actually retry. So, we will send the same transaction to multiple peers, I think three attempts or so, and only after each of those had a few minutes, we will actually propagate it ourselves. So, the idea that transactions would hang around forever is pretty unlikely, unless we’re sending transactions that are so low feerate that they just never propagate on the network and never get mined. 10,000 transactions are a lot of transactions. That’s about two-and-a-half blocks’ worth of transactions. So, that any node would have these many transactions in their private broadcast queues would be extremely uncommon and a bit of shooting your own foot with a foot gun. Andrew, please?

Andrew Toth: Yeah. So, it’s really just a guard against some kind of misconfiguration. Like you said, we won’t get that node back if it’s a low feerate or if it’s not following policy, non-standard, then we would never get it back either, and we would just keep retrying. And so, we do the three initial tries, but if we don’t hear back, we keep that transaction in the queue. And every, I think, five minutes or so, we initiate another broadcast. And so, if we have poor connectivity so we don’t actually manage to make these three connections, we’ll still keep that transaction in the queue. So, if we have a misconfigured node, then we don’t have many peers, or our Tor goes down, or something, we won’t actually be able to send these out. And so, if you have this hooked up to a system that’s making lots of transaction broadcasts, these can start piling up. And so, this is kind of just guard against us crashing your node. Eventually, your system will get an RPC error saying, “Your queue is full, so abort some of these or see what’s wrong”. But we’re not going to actually crash the node due to this. So, I think that’s a nice safety feature to have for this.

Mark Erhardt: Thanks. Great addition.

Bitcoin Core #35380

Gustavo Flores Echaiz: Thank you guys. We move forward with the next item, which is Bitcoin Core #35380. So, here, the libbitcoinkernel API, which we’ve covered multiple times, and which was introduced in Newsletter #380 as a C header that serves an API for libbitcoinkernel, which enables external projects to interface with Bitcoin Core’s block validation and change state logic, here this API is extended to expose, through a specific view called the btck_WitnessStack view, to expose each transaction’s inputs, witness stacks, and scriptSig to allow an external application to retrieve the public keys either stored in the witness data for segwit inputs, or the scriptSig for P2PKH inputs. So, the goal here is to allow these external applications, like I said, to retrieve the public keys, but it specifically targets silent payment scanners who instead of having to deserialize the raw transactions separately, can simply obtain the public keys of the transaction inputs through this specific view. And this is necessary for a silent-payment scanner to determine whether any of these transactions’ outputs belongs to the wallet. It needs to scan all the inputs, obtain the public keys of the inputs, and then combine it, hash it, with its own scan data to in order to conclude that specifically these P2TR outputs are maybe part of its of its transactions. So, this is what this item covers.

Bitcoin Core #34538

Gustavo Flores Echaiz: The next one, #34538. Here, the option, externalip, which allows a node to advertise an address where it accepts inbound connections and other nodes can connect to, previously if you added an address from a network that was excluded by the onlynet option, if you had configured that option, you would simply get an error and you couldn’t add that address. So, what is the onlynet option? It’s an option that allows you to configure that your node will simply establish outbound connections via a specific network. So, you could say, “I onlynet IPv4”, I only want connections via IPv4. Previously, this was conflicting with external IP, so onlynet was also applying it to inbound connections. I cannot set an external IP from a network that I have excluded via onlynet, and that was the previous behavior.

Now, Bitcoin Core basically says, “The user is manually inserting an address and explicitly configuring an address with external IP. Let’s allow the user to use that, even if it conflicts with the networks that have been excluded via the onlynet option”. And for example, this could allow a node to only establish connections via IPv4 as set by onlynet, but also operate separately in the Tor onion service that accepts inbound connections via Tor and which is configured using the externalip option. Also, important to say that the externalip option isn’t validating whether these addresses will actually work and they’re properly configured to open an inbound connection to the node. So, it’s simply trusting that the user has properly managed that configuration separately.

BIPs #2208

Gustavo Flores Echaiz: The next item is from the BIPs repository. It’s an update to BIP54, specifically its rationale around the invalidation of 64-byte witness-stripped transactions. So, I believe, Murch, you might have something to add here.

Mark Erhardt: Yes. So, BIP authors are supposed to document issues that were raised or concerns as they are being discussed while a BIP is being proposed and reviewed by the community. So, in this case, the BIP54, which is consensus cleanup, just got slightly extended in the rationale section to document the discussion about the 64-byte mitigation that BIP54 proposes, and the alternative that Jeremy Rubin has proposed. So, it was pointed out that either way, nodes that rely on the fix would need to update in some cases in order to benefit from the fix. So, this correction was incorporated. And there’s a link to the debate with Jeremy Rubin and a commentary on why BIP54 still chooses to stick to its initial approach.

LND #10962

Gustavo Flores Echaiz: Awesome. Thank you, Murch. The next two items are from the LND repository. So, first, LND #10962. Actually, both of these items are specifically about auxiliary channels, such as Taproot Asset channels. The first one, #10962, is a specific issue when using the RBF cooperative-close flow that was covered in Newsletter #347, where basically this flow says that either peer can bump the feerate using their own channel funds. Previously, in the other RBF mode, peers had to convince the counterparty to pay for the fee bumps. So, this is an easier flow to fee bump a cooperative-close transaction. So, there was a conflict between this flow and when it was used in auxiliary channels, such as Taproot Asset channels, where basically the RBF flow, when increasing the feerate and choosing a coin to spend, it could accidentally choose a coin that had some overlay asset included in it. So, for example, it was 10,000 sats, but in reality it represented an overlay asset of, let’s say, a stablecoin worth much more. So, this was included in order to fee bump the cooperative-close flow transaction.

But the issue was that the transaction would go on, would get broadcasted onchain, even confirmed, but it would not invoke the auxiliary hooks needed to carry the overlay assets into the closing transaction on the meta protocol that it was coming with. So, technically you could destroy the overlay asset when including this input in the RBF, to add additional funds to fee bump the RBF cooperative-close flow. So now, the fix is simply to make the Taproot Asset channels, or the auxiliary channels as a whole, incompatible with this RBF cooperative-close flow to avoid using coins that would not invoke the auxiliary hooks required to carry the overlay asset into the next state.

LND #10897

Gustavo Flores Echaiz: And the next item, #10897, is a different but related issue. It’s a bit the opposite direction, where when you are trying to increase a feerate, you would skip including an output that was not of a sufficient set amount that would suffice for the feerate increase you wanted. So, for example, once again, a UTXO that represents an overlay asset of a very high value, but a very small bitcoin value, would always get skipped by the sweeper because its bitcoin value was very small, so it was never included. And now, basically the fix is to understand that this output is not simply a Bitcoin output, but it represents an overlay asset, so include it and include another input that can also be used in this transaction to increase the feerate to be able to sweep both of these UTXOs. So, that’s the final item from LND.

BINANAs #21

Gustavo Flores Echaiz: And the final item from the newsletter is a new BIN number assignment, so in the BINANAs repository #21. Yes, Murch, I mispronounced it.

Mark Erhardt: You have to give this more of an Australian pronunciation. The BINANA repository, I think.

Mike Schmidt: There’s an R at the end there too, I think, BINANA(r)!

Mark Erhardt: Okay. The BINANAs are, of course, the Bitcoin Numbers-and-something Authority!

Mike Schmidt: Numbers And Names Authority?

Mark Erhardt: Right, that’s it.

Gustavo Flores Echaiz: Yeah, Bitcoin Inquisition Numbers And Names Authority. So, a new one is assigned to BIP442, BIN-2025-0003. That number is assigned to BIP442, which is the proposal for OP_PAIRCOMMIT. Yes, Murch?

Mark Erhardt: Yeah, so the BINANAs serve two purposes. One is that these numbers are being referenced when you try to activate a soft fork on Inquisition, which is running on the default signet. So, if you want to test your soft forks on signet, you would request that something is assigned a number and then activate the soft fork there, and then you can play around with it on the signet. The other thing that the BINANAs did was a few years ago, when the BIPs repository was not moving very quickly, some developers got frustrated. And the BINANAs repository served as a means to be able to standardize and publish documents. The policy for publishing stuff there is a bit different than in the BIPs repository. My understanding is, well actually, I think I’m a BINANA editor. I haven’t done anything, but when someone opens a PR, they get a number. That’s the process. So, if you need a number for something, you can always go with the BINANAs instead.

Gustavo Flores Echaiz: Excellent, thank you, Murch. And that is the final item from this newsletter and it completes the whole episode.

Mike Schmidt: Thanks, Gustavo. Thanks, Keagan and Andrew, for joining us. Thanks, Murch, for co-hosting. We appreciate your time everyone and for you all for listening, and we’ll hear you all next week. Cheers.

Bitcoin Optech Newsletter #414

2026-07-17T00:00:00+00:00

This week’s newsletter describes a new project to apply formal verification to the Bitcoin protocol. Also included are our regular sections announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

● Formal verification of the Bitcoin protocol: Keagan McClelland posted to the Bitcoin-Dev mailing list and Delving Bitcoin about his effort to formally verify the Bitcoin protocol. Formal verification is a software development practice that aims to prove the correctness of a system with respect to a specification using the formal methods of mathematics. This could help resolve factual disputes about proposed changes to Bitcoin’s consensus rules. Optech previously covered a related project developing a declarative executable specification of Bitcoin’s consensus rules (see Newsletter #402).

McClelland is developing btc-verified, a Lean4 implementation of the verification process. The author provided initial results demonstrating the approach. In particular, he focused on the algorithm Bitcoin uses to compute the merkle root, which contains a known flaw (CVE-2012-2459) that can cause two different transaction lists to produce the same merkle root. Bitcoin Core’s merkle-root construction includes a check meant to detect this mutation. McClelland used btc-verified to formally prove that the check is correct and that no two distinct transaction lists can pass it and produce the same merkle root under the assumption that SHA256 is collision resistant.

Finally, the author asked for feedback from others both on the repository and on the general approach. He also provided some disclaimers, such as the heavy use of AI in the repository, and the current immaturity of the project.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

● Bitcoin Core 30.3 is a maintenance release of the predominant full-node implementation. It fixes a chainstate database issue that could cause excessive disk reads and writes during normal operation, along with wallet, PSBT, miniscript, networking, build, test, and documentation fixes. See the release notes for details.
● Bitcoin Core 29.4 is a maintenance release of the predominant full-node implementation. It fixes the same chainstate database rewrite issue as 30.3 and includes selected validation, wallet, build, test, documentation, CI, and compatibility fixes. See the release notes for details.

Notable code and documentation changes

● Bitcoin Core #35295 speeds up block validation by fetching the coins spent by a block’s transaction inputs in parallel. Before validation begins, Bitcoin Core starts several worker threads that retrieve different previous outputs concurrently, while the main thread processes the block in the normal order. The new -prevoutfetchthreads option uses eight workers by default, allows up to 16, and can be set to zero to disable the optimization. This change prevents the latency of many disk reads from accumulating sequentially. Depending on the hardware and configuration, the author’s benchmarks show initial block download (IBD) speedups ranging from 1.18 times to over three times faster.
● Bitcoin Core #34897 ensures that optional indexes never persist state ahead of the chainstate’s last durable UTXO flush by skipping an index commit unless the index tip is an ancestor of the last flushed chainstate block. Previously, an unclean shutdown could cause Bitcoin Core to restart with the chainstate at an earlier block than the index, creating an inconsistency between the two databases. This was particularly problematic for coinstatsindex, whose rolling MuHash state is difficult to reverse without reprocessing the corresponding blocks, which would then be unavailable in the chainstate. While the index can process newer blocks in memory, it now waits for the chainstate to catch up before saving that progress to disk.
● Bitcoin Core #35406 limits the private broadcast tracking queue to 10,000 transactions (see Newsletter #409). Transactions broadcast using this method are tracked until they are observed returning from the network. Previously, the size of the tracking queue was unlimited, so transactions that never returned due to policy differences could accumulate indefinitely and consume unlimited memory and CPU. Once the limit is reached, Bitcoin Core rejects new submissions without removing existing entries. Users can inspect the queue with getprivatebroadcastinfo and remove stuck transactions with abortprivatebroadcast.
● Bitcoin Core #35380 extends the libbitcoinkernel API (see Newsletter #380) to expose each transaction input’s witness stack and scriptSig by adding a btck_WitnessStack view and functions for counting, retrieving, and copying its elements. This allows external applications, including silent payment scanners, to retrieve public keys stored in segwit witness data or P2PKH scriptSigs without deserializing the raw transactions separately. These input public keys are necessary for silent-payment scanners to determine whether any of the transaction’s outputs belong to the wallet.
● Bitcoin Core #35568 reduces the synchronization time and disk usage of the optional txospenderindex (see Newsletter #394) by disabling its internal LevelDB Bloom filters. These are database-lookup optimizations, unrelated to the BIP37 bloom filters historically used by SPV wallets. LevelDB bloom filters were never consulted and only added processing and storage overhead. In the author’s benchmark, a full index synchronization decreased from 4 hours 37 minutes to 3 hours 57 minutes, while disk usage fell from 85.0 GiB to 80.9 GiB. Existing indexes remain compatible, but reclaiming the space used by previously generated filters requires rebuilding the index.
● Bitcoin Core #34538 allows an address explicitly configured with the externalip option to be eligible for advertisement, even if the onlynet option excludes its network. This change benefits nodes that open automatic outbound connections over one network but accept inbound connections over another. For example, consider a node that establishes outbound connections via IPv4 only while operating a Tor onion service that is configured separately. Previously, Bitcoin Core would reject manually supplied onion addresses because the onlynet option marked Tor as unreachable.
● BIPs #2208 updates the rationale for BIP54’s consensus cleanup, which proposes invalidating 64-byte witness-stripped transactions to prevent their hashes from being confused with Merkle internal-node hashes. The PR documents an alternative proposal that keeps 64-byte transactions valid while rejecting Merkle internal nodes whose two 32-byte child hashes, when concatenated, form a valid 64-byte transaction (see Newsletter #412). Additionally, it corrects BIP54’s previous claim that Merkle-proof verifiers would never need updating. Proofs of ordinary, non-64-byte transactions are automatically protected, but a verifier that accepts proofs of 64-byte transactions would need to reject them after activation.
● LND #10962 prevents the RBF cooperative-close flow (see Newsletter #347) from being used for auxiliary channels, such as Taproot Assets channels, whose funding outputs commit to additional protocol state. LND previously selected the RBF closer using peer-level feature bits, but that closer does not invoke the auxiliary hooks needed to carry the assets into the closing transaction. Therefore, it could broadcast a valid Bitcoin transaction that would destroy the asset commitments and leave the channel stuck in a waiting-close state.
● LND #10897 fixes a sweeper bug that could have permanently stranded inputs from auxiliary channels, such as Taproot Assets channels. These inputs may have only a small bitcoin fee budget because most of their value is represented by the overlay asset, while an auxiliary sweeper contributes additional budget to the final sweep transaction. Initially, LND’s filter only considered each input’s own budget, so after a failed sweep increased the required starting feerate, the input could be excluded from every future attempt. Now, the filter includes the auxiliary contribution when determining whether an input can afford the minimum relay fee and the starting feerate.
● BINANAs #21 assigns BIN-2025-0003 to BIP442, the draft OP_PAIRCOMMIT proposal (see Newsletter #395).

Bitcoin Optech Newsletter #413 Recap Podcast

2026-07-14T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Sjors Provoost to discuss Newsletter #413.

The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0

Download audio

News

● Using fountain codes for IBD (13:53)

Releases and release candidates

● Bitcoin Core 31.1 (22:52)
● LND v0.20.2-beta (28:49)

Notable code and documentation changes

● Bitcoin Core #32489 (31:11)
● Bitcoin Core #32606 (33:59)
● Bitcoin Core #34020 (0:48)
● Core Lightning #9104 (42:55)
● Eclair #3323 (45:11)
● LND #10832 (46:24)

Transcription

transcription coming soon