Bitcoin Optech

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

Bitcoin Optech Newsletter #413

2026-07-10T00:00:00+00:00

This week’s newsletter describes research into using fountain codes to allow pruned nodes to contribute to initial block download. Also included are our regular sections announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

● Using fountain codes for IBD: Lucas Lima posted to Delving Bitcoin about his latest research on using fountain codes to allow pruned nodes to contribute to Initial Block Download (IBD), without significantly increasing their storage requirements.

Lima provided a dedicated blog post where he explains how this could be achieved by dividing the entire chain into epochs, fixed-length chunks made of k blocks, encoding these epochs using fountain codes, and sending these encodings, called droplets, together with block headers to those nodes that need to reconstruct the chain. The receiving node, referred to as a bucket node, needs to gather and decode enough droplets belonging to a certain epoch in order to reconstruct the k blocks. Block headers are then used to verify that the received data is valid, preventing malicious nodes from corrupting the reconstructed chain.

Some critical points were raised during the discussion. In particular, developers highlighted the need for a high number of connected peers to manage to reconstruct the chain, slower IBD, risk of node fingerprinting, and possible increased DoS attack surface.

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 31.1 is a maintenance release of the predominant full-node implementation. It fixes an IP address leak in -privatebroadcast that could undermine transaction origin privacy (see Newsletter #409), and includes fixes for chainstate database compaction, wallet migration, input-size estimation, MuSig2 key aggregation, and proxy handling during v2 P2P transport reconnections. See the release notes for details.
● LND v0.20.2-beta is a maintenance release of this popular LN node implementation. It fixes a DNS fallback panic and an onchain forward-interceptor settlement bug, and adds the final-hop HTLC CLTV expiry validation covered last week (see Newsletter #412).

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 #32489 adds an exportwatchonlywallet RPC that exports a watch-only version of the currently loaded wallet to a new wallet file, which can be loaded on another node using the restorewallet RPC (see Newsletter #366). The exported wallet contains the original wallet’s public descriptors, transactions, labels, and other metadata, but not private keys. Previously, users had to manually construct such a wallet by importing public descriptors.
● Bitcoin Core #32606 updates compact block relay to ignore compact block messages from peers that have not negotiated support with sendcmpct, from peers not selected by the node for high-bandwidth announcements with sendcmpct(1), and whenever the local node is running in -blocksonly mode. Since compact blocks are reconstructed using transactions from the receiver’s mempool, processing them can reveal which transactions the receiver is missing or already has. This is particularly undesirable for blocks-only nodes because the transactions in their mempools are more likely to have originated locally.
● Bitcoin Core #34020 adds the getTransactionsByTxID() and getTransactionsByWitnessID() methods to the Mining IPC interface (see Newsletters #310 and #323). Each method takes a list of txids or wtxids and returns the corresponding serialized transactions from the node’s mempool, or empty elements for transactions it doesn’t know about. This is useful for Stratum v2 custom job declaration, where a pool may want to request only those transactions from a miner-proposed block template that it doesn’t already have.
● Core Lightning #9104 and #9292 add experimental support for the option_simple_close cooperative close protocol (see Newsletter #342). Legacy cooperative closes require peers to agree on a single closing transaction and fee, and if they disagree, the close can get stuck. Simple close avoids this issue by enabling each peer to propose a valid closing transaction that subtracts their chosen fee from their own output. Both versions can be signed and broadcast, and whichever conflicting transaction confirms first closes the channel. CLN implements this flow in a new simpleclosed subdaemon, that delays broadcasting its own version when the peer’s version pays a higher fee. #9292 fixes an edge case where CLN rejected a signed simple-close transaction that replaced the closer’s uneconomical output with a permitted zero-value OP_RETURN, causing a force close.
● Eclair #3323 fails incoming HTLCs whose CLTV expiry is more than 2016 blocks (approximately two weeks) in the future. This extends Eclair’s existing maximum expiry policy for outgoing HTLCs, which reduces the risk of funds being locked for an extended period and makes channel jamming harder. Eclair temporarily accepts an offending HTLC into the channel commitment and then fails it, since rejecting it outright would force close the channel.
● LND #10832 continues LND’s implementation of BOLT12 offers by adding support for InvoiceRequest messages (see Newsletter #410). The new code adds TLV encoding, decoding, and structural validation, while deferring signature verification and cross-checking against the corresponding offer to subsequent PRs.

Bitcoin Optech Newsletter #412 Recap Podcast

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

Mark “Murch” Erhardt and Mike Schmidt are joined by Conduition and Jeremy Rubin to discuss Newsletter #412.

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

Download audio

News

No significant news this week was found on the Bitcoin-Dev or Lightning-Dev mailing lists.

Changing consensus

● Benchmarking SLH-DSA STARK aggregation (1:05)
● Bird of Prey 2 (BoP-2) non-malleable schnorr and PQ signatures (10:21)
● Lattice-based signatures (19:41)
● Public key recovery for P2MR EC leaves (25:50)
● Aligning privacy incentives in P2MR (30:48)
● Prohibit merkle internal node preimages that encode minimal 64-byte transactions (49:38)
● Triggering EC disabling with a NUMS point spend or hashrate majority (37:36)

Releases and release candidates

● Bitcoin Core 31.1rc1 (1:32:43)
● Bitcoin Core 30.3rc1 (1:32:48)
● Bitcoin Core 29.4rc1 (1:32:52)
● Core Lightning v26.06.2 (1:36:01)
● LND v0.20.2-beta.rc1 (1:36:39)
● LND v0.21.1-beta (1:38:10)
● LDK v0.2.4 (1:38:57)

Notable code and documentation changes

● Bitcoin Core #35266 (1:40:00)
● Bitcoin Core #35550 (1:41:10)
● Bitcoin Core #35610 (1:42:15)
● BIPs #2196 (1:43:52)
● BIPs #2165 (1:47:46)
● BIPs #2201 (1:50:13)
● LND #10900 (1:51:20)
● LND #10927 (1:52:37)
● LDK #4748 (1:54:13)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #412 Recap. We didn’t have any significant News items this week, but the Changing consensus monthly segment is pretty packed. We have seven items, with most of them being quantum-related, so there’s a lot to get through. Luckily, Murch and I this week are joined by Conduition, who can help us through that segment. Conduition, who are you? What are you working on?

Conduition: Hey, Mike, thanks for letting me be here. I am a cryptographic security engineer working on various post-quant initiatives, the namely largest one being SHRINCS. And I’m also hoping to work on isogenies and commit/reveal soon, and I’m funded by a grant from Brink. I’m very glad to be here to discuss some of this very cool stuff, because we’ve got a lot of really interesting changes that are being proposed.

Benchmarking SLH-DSA STARK aggregation

Mike Schmidt: Well, thank you for joining us. You did participate in many of this week’s Changing consensus discussions and authored one of the proposals. So, we’ll take these quantum-related items first for listeners while Conduition is with us, and then we’ll finish with the remaining Changing consensus item, starting with “Benchmarking SLH-DSA STARK aggregation”. I think listeners are probably familiar with the challenge. One of the challenges with post-quantum signatures being they’re enormous and a block full of them barely fits. One proposed workaround is potentially don’t put the signatures in the block at all. Maybe you can have one compact cryptographic proof that says, “I verified all these signatures and they check out”. That’s where we get into the STARKs and this week’s Remix7531 post about some benchmarks on the Bitcoin-Dev mailing list post. This was based on an earlier proposal from Ethan Heilman along these lines. But Conduition, how would you break down the idea, and then also the meat of this, which is the benchmarking piece?

Conduition: Yeah. So, for the uninitiated, SLH-DSA is a hash-based signature algorithm. It’s the only one that’s been standardized by NIST. It’s known for being extremely performance-intensive for the signer, but for verifiers it’s actually quite cheap. It’s a lot cheaper than schnorr in terms of cost per byte. But like you said earlier, hash-based signatures are very, very large. And so, a common strategy that people have been looking into recently is using STARK aggregation, where you have a list of signatures and messages. And kind of like CISA (cross-input signature aggregation) style, you aggregate them all together into one single zero-knowledge proof that is essentially a proof of the statement, “I verified this list of signatures on these messages”. And this way, the verifier of a block wouldn’t need to actually have the signatures, they would only need to have the messages. And this would save a lot of blockspace.

The downside to this approach is that proving time is incredibly long, and it scales linearly with the number of signatures. And benchmarking this stuff is a really useful and important metric to have in mind when we’re researching this kind of stuff. So, I’m really glad to see people actually going and building the code that actually runs this stuff. I’ve seen two people independently pursue this line of research, one of them being Remix here. It is unfortunately bad news, being that the number of signatures we’d be trying to aggregate here would be in the hundreds or the thousands. And so, we would be looking at proving times, based on extrapolating from Remix’s results here, we’d be looking at proving times running into 30 minutes to an hour or more.

Mike Schmidt: How does that grow? Like, for each additional signature, are we growing linearly?

Conduition: Linearly for each signature. However, the proof size grows, I believe, logarithmically. And so, the proof size would never really exceed 1 MB, even if you compiled in thousands and thousands of signatures to this one proof. The verification time likewise also grows logarithmically. And I’m not actually 100% sure, it might be polylogarithmic. Anyway, it’s much, much faster to verify than it is to prove a STARK like this.

Mike Schmidt: Now, for the proving piece, what is your feeling or what have you seen in terms of optimizations? I know oftentimes these things, the first iteration is slow, but then there’s little discoveries and optimizations and performance improvements that are made. Is your feeling that there’s meat on that bone there? Can we whittle it down? Or is this roughly where this would end up?

Conduition: Absolutely, we could. It’s a matter of what we’re willing to sacrifice to get there. So, there’s trade-offs. One trade-off you could make is to ask every signer who posts a Bitcoin transaction to do the proving of their own transaction signature on their own message. And then, when aggregating, the miner, I would assume it would be the miner who would be doing this, would aggregate together a bunch of STARK proofs recursively. Now, I’m not sure of the wisdom of doing this, because at that point you’re depending more on the security of the STARK scheme than on the signature scheme. And so, you might as well remove the signature scheme entirely and just have like a STARK proof of knowledge of a hash preimage instead of using SLH-DSA. But another trade-off that you could make is using a more arithmetization-friendly hash function, a more STARK-friendly hash function.

So, the way that STARKs in general work is that they turn any arbitrary computation into an arithmetic circuit. You can think of this as a directed graph where you start with a whole bunch of input data, and then you parse that data forwards through a series of multiplication, addition gates. And eventually, you come out with a final result. And the STARK proof is a way of formally showing to a verifier that you computed the circuit with some inputs and got these outputs. Now, the bigger the arithmetic circuit is, the slower it is to prove. And so, you can make proofs much more efficient by using computations that are more arithmetically-friendly, so to say. And unfortunately, SHA256 is very unfriendly to arithmetization. It uses a lot of bitwise operators, and that makes it very hard to arithmetize. There are other hash functions that are easy to arithmetize, and I have seen some work from someone else who’s been doing work on Poseidon SLH-DSA. And the Ethereum Foundation, I know, is very interested in this subject. I don’t want to dox him because I’m not sure if he’s made his findings public yet, but it is definitely an open avenue for research, and there’s a lot more that could be looked into. But I’m not 100% sure that the Bitcoin community would like to use something other than a NIST-approved hash function here, because it would slow things down on the signer side and there would be other concerns with security.

Mike Schmidt: Now, we’re talking about SPHINCS in this benchmark, but does SHRINCS or any of these other smaller optimized variants for Bitcoin change roughly the conclusion here?

Conduition: I would say it changes it by a linear amount. Verifying a stateful SHRINCS signature is a certain factor cheaper. I can’t remember off the top of my head exactly how much. I think it’s maybe around an order of magnitude cheaper to verify. So, just take the benchmark numbers in Remix’s post there and scale them down by a factor of 10 approximately. Again, I’m not exactly sure. I can’t remember off the top of my head what the compression call numbers are for stateful SHRINCS versus stateless. But it’s not such a huge speed-up that it would be game changing.

Mike Schmidt: Got it. Murch, any questions from you or, Conduition, anything else before we wrap up this item?

Conduition: No, not really. I do think that the idea I mentioned earlier about using STARKs to prove knowledge of a hash preimage, I think that has been done before as a signature scheme, standalone. So, that would be worth looking into whether that can be aggregated, and whether it would provide more efficient proving time than aggregating SLH-DSA with all of its 21 million hash function invocations.

Mark Erhardt: Maybe what sort of new cryptographic assumptions would we need to verify STARKs in Bitcoin?

Conduition: Actually, I don’t think any. The biggest drawback to STARKs in terms of security is not the cryptographic assumptions. Because they don’t use any new cryptographic assumptions that I’m aware of beyond hash function security. The drawback would be implementation complexity. Definitely a far, far greater scope of implementation would be needed for STARKs than for simple hash-based signatures. It’s why I’m personally skeptical of them making their way into consensus anytime soon. But in the long term, anything could happen.

Mark Erhardt: Okay, so they’re very complicated to implement and they’re very expensive, slow to prove. So, this probably doesn’t make for a great signature scheme when we’re trying to aggregate a few thousand payment transactions per block?

Conduition: Well, not with current benchmarks, but you know, there’s always room for improvement. I’m hopeful that this is an active area of research that will find some value yield in the near future.

Bird of Prey 2 (BoP-2) non-malleable schnorr and PQ signatures

Mike Schmidt: Next item from Changing consensus, “Bird of Prey 2 (BoP-2) non-malleable schnorr and PQ signatures”. This was motivated by a post from Pieter Wuille to Delving Bitcoin about this 2026 paper from EuroCrypt on having this hybrid scheme. So, it’s a hybrid scheme, it’s a schnorr-like scheme, and an arbitrary post-quantum signature scheme put together in a hybrid manner and in a strongly unforgeable signature. Maybe we can unpack some of those words, Conduition. Is it as simple as, you know, I know a lot of people have been talking about, “Hey, just have the ability to have a schnorr signature and a SHRINCS signature, and you can multisig that, or it can be 1-of-2, or whatever”. What is being spoken about here? This seems like something different.

Conduition: Yes. This is a really cool paper. Okay, first of all, I should back up and explain what ‘strongly unforgeable’ means, for anybody not familiar. Strong unforgeability is a notion that says if I’ve signed a message, you should not be able to take that signature and turn it into a different one on the same message and still verify that signature valid. And this used to be extremely important for Bitcoin. In fact, ECDSA actually had big issues, because it was not strongly unforgeable under the encoding schemes that we used in Bitcoin. And this led to, I believe it was BIP66. Murch, maybe you can correct me on this, but the DER encoding standard for ECDSA.

Mark Erhardt: 60-something, definitely. I can look at it while you continue talking.

Conduition: Anyway, the problem with ECDSA was that its signatures could be malleated. Given a signature, you could change the encoding of that signature in a way that’s still verified to a Bitcoin node. But by doing that, because the signature was in the script input field of the transaction, you would change the txid, and that would complicate a lot of multiparty protocols, especially ones like Lightning, which rely on having child transactions of parent transactions that aren’t in the mempool. You need to watch out for specific txids. And if those txids change unpredictably, it’s very hard to handle the result. So, strong unforgeability can be very useful, but nowadays it might be a little less important because the signatures are in the witness, which do not affect the txids anymore. They only affect the witness txids.

Anyway, going back to the topic of discussion here, BoP-2, it is a way of taking a strongly unforgeable post-quantum signature scheme, like for example SLH-DSA or SHRINCS, and composing it with a schnorr signature scheme, like BIP340. And from it, you can construct a strongly unforgeable hybrid signature scheme. In other words, a schnorr-plus-PQ signature on a single message. And as a little added bonus, you also get a small savings in terms of the signature size. I think it’s about 32 bytes, because you can actually reuse some of the data. You don’t need to post it all together, because you can make use of a common piece of data between the two signatures. Now, the biggest advantage of this is really, of course, the strong unforgeability property that you get from the resulting hybrid scheme and the savings in size.

Mike Schmidt: So, I’m reading from our write up. Maybe you can get into the fact like, how is that strong unforgeableness attained here versus just concatenating the two signatures? Or maybe you got into that and I missed it.

Mark Erhardt: Yeah, maybe let me ask my question. I seem to remember that the schnorr signature would commit to the post-quantum signature, and because then, of course, if the post-quantum signature changed in any byte, I think that the post-quantum signatures tend to be more malleable because it’s all, well, actually hash trees, so maybe not. Do I have a right intuition there?

Conduition: I’m sorry, I would have to go back and review. I haven’t actually delved too deep into how BoP-2 works myself. I was actually more involved in Boris Nagaev’s idea for how to do this. And he had a similar idea to BoP, but it was a little more involved because you can’t treat the PQ scheme as a black box in Boris’s scheme; whereas with BoP-2, you can treat the PQ scheme like a black box where you don’t actually need to know how it works internally. We’ll actually get to that subject a little later in the newsletter, because it evolved into something very different and I think much more useful.

Mark Erhardt: I see. Well, either way, we would want these signatures to be non-malleable, at least in the sense that whatever propagates to the surface, the non-witness data should not affect the txids, because changing txids are a problem for us. So, I seem to have remembered that it was done by the, well, I’m speculating. Let’s move on if there’s not much more to say!

Conduition: Well, there is one other thing to say, which is we should also set the expectation for what the default would be if we do not use something like BoP-2, and Mike, you alluded to this earlier. But the idea is if we add a post-quantum signature scheme as a standalone scheme in the future, say SHRINCS, then anybody who wants to use a hybrid scheme, first of all, they have to make a choice if they want an AND scheme or an OR scheme. In other words, do you want to be able to spend your coins with a schnorr signature or a SHRINCS signature? Or do you want to be able to spend with a schnorr signature and a SHRINCS signature? If it’s the former, if you want an OR hybrid, then you can very easily do that today using P2TR or P2MR or some other script tree construction. But if you want to do an AND, then the default way to do that would just be to have a hybrid script that contains two public keys and two CHECKSIG operations. Now, that actually is not a single-signature scheme, so it’s not fully correct to say this, but in a way, that construction is not strongly unforgeable. Because although both signature schemes independently might be strongly unforgeable, when taken together, especially in the quantum context, they are not unified strong unforgeable. Because if you have a quantum computer, that quantum computer could just break the elliptic curve key and then change the signature to whatever it wants. It can’t change the message, but it can change the signature.

The other consideration is in the classical setting, if you use those keys to sign the same message multiple times, then you can mix and match signatures from the different transactions you see. I don’t think any of this is of severe consequence now that we have segwit, because they won’t affect the txids, no matter what you change the signatures to. I still haven’t heard any good arguments for why it might be important if wtxids changed. I think Pieter Wuille referred to this briefly, but didn’t give a concrete example.

Mark Erhardt: You can waste a bit of bandwidth, because in the P2P messages, we identify transactions by wtxid to determine whether we have them already. Because you could theoretically have, for example, a P2TR input that can be spent by a keypath and a scriptpath, where you first see a scriptpath signature, and then later someone signs with a keypath signature that is smaller, and thereby the transaction has a higher feerate, although the inputs and outputs didn’t change at all, just the witness structure was smaller and thereby the feerate increased. So, in order to be able to propagate different transactions with different witness data, but otherwise the same, we propagate them by wtxid. So, if someone can malleate wtxids, we might see more than one version of the transaction propagate.

Conduition: Okay, thank you. I’m going to take a note for that and look into that later, if that sounds interesting.

Lattice-based signatures

Mike Schmidt: I think we can move to the next item titled, “Lattice-based signatures”. This was a post to both Delving and Bitcoin-Dev mailing lists from Nikita Karetnikov, and it referenced a Blockstream blog post comparing different post-quantum signature families, including Lattice-based schemes. So, Conduition, we have hash-based, we have lattice-based, I know you’re looking into isogenies as well. How are you thinking about lattice? I think I saw a clip of Dan Boneh encouraging or somehow speaking positively about Bitcoin and lattice. Maybe tl;dr on lattice and we can get into maybe some pros and cons and how you’re thinking about it.

Conduition: So, I don’t know too much about lattice cryptography, and I don’t want to talk out of my butt on this one. But from my research that I did do a year or so ago onto lattices, I was a little let down and disappointed by the lack of mathematical flexibility that they offered. They’re often pitched as a more flexible and more potentially promising cryptographic family of schemes. But in reality, the constructions that we have available just aren’t that great. What we have right now consists of a cobbling together of different papers that have proposed various ways of doing things, like BIP32 or multisignature or threshold signature on lattices, but they all require changing the schemes. For example, one that I know of, and the most efficient re-randomization scheme that I know of, is called DilithiumRK. And I can’t remember off the top of my head exactly how big they are, but they do increase the size of Dilithium signatures, and I don’t know of any multisignature schemes. I think there are some, but they do result in much bigger signatures, and these kinds of trade-offs, it’s not clear how you’d combine them. Like, how would you get a scheme that has both re-randomization so you can get BIP32 hierarchical deterministic wallets, and multisignatures so that you can do multisignature things on Bitcoin. And that’s a gap that still needs to be filled.

But there are other options, but I’m mostly skeptical of lattices for that reason. And don’t get me wrong, it would be really cool to have those things, and I think we should still pursue them as research avenues. But well, it’s my opinion that we should engineer based on what we have and not what we think we will have in the future. So, that’s why I’m personally working on hash-based signatures first.

Mike Schmidt: While also pursuing some of the isogenies work, right? And that’s maybe more of a longer-term thing. So, maybe the lattice, the way you’re thinking about it is lattice is somewhere, I don’t want to make it linear, but somewhere in the middle of the two, where hash-based is kind of this dumb quantum-resistance signature scheme, and maybe isogenies could get us more towards the full feature signature schemes that we’re used to today. And the lattice is kind of somewhere in the middle. Is that how you’re thinking about it? Yeah, yeah. Isogenies are great for flexibility and there’s a lot of promise there. There’s actually just been a recent paper published proving key re-randomization on isogenies secure, which is really great and exciting. Threshold and multisignature on isogenies is still forthcoming. But I think the major problem with isogenies right now is verification time, and that’s something that I’m really hoping to work on in the future.

Hash-based, like you said, is kind of like the dumb brute of the post-quantum signature families. And they’re very fast to verify, which is great. So is lattices. Lattices are very fast to verify. So, I think any scheme that we want to integrate into Bitcoin is going to have to tick a few important boxes. Unfortunately, we don’t have one that ticks all of the boxes right now. And that’s why there’s so much debate going on between people on post-quantum crypto schemes.

Mark Erhardt: Luckily, we need to check some of those boxes maybe at different times in the future. So, there had been some talk about a dual-front approach, where we tried to have something rather quickly. And I think the hash-based signatures that don’t require as much innovation in the cryptography, and the dumb brute as you say, will fit that short-term horizon, where we just maybe enable large cold-storage holdings to be post-quantum secure, and we do have support for some post-quantum scheme. And then, maybe the isogenies and lattice-based signatures and future research-based topics are more of an approach that becomes available when we look at the long-term solution, if we want to migrate the entire system to post-quantum and we have a little more time towards making a lasting solution.

Conduition: Totally agree. And multiple things can be pursued at once and that’s why I think it’s really cool that people are also looking into lattices because, well, I mean it is what the whole rest of the Web 2 world is using right now for post-quantum. And it would be cool if we could make use of that research and the activity going on in that domain. And so, I’m really happy to see Blockstream and Project 11 and other think tanks working on seeing if we can make lattices work for Bitcoin because if we could, it would be really cool. Right now, I’m not convinced, but that’s not to say that I can’t be.

Public key recovery for P2MR EC leaves

Mike Schmidt: Next item, “Public key recovery for P2MR EC leaves”. And this was a post to Delving Bitcoin from starius, and he outlines this trick of a schnorr signature actually containing enough information to reconstruct the public key that produced it. So, why bother including the public key in the transaction at all? Maybe, Conduition, what is starius getting at here? I guess there’s space savings by not having the public key and then it wouldn’t be sitting there for a quantum computer as well. Maybe tie it together for us.

Conduition: Oh, I’m excited about this. This is probably one of my favorite ideas that I’ve seen in the past six months. This is an idea that has already been used before in other situations, like Ethereum uses public key recovery from ECDSA, for example. So, this is a known mathematical thing you can do. The key innovation here that Boris proposed is avoiding related key attacks while also allowing public key recovery. So, in order to understand this, we need to go back to BIP340 and understand why the public key is included in the schnorr challenge hash. So, when you compute a schnorr signature, you run a hash, and that hash determines something called a challenge. And the challenge is the thing that you actually sign. Like, if you look at the mathematics of how a schnorr signature works, it’s basically just your private key multiplied by the challenge plus some random number. Now, the challenge, if that stays the same, then anything else outside it could be mutated and the signature is still valid. So, if you have a challenge hash that is just the default, like a canonical schnorr signature challenge hash, that would just be a hash of your nonce, R, and the message, M. Now, if you change the public key, and add some sort of additive tweak to it, then the signature would still be valid on the same message but the key would have changed.

This is a really, really bad thing for Bitcoin because we use BIP32 tweaks, we use taproot tweaks, there’s a lot of situations in which keys can be related by these tweaks. And so, we really, really don’t want you to be able to rebind a signature to a different public key that is related. And that’s why the public key is included in the BIP340 challenge. Now, if Boris’s idea here had been known about at the time of BIP340, it could have been possible that we could have hashed the public key before putting it onchain. Because what Boris realized was that you don’t actually need it to be the public key itself in the challenge hash. It can be a hash of the public key instead. Or actually, it could be any binding commitment to the public key. And if you can do this, and assuming you already have that commitment on the verifier, then the verifier can actually recompute the public key point and then verify it against that commitment. And this lets you save the public key from going onchain in the context of Bitcoin transactions, because what you can do is you can, say, post a hash of the public key onchain, or in the case of P2MR, you post a merkle root, which is a commitment to the public key. And then, when the verifier sees the signature, they can recompute the public key and then hash it, and then check that against the commitment that’s onchain. And the challenge hash is still fine. You can still compute that just fine because you already have the commitment, which is the part that actually goes into the challenge hash. And you’re safe against related key attacks. It seems like it’s a win-win-win situation.

Mike Schmidt: Does this mean then we don’t have the long exposure on these address types? Is that the main win, in addition to space savings?

Conduition: Well, we still have long exposure on existing UTXOs, but this does free us up to implement something like P2TRH, which is just P2TR but with a hash on the public key. It would have the exact same witness size as P2TR keyspends, it would also have script trees. It would be secure against long exposure attacks, but not short exposure attacks. So, I think that’s an interesting potential compromise between the two sides of P2TR v2 and P2MR, which is another debate that I’m sure we’ll get into later in this podcast.

Aligning privacy incentives in P2MR

Mike Schmidt: “Aligning privacy incentives in P2MR”. Well, Conduition, this is your post to the Bitcoin-Dev mailing list, so I’ll let you frame it.

Conduition: Thank you. Yes, this one got a little digressive, but initially it was pointed out that P2MR admits a kind of perverse incentive in some scenarios, where P2MR is essentially just the script tree element of P2TR, but transplanted out of taproot and into its own output type. So, you post a merkle root onchain, and that merkle root’s leaves are supposed to be scripts and tapleaf versions. And you can spend from that address by revealing one of those scripts, a merkle path, and a script witness to authenticate it. Now, unfortunately, this would be a little bad for privacy in some situations, because some people might want to have a merkle root with just one leaf, because maybe they only need one script. And maybe they don’t care about having a cooperative spend path and they just want to minimize the fees. Well, that allows for easier fingerprinting of such wallets or protocols, and that, of course, decreases the anonymity set for everyone else. And this is a distinction from P2TR, where in P2TR, everybody has to pay the cost of the default spend path. Sorry, Murch?

Mark Erhardt: Yeah, I think beyond the privacy impact, the other issue is we would want people to move to P2MR in order to achieve post-quantum security. And if they were moving to a P2MR with a single script leaf that is motivated by economic reasons, they would not have post-quantum security in that P2MR output, because a single leaf, no keypath, no other leaf to fall back on with the post-quantum security. And so, we would see a bunch of P2MR outputs potentially. But they would be sort of a false signal in the sense that they do not indicate people that have moved funds into post-quantum security. The other reason being also that any new output type will of course split the UTXO set into further output types and adds fingerprints.

Conduition: That’s very true. We want the migration to proceed in a way that everyone has a post-quantum leaf in every address. And there might be some edge cases where that doesn’t happen, but by and large everyone will because, well, here’s maybe a good way to segue into my post. My suggestion to change BIP360 was to ban depth-zero trees. And this fixes the perverse incentives that we were just talking about, because now there’s no way to have a depth-zero tree at all. Every P2MR tree must have at least two leaves. And because of the way script trees work, because leaves can be at any position in the tree, you can never be sure as an observer if a particular script tree has two leaves, or three leaves, or four leaves, or eight leaves. At best, you can get a lower bound for how many leaves there are. And I actually got a great suggestion from Ethan Heilman when I submitted this PR. He suggested making this change an ANYONECANSPEND success path instead of an outright ban. I think this is a really smart idea because it opens the door to potential upgrades to P2MR in the future that might do stuff like isogeny-based key tweaking, or even have a schnorr, what’s it called? Have P2TRH nested inside of a depth-zero merkle tree, which actually might be worth talking about at some point here.

Mark Erhardt: Would that potentially allow for your P2TRH idea, basically? Because isn’t there a crossover maybe?

Conduition: There absolutely is. I think this is actually one way that we could potentially resolve the P2TR v2, P2MR debate, which is what this discussion on the mailing list kind of devolved into. Because I initially proposed this on the mailing list and to seek feedback from Antoine and Pieter and people who are critical of this privacy aspect of P2MR. It ended up devolving into a larger-scale debate about P2MR and P2TR v2. But I think we overall had consensus on the core idea of getting rid of depth-zero script trees. Now, what if we didn’t, though? What if we got rid of just the bad case of depth-zero script trees, and instead made use of depth-zero script trees for P2TRH? Because then, you could get the same witness size as P2TR, but still have the post-quantum security of P2MR. Sorry, I didn’t give you guys any warning about this, but I literally just had this idea before this podcast. So, I don’t want to go too deep into it.

Mark Erhardt: I guess I’m going to talk back at myself right away, because if we go back to using the depth-zero leaf, then of course there wouldn’t be a post-quantum secure leaf there either. So, if the idea is anyone that moves into a P2MR is expected to have a post-quantum leaf, then that would be undermined by making use of the depth-zero leaf. If the idea is just to offer a way of using the schnorr signatures and tapscript, without having the output be long-range-attack vulnerable, then of course that might make more sense.

Conduition: Yeah, I think there’s definitely some more discussion to be had. But I think the idea of depth-zero script trees is certainly a focal point that we need to discuss more, because there’s some options to consider either way we go and different trade-offs for each of them. So, fun discussions to be had on the Delving.

Triggering EC disabling with a NUMS point spend or hashrate majority

Mike Schmidt: Sounds like you need to start another one now, Conduition. We have one more quantum item from the Changing consensus segment titled, “Triggering EC disabling with a NUMS point spend or hashrate majority”. And Conduition, this also references P2MR and P2TR v2, which I know you referenced was sort of a battle that sprung out of the last item that we were talking about. Can you articulate why Pieter posted this idea? And then, that can tie into potential downsides of P2TR v2? And then, I think that will maybe frame up the quasi battle that emerged in the last discussion that was in its own item.

Conduition: Great prompt. So, to summarize here, there are a couple of competing post-quantum output type proposals. One of them, probably the most mature, is P2MR, which most people here have probably heard. I described it earlier. It’s basically just the script tree part of taproot taken out of taproot. P2TR v2 is much simpler. It is just a one-for-one duplicate of P2TR. The only distinction between it and P2TR is that it explicitly opts anyone who uses it into a future disabling of the keyspend path.

Mark Erhardt: And of course, it would use a native segwit version that is different from P2TR. So, wallets and services and so on would have to probably … well, the spec of segwit suggested that all future segwit versions should be allowed to send to, but I think the past has shown that most services do not permit that. So, they’d probably have to make some minor tweaks to allow sending to them. But then, the implementation otherwise should be pretty trivial for anyone that already supports accepting and sending from P2TR outputs.

Conduition: That’s right. It would be a minor change. However, it comes encumbered with some technical debt, and that technical debt is that we must find a way to reliably disable that keyspend path before a scalable quantum computer tries to attack Bitcoin. If we do not, then all of those supposedly post-quantum outputs in P2TR v2 are not so post-quantum, they are completely stealable. The debate between P2TR v2 and P2MR mostly revolves around this question of, can we reliably disable EC spending at a time that we should? And what time should we disable it? So, this is the post that Pieter made, and this is the subject matter that he is seeking to discuss and try to build some technical solutions to. And I really like that, because whether we do P2MR or P2TR v2, it’s actually a really good idea to disable EC spending on that new output type eventually. But the problem really boils down to timing in the case of P2TR v2. We really, really would want to have EC spending disabled at exactly the right time. We don’t want to go too early, or people are going to regress onto vulnerable addresses. And we don’t want to go too late, because then the quantum computer can steal all the money that’s on those addresses.

So, Pieter suggests a few ways of doing this. One of them is a provably certain tripwire, where you have a NUMS point (nothing-up-my-sleeve). A NUMS point is a point on the secp256k1 curve that you find by computing a hash function. In other words, you hash from some fixed input to a point on the curve. And this is provably unspendable classically, because if you’re given any point on an elliptic curve, you shouldn’t be able to derive its discrete logarithm. That’s the ECDLP in a nutshell. So, if you can find the discrete log of a NUMS point and sign with it, or even just disclose the discrete log itself, well then you’ve provably beaten ECDLP. So, that’s an unquestionable certainty that if somebody can spend a NUMS point, we should disable EC spending, because the ECDLP is no longer secure.

Now, there’s another method Pieter suggests, which is mining activation. He wasn’t exactly clear about how this would work, but I would imagine it would work a lot like most other soft forks in the past. It would probably just have a very long activation window so that we can activate it at any point in the future, if and when a quantum computer appears suddenly. Both of these options come with some caveats. For one, the NUMS point tripwire will only work if the quantum computer that we are trying to defend ourselves against is cooperative with us. Because no quantum computer who wants to attack Bitcoin is going to willingly disable its ability to attack Bitcoin. And so, you really want a quantum computer who isn’t your adversary available to activate this tripwire. The mining path is also somewhat problematic, in that you would need to find some way of triggering the activation quickly in case of an emergency, but also in a way that random solo miners can’t just activate it willy nilly by mining a specific block with a specific flag. I’m not sure how exactly you’d do that. I’m not too knowledgeable on software activation logic, but Murch, maybe you can opine on that subject.

Mark Erhardt: I haven’t been following too closely, but yeah, it seems to me that one of the not just tripwires, but tripping points in the whole, “Oh, we’ll disable elliptic curves and the keypath on P2TR at a later date”, is determining when the correct time is. Optimally, you would want to disable it just before quantum computers become able of attacking Bitcoin. But of course, the industry has been extremely opaque in general. There’s a lot of speculation around the capability and the timelines. So, if you disable it too late, you might still be vulnerable; if you disable it too early, you force people into overspending on the post-quantum outputs, because they now have to fall back away from the keypath spend, although that might have not been necessary yet. And yeah, there are some ideas, but that is one of the interesting points about having a dedicated post-quantum scheme, is the people that want to opt into that can opt in at any point. They will have to then spend the expensive post-quantum output if they want to access those funds, but it makes it the individual decision, which of course people will probably also procrastinate on. So, there are so many different areas where there are still dragons here that, yeah, it’s no wonder that most of the discussions on the mailing list are about post-quantum now.

Conduition: Yeah, the whole subject of when quantum computers will arrive is a garbage dump discussion fire that nobody can really resolve until somebody has a quantum computer. So, my personal philosophy is we can’t predict technological revolutions with certainty, let’s not try to. So, let’s just prepare for when it happens and be ready for anything.

Mark Erhardt: Yeah, especially lately with the breakthroughs in AI and LLMs, certain areas of research have just taken totally different trajectories. Luckily, I think quantum computers still require a large amount of people doing stuff in labs, which AI will probably not be able to do for them anytime soon. But yeah, we live in interesting times.

Mike Schmidt: Conduition, it may be intuitive for people of why the EC disabling would be a priority for P2TR v2. It may be less obvious why that would be necessary in P2MR world, where there’s a post-quantum signature scheme. Maybe, can you comment on that?

Conduition: Yeah, absolutely. This is actually a very key point in the debate between P2TR v2 and P2MR. So, whether we use P2MR or P2TR v2, there will be some subset of coins that end up on that output type with exposed EC public keys. And this would come about through things like address reuse or xpub sharing or watch-only wallets or multisignature. And through all these avenues, your EC public keys can be exposed to a quantum computer who would be able to factor them and attack you. Even if you’re using P2MR, where everything’s hidden behind a hash, even if you’ve never reused an address, it might come about just because your desktop wallet was sharing your xpub with a server, like think of Samourai Wallet, for instance. And these kinds of risks would mean that there will be some subset of users using P2MR who will be exposed to quantum computers. And so, once we’re sure that a quantum computer is around, we want to disable EC spending for those addresses so that they can be protected, and then they can start using their post-quantum signing leaves instead of elliptic curves.

That’s why it’s useful to have EC disabling, even for P2MR, even though we don’t strictly need it in P2MR, because it would still be nice to have. And once we’re sure that it’s a thing, why not activate it?

Mike Schmidt: Conduition, anything else on this item before we move along?

Conduition: No, I think I’m all good. I think that was a very good summary.

Mike Schmidt: Well, Conduition, thanks for joining us and shepherding us through the quantum items in this Changing consensus segment. You’re welcome to hang on, and you’re welcome to drop if you have other things to do. We understand.

Conduition: I’ll hang around for a while.

Mike Schmidt: All right. Well, we have another guest who’s joined us. Jeremy, how you doing? You want to say hi to the folks?

Jeremy Rubin: Good, how are you?

Mike Schmidt: I’m doing good. Who are you? What are you working on?

Jeremy Rubin: Well, I am Jeremy Rubin, I am currently working on something called Char Network, which is a layer 2 consensus system generally working on kind of BitVM more scalable functionality layers on top of Bitcoin. And so, we’re solving a problem of in between blocks, people still want to be able to get confirmations of their transactions for lower latency. And so, that’s the core of the problem that we’re solving. Today, I’ve worked on Bitcoin for a long time, so I also work on a bunch of other things as well, including I guess the topic that we’re going to talk about today.

Prohibit merkle internal node preimages that encode minimal 64-byte transactions

Mike Schmidt: Yeah, today’s topic is, “Prohibit merkle internal node preimages that encode minimal 64-byte transactions”. This was a post that you sent to the Bitcoin-Dev mailing list, related to a discussion that we had a few weeks ago in Newsletter #408, where Murch and I tried to talk through your previous post on the matter of valid 64-byte transaction use cases. Maybe, since you weren’t here to represent that then, and it would also be helpful for people to understand your perspective, maybe summarize those use cases and why you’re trying to protect 64-byte transactions in some cases?

Jeremy Rubin: Yeah, I think that the thing that I’m really trying to protect is not really 64-byte transactions. I kind of don’t really care that much about them, but what I care about is I care about transactions being linear and discontinuities in consensus rules. An example of a discontinuity in a consensus rule would be, I’m going to make up an example, like let’s say that you can do a sequence lock of 10 blocks, 11 blocks, 15 blocks, 16 blocks, and 17 blocks, so on and so forth. And then, every now and then, there’s just a random gap and you’re not allowed to do that. And so, somebody later on might be making a piece of tooling and then they might not know about these discontinuities. And then, that might lead to either a loss of funds or it might lead to a bunch of excess complexity later on down the road, because they now have to contend with some rule of, “This isn’t allowed”.

With transactions, transactions can be as small, I believe, as 60 bytes, is the smallest possible valid transaction. And that is a transaction that is one input, one output. And there is no script or scriptSig with that transaction. That’s the smallest transaction. Part of what makes this issue particularly a little bit thorny is that really, we’re talking about the witness stripped size. So, in a lot of cases, you might have the actual transaction, like if you read it from your disk, it might be 100 kB. But if you’re looking at the difference between the segwit component and the onchain, you know, from the legacy section of the block would be 60 bytes. The issue that comes up is that if you specifically target 64 bytes, which can be done, I think, by a couple different combinations of bytes in the scriptSig or bytes in the scriptPubKey of that one in, one out. There’s just a couple combinations because it’s a small, you know, you do three here and you do two there, or one there, so on and so forth.

So, the problem that arises is that when transactions are hashed, that gives you a 32-byte hash. And when we put the transactions into the merkle root of the block, we put two hashes side by side, and then you hash again. And what this can lead to is a confusion of, “Is the piece of data that I’m looking at, is it a transaction or is it a higher-level node in that tree of 2 transactions’ hashes?” So, the merkle root in Bitcoin is kind of an interesting one in and of itself, but that’s the core problem that we’re dealing with. And then, the concern that I have is not really about 64-byte transactions in particular, though we can talk about the specific types of use cases that might come up. It’s more around the discontinuity of it being valid to have 60-byte transaction, a 61-byte, a 62-byte, a 63-byte, not a 64, a 65. And so, the concern is less so from maybe somebody writing a library that does something, and perhaps a little bit more oriented towards in the future, we might have covenants or something, or we might have some other advanced use cases. And then, avoiding those automatically getting into situations where 64-byte transactions are omitted without having like lots of guardrails around that might be problematic. So, that’s really the core of the problem.

The use cases, and I’ll pull up my email just so I can give it, because it was a while ago that I wrote that one.

Mark Erhardt: Well, if you just want to take a glance at that, I maybe recap a little what you said.

Jeremy Rubin: I have it up. But yeah, if you want to recap, go for it.

Mark Erhardt: I just wanted to confirm. Yes, the smallest possible stripped size of a transaction is indeed 60 bytes. That is by having 41 bytes for the input, 10 bytes for the transaction header, 8 bytes for the amount, and then 1 byte for the length of the output script, which then is empty. And the 41 bytes of the input are the 32 bytes of the txid, the 4 bytes of the output position that you’re spending, 4 bytes for sequence, and then again a length indicator for the input script and an empty input script. So, the problem indeed exists that we would be allowed to have stripped transaction sizes of 60 to 63 bytes, not 64 bytes, and then 65-plus. And that leads me to my first question. Would it then be preferable to you if just all sizes below 65 were forbidden, rather than having the discontinuity?

Jeremy Rubin: I think that that’s a little bit preferable. But the problem then is you have the issue that scripts can be, if you have more than one input, then you can have two scripts that are of 0-byte, 1-byte, 2-byte, 3-byte, 4-byte length. And so, now script length has a dependency on how many outputs are in a transaction. So, a fix that I would prefer would actually probably be, if we’re worried about these discontinuities, is that scripts have to be at least 5 bytes.

Mark Erhardt: Sorry, I didn’t understand what multiple inputs would be a problem here.

Jeremy Rubin: So, the Bitcoin transactions work is bizarre in a lot of ways. So, if you’re enforcing a 65-byte transactions or greater rule, this is generally sort of also forbidding these small script sizes, if you are only spending one output or only creating one output.

Mark Erhardt: Well, if you have one input and one output. If you have two inputs, obviously you’re already over a 100-byte stripped size.

Jeremy Rubin: Yes. And so, then you can have these 0-byte ones. So, it does still kind of create a discontinuity of like, let’s say that you are brokering a transaction with someone, and just imagine that you have a protocol where you’re going, “Okay, we’re going to do this, we’re going to do that”. Okay, and then now we’re going to drop this other output”.

Mark Erhardt: Oh, I see. So, if you were doing the same use case and sometimes you had one input or two inputs, if you did it with one input, you would have to pad the transaction. And then, if you use two inputs, you could use them with empty scripts. Well, you could pad them in both cases, but that would waste blockspace.

Jeremy Rubin: Well, you can pad them depending on if you can pad them. That’s kind of the problem, is maybe you can’t pad them for some reason. And so, I think that these types of rules are just really tricky. And they’re also tricky in terms of, I think a really good example, because this is where we talk about the current use cases, is let’s just say that I had some segwit output and then I want to turn it into an ephemeral anchor, P2A (Pay-to-Anchor) under the current P2A protocol. For some reason, that’s all I want to do; and then sometimes, I can have a change output where I send the other funds and sometimes I don’t, because I might say, “Oh, well, it’s a dust amount anyways, so I’m just going to turn this into an anchor with no other output”, or sometimes I do. And so, what can happen in theory, let’s say that you had this being omitted from some sort of covenant system, which again, keep in mind, you can have a huge covenant, 100 kB of script data that’s all living in the segwit space. So, these aren’t transactions with no functionality. They’re transactions that the functionality is living in the segwit script space. So, you could have a situation where maybe the covenant gets into a state where it is expecting, based on its rules to, in the case where it’s dust, only omit one output and then it gets stuck in that state because of this this discontinuity.

Mark Erhardt: Right. But if you were relying on this transaction to enforce a previous transaction existing, you would need to have some script that exceeds 2 bytes, like an ephemeral anchor.

Jeremy Rubin: So, the script program from segwit can be however long you want. It’s only the script output that we’re talking about.

Mark Erhardt: Right, the output. Ephemeral anchors, of course, ANYONECANSPEND.

Jeremy Rubin: And this is where the current use cases come in, is there are multiple ones that are interesting for different reasons, that are currently used in various places. One is transaction donating to a future miner, which I guess there’s a little bit of disagreement on whether that is really different than just a present ANYONECANSPEND; there’s using outputs as some kind of connector; and then there’s P2A, which is currently a 4-byte script.

Mark Erhardt: No, it’s a push and then 2 bytes, right, so that’s 3 bytes.

Jeremy Rubin: I think P2A is 64.

Mark Erhardt: Oh yeah, it’s a diversion and then a push and 2 bytes, so 4 bytes. You’re correct. So, a witness input with an empty input script and a P2A output, ephemeral anchor, or P2A output, could be exactly 64 bytes. Yes, you’re correct.

Jeremy Rubin: Yeah. So, In any case, I guess It’s not really particularly that, and I think that this is where maybe there’s a little bit of confusion, but it’s not really that in particular, 64-byte transactions are the most important thing. But it’s like creating these really, really rough edges of consensus, I think is, is very undesirable. And so, I would prefer not to do that.

Mark Erhardt: I think I’m sympathetic to that argument, but I would like to push back a little bit on the listed use cases. I think you yourself had described them as somewhat esoteric, but I think generally, if you have an ANYONECANSPEND output or a donation to future miners, the construction here was in CHECKSEQUENCEVERIFY (CSV), and then a larger number of blocks than what you can push in a single byte, so I think it was on the order of 500-plus blocks. Lower would be fine, even much higher would be fine. I don’t see how they would fulfill this role of an anchor or a connector output if there were only a single output. So, yes, of course, the input script can be more complicated, but you’re only proving that some output will exist. Could, could you elaborate on that?

Jeremy Rubin: Yeah, so one example of this would be, let’s say that I create a 512 CSV, so it’s claimable by a miner in 512 blocks, and then I use that as a connector. I can now sign or spend funds to other things that are locked that I then also preauthorize transactions. And then, I can use that specific 512 OP_CSV as a mutex, or semaphore really, to say that only one of these offered outcomes can be selected by that miner.

Mark Erhardt: Right. But anyone can spend that output.

Jeremy Rubin: It can only be spent by the miner at block 512 from now.

Mark Erhardt: Why?

Jeremy Rubin: Because it has 512 CSV.

Mark Erhardt: Right. So, it can be spent by anyone 512 blocks later, and a miner could just claim it in a different transaction without fulfilling your covenant. So, it doesn’t work as a connector output. Can you stop interrupting me? I’m speaking right now. It cannot work as a connector output because anyone can spend it. So, the claim that you could make connector outputs with 3 bytes doesn’t make sense to me.

Jeremy Rubin: Okay. It is a connector because the connector that I am using is I am making an offer to any person in the future, and I am saying any person in the future may use this specific output to select from any of these, let’s say 30 offers that I’ve made. As soon as they select using that output, all of my other offers are canceled and this is reorg safe, correct?

Mark Erhardt: Right. But they might just not select any and just take the connector output. So, usually connector outputs are tied to a public key in order to make sure that they are consumable by the person that relies on the connector output.

Jeremy Rubin: Yes, and that’s fine because the condition that you are talking about in this example, let’s just imagine, if you choose to just spend without exercising one of your options, let’s just say it’s a simple, you get to claim one coin of your choice, in that case, this would be equivalent to you claiming the coin and then sending it to an OP_TRUE. So, it really doesn’t matter. With the way that you’re using this protocol, in a sense, is that you’re making the offer of the value to the person in the future. Whether or not they take it is fine. It doesn’t impact you negatively whether or not they take it. It’s just that you are giving them this right to claim.

Mark Erhardt: Okay, so you’re talking about a specific connector output that is used to give away money, but not one that other parties need to rely on being able to spend.

Jeremy Rubin: Generally, for connectors, they have like one party that is in reliance on the connector. One party creates the connectors and another party relies on it of, “This is proof that I can claim some funds”, but it doesn’t guarantee that those funds will be claimed. In the case of Ark, for example, you have the connectors, and it is a proof that the ASP (Ark Service Provider) can claim the funds that have been revoked, but the ASP does not have to claim the funds if they don’t want to.

Mark Erhardt: Right. But I believe they’re keyed, right?

Jeremy Rubin: Doesn’t particularly matter. They can still not claim the funds and then they will revert to the original sender or original holder if they don’t claim them.

Mark Erhardt: Right, but they can only claim the funds by also claiming the connector output.

Jeremy Rubin: The original person does not need to. Well, I guess it is the connector that they’re claiming.

Mark Erhardt: I’m just saying, I see what you say about the discontinuity and, for example, the using one input and using two inputs, needing to use different input scripts would, for example, suck or not being able to predict whether you will hit a 64-byte transaction size. I can see how those concerns make sense at first glance. But when we dig down into these claims, it seems to me that all of the constructions that have been listed are not really useful from today’s perspective. And I have also not heard a construction that plausibly makes them useful in the future.

Jeremy Rubin: Okay, well, so I’ve only really mentioned so far, in discussing this, we’ve only gone through the first two, or I guess three in terms of current uses. Then, these are things that are like currently possible today with no future changes to Bitcoin. Whether or not it’s useful to pay miners in the future, I think, is sort of a matter of taste and opinion. All that I’m really talking about is that technically, you can use this to give a claim to a future participant and you can bind that to a specific block height or time. This can be used, for example, if we wanted to have some sort of block fee smoothing. You can use these types of things to do that. You can make claims by using combinations of connectors that have both time, relative time, and relative height locks to enable redeeming of different Bitcoin offers. And those can be shared out of, for example, the coinbase that you mine. And this might be something that happens in a future where let’s say we say, “Oh, it’s actually game-theoretically sound to lock additional funds up for block 101”. That gives incentive for miners not to rewind and try to change things.

So, again, it’s an example of something that could come up and then the natural way to do it happens to be for a 4-byte script. In some of these cases, you can for sure say, “Okay, well, we’re going to just make sure that we know the discontinuity”, because what can happen with the current example that I’ve given is that 512 CSV happens to be 4 bytes. But if you wanted to do 100 CSV, I think it’s only 3 bytes. And so, that’s a discontinuity. It’s just like, as you change the parameters on what script you might naturally use, you hit a bump of, “This is magically invalid because you’ve selected a number that is in the invalid range”. And then, once you get up to, let’s say I think it’s probably at least at even 2,000.

Mark Erhardt: It’s huge, it’s much bigger. It’s like into 30,000-something.

Jeremy Rubin: 30,000? So, wherever it is, it’s a discontinuity. For time and height, it’s different. So, I don’t know which one. Because I know that for time, it therefore has the flag set. And so, are all times valid or small times? I’m not sure exactly how times work for a CSV.

Mark Erhardt: I think the times are all valid because they’re very large numbers.

Jeremy Rubin: And I think that this is maybe where some of the confusion or disagreement is, is that I’m not really particularly trying to say that these are incredibly highly desirable use cases. What I’m trying to say is that these are use cases that somebody might reasonably one day build something that’s like this. And then, having the discontinuity is a very bad choice to create more confusing consensus rules, where they’re already actually pretty confusing and hard to get correct.

Mark Erhardt: Although, of course, if you’re just giving away money in 512 blocks, you can just add an OP_NOP and make sure that your output script is always 5 bytes. You’re giving money away anyway. So, if you’re paying a few sats ents more for the transaction, that probably doesn’t concern you.

Jeremy Rubin: The problem would be is if you’re deciding that omission via a covenant, then you need to write your covenant in order to introspect the script length, and then you have to add a condition into that logic as well to ensure that you can never enter a condition where you’re expected to omit a 4-byte script.

Mark Erhardt: Well, you could make sure that your output script is always at least 5 bytes and you will never hit this condition.

Jeremy Rubin: Yeah, it’s just one more thing to check. And that’s also not even the correct condition. I mean, you can use that one, which I think is part of what I was talking about earlier, where I said maybe I would prefer a rule that said scripts have to be at least 5 bytes, because that’s probably the better place to apply the rule. Otherwise, you introduce a new discontinuity, which is that transactions vary what script size is allowable based on how many outputs are in it. So, there’s just some trade-offs and I strongly prefer not to introduce discontinuities.

Mark Erhardt: Talking about trade-offs maybe we should talk about your suggestion how to fix the 64-byte transactions differently than forbidding the 64-byte transactions.

Jeremy Rubin: Okay. Well, I think that there’s been maybe some commentary that this is a proposal that I’m really attached to or advancing. Really, where this came up is I have been taking a survey of current SPV (Simplified Payment Verification) users. I think that’s important context, is the reason to patch this is not because it introduces any problem, at least as far as I’m aware, into Bitcoin Core or Bitcoin Core consensus or Bitcoin consensus in general. Really, this is a problem only for kind of very esoteric SPV use cases where this confusion can come up. And so, the rule that has been proposed is to just eliminate 64-byte transactions. An alternative rule, which can also help, is to forbid internal nodes, from Bitcoin Core’s perspective, of the tree from colliding onto a valid transaction shape. This would require these SPV users to also enforce this rule. If they did enforce it, then it would protect them from misusing the merkle roots. It has some theoretical differences. So, technically, with the 64-byte transaction ban, you can still have interior nodes that look like transactions. It’s not particularly likely that they are, and there are things you can do to defeat it, such as checking that the outputs actually exist. But every time you introduce a new thing you have to check, that’s sort of defeating the point of the original proposal to remove 64-byte transactions, which is to silently patch all current SPV users.

So, you can think of it as there are two rules, one which is a rule looking to the bottom, and the other is a rule from the bottom looking up. The rule looking to the bottom is forbidding 64-byte transactions. The rule looking from the bottom up is preventing any interior node from being a valid transaction. They are in some senses complimentary. But the main difference for if we were to actually enact this rule is that there might be some adversarial cases where this might harm legacy miners who are un-upgraded, because there’s a new check that they have to apply. The check itself is actually relatively trivial. I haven’t benchmarked it, but it’s a couple of x86 opcodes. So, it’s really a very quick structural check. Compared to the hashing, it’s essentially free. And I mean, I can validate that with an experiment, but it’s really a trivial amount of additional checking.

But if you were un-upgraded, then there are two outcomes that can happen. One is there’s a negligible probability that you mine a block and of all honestly generated transactions, then there’s just a negligible, and maybe not in the cryptographic sense of the word negligible, but in like maybe it would take millions of blocks in order for you to have this problem come up naturally. So, you’d have to both be un-upgraded and mine a block, and you’d have to mine millions of blocks in order to really see this problem for un-upgraded users.

Mark Erhardt: The problem which you hadn’t said is that naturally, an inner node would actually match the layout of a transaction.

Jeremy Rubin: Yes. So, the natural interior node ends up looking like a transaction case, I think can basically safely be ignored, where it’s just unlikely. And then, the more troublesome one is that somebody would explicitly grind a transaction that satisfies the right-hand side rule, which I think is like 251 grinding, and then that would result in an invalid block being mined. That one’s a little bit more problematic. Conduition, hand raised?

Conduition: Yeah. I just had a minor philosophical question regarding discontinuities. So, you said you’re a bit opposed to having discontinuities in the situation where we’re banning 64-byte transactions outright. But by this alternative proposal that you have, it also introduces a discontinuity, just in a different location. You’re now creating a discontinuity where there are certain merkle nodes that just aren’t valid. How do you square that?

Jeremy Rubin: So, that is also a good question. I think that the rule that I’ve proposed, one, and this is an important point, is it is a right-hand side and left-hand side rule. And so, if you were to make an unlucky transaction just by virtue of whatever on the right-hand side, then a miner can always take that right-hand side and put it next to a left-hand side that doesn’t violate. So, I just want to underscore that it doesn’t introduce a new discontinuity for transaction creators, as long as transactions can move about with some degree of freedom within a block. It does create a new sort of discontinuity in the merkle root itself. I think that the reason why that is preferable is that it impacts a different class of user. Impacting the class of all users who are creating transactions is different than impacting the class of users who are professional, essentially miners. And I think that when you change what’s happening at the transaction layer, you’re also impacting what’s happening for the miners. When you change just what’s happening for the miners, you’re not impacting users, you’re not impacting scripting, you’re not impacting all these other things.

The other reason, which is maybe more of a moral case for it, is that this problem is purely a problem that is rooted in the merkle root being bad, like that we didn’t design the merkle root correctly. And so, if there is a punishment, then the punishment goes to the thing that’s messed up. We’re not going to punish another part of the system that really already has enough complicated rules. We should leave that alone. If really what we’re doing is patching over something that was broken, we should apply the patch close to the problem.

Conduition: That’s a fair assessment. I feel like I can understand that. You’re saying that it’s essentially a don’t-break-use-space philosophy of, okay, developers and miners, they should be able to know to apply this patch and check for this particular discontinuity. But users and wallet developers of Bitcoin might not have the same level of resources. So, okay, I can see that. Thank you.

Jeremy Rubin: Yeah, that’s a good question, and I like the framing of, “Don’t break user space”. I think that the other thing that I would add is that with respect to general, like, why is this even being discussed, it’s kind of important because who is the user who’s benefiting from this? And it’s really SPV clients, of which there are a couple of relatively important deployed systems that are actually using SPV proofs. So, from what I can tell, the most used SPV system is probably Rootstock. And they actually use the rule that is in this BIP; they use a very similar rule to protect their systems. This would be enforcing what they are already doing. And then, there are some other systems like Citrea, which is launched, potentially Alpen, and then there’s Electrum wallets as well, which would be the other class of system. I think that that covers almost all. And then, there’s like some things like tBTC. I think that they use one variant of the rules, I’m not sure which one they use. But there’s only a handful of these SPV systems that are really out in the wild right now, as far as we know.

This is why I was saying this is not really my main proposal, it’s just something that came up, is that there is actually an alternative rule that’s out there in the wild actually being used by one of these systems and has a set of trade-offs, but it’s not necessarily a bad set of trade-offs. If I were doing it anyway, what I would probably be doing is adding a different merkle root inside of, let’s say, the coinbase, which there’s another footnote there. But I would maybe add another merkle root inside the coinbase. And then, I would structure that one as a sparse merkle tree, or set a sparse merkle tree keyed on interesting pieces of data, such as which outputs are being spent or which addresses are having funds sent to. Because that sort of merkle tree is actually much more useful for these SPV clients than the current merkle root. So, if it’s something that’s being done in service of SPV users, we can maybe give them something better in any case.

Mark Erhardt: Right. You said that this would benefit SPV users, and the idea would be that SPV users could rely on any 64-byte inner node in the branch being invalid if it matches a transaction layout. However, they would still need to check the inner nodes for that. And if someone gave them a shorter branch, that would still be able to confuse them. On the other hand, if they had to check for 64-byte stripped transactions, that would just always apply to any transaction that is 64 bytes. So, from a perspective of an SPV system, could you please elaborate how this is an improvement?

Jeremy Rubin: Are you asking how this current role is an improvement, or what I was just mentioning?

Mark Erhardt: Well, this is directly juxtaposed to the proposal in BIP54, just forbidding 64-byte stripped transaction sizes. So, I’m curious, how does forbidding the inner nodes to match each valid transaction template benefit SPV more than just forbidding 64-byte transactions? Because all SPV clients already have to calculate txids. So, they certainly can get the stripped transaction and calculate txids. Counting the bytes is not particularly hard. Checking merkle branches is probably more complicated than that.

Jeremy Rubin: Yeah. So, I think that what I would say is that the foundational idea that we can do something to protect users of buggy software is probably just a bad idea. And there are deployed SPV systems out there that have mitigations against this problem already. And also, the main one that had this vulnerability has also been patched. And so, really what we’re being asked to do is to assist, theoretically, someone’s side project where they write a naïve SPV proof and then don’t know about this issue.

Mark Erhardt: But your argument was that people wouldn’t know about the 64-byte for discontinuity, which would be a bug, right?

Jeremy Rubin: Yeah, so I mean in theory, any consensus rule can lead to un-upgraded clients accepting invalid blocks. That’s a problem. But I think that the point that I’m trying to make is that in any case, the answer to buggy software is not to make a breaking consensus change. If you have buggy software and there’s a solution, then you should probably just use a solution to that. And I think we’ve seen deployed by layer 2 systems, both in their protocol not having 64-byte transactions be meaningful or acknowledged, which is an acceptable solution; and we’ve also seen deployed the path-checking rule, which is also acceptable. And so, I think that the idea of consensus enforcing it to me is generally suspect at all. I wrote this up as, well, I think that the way that the 64-byte transaction rule has been pitched has been like this is a foregone conclusion and this is the only thing that can solve this and we need to do this to protect these SPV users. I’m actually not really strongly in favor of that at all, I’m just not in favor of removing 64-byte transactions.

I don’t know if that makes sense. And I’m proposing this as an alternative of this seems to be, to me at least, a reasonable burden, not on miners, I agree it could be unreasonable for miners, but it seems to be a reasonable burden to place on SPV users to write the software correctly. At a certain level, you have to say, “Write the software correctly”. Really, the reason to introduce any new rule is that the trade-offs on writing it correctly are a little bit too high, where it’s either, like for the case of how Rootstock is implemented, there is a real risk of somebody grinding to hide a transaction from Rootstock. So, this would prevent an attack on Rootstock, for example. So, if we’re in the business of protecting SPV users, then it would make sense to do a rule that protects Rootstock, because they’re a deployed system with capital. I don’t know if there’s a particularly exploitable thing on hiding a transaction from them, because I think that at most, you can lose your own money. But maybe somebody could attack a user by grinding to hide their deposit, which would be bad.

So, I think that generally what I would prefer though, and this is what I was saying, is I would prefer actually just introducing a more useful merkle proof for these systems. And that seems to me to be a much better pathway that also solves the problem. And if you are really have your heart set on using Bitcoin’s merkle root, that’s sort of your problem if we give a better tool to use in general.

Mark Erhardt: Right. Although if we’re heavily relying on the SPV clients to fix it for themselves, they could also, like as Eric proposes, just look at the height of the coinbase transaction and not accept anything that isn’t at the same height as a valid transaction.

Jeremy Rubin: Yeah, so actually, for that to be secure, I believe you also need to ban 64-byte coinbase transactions.

Mark Erhardt: I think we got that covered, at least for segwit blocks.

Jeremy Rubin: Yeah, at least for segwit blocks, correct. But it’s not guaranteed that you’ll have a block that’s segwit.

Mark Erhardt: Right. All right, let’s wrap this up. Do you have anything else that you would like to share with the audience at the end of this topic?

Jeremy Rubin: Yeah. I mean I guess I’d say, I still have that knowledge-gathering one open. I’m planning on leaving that thread open for a while before trying to summarize it, and then propose an alternative merklization. Generally, I think I agree with what Sjors is saying, which is that it just seems like the benefit of anything right now is not that high. So, probably we should just drop that rule from the slate of activation, and I think that that seems fine. If we are going to do something though, eventually I think it ends up looking like, we know in the long run that we’re going to have to replace the block header in some shape or form. And so, I think that thinking about alternative merklizations, whether fully deployed in the format of new headers, that might be a little bit extreme, although there are some ways of doing it that are provably low impact to miners, which maybe is a topic for another week. But you can also just have it as a commitment in the coinbase, that has a cost of your proofs getting at least twice as long, because you have to go to the coinbase and then to your other proof, which might be annoying. However, it amortizes because any transaction in that block would have the same one. So, it might be a reasonable trade-off, especially, I think, SPV proof size is, at the end of the day, not a huge deal, given that for a lot of these systems, they’re using zero-knowledge proofs anyways, which can condense a lot of the data.

So, if we’re going to do something, that would really be my favorite approach, would be to deliver a more useful SPV proof that can both prove other properties and also doesn’t have rough edges.

Mark Erhardt: Yeah, maybe we could just put the height of the merkle tree somewhere that is easily retrievable.

Jeremy Rubin: That is the coinbase, that’s where you can retrieve it from.

Mark Erhardt: Yeah. Well, thank you for joining us and sharing your perspective.

Jeremy Rubin: Thanks guys, bye.

Mike Schmidt: Thanks, Jeremy. Cheers. We do not have Gustavo this week. So, Murch and I are going to tag-team the Releases as well as the Notable code segment, starting with a handful of Bitcoin Core RCs, Murch?

Bitcoin Core 31.1rc1

Bitcoin Core 30.3rc1

Bitcoin Core 29.4rc1

Mark Erhardt: Yeah, we got a whole batch of them in the past week. So, there is Bitcoin Core 31.1rc1, Bitcoin Core 30.3Rrc1, Bitcoin Core 29.4rc1. And I’m treating them as a batch because, well, all of them are maintenance releases. They just backport fixes to the last few major branches. I have said as much before, but in Bitcoin Core, we have two major releases per year, one early April and one early October. The major releases bring the new features, and then there are maintenance releases that bump the minor version that are issued as needed.

In this case, 31.1 brings us the fix for the -privatebroadcast issue, where in really only deliberately-created circumstances, a node that claims to support v2 transport downgrades the transport on a -privatebroadcast handshake, and then the peer would reconnect, ignoring their proxy, and thereby reveal what IP address they had. We talked about this a few weeks ago. This was discovered after the risk of this brand new feature, and will be fixed with 31.1 there are some other fixes. I think most notable is maybe the chainstate compaction fix. So, in 31 or maybe 30, I think in v30, we changed from flushing the UTXO database once per day at least to once every hour. And when we flushed the database, the LevelDB would be compacted. So, if there had been any slack or unused space, it would sort of be, well, if you’re as old as me and have ever watched your Windows computer defragment your disk, you can think of it as sort of like that for LevelDB. And that would now trigger every hour and recompact the entire UTXO LevelDB under certain circumstances. So, there’s a fix in 31, and this fix is also backported to 30.3 and 29. And yeah, there are a few other smaller fixes that are being backported.

If you are using any of these major branches, please take your time to review the RC. We would always love for downstream projects that rely on Bitcoin Core to throw it into their development or testing framework and tell us if there’s any issues for them. Read the release notes for all the details. And other than that, they should be out in a few weeks, probably a week or two.

Core Lightning v26.06.2

Mike Schmidt: We have some Lightning-related releases here. Core Lightning #26062, this is a maintenance release for Core Lightning (CLN). And what we pulled out to note was the cln-currencyrate plugin. If you were using that on a minimal operating system, or some sort of a minimal Docker setup and you did not have TLS root certificates installed, you would have some failing related to that when doing the lookup, because you couldn’t actually reach out to that currency rate site to get the information because you didn’t have the root certificate. So, there’s a fix for that pretty small one there.

LND v0.20.2-beta.rc1

Also have LND v0.20.2-beta.rc1 and LND v0.21.1-beta. These two releases share many of the same fixes, and I’ll note where the 21.1 beta differs. But there’s a fix for a DNS fallback issue that caused a panic in LND. So, LND has this fallback path that can look up a peer via a DNS SRV record. But there were some assumptions baked into that code, and it could result in an outright crash when those certain casting happened internally. So, that’s fixed. There is a fix for the onchain forward-interceptor settlement bug. This is part of LND’s API that lets external applications hold and decide about an HTLC (Hash Time Locked Contract) parsing through a node. The situation was if the incoming channel force closed while that forward was being held, that settlement could actually get, I guess you could say, stranded, and that held forward was tracked as an offchain entry. And there was no way for the onchain version of that HTLC to replace it. So, there was a fix for that. Those were in both versions.

LND v0.21.1-beta

Then, there is a Tor v3 fix in the 0.21.1 beta. This is where you would start a fresh LND node with the Tor active, Tor v3. And that could actually fail to create the onion service at all. And the internal root cause there was that LND was still resolving an older version of that Tor module. And so, that’s been fixed. And both releases also ship with a tightened-up final-hop HTLC CLTV (OP_CHECKLOCKTIMEVERIFY) expiry. And we’ll get to that in the code section below, since we dug into that in the Notable code segment.

LDK v0.2.4

Finally, we have LDK v0.2.4, which is a maintenance release and it’s another narrow fix here. It fixes a regression in 0.2.3 that accidentally, unintentionally raised the minimum supported Rust version for the Lightning Crate. And that matters because LDK commits to compiling with rustc 1.63, a deliberately older compiler version, so that other projects can keep building without being forced to upgrade their compiler. And then 0.2.3 accidentally broke that sort of promise unintentionally. But v0.2.4 restores that compatibility and allows you to use those older rustc versions.

Notable code and documentation changes. We have a handful of Bitcoin Core and BIPs ones that Mirch is going to walk us through, and then I’ll wrap up with a couple of Lightning PRs.

Bitcoin Core #35266

Mark Erhardt: All right, we’re starting with Bitcoin Core PR #35266. This adds a load_wallet argument that defaults to true to the migratewallet RPC. So, the migratewallet RPC will convert a legacy wallet to a descriptor wallet. And the load_wallet argument is especially useful if you’re trying to migrate a legacy wallet on a pruned node who has already pruned the nodes below the wallet’s birthday, and loading would therefore require those blocks to be present. So, with load_wallet faults, you can migrate the wallet to a descriptor wallet and not automatically load it at the end of the migration, which then will succeed; whereas a migratewallet with a wallet of which the birthday is already pruned would usually fail to load, and therefore not be allowed to migrate.

Bitcoin Core #35550

We move on to the Bitcoin Core PR #35550. This updates the compact block relay negotiation. And when you send the send this compact message, which tells your peers that you accept compact blocks, you would usually expect a Boolean field to only have the values 0 and 1, and this is also specced in that manner. But Bitcoin Core used to accept any value in this field, because it was just treating it as a C++ Boolean. So, other true C values, like any positive value, would also be treated as one. Now Bitcoin Core, in the upcoming release, it will disallow any other value than 0 and 1. So, it tightens up the interpretation of the sendcmpct field in the feature negotiation during the handshake.

Bitcoin Core #35610

Bitcoin Core PR #35610 adds a netmagic command to bitcoin-util. Maybe if you’re not aware, bitcoin-util is a small, I think, library that is shipped with Bitcoin if you do the full install, and allows you to sort of do stuff with your Bitcoin nodes’ data. In this case, the netmagic command will print the 4-byte network identifier, and that allows you to realize what network your node is currently following. So, the network magic is the 4 bytes that are prefixed to any P2P messages, and this would, for example, point out if you’re on a custom signet or testnet or mainnet. So, if you use the netmagic command, this allows you to select the correct directory before starting bitcoind.

Mike Schmidt: Murch, quick question. What’s a rough heuristic as to what gets in the bitcoin-utils versus elsewhere?

Mark Erhardt: Honestly, I’m not very familiar.

Mike Schmidt: Okay, I wasn’t either.

Mark Erhardt: This is left as an exercise to the listener!

Mike Schmidt: All right, there you go. Maybe a Stack Exchange question can come up.

BIPs #2196

Mark Erhardt: Sure. Maybe someone will research it and write an answer, and that might not be me. Okay, we’ve also got a few BIPs PRs for you. The BIPs PR #2196 adds BIP95. And if you’ve been paying close attention, you might remember that BIP94 is testnet44 or colloquially called ‘forknet4’. BIP95 proposes testnet5. So, we do that thing where we create a new testnet that developers might use to test new features on testnet, especially mining features, which you can’t test on signet. And then, some people ruin this common good, per the tragedy of the commons, by monetizing testnet coins and mining blocks with the difficulty exception, and so on. And then, we put out a new testnet and I think testnets will continue until testnets are useful or we give up fully on them.

But so, testnet5 tries yet another set of trade-offs compared to testnet4. In testnet4, we fixed block storm attacks by using the first block in a difficulty period as basis for the difficulty adjustment, because the 0th block, I should say, or 1st block, is exempt from the 20-minute exception, so it cannot be mined at the minimum difficulty. But it still had the difficulty exception, which then caused people to just, as soon as a block was mined with the actual timestamp and real PoW, mine six more blocks, spacing them 20 minutes into the future, 40 minutes into the future, 60 minutes in the future, 80 minutes in the future, 100 minutes in the future, and 120 minutes in the future, with minimum difficulty. And because so many people were doing that at the same time, we would get a vast branching on every real PoW block in testnet4 and constant reorgs. So, in testnet5, we get rid of the difficulty exception altogether.

Testnet 5 is therefore more closely related to mainnet, in the sense that it has only real PoW blocks and only allows blocks to be mined at the actual PoW, although that will probably be lower than on mainnet. Otherwise, that would make very little sense to spend so much money on it. The minimum difficulty is also raised. So, instead of starting at a minimum difficulty of 1, which previous testnets used, which is almost trivial even on thin laptops or something, it starts with a minimum difficulty of, I think, a little over a million. It is not 220. But anyway, a little over a million, so a million times more difficult than difficulty 1. And it also enforces the BIP54 consensus cleanup rules from block 1. So, the idea is that testnet5 will be able to be used by miners to check whether they are compatible with BIP54, should BIP54 get more momentum towards activation.

There is a new network magic, which we just talked about, which is derived from the hexadecimal representation of the word ‘five’, and it has a new port. Please see the details in the newsletter. I’m not going to read them out to you yet.

BIPs #2165

BIP’s PR 2165 updates BIP52. BIP52 was a hard fork proposal that changed Bitcoin to an Optical Proof-of-Work system that was proposed, I think, about five years ago. So, I had been working a little bit on looking through old BIP drafts, so BIPs that had been published in draft status, but haven’t really made significant progress since then. BIP52 was one of the ones that I was unable to get a hold of the authors. I had reached out to them directly, and then also on the mailing list, and it seems to be abandoned. So, it was pushed to closed. And we’re hopefully going to also look through a few more of the open BIP drafts. There are a few that just have been open forever and don’t seem to make progress. The idea is that BIPs for which the specification is essentially complete and the authors have finished all the planned work, and they are still thinking about those BIPs potentially being adopted in the future, those should probably be moved from draft to complete; whereas BIP drafts that are abandoned should probably be closed, so readers of the repository know that they don’t have to pay too much attention to those BIPs. So, BIP52 was the first one that we closed in this initiative, but hopefully I’ll get around to looking at a few more of those.

Mike Schmidt: More coming soon then?

Mark Erhardt: Well, this is maybe also something that prospective BIP editor candidates, or anyone else that’s interested in learning a little bit about what BIPs exist, could help with. You could look through the BIP drafts, especially the ones that have been open for a while, and open a PR to propose some to be moved to complete or closed, depending on your read of the situation. That doesn’t have to be work that only BIP editors can do.

Mike Schmidt: Sounds good.

BIPs #2201

Mark Erhardt: All right. We have a third BIPs PR, and that is #2201. This one advances BIP110, the Reduced Data Temporary Softfork proposal, from draft status to complete status. And I think that’s high time, because obviously they are trying to perform their mandatory signaling period next month. So, it might be good to actually show that their BIP is complete and no longer subject to planned work. Yeah, I think you have probably read as much or as little about BIP110 on the social media platforms that are discussing it lately, so let’s just leave it at there were no changes to the specification. This is just moving the BIP to the complete status, as in signaling that the planned work is finished. It also linked test vectors and reference implementation, which I think hadn’t been linked before.

LND #10900

Mike Schmidt: Moving to our Lightning PRs, we have LND #10900, which adds an RPC for submitting packages. That’s both in the RPC and lncli wallet. This allows users to submit a 1p1c (one-parent-one-child) transaction package to LND’s backend. With LND, you can have a bitcoind backend, but you can have other backends as well. If you have a bitcoind backend, then LND will forward that package to Bitcoin Core’s submitpackage RPC, which obviously is advantageous for Lightning to have these sorts of transactions, because you’ve got to have a zero-fee v3 parent with an ephemeral anchor to be accepted together with its fee-paying CPFP child. The other backends, if you’re not using bitcoind, if you’re using btcd, for example, these functions will return something like unimplemented; and neutrino, if you have a neutrino backend, will just broadcast the transactions individually, which may have varying degrees of success, depending on the details. So, good to see LND implementing some of the 1p1c stuff.

LND #10927

Next PR, also to LND, this is LND #10927. This fixes an issue where a sender could potentially tie up a receiver’s funds for much longer than the receiver actually agreed to. This is because with Lightning HTLCs, there is a CLTV expiry, which is a block height sort of deadline after which the payment attempt can actually be reclaimed, and the nodes can set different policies limiting how far in the future those deadlines can be. Because pending HTLCs lock up liquidity, you want to make sure that you manage those expiries versus your liquidity preferences. But the issue was that those policy limits were enforced in LND on forwarding hops, so hops along the path, but not actually on the final hop would be the recipient. So, the sender could actually construct a payment, and then that final hop HTLC could have an expiry that was very far in the future, for example, and that receiving node would accept it, and that would end up locking the receiver’s channel funds for much longer than what their policy had articulated.

So, the fix is now that LND will reject those final HTLCs if the expiry falls outside of the receiver’s policy, and there’ll be a failback message. So, essentially fixing, I guess, a bug, so good to see that that’s fixed. That was also the item that was referenced in the two LND releases earlier that we discussed in the newsletter.

LDK #4748 and #4751

And last PR/PRs, both to LDK. This is #4748 and #4751, which we bundled together in this Notable code item. There are two fixes for splicing, I guess you could say edge cases, where a message receives at a sort of awkward or inopportune moment. The #4748, this is a fix for a splice potentially getting stuck. So, when there is a completing splice, LDK actually waits for its own internal bookkeeping to be safely written to disk before moving forward, which makes sense. But the bug was it was actually waiting on any pending bookkeeping write, even ones that were totally unrelated to the splice. So, this could actually result in LDK blocking the splice from completing for no good reason. So, the fix in this #4748 is that now LDK will only wait when the pending write is the one the splice actually depends on.

Then, the second fix, which is #4751, is related to a stale signature force closing, and this is force closing a healthy channel. So, the scenario here is you’re LDK, you start contributing funds to a splice, and then cancel your contribution. But the peer signature for the now canceled version was actually already in flight and arrives after your cancellation. But the bug is that LDK would try to validate that signature against the splice version that no longer exists, which would result in a failure and then potentially force close that perfectly healthy-otherwise channel. So, now LDK will check which funding transaction the signature actually refers to, using one of the fields in the message, and then it’ll ignore signatures for stale or splice versions.

That wraps up the newsletter. We want to thank Conduition and Jeremy Rubin for joining us to talk through the Changing consensus monthly segment this week. We also want to thank our co-host, Murch, and for you all for listening. And we look forward to having Gustavo back next week. Cheers.

Mark Erhardt: Cheers. Thanks for your time.

Bitcoin Optech Newsletter #412

2026-07-03T00:00:00+00:00

This week’s newsletter includes our regular sections summarizing discussion about changing Bitcoin’s consensus rules, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

No significant news this week was found in any of our sources.

Changing consensus

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

● Benchmarking SLH-DSA STARK aggregation: Remix7531 posted to the Bitcoin-Dev mailing list his benchmark results for aggregating many SPHINCS signature verifications into a single STARK proof. This follows Ethan Heilman’s earlier proposal to use STARKs to scale post-quantum blocks. In this benchmark suite (built in RISC Zero’s zkVM), proving time scales roughly linearly with the number of signatures (~3.1 seconds per signature on an RTX 5090), proof size grows sublinearly (218 KiB for one signature up to 454 KiB for 512 signatures, versus 3.8 MiB of raw signatures), and verification stays near 12-15 milliseconds regardless of batch size. Proving an entire block on one GPU would still take hours, but Remix suggests that dedicated AIR circuits (polynomial constraints tailored to signature verification rather than the general-purpose zkVM used here), mempool preprocessing, and multi-GPU proving could improve this. The benchmarks also use standard SPHINCS rather than the more compact Bitcoin-optimized SPHINCS+ variant.
● Bird of Prey 2 (BoP-2) non-malleable schnorr and PQ signatures: Pieter Wuille posted to Delving Bitcoin about a EuroCrypt 2026 paper on constructing hybrid strongly-unforgeable signature schemes from a schnorr-like scheme and an arbitrary post-quantum signature scheme. While simply concatenating signatures from both schemes is unforgeable if at least one remains secure, it is not strongly unforgeable. If either scheme breaks, an attacker can replace that scheme’s partial signature while the signature as a whole remains valid. The paper’s BoP-2 construction avoids this by having the schnorr signature commit to the post-quantum signature in its challenge hash.

Adam Gibson and Conduition discussed whether strong unforgeability still matters post-segwit, since witnesses no longer affect txids. Wuille explained that the concern is a quantum or classical break allowing anyone to malleate the broken scheme’s signature component. Conduition compared the construction to Boris Nagaev’s space-saving hybrid hash-based design (see the lattice signatures item below) and concluded BoP-2 looks like the stronger unified-hybrid contender, though Wuille and Conduition both questioned whether unified hybrid schemes are worth the complexity when separate BIP360 (P2MR) leaves, or simple script combinations can achieve similar results.
● Lattice-based signatures: Nikita Karetnikov posted to Delving Bitcoin and cross-posted to the Bitcoin-Dev mailing list about a Blockstream blog post comparing post-quantum signature families, where lattice-based schemes appear favorable on size and functionality. He inquired as to why Bitcoin post-quantum work has focused on hash-based signatures instead.

Conduition replied that hash-based signatures remain attractive for Bitcoin because of weaker security assumptions, implementation simplicity, fast verification, and suitability as a long-term fallback. Mikhail Kudinov noted that while naïvely, lattice-based signatures often require floating point computations, Falcon’s floating-point operations can be simulated with integers. Conduition and Jesse Posner discussed whether unified hybrid schnorr+lattice schemes are necessary versus achieving similar security with separate BIP360 (P2MR) leaves. On the other hand, Boris Nagaev described space savings from treating hybrid signing as a single construction rather than a simple concatenation of multiple signature schemes, since they could likely share certain required randomizing parameters, for example.
● Public key recovery for P2MR EC leaves: starius posted to Delving Bitcoin a proposal to add a recoverable elliptic curve (EC) key leaf type to BIP360 (P2MR). The idea is to recover the EC public key from the schnorr signature. The public key is committed to in P2MR merkle tree instead of a script, and the schnorr signature challenge is modified to include the merkle root and control block instead of the public key itself. Because both the merkle root and control block are known both at signing and verification time, the signature can be verified without knowledge of the public key, and then the public key’s inclusion in the merkle root can be verified via the control block. Using this technique, a depth-1 schnorr leaf witness shrinks from 135 bytes to 100 bytes, between the size of a P2TR key spend and a P2WPKH spend, at the cost of giving up BIP340 batch verification. starius and Conduition explained that including the control block in the challenge prevents a related-key attack when multiple such leaves share a tree. Pieter Wuille reviewed the construction favorably. Anthony Towns, Pieter Wuille, and Conduition discussed implications for BIP32 derivation, batch-verification discounts, and the interaction with Conduition’s depth-zero tree ban (depth-zero recoverable leaves could match P2TR witness sizes without a post-quantum fallback). starius explained that this should be folded into BIP360 before activation because it changes witness parsing rules.
● Aligning privacy incentives in P2MR: Conduition posted to the Bitcoin-Dev mailing list a proposed BIP360 (P2MR) change to require every P2MR control block to include at least one 32-byte merkle authentication path (i.e. ban depth-zero script trees). Depth-zero trees make some protocols requiring only a single script path more efficient in P2MR than P2TR, creating a perverse incentive to skip cooperative signing paths and making some contract protocols easier to fingerprint on chain.

Antoine Poinsot agreed this would address that privacy concern but still prefers P2TRv2 for mass migration because typical single-key P2MR spends cost roughly 15% more than P2TRv2 (possibly less with key recovery discussed above). Pieter Wuille argued that pre-quantum adoption incentives matter more than long-term post-quantum efficiency and that P2TRv2 better minimizes migration costs. He also noted that P2MR only makes sense if users can rely on a future soft fork disabling elliptic curve paths within P2MR. Conduition predicted similarly low voluntary migration rates for either design and noted an upcoming witness-size optimization for common elliptic curve spends (see the next item). Hayashi suggested an additional witness discount on P2MR schnorr leaves to further close the cost gap.
● Prohibit merkle internal node preimages that encode minimal 64-byte transactions: Jeremy Rubin posted to the Bitcoin-Dev mailing list a draft BIP proposing an alternative to the consensus cleanup (BIP54) rule making 64-byte witness-stripped transactions consensus-invalid. Instead of banning the transactions themselves, Rubin’s rule would invalidate any block whose transaction merkle tree contains an internal node preimage with the byte layout of a minimal one-input, one-output, witness-stripped transaction. This targets the same merkle tree vulnerability at the internal-node boundary while preserving potentially useful 64-byte transactions (see Newsletter #408). SPV verifiers would need to reject proofs whose branch preimages match the forbidden pattern. The draft includes miner recovery guidance (reorder or drop offending transactions) and notes that accidental violations should be rare.

Several responses preferred the simpler outright 64-byte transaction ban of BIP54. Antoine Poinsot argued that any system securing value already validates these transactions properly, so the distinction Rubin draws matters little in practice. Matt Corallo noted this would require miners to change their block-building software or risk producing invalid blocks. Murch pointed out that occasionally adding a one-byte padding is a smaller burden than making every node check thousands of hashes during block validation. Sjors Provoost suggested deferring a cleaner fix to a future block-header format change.
● Triggering EC disabling with a NUMS point spend or hashrate majority: Pieter Wuille wrote to the Bitcoin-Dev mailing list about codifying the expected future disabling of elliptic curve (EC) spending paths within new post-quantum output types such as BIP360 (P2MR) and P2TRv2. Without consensus-enforced triggers, users won’t be confident that EC spending will actually be disabled, undermining the quantum-resistance story for output types that initially allow cheap EC spends.

Wuille proposed two mechanisms bundled with the introducing soft fork: tripwire (P2XX-T), which disables EC paths in the new output type after any successful <NUMS> OP_CHECKSIG spend proves secp256k1 is broken, putting a non-confiscatory upper bound on EC availability; and miner lockdown (P2XX-ML), which lets a hashrate majority activate the same disabling through a separately signaled soft fork with a very long activation window. Boris Nagaev supported tripwire but raised false-positive concerns for miner lockdown after large classical thefts. Sjors Provoost suggested long delays and user migration back to P2TR as a remedy. Conduition supported tripwire, noted that the proof need not be mined on-chain, and warned that early miner lockdown could be fee-incentivized. Wuille clarified that disabling must cover all EC usage within the output type (not just key paths) and that hybrid signing should use dedicated opcodes rather than arbitrary script combinations to ensure spendability post-EC disabling.

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 31.1rc1 is a release candidate for a maintenance version of the predominant full-node implementation. It fixes an IP address leak in -privatebroadcast that could undermine transaction origin privacy (see Newsletter #409), and includes fixes for chainstate compaction, wallet migration, input-size estimation, MuSig2 key aggregation, and proxy handling during v2 P2P transport reconnections.
● Bitcoin Core 30.3rc1 is a release candidate for a maintenance version 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.
● Bitcoin Core 29.4rc1 is a release candidate for a maintenance version of the predominant full-node implementation. It fixes the same chainstate database rewrite issue as 30.3rc1 and includes selected validation, wallet, build, test, documentation, CI, and compatibility fixes.
● Core Lightning v26.06.2 is a maintenance release that fixes cln-currencyrate on minimal OS and Docker setups without installed TLS root certificates.
● LND v0.20.2-beta.rc1 is a release candidate for a maintenance release of this popular LN node implementation. It fixes a DNS fallback panic and an onchain forward-interceptor settlement bug, and adds the final-hop HTLC CLTV expiry validation described in the notable code section below.
● LND v0.21.1-beta is a maintenance release of this popular LN node implementation. It fixes Tor v3 onion service creation for fresh Tor-enabled nodes, a DNS fallback panic, and an onchain forward-interceptor settlement bug, and tightens final-hop HTLC CLTV expiry validation.
● LDK v0.2.4 is a maintenance release of this library for building LN-enabled wallets and applications. It fixes a regression in v0.2.3 that raised the minimum supported Rust version for the lightning crate; the crate now again compiles with rustc 1.63.

Notable code and documentation changes

● Bitcoin Core #35266 adds a load_wallet argument (default true) to the migratewallet RPC, allowing a legacy wallet to be migrated to descriptor wallets without immediately loading the migrated wallet. This helps users migrate a legacy wallet on a pruned node whose chain state is pruned below the wallet’s birthday, where loading the migrated wallet would require unavailable block data even though migration itself does not.
● Bitcoin Core #35550 updates compact block relay negotiation to reject sendcmpct messages whose boolean announcement field is not exactly 0 or 1, as required by BIP152. Previously, Bitcoin Core decoded the field directly as a C++ bool, causing any non-zero value to be accepted as true. The PR now reads the field as an integer and treats values greater than 1 as peer misbehavior, disconnecting the peer.
● Bitcoin Core #35610 adds a netmagic command to bitcoin-util that prints the four-byte network identifier used in Bitcoin P2P messages for the selected chain, including custom signets. This command is useful for the proposed multi-signet datadir support, in which custom signets would be stored in datadirs that are suffixed by their network identifiers. This allows scripts to select the correct directory before starting bitcoind.
● BIPs #2196 adds BIP95, a draft specification for testnet5, a new test network intended to replace testnet4 (see Newsletter #409). Testnet4 has a difficulty exception that allows for minimum-difficulty blocks after long gaps. However, this exception has been persistently exploited, resulting in frequent, small reorgs and rendering the network difficult to use for testing. Testnet5 removes the exception, raises the minimum difficulty to about 1,048,561, and enforces BIP54 consensus cleanup rules from block 1. The draft also specifies message start bytes 0x46495645 (FIVE) and default P2P port 18335, although its genesis block values remain placeholders for now.
● BIPs #2165 updates BIP52, the Optical Proof-of-Work proposal described in Newsletter #181, changing its status from Draft to Closed. BIP52 proposed a hard fork that claimed to shift mining costs away from electricity and operations and toward specialized optical mining equipment. After several years without progress and recent unsuccessful attempts to contact the authors, the proposal was closed.
● BIPs #2201 advances BIP110, the Reduced Data Temporary Softfork proposal, to Complete status (see Newsletter #392). This update emphasizes that UTXOs created before activation are grandfathered and can be spent under the old rules during deployment. It also adds reference-implementation test coverage and transaction-level test vectors. Additionally, it clarifies the impact of the temporary ban on executing OP_IF and OP_NOTIF in tapscript leaves: existing UTXOs are exempt, but new constructions using these opcodes would require alternatives, such as separate leaves.
● LND #10900 adds a WalletKit.SubmitPackage RPC and lncli wallet submitpackage command for submitting a 1p1c transaction package to LND’s chain backend. For bitcoind backends, LND forwards the package to Bitcoin Core’s submitpackage RPC, allowing a zero-fee v3 transaction relay parent with an ephemeral anchor to be accepted together with a fee-paying CPFP child. Other backends do not provide the same package submission: btcd returns unimplemented, and neutrino broadcasts the transactions individually.
● LND #10927 tightens validation of final-hop HTLC CLTV expiries. Previously, a final-hop HTLC could specify an expiry much farther in the future than the receiver’s policy allowed, tying up liquidity for an excessive amount of time even though forwarding CLTV deltas were already bounded. LND now rejects final HTLCs outside the receiver’s CLTV policy with incorrect_or_unknown_payment_details, validates related config bounds, and applies the same checks if the channel is force-closed before deciding whether to claim the HTLC on-chain with a preimage.
● LDK #4748 and #4751 fix two splicing state-machine edge cases involving delayed messages. LDK #4748 fixes a case in which delayed splice tx_signatures could arrive while an unrelated HTLC-preimage channel monitor update was pending, causing LDK to incorrectly block completion of the splice flow. LDK now only waits when the pending monitor update is the splice-related update that must be durably persisted first. #4751 fixes a case in which a peer’s in-flight splice commitment_signed could arrive after the local user canceled their funding contribution, causing LDK to validate a signature for a stale splice funding transaction and potentially force-close the still-live channel. LDK now checks the optional funding_txid in commitment_signed and ignores signatures for stale splice funding transactions.

Bitcoin Optech Newsletter #411 Recap Podcast

2026-06-30T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Nishant Bansal and Matthew Zipkin to discuss Newsletter #411.

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

Download audio

News

● LND zero-timestamp gossip DoS disclosure (1:00)

Selected Q&A from Bitcoin Stack Exchange

● Is it a bug that `OP_IF` is part of the tapscript opcodes? (34:02)
● Why would forbidding `OP_IF` in tapscript be a problem? (41:11)
● Does a softfork always succeed? (49:17)
● How to set up Bitcoin Core to mine a valid block after the BIP110 activation in August 2026? (56:44)
● Are BIP110 blocks on a branch with lower difficulty valid? (59:47)
● What is the story behind Bitcoin test networks? (1:07:41)
● Why was `-datacarriersize` redefined in 2022, and why was the 2023 proposal to expand it not merged? (1:15:35)
● Are chains of 26 unconfirmed transactions prohibited by the wallet in Bitcoin Core 31.0? (1:25:33)
● Are there changes in Bitcoin Core 29.0 that affect memory usage? (1:28:20)
● What is Bitcoin Core's release schedule? (1:30:21)

Releases and release candidates

● LDK v0.1.10 (1:34:50)
● LDK v0.2.3 (1:35:31)
● BTCPay Server 2.4.0 (1:37:04)

Notable code and documentation changes

● Bitcoin Core #35070 (1:39:27)
● Bitcoin Core #35182 (13:15)
● BIPs #2198 (1:46:09)
● LDK #4713 (1:51:17)
● LDK #4684 (1:53:47)

Transcription

Mike Schmidt: Welcome, everyone, to Bitcoin Optech Newsletter #411 Recap. This week, we’re going to talk about a disclosure of a DoS vulnerability in some older LND versions; we’re going to jump into a Notable code PR, or a series of PRs, around removing a dependency, called libevent, in Bitcoin Core; and we have a bunch of questions actually this month from the Stack Exchange that we’ll get into; and then we have our weekly Notable code and documentation changes and Releases as well. This week, Murch, Gustavo and I are joined by two guests. We’ll have them introduce themselves briefly. Nishant?

Nishant Bansal: Hey, I’m Nishant, and I work on fuzzing LN implementations.

Mike Schmidt: Awesome. And we also have Mr Zipkin.

Matthew Zipkin: Hi there, I’m Matthew, pinheadmz, and I’m a developer at Chaincode Labs.

LND zero-timestamp gossip DoS disclosure

Mike Schmidt: Thank you both for joining. We’re going to jump into the News section, which just has one item this week titled, “LND zero-timestamp gossip DoS disclosure”. Nishan, this was based on a Delving post that you made, disclosing a DoS vulnerability that you discovered through state-machine fuzzing of LND’s gossip handling. Maybe you can get into, Nishant, what did you actually find? We can talk about the actual vulnerability itself. And then, I’m also curious, maybe after we wrap that up, we can talk a little bit about what is state-machine fuzzing, since we’ve talked about fuzzing on the show before, we want to hear about state-machine fuzzing. But what did you find?

Nishant Bansal: Yeah, sure. So, I’ll start from the very beginning. So, Lightning nodes exchange gossip messages, and the one we are going to talk about are channel_announcement, node_announcement, and channel_update. So, basically, these three messages Lightning nodes share so that every other node can know about new channels, new nodes, and basically the update in the existing channel or new channels’ routing policies. And what happened is three messages, every node processes, validates them, and it updates their network graph and then again rebroadcasts these messages so that other peers can also update their network graph, which are basically used to route payment throughout the network via HTLCs (Hash Time Locked Contracts). So, in LND, there was a vulnerability in their rebroadcast logic, so LND broadcasts this gossip message in some periodic fixed intervals, and during that fixed interval, LND de-duplicates these messages. So, maybe during that interval, there is certain channel_update or channel_announcement which are the same but their timestamps are newer. So, LND only stores those messages whose timestamps are latest and discards the ones which are old.

The vulnerability was that an attacker could send a channel-update or a known announcement whose timestamp can be zero. And on seeing the timestamp of zero, LND incorrectly assumes that this message was already seen and tries to deduplicate it to its map base, like internal bookkeeping. And when it tries to put that message to not initialize map, LND basically panics. So, that is what the vulnerability is. But if the victim node restarted after the crash and if the attacker tries to send the same message again, LND is going to reject those messages as stale gossip, because this bug was in the rebroadcast logic and the stale gossip part was before that in the validation stage. So, an attacker cannot send the same message again if it already crashes the victim node. But this can still be manipulated if the attacker creates a new channel and sends again this new channel_update with a zero timestamp for that channel.

With that, I tried two ways. So, in my post, I mentioned two ways. One is the very straightforward way, where the attacker tries to create an actual channel and tries to send the channel_announcement and channel_update for that channel. And another could be that the attacker does not have to open an actual channel; the attacker can create a fake LN node which it only used to do a noise handshake and which periodically sends pings so that the connection stays alive. And then, the attacker can fund basically 2-of-2 P2WSH funding output, and then tries to send the channel_announcement based on that. And since all the LN nodes only validate that whatever the Bitcoin keys mentioned in the channel_announcement message are valid, and output is actually that P2WSH, all the LN nodes basically will accept those channel_announcements. And if after that, an attacker sends a channel_update or maybe a node_announcement further, then it can again crash the victim node.

Mike Schmidt: Okay, all right. So, it sounds like there’s a few different attacks across a few different potential messages that are possible. One, you mentioned the synthetic channel is probably the cheapest one, because they could just have a 2-of-2 with themselves and then do an announcement based on that and crash LND nodes. Do I have that right?

Nishant Bansal: Yeah. So, the attacker has to first fund the 2-of-2 output, and then based on that, it has to send the channel_announcement. The LN node basically has, you can say, a prerequisite that a channel_update or node_announcement will only be processed once a corresponding channel_announcement is fully processed and validated. So, for these messages to ultimately reach the rebroadcast logic, which only comes after the full validation phase, a corresponding channel_announcement has to be parsed completely. So, an attacker needs a valid channel, or maybe a 2-of-2 output, to actually crash the LND node.

Mike Schmidt: Okay, that makes sense. That answers my next question, which is why not just do a bunch of fake node_announcements? But, per what you just said, that’s not sufficient to trigger the codepath that would crash the node here.

Nishant Bansal: Yeah.

Mike Schmidt: Okay. Murch or Gustavo, any questions so far on the vulnerability and then we can talk about state machine fuzzing? Okay. Maybe, Nishant, I think listeners have heard us talk about fuzzing just at a conceptual level a few times with different folks, the idea of throwing quasi-structured but quasi-random inputs into various functions to see how node software or any software behaves, and then pulling out the unique cases there or crash cases to build sort of a corpus, and then build upon that. But maybe we’re not familiar with the idea of state-machine fuzzing. Maybe you can let us know what that is?

Nishant Bansal: Yeah, so basically, state-machine fuzzing, or sometimes it is mentioned as protocol fuzzing, takes this traditional fuzzing to one level higher. So, in the traditional fuzzing, we try to think of a particular function as a black box and try to feed all sorts of parameters it has to see if that function has any edge cases. But in the state-machine fuzzing, we try to feed some sequence of messages to a particular subsystem of a whole system. So, for example, if you take gossip, so LND has a lot of systems. So, there is a gossip handling system and there is an HTLC switch which handles all the HTLC-related state transition. So, for the gossip subsystem, there is a specific, like once a particular peer sends a message wire message of gossip, and that wire message is decoded and directly fed to that particular gossip handling, that is where the state-machine fuzzing comes. So, state-machine fuzzing tries to initialize that particular subsystem, and then it tries to generate a sequence of both valid and invalid messages, and tries to feed those message to that subsystem and tries to see how that particular subsystem is behaving, and if there is any edge case in that subsystem, or that subsystem is not crashing, or its internal state remains consistent, even if there is any unexpected messages coming to it. So, that is how the state-machine fuzzing goes.

Mike Schmidt: Super-interesting. Did you build out the state-machine fuzzing? I guess question one. And question two, can such state-machine fuzzing be easily applied to other LN implementations and how they handle gossip, or is it really custom for the way the LND subsystem works?

Nishant Bansal: Yeah, so for state-machine fuzzing, I came to know about last year only. So, I was going through LDK’s first suite, then basically Matt Morehouse pointed me to that. So, he was my mentor I was a Summer-of-Bitcoin student last year, so he was my mentor on that, and I was curious about fuzz testing. And that is where he pointed me to LDK, because I checked the state of the state-machine fuzzing for LN implementations and during that time, during last year only, LDK was the one which has pretty good fuzz tests for the state-machine fuzzing. And that is how I went through that. And then I thought, at that time, LND didn’t have any single state-machine fuzz test. And so I thought, maybe I’ll understand what is going on in the LDK and try to do the same for LND. And that is how I found this bug.

Mike Schmidt: Awesome. So, this was found during your Summer-of-Bitcoin internship?

Nishant Bansal: No. So, my Summer-of-Bitcoin internship was mostly on LND, so it was on making an application which can continuously fuzz Go projects. And since LND was in Go, so ultimately that project was for LND. And then, during that time, I came to know a lot about normal fuzzing, which includes like, functional-level fuzzing and then state-machine fuzzing. So, once my project completed, I thought maybe let’s see what is the state of fuzzing in LND. And then, I came to know LND doesn’t even have any single state-machine fuzz tests, and that is how I tried to fill some gaps in the LND.

Mike Schmidt: Awesome. Well, great work. Murch, Matthew, or Gustavo, any questions for Nishant before we wrap up? Okay, great. Nishant, any parting words for listeners who might be interested in doing similar work or anything else that’s on your mind?

Nishant Bansal: Yeah, I think this implementation’s flaws are most easy to get exploited considering how easy they can be carried on, like this vulnerability as well. So, I think state-machine fuzzing is very helpful in such cases, and it would be really great if all LN implementations at least follow or adopt state-machine fuzzing beside their normal testing or fuzzing approach. I think LDK is already doing a great job. Whatever feature they try to add, whatever protocol they try to add, they add state-machine fuzz tests for that. And I think it is practical for other LN implementations to add that as well.

Mike Schmidt: Awesome. Well, Nishant, thank you for your work on this. Thank you for responsibly disclosing it and for coming to talk to us today about it. We appreciate your time.

Nishant Bansal: Yeah, thanks, everybody.

Bitcoin Core #35182, #34411

Mike Schmidt: Cheers. For listeners, we’re going to jump out of order. We’re going to Notable code and documentation changes, which means something interesting is happening that we want to have a special guest on for. We have Bitcoin Core #35182 and Bitcoin Core #34411. And we’ve brought on Mr Zipkin to talk about this. This is around this libevent. And I think folks, maybe through the grapevine, have heard something about removing dependencies, some people are working on libevent. Matthew, what is libevent? Why is it good to remove libevent? How do you move libevent? What was libevent doing? You pick where you want to tell the story from.

Matthew Zipkin: Okay, all right. I’ll try to make it a good, interesting story. So, libevent is an old library written in C and it provides an event loop for consumers of the library. So, that means scheduling tasks, timing things, it’s single-threaded. Node.js developers are probably more familiar with its cousin library, libuv, and the idea of an event loop in general that you schedule things and processes, stuff like that. So, another feature that libevent provides, in addition to that event loop, is the HTTP server, and this is primarily what it was being used for in Bitcoin Core. So, I believe it was added, I want to say probably by Mara van der Laan, ten years ago to replace Boost. I think there was an HTTP server in Boost before that. I’m not quite sure about the very first generation, but libevent was still a popular and well maintained library at that time.

Over the years, it’s become less maintained, and certainly there’s been very few releases, I think zero releases in the last four or five years. And in addition to that, they’re looking for a new maintainer. There’s an issue on their repo about looking for a new maintainer, which is a bit of a red flag. It’s kind of this really important project, Bitcoin, depending on this piece of open-source software that’s going through a maintainership, leadership change, and we’ve seen vulnerabilities introduced at times like that, with compression libraries and stuff. We don’t want to get sucked into that. And also, if you look at the libevent issues and PRs, most of them are from Bitcoin Core contributors. I don’t know how popular the library is anymore. So, it’s one of the last external dependencies, meaning we, in some cases, expect the computer to have libevent already installed and we link to it. There’s obviously stuff like a depends build, where the entire codebase of libevent is pulled in and we release it. So, that’s a little bit different. But libevent has become a liability because it’s this potential risk and maintenance burden in the depends code. And so, there’s plenty of good reasons to reduce dependencies.

My personal adventure down this path is kind of funny. I think two or three years ago, whenever Core Dev Berlin was, it was around that time, I was looking at some really old issues in the Bitcoin Core repository. And one of them was a feature request by users to add Unix domain sockets for the RPC server. So, what that means, for people who don’t know, is when you run Bitcoin Core, it spins up an HTTP server, which is what we’re using libevent for, and you can send messages to it, commands like, “Create a wallet”, or, “Tell me what the hash of this Block is”, and stuff like that. And those questions and answers get sent over HTTP, same protocol we use for web pages. Since typically the client and the server are on the same machine, there’s no real need for that kind of infrastructure. You can use what’s called a Unix socket, which is basically just a path on your file system. Except it’s not really a file there, it’s a socket and you can send data back and forth over it. Tor, for example, uses this, Docker uses this. It reduces the overhead, it reduces security risk, and it’s a good feature for Bitcoin Core to have.

So, I originally was looking at how to add Unix sockets to Bitcoin Core for the RPC interface. Is that a question? Was that a finger? Okay, go.

Mark Erhardt: I was just wondering, so if you were able to use these Unix sockets in order to talk from your own computer with your own computer through the file system, would that mean that you could turn off the HTTP server, because most RPCs interfaces should not be open to the entire internet and so on, maybe not even to network. So, only being able to talk through your own computer to it would kind of make sense.

Matthew Zipkin: Yeah, exactly. It would obviously be optional, because I think after 15 years of Bitcoin Core having the HTTP server, there’s probably lots and lots of clients and applications that are used to it being there. So, I don’t think it’s something we could ever get rid of, but it would be a nice option to switch to the Unix socket. And as I looked into implementing this, I hit a roadblock in libevent. And I had an issue and maybe even a PR to libevent back then. But the problem with libevent is like, even if they fix something in master branch, they haven’t cut a release in so long. And nobody’s installing libevent from master. You do apt install libevent-dev, and it’s just packaged, you know, depending on what operating system you’re using. And the fact that libevent was not keeping their patches up to date with new releases means we couldn’t just be like, “Oh, Bitcoin Core, this version. Use a new version of libevent and you’ll have this Unix sockets feature”. It just wasn’t going to happen.

So, we started looking into the alternatives to libevent, or there’s other solutions to this problem, which are one, we can take the entire libevent source code, move it into Bitcoin Core, and own it, fix stuff there. And this is what we’ve done with, I want to say LevelDB. Maybe Murch knows more than me. So, we’ve done this with the LevelDB source code. That was one option. Another option is to find another HTTP library that’s just out there and swap. And the third option was to write a new HTTP server entirely as part of the Bitcoin Core codebase. And after discussion with other developers and contributors for Bitcoin Core, that’s what we decided to do. Any questions up to there? Yeah?

Mike Schmidt: I’m curious how much of the libevent library would need to be/was recreated. So, the reason I ask is I’m thinking about like OpenSSL and secp, and that was just like a very, very small portion of a giant library that was getting used, and so it made sense to carve off, even though it probably was still a big chunk, into its own code that was managed by Bitcoin Core. And I’m curious, of libevent, how much of that needed to be recreated? Was it basically the whole thing, using all the features, or was it just a small piece of it?

Matthew Zipkin: Right, good question. So, yeah, libevent is primarily this event loop, which is not really what Bitcoin Core needs. It has an HTTP application as a bonus on top of the event loop. And the server is what we really need. It’s really easy in C++ to just write a loop in a thread. And in fact, we do this for P2P already. I mean, there’s loops all over Bitcoin Core, but we have the P2P messaging takes place in a thread with a loop that checks sockets and sees if there’s any connections coming in and any messages coming in on those sockets. So, a lot of that architecture was already there written in C++. The HTTP protocol itself, like get, post, URL parsing, stuff like that, we relied on libevent for that. The other thing I’ll mention that might not be obvious is that we also ship a client tool, bitcoin-cli, which also used libevent for the client stuff. So, ultimately, we would need to replace both the server and the client. Both were being used, both were using libevent. And there’s also smaller areas of the codebase. The way that Bitcoin Core interacts with the Tor daemon, a protocol called Tor Control also was using libevent, because that’s also an HTTP-based – it’s actually not HTTP but it uses the same socket-reading protocol. So, that was replaced by Fabian. Other little utilities, like parsing URLs, those were replaced by Fabian.

Then, I wrote the server replacement, which I mean it took two PRs each with 300 comments over two to three years. The architecture went all the way out and all the way back on how we were going to do it. As I mentioned in the P2P code, we already have socket-management stuff and it’s cross platform, because obviously, without any type of dependency like libevent, you can run Bitcoin Core on all of our supported platforms, we can open software sockets and make network connections on all those platforms. So, we already have that stuff in there. And the debate early on was how much of that to reuse. So, Vasil had a great effort of abstracting away the socket layer into its own socket library that could be consumed by both the P2P function and the HTTP function. We’d both be consuming the same socket library. There was some pushback on that, and so my first HTTP server actually used that socket abstraction, and then we decided not to do it that way.

So, the way it is now, the way that it got merged is that there’s socket-handling code in a single thread loop for P2P, and basically a second version of that code for HTTP. And it means that we can adjust the socket implementation very specifically and granularly, which was Cory Fields’ contribution to the debate. So, if there’s things we want at the socket level for P2P, it won’t interfere with what we need for HTTP.

Mike Schmidt: Very cool. So, does this wrap up? Do these PRs wrap up libevent removal? Or is it over?

Matthew Zipkin: Yes. Fanquake was very excited about removing the dependency. And for the last six months, I think he had a follow-up ready. After my work on the server was done, all that was needed was to remove libevent from the build system and from the docs is basically just still being pulled in by the build system and mentioned in certain places. And the server was the last thing where the code was actually consumed. And so, having that merged meant that we could immediately remove it from the build system. So, this is not something that users will notice, it’s not a cool new feature. Hopefully, nobody notices it. We’ve done a bunch of extensive integration testing and fuzz testing. I made sure that the HTTP server was still going to work with LND and Eclair and Electrs and as many libraries as I could find. We didn’t want to break anything. Of course, there were still some API breakages from other reasons, but at least it wasn’t HTTP-related. And fuzzing, lots of fuzzing, just ran the fuzzers all the time. So, hopefully nobody notices that this change has happened.

Mark Erhardt: Once again, it would be super-helpful if consumers of Bitcoin Core, ie software projects that rely on Bitcoin Core’s interfaces, and especially HTTP server in this case, would run the master branch and the RCs before the release. Every time we ask for this, and every time a few months later, or when the release is cut in the following weeks, someone is like, “Oh, it breaks my use case”. That’s exactly why you should be running the RC and testing.

Matthew Zipkin: So, I also think this is something that we might be able to take over. Let me explain. For this integration testing, what I did is, so take LND, for example. They have their own continuous integration testing where they download a release of Bitcoin Core. I think right now their CI is pinned at like 29, maybe 30, and they run all their tests against it. So, what I did for each of these projects I wanted to make sure we weren’t breaking is, I forked the project, modified their CI to run my branch of Bitcoin, and then removed all the tests that I didn’t need. And I found stuff that was breaking, most notably, cluster mempool has changed a lot of the mempool-based RPC responses. Those APIs are broken. And another one is varying taproot activation. I’m sure you guys have talked about this stuff with your audience before. And so, LND, one of the things it would do to see like, “Hey, does the node I’m talking to know what taproot means?” and it would use the getdeploymentinfo RPC to ask that question. Now that taproot is buried, it no longer is in the right place. So, LND would suddenly, with the latest version of Bitcoin Core, think it’s not talking to a taproot-enabled node.

So, the infrastructure to do this is very simple. I just forked all these projects, replaced their Bitcoin Core with my Bitcoin Core and ran their CI to see if the tests pass. And I think this is something we could maintain.

Mark Erhardt: I think that is very generous of you, but it shouldn’t be the upstream project’s job to go to all the downstream projects and fork their infrastructure in order to do their testing for them. Downstream projects should just have maybe their recommended release in one branch and then also the master branch.

Matthew Zipkin: You get on that soapbox, Mark, and keep tweeting about it.

Mark Erhardt: You’ll be the bridge-builder! I’ll be on my soapbox saying, “Hey, this is your job”!

Matthew Zipkin: I wasn’t doing much for these. Like, there was a Rust crate that broke with the new mempool RPC changes. And I just opened an issue and I’m like, “Here’s the patch that Claude generated for me to get your code to work with our code”. And that’s all I’m going to do, is open the issue, not even try to open a PR, especially because I was just using Claude to generate the PR like, “You guys know what this code does. Just telling you, you need to fix this”.

Mark Erhardt: Yeah, but if you didn’t do much, that should be something that the downstream project can do.

Matthew Zipkin: Well, the thing is, I already have experience modifying an RPC with Bitcoin that breaks something downstream. And there was something, I forget which one it was, we changed the string to a list, or something, and it broke stuff downstream. There’s a PR open right now to formally define the RPC interface, and I think that’s interesting, so we have machine-readable instructions on how to consume it. So, if we break the API downstream, they automatically know it’s broken, as opposed to this kind of thing where we change a string to a list and then stuff gets broken because they expect it to be a list. Anyway.

Mike Schmidt: Well, we need to know. What is this downstream testing suite that you’ve put together? Does it have a cool name yet, or is it just you patching some things together; doesn’t have a hat, doesn’t have a shirt, doesn’t have a logo?

Matthew Zipkin: Yeah, all that fun stuff. No, nothing fun. It started off being manual, and then over the last two years as I was working on this, the LLMs got good enough that I could just have an agent do it and say like, “Here are the six forks I want you to do. Build a Docker image, write a PR, open it against my own fork, let’s run the CI and see what happens”. And it would find stuff like, “Oh, the mempool RPC changed”. The agent says, “I can fix that. Here’s the patch. Now it’s running”. And that’s been cool. There’s also been some hangups. Like the first bot I tried, GitHub banned, and it had already opened all these PRs with fixes, and those all disappeared, and that was upsetting. But you know, whatever. That’s just a speed bump.

Mark Erhardt: That brings us to another conversation that we might report on in another week. But there’s been a lot of problems with GitHub’s content moderation lately, like they broke LDK for three weeks or something. And then, after tons of tries to reach out, eventually just re-enabled them and never explained what happened. But you know.

Mike Schmidt: Well, that’s a pretty cool initiative that you’ve been running, Matthew, and I’m glad that the LLMs can help with that. And yeah, I guess since you’re opening PRs to these different projects, obviously it’s on them to sort of review and QC that. So, at least the LLMs give it a good try to fix that. That’s an interesting initiative.

Matthew Zipkin: At least we have the ‘I told you so’, so they don’t open the issues and they’re like, “You guys broke this API without telling us”.

Mark Erhardt: Yeah, I mean I’m not saying that it’s not nice what you’re doing, but I’m still kind of confused how this is a conversation that we have at least once a year.

Matthew Zipkin: I just didn’t want to be the guy that breaks the Bitcoin Core LND thing because I was using an HTTP thing that libevent wasn’t using. And so, the last thing I’ll throw in here is, I was excited at first about replacing libevent, because I thought we might actually be able to get a speed up in the code. And there are some benchmarks, notably contributed by romanz, who I think is the Electrs developer maintainer, showing that it is actually faster for certain HTTP requests than libevent was. So, I was really excited that this was going to revolutionize our CI and everybody was going to be so excited that the functional tests are faster now. And that’s not the case. And here’s a very simple reason why. When you build Bitcoin Core with libevent, libevent is not built, it’s not compiled with debug flags. It’s a compiled library that you just download. It’s already as optimal as it possibly can be. And so, this wasn’t a line-of-code reduction at all. I mean, it took something like 400 lines out of Bitcoin Core to remove libevent, and added something like 2,000 or 3,000, because there was an entire HTTP implementation in there. And when you do a debug build, all that code is now built with the debug flags.

So, my guess is that the functional test suite is going to run a little slower, and that’s been my observation. And if you build with optimization, like our releases, it’s about the same, performance-wise.

Mike Schmidt: So, I think we’ve hinted at it, but this will be in the next version of Bitcoin Core; this will not be, and the new version, internal version, will be?

Matthew Zipkin: Yeah, the 32 release is when I find out if I – I mean, this is the thing. HTTP, everybody who uses Bitcoin needs the HTTP interface. This isn’t something that’s optional. It’s not like v2 transport where you can opt in or opt out. It’s like. Coinbase uses the HTTP interface, Binance uses the HTTP interface. There’s no way around it. This is how Bitcoin Core is used by every single application. Your wallet password goes through this library. Maybe another reason why using libevent after it’s been unmaintained is so dangerous. So, we’ll see. Hopefully, no issues come up. But yeah, version 32.

Mike Schmidt: Matthew, thank you for your work on this. Thanks for jumping on and talking us through the story behind this.

Matthew Zipkin: Thanks for having me. It’s great to talk to you guys, great to see you guys. Take care.

Mike Schmidt: Cheers. Back up to our monthly segment on QA from the Bitcoin Stack Exchange, which we had none, I think, last month. So, it was good to see some this month. As you can tell from the subject matter, the Stack Exchange follows what’s being discussed more broadly as people have questions about what they’re seeing online and what’s being discussed. So, with that, we’ll jump into it.

Is it a bug that OP_IF is part of the tapscript opcodes?

First one, and Murch, I think you answered a lot of these. So, I’ll be the chaperone here, but you’re the main event. “Is it a bug that OP_IF is part of the tapscript opcodes?” And I think, Murch, you can elaborate on the motivation of this question. But given that you have these different leaves, I guess that would be the IF, right? And so, why do we need an IF, I think is the question.

Mark Erhardt: Yeah. So, for some reason, there’s a lot of discussion about BIP110 on X in the last few weeks again. I think with the mandatory signaling coming up in a few weeks, people are really trying to make or break it. And maybe I’ll editorialize not too much here, but I feel like it’s very much in the fake-it-till-you-make-it territory right now, because the hashrate support is under 1% and node support is a little higher, but also a small minority of all nodes. So, I think it’s going to be a non-event. But people are spinning all sorts of interesting narratives around this, and then other people are asking questions about that. So, I asked this question because someone had been going around claiming that having OP_IF in tapscript is a bug in the first place. So, I think that narrative doesn’t have any legs to stand on.

IF, in general, is one of the most basic functions in every program language under the sun. So, removing OP_IF is something that you first have to think about very hard, because everybody would consider that an option in any programming language. But more specifically, this narrative was based on the claim that any tapscript, so any script that appears in a script leaf in the script tree of a taproot output can be replaced with multiple leaves if it contains an OP_IF. And this claim is true because, of course, you can always restructure a set of logical expressions into a disjunctive form, where you separate all of the conditions into blocks of ANDs that are grouped and separated by ORs, and the OP_IF would be basically an OR in that expression. So, yes, you can always split any script that has OP_IFs into multiple leaves that just do the expression that was in one of the two conditional branches. However, that is (a) not always smaller and (b) it’s definitely not a bug to have OP_IF in a programming language, because that’s just very basic and present in any programming language.

So, why is it not always cheaper? First, maybe yes, splitting up a script into multiple parts is a privacy improvement, because you’ll only reveal the part that you’re using. But when you split into multiple leaves, you might need a higher depth of tree. So, if you have a single leaf, this leaf will live at depth 0. So, it requires a control block of zero hashing partners, and only you have to reveal the internal public key. But you always have to reveal the internal public key if you spend a scriptpath. So, at depth 0, there is no hashing partner. You simply show your script leaf, and for the script tree, it is hashed with the internal key, and now you see the external key, and you have proven that the leaf was committed to when it was created. If you have two leaves, you need a depth 1 tree. So, for two leaves, you need one inner node and then a split to two outer nodes that adds 32 bytes to each of the two leaves. If you want to have three leaves, you need a script tree that is at least a depth of 2, one inner node to split the two branches. You find one of the three leaves, and then two more leaves split up from another inner node. And now, the two other leaves need 64 bytes, two times 32 bytes, for the hashing partners to prove that they’re part of the script tree. So, if the script that you’re expressing adds less than 32 bytes in the conditional OP_IF, it’s actually getting bigger by adding script leaves, because you push it to a lower depth.

So, the other aspect of this narrative was, “Oh, if you want to put everything into a single script, you should always do it as P2WSH, because P2WSH already doesn’t have the control block, and therefore you save the reveal of the inner key. And if you’re showing the whole script, you only have one, so it should live in P2WSH. This is invalid, of course, because a P2WSH doesn’t have schnorr signatures which tapscript has. So, for example, if you’re using MuSig or you want to tweak, that doesn’t work with P2WSH. The other one being, if you’re building a complex wallet policy, you might be using the keypath to use one of the spending conditions. So, if you have a spending option that is just multiple keys signing off on something together, you can do that with MuSig if it’s 2-of-2 or 3-of-3. You can do that with Rust if it’s a threshold setup in the keypath directly. So, you can pull out one of the leaves into the keypath and it’ll look like single-sig to anyone else. Both of those things are not possible with P2WSH. So, if someone claims that it is a bug for OP_IF to exist in tapscript, I hope you feel that that is not a valid statement at this point.

Why would forbidding OP_IF in tapscript be a problem?

Mike Schmidt: Next question from the Stack Exchange is also about OP_IF in tapscript, “Why would forbidding OP_IF in tapscript be a problem?” So, I think there’s discussion that since OP_IF in tapscript is being abused, turn it off. And I guess that’s the crux of this question. What might happen, Murch?

Mark Erhardt: So, the context here is again BIP110, of course. The reduced data temporary soft fork proposes seven new consensus rules, which target different ways how data embedding is happening on the Bitcoin Network. And the biggest target here, of course, is to forbid inscriptions. Inscriptions use something called the inscription envelope, which basically is an OP_FALSE and an OP_IF. So, it always negates the conditional. And then, on that dead branch that will never be executed, it pushes the data in. So, the data is part of the script, but it is not part of any executable branches of the conditionals. And thereby, OP_IF is abused in this manner to produce a data-embedding envelope in witness stacks. So, the idea of BIP110 here is, “Oh, obviously we’ll just forbid OP_IF, then people can’t use this envelope idea, and no more inscriptions on Bitcoin”. So, this is naïve because there are multiple other ways how you can easily produce another envelope that uses a different way of creating such conditional branches, or you just push the data and then drop it with OP_DROP, or you push the data and push it to the alt stack, and so forth. So, closing one of these doesn’t prevent inscriptions. It just means that with the year lead or so that you have on a soft fork, people that want to do data embedding are going to use one of these multiple other ways of doing the same thing. And just if they were worried that it activated, they would just start doing it a few months in advance with a different method and you’d start from scratch, which is exactly why people have been saying you can’t police what people are doing on the network with policies, because policies are broken by a minority that doesn’t go along with enforcing the policy. But then, the second part of that is, you also can’t police data embedding effectively with forks, consensus rule changes, because consensus rule changes move so slowly that data-embedding schemes will evade them easily.

So, now, why would forbidding OP_IF be a problem? Well, we already established that OP_IF, or the IF functionality in general, is one of the most basic building blocks of programming languages. But very specifically, there are numerous or several software projects that have support for miniscript, and miniscript was built using OP_IF. So, if you use miniscript to describe a policy in a more human-readable fashion and then compile it to a descriptor, the descriptor may include OP_IF opcodes. And we can’t tell what is in the preimages of hashes. So, if someone has some spending condition, for example, that resolves to a keypath spend for their personal use, but then has a scriptpath spend for inheritance or a fallback for their other wallet, or more complex spending conditions that are based on an OP_IF, we might never have seen that on mainnet because they never reveal the scriptpath while they’re just using their keypath fallback that is more private and cheaper.

So, if the wallet developers decided to update the software, if the software then had a release that got rid of OP_IF, there would be no guarantee that the user had upgraded to no longer produce OP_IF scripts, and even if they updated, that nobody continues to send to their old wallet pattern after the time that such a soft fork activated. But more likely, someone that set up such a complex script continues to just use it over time. And then, when they send themselves a change output after making a transaction, they might not realize that their fallback mechanism was broken, because even if they tested it before, they didn’t expect the rug to be pulled from underneath them. So, this breaks user space. This is by far the most controversial change that is being proposed with BIP110, and I think it is completely indefensible.

Mike Schmidt: I think there’s been some discourse online from Knots users reaching out to folks like Nunchuck, I believe, supports things like this, or the primitives for people to be able to do it using Nunchuck, something like that. And I think the encouragement from Knots users is saying, “Well, don’t let people do that, or take that part out because it could result in issues if BIP110 activates”. And I’m curious, since it’s Knots users saying that, I’m wondering if Knots itself, would it be able to generate such addresses?

Mark Erhardt: Actually, yes, I think, since Bitcoin Knots is a fork, a project fork of Bitcoin Core, and miniscript has been supported in Knots for, I don’t know, five years or so. And I think that Knots also supports descriptive wallets, but don’t nail me down on that. I know that Luke has been very opposed to the legacy wallet removal, so maybe he hasn’t added descriptive wallet support either. I don’t really follow the internals of Knots that closely. But if Knots actually supports miniscript, which I think is the case, and it supports descriptor wallets, then you can create wallets that have OP_IF in Knots and they’re basically breaking their own user space. And I think the biggest problem here is we put out software that can do these things. We have no idea whether people have taken up our offer and started doing those things. They might never tell us. They might just tinker away, see the new features and just are turned off by the public discourse about Bitcoin and never look at it. And because we traditionally have had a very high bar for not breaking the user space, they might just rely on anything that works in Bitcoin will continue to work forever. And just assuming that you will not break someone is a fallacy here.

Does a softfork always succeed?

Mike Schmidt: Next question, “Does a soft fork always succeed?” Murch, you answered this question, and of course, give your answer. And you asked the question as well, but clearly you’re seeing some discourse that’s making you want to surface this answer that you’re going through. But I’m also curious as to what you think someone is thinking, like why are people thinking that soft forks always succeed? Like, what’s the misconception there? Is it just historical, or maybe you can get into that, like why you think this needs to even be asked?

Mark Erhardt: Well, again, a lot of people have been making some claims that I find dangerously misleading. And one of the ones that I keep seeing repeated is a soft fork that is not opposed will always succeed. And now, this is based on a couple interesting definitions. One is they claim that a soft fork that’s not adopted is not opposed. So, basically, you have to actively oppose a soft fork for it to be opposed. Just not supporting it is insufficient. I think this is incorrect. The other one is that the party or the group of people that are enacting a soft fork will always succeed to enforce these new rules on their own node. And there’s a difference, of course, between your own node enforcing the rules that you’ve picked with the software that you’re running, which is basically true for any software that parses its test suite, or the network adopting a soft fork. And this is sort of a piece of charlatanry, where they just say one thing and are truthful about it, “Yes, of course, your node will always enforce the rules that you run”, and then claiming or pretending that it means that the network will adopt it, and I think those are two very, very different things.

So, let’s get into this a little bit. Obviously, if you introduce a new rule on your node, your node will, if you did it right, enforce that rule. So, such a rule could be, for example, a blockhash cannot have any A’s in the hash. That is a soft fork. And you would very quickly be alone on your own network, because everybody else accepts block hashes that exclude the number 11 from the hexadecimal in the hash result. But you would, of course, enforce that rule. So, you succeeded, you soft forked from the network. However, you’re alone on your network because everyone else just continues moving on with the Bitcoin Network. And exactly the same thing is happening here. So, there’s a few people that are introducing a bunch of new rules that are very controversial and not supported broadly. And of course, they will succeed on being on their own fork once they start enforcing those rules. But that doesn’t mean that the Bitcoin Network will follow along with those rules. So, by that definition, yes, their soft fork will always succeed, but it might not succeed at pulling Bitcoin along onto their new rules.

The other one is we traditionally have been collaborating with the miners to adopt new, more restrictive rules on the Bitcoin Network. And this works very well, because when the majority of the hashrate enforces new rules with the support of hopefully a big majority of the nodes, that is a stable change in the rules. If there are any blocks created that don’t adhere to the new rules, they will be reorganized out and they will be a part of a shorter stale chain tip. However, if you adopt a soft fork with a very small minority of the hashrate, in this case BIP110 has under 1% of the hashrate right now, this effect doesn’t hold. You start enforcing your new rules and you’re off on your own chain tip that follows those rules. But everybody else who’s ignoring those rules keeps building blocks that don’t adhere to those rules. And they, in this case, find about 99 or more blocks on average, while you find a single block. So, after a day, they’ll be about 140 blocks ahead. They will have more work on their chain. There is no reason for them to ever reorganize to your chain tip, because they would be losing on out on 140 blocks’ worth of block rewards.

So, if you are trying to attempt a soft fork that does not have broad support, and does not have the majority of the hashrate, the soft fork creates a similar chain split as a hard fork does, where you restrict yourself to these new rules, but nobody else’s, and you’re off on your own network. And this is pretty much what almost all the developer community sees happening here, is that BIP110 will fork itself off with a minority hashrate. And then, after getting about one block per day, they will probably change their PoW to something else, or have a difficulty adjustment, because one block per day is not sufficient blockspace to have a network running. And then, of course, because the mandatory signaling starts at the start of a difficulty period, they will have to get through 2,016 blocks for the difficulty to adjust. And even then, it will only adjust up to a factor 4. So, if they fork off with less than 1% of the hashrate, we can anticipate that it takes not two weeks, but roughly 200 weeks to reach the first difficulty adjustment, and then another 50 weeks for the second difficulty adjustment, and so forth.

So, unless suddenly they conjure up a lot more hashrate support for the BIP110 fork, this is dead on arrival, which is why nobody has to actively oppose it. It’ll just stop itself.

How to set up Bitcoin Core to mine a valid block after the BIP110 activation in August 2026?

Mike Schmidt: Another question in a similar vein, how to set up Bitcoin Core to mine a valid under-BIP110-rules block for August. I guess the time frame doesn’t necessarily – but if I wanted to use Bitcoin Cash to mine a BIP110-compliant block, obviously I could mine an empty block, which would be compliant. But how would I go about sorting out my block to fulfill these rules using Bitcoin Core?

Mark Erhardt: Right. So, there’s two different phases here. There’s first the mandatory signaling phase in which blocks are required to set bit 4 in the version in order to signal that they now support BIP110. This is going to happen exactly two difficulty periods before the last possible activation of BIP110. So, anybody running the reduced data, temporary soft fork software, BIP110, or the latest, Knots also supports it, will only accept blocks at that height, that signal for activation. So, if someone were to modify their Bitcoin Core or try to find a block with Bitcoin Core, they would have to find a way to set that bit in the version. And I don’t think that there is a configuration option for that. They’d have to modify the source code, recompile and rebuild, and then they could use almost vanilla Bitcoin Core to build a block that signals.

After activation, which is roughly two difficulty periods later or never, they will enforce seven new consensus rules on transactions, which include a limit on output scripts, a limit on OP_RETURN outputs, a limit on OP_IF not appearing in tapscript, and script trees being at most a depth of 7, or up to 128 leaves. And there’s a few others that basically just forbid upgrade hooks that are currently present in Bitcoin Core after hard work for many years. And so, you would have to either manually filter those transactions that are not in compliance with the new rules – again, we’re speaking about a hypothetical scenario here, just to be clear – or you just mine empty blocks, because empty blocks will not have any transactions that injure any of these rules. So, if you want to mine with Bitcoin Core, you’ll have a tough time during the mandatory signaling. And after activation, probably the easiest is to just mine empty blocks.

Are BIP110 blocks on a branch with lower difficulty valid?

Mike Schmidt: Next question from the Stack Exchange, “Are BIP110 blocks on a branch with lower difficulty valid?” Maybe some terminology here, Murch. How do we think about branches and how does that manifest itself on my nodes file system, and things like this?

Mark Erhardt: Right, this is a very frequent source of confusion regarding splits or chain forks, right? So, I’m not talking about a soft fork or a hard fork, but just two different chain tips existing in parallel. So, a valid block is always considered within its own history, “If this were the best chain tip, would Bitcoin Core accept it?” That is a valid block. Or, sorry, any Bitcoin software that is compliant with whatever rules you’re trying to test, right, and not just Bitcoin Core. However, obviously the point of the blockchain is for the entire network to pick one history, one version of the truth and to coalesce on one ground truth in the network. And we do this by reorganizing to the best chain tip that we’re aware of. So, ‘best’, it means it has to be valid, which we discussed. And the other one is it is the most PoW chain tip that we know of, and valid at the same time, obviously.

So, the confusion here is people look at one chain tip and then try to evaluate the other chain tip from that perspective. And the same question often comes up with the context of, “Oh, what if my transaction is confirmed in one chain tip? How can it also be confirmed in the other chain tip?” Well, from the point of the chain tip or a node that is on that chain tip and considers it to be the best chain tip at that time, they only see a chain of blocks back to the genesis block that is single file, there are no branches in it. The best chain is just one block per height. And in the history that leads up to that block, if a UTXO is unspent, it’s spendable at that time. And it’s perfectly fine for a competing block to also have the same transactions in it. Because if you were on that competing block and evaluating the chain as if that was the only relevant block at that height, it’ll also be allowed to spend the same UTXOs, or TXOs at that point, in that block.

So, if you were now in a scenario where Bitcoin had found several hundred blocks more than an RDTS fork – or actually, we need thousands of blocks, the difficulty has reset, they now have a lower difficulty chain tip – they could even have more blocks at that point maybe if they don’t have more total work, their chain tip will look valid to Bitcoin Core, but not attractive because it doesn’t have the most work. So, yes, if there were a permanent split in the network and there were two persisted chain tips, and one probably has a lot less work, then that would look valid to Bitcoin Core, but there’s no danger of reorganizing to it because it doesn’t have the most work.

Mike Schmidt: And does that mean a Bitcoin Core node, you gave the hypothetical earlier of these 200 weeks of slow blocks, would Bitcoin Core then, assuming it’s connected to a node which would relay these 110 blocks, would it then be storing that chain as well in parallel?

Mark Erhardt: By default, we will store headers that we hear about, but we will only download blocks that are at the same height as our best chain tip. So, if there were a split and there were two blocks at the same height, we would download the block and store it in our block files. If it’s back a few hundred blocks, if we hear about the chain tip, we would remember the chain tip header, but not the block itself.

Mike Schmidt: Okay.

Mark Erhardt: And of course, in the theoretical situation that they get through their difficulty adjustment, it activates after two more difficulty periods after mandatory signaling, and now their difficulty has gone down by a factor of 16, and now some hashrate switches over and they suddenly start racing through blocks and catch up in height. Even if they have a higher count of blocks, that doesn’t necessarily mean that they have more work on it. It is simply the weight of the blocks calculated by their difficulty and their count. So, if one chain were progressing at 16 times the difficulty, that would still make up for 16 times more blocks on the lower difficulty chain. So, this was actually a bug in the original release of Satoshi, who conflated the height for most work, and the original release was vulnerable to low difficulty chains. So, if someone were today still running the original release, and were following the Bitcoin blockchain, if someone just created a difficulty 1 chain from the genesis block, they could reach a higher height for very little computation and the original block would have accepted that and reorged away from our current best chain tip. But that was fixed very, very early, and now we follow the chain with the most work.

Mike Schmidt: Most valid work.

Mark Erhardt: We will only ever accept a valid chain. And then, among all the valid chain tips, we will pick the one with the most work.

Mike Schmidt: So, on the on the 110 side, they would not keep the headers for the Bitcoin non-110 chain.

Mark Erhardt: Right. So, Bitcoin blocks would look invalid to RDTS nodes because they’re not signaling. So, I had an interesting idea here. If we get an invalid block or an invalid transaction from a peer, I thought that we might disconnect that peer. So, I figured that once the first non-compliant block, so the first block that doesn’t do mandatory signaling for 110, we’d find, we would get a topology split where all the 110 blocks would go off in one direction and disconnect all their Bitcoin peers because they don’t accept them. But I was corrected. Supposedly, RDTS has a special rule that allows Bitcoin blocks to be accepted and stored, and not disconnect the peers. So, the topology will not split immediately. But yeah, so RDTS nodes will probably download and store Bitcoin blocks, or at least not disconnect their peers. But honestly, I can’t be arsed to look at the code.

What is the story behind Bitcoin test networks?

Mike Schmidt: “What is the story behind Bitcoin test networks?” This is you and Antoine tracing the history of testnet from testnet1 through the proposed, and covered, and should have been linked in this answer, testnet5 from Newsletter #409. I should have put that link in there.

Mark Erhardt: Yeah. So, we heard about a proposal to add a testnet5. The problem here is, of course, that testnet4 has had all these parallel chain tips because I think through the launch of testnet4, a lot more people learned about the difficulty exception rule. So, on testnet4 and also every testnet since testnet2, there was an exception. If the timestamp since the last block had increased by at least 20 minutes, the difficulty of the new block had be minimum difficulty, which means that you can just tweak the timestamp and then mine a difficulty 1 block and it will be accepted by the network on testnet, right? The idea was that this would enable developers at home to mine blocks that contain non-standard transactions if they’re, for example, testing a soft fork proposal that introduces a new opcode, or to get a few testnet coins in order to be able to test on testnet. As all these testnets over time tend to get monetized, where people then start trying to acquire a lot of testnet coins and selling them to developers so developers can test, this on the one hand, to be fair, makes it much easier to get testnet coins because you know where to look, but more expensive. And it also sort of undermines the incentives of faucets to just give away testnet coins. It also makes it harder because now, everybody is mining these difficulty exception blocks and that raises the time horizon of the blocks to two hours into the future, which is the maximum that Bitcoin nodes will accept on timestamp flexibility.

So, yeah, testnet3 had these block storms, as they were called, where someone would reset the difficulty of the last block in a difficulty period to one per the 20-minute exception. And then, the next block would recalculate the difficulty and basis of the last block’s difficulty. And because that was 1, it would be a difficulty between 1 and 4 for the next difficulty period. And then, of course, difficulty 1 or 4 is fairly trivial. That’s a few megahash or something, something you can do on a very old laptop in a few minutes, and the next 2,016 blocks would flash by if someone had an ASIC pointed at testnet. And then the difficulty would quadruple, and the next 2,016 blocks would flash by, because it was still way below what an ASIC could do, and so forth. And you would get thousands of blocks in minutes until the difficulty had risen again to a higher level where blocks slowed down. And some people, to demonstrate how bad this vulnerability was, just sustained difficulty 1 blocks for a long period of time. And testnet3 is past its 10th halving. The block reward is like 546 sats now. So, testnet3 became basically unusable.

Testnet4 was rolled out, removing the block storm vulnerability by always using the first block’s difficulty, which is fine because the difficulty is the same for an entire difficulty period. So, it doesn’t really matter whether you calculate from the last block or the first block. Calculating from the first block was safe however, because when the difficulty adjusting the exception was introduced in testnet2, they did realize that the first block should be exempt, because it sets the difficulty for the entire difficulty period. So, by recalculating the actual difficulty on basis of the first block of the previous difficulty period, you at least kept tracking the actual difficulty, even if there were some blocks mined with the difficulty exception at a lower difficulty. However, people much more aware of this exception now started CPU mining testnet4. And basically, every time a block was found with actual PoW at the actual difficulty and a current timestamp, there would be immediately six more blocks that go 20, 40, 60, 80, 100, and 120 minutes into the future. And now, the timestamp is two hours in the future, and no minimum difficulty exception block could be mined. And because so many people did that, there would be dozens of blocks at each height in parallel, and there were constant reorgs on testnet4. And then, of course, it also got monetized almost immediately again.

So, new testnets will continue until we find one that is usable by developers for a bit. Testnet5 now is being approached as, “Let’s get rid of the difficulty exception”. Clearly it’s not worth the effort right now anymore. You will need a small ASIC or something to mine a block on testnet5. This will allow people, miners, to test their mining hardware, whether it’s set up correctly and so on, but it will no longer enable developers to mine a block at home. And I guess if it gets monetized again, we’ll just roll out testnet6 in a few years again, or maybe we’re done with testnets, who knows.

Mike Schmidt: I maintain that the likely outcome of a testnet5 is not that it gets monetized, but that it gets bricked by somebody spending a few thousand dollars on cloud hashrate to ramp up difficulty and then pulling the plug on it.

Mark Erhardt: Yeah, that would cause it to be in a similar situation as we expect RDTS to be in, where the difficulty is a hundred times what the hashrate supports and it’ll take forever to reduce the difficulty again on testnet5. So, yeah, that is a possibility that someone trolls testnet5. That could be maybe mitigated if some benevolent miner points a little hashrate at it until the difficulty goes down again. But I don’t know. Maybe signets and private testnets are sufficient now. But who knows? It’s just a tragedy of the commons, basically. People started monetizing the testnets, and now testnets are basically unusable for developers. Great job.

Why was -datacarriersize redefined in 2022, and why was the 2023 proposal to expand it not merged?

Mike Schmidt: Well, that was a good bit of testnet lore. We have additional lore to jump into here, “Why was -datacarriersize redefined in 2022, and why was the 2023 proposal to expand it not merged?” So, not only are we revisiting a question that was asked last year, it was asked about events from the few years prior. And, I guess, the answer/evidence on either side comes from even years before that. So, how do you think about this question, Murch?

Mark Erhardt: So, the reason why OP_RETURN was standardized as a thing in the first place was because people were putting data into payment outputs by reusing the hashes in P2PKH and the hashes or public keys in P2PK and P2MS, or I guess you could also do it with paid to scripthash. And so, there were several ways known of how to embed data into Bitcoin, and writing it to payment outputs produces UTXOs that will never be spent, because clearly nobody actually knows a key that hashes to the hashes that someone put into the blockchain in order to store data in them. And yeah, so the idea was blocks were maybe a seventh full. I think the common block size was about 140 kB or so, so block space was abundant and cheap. People putting data into P2PKH outputs could have bloated the UTXO set pretty drastically if it had taken off. So, people were like, “Okay, we don’t love the data embedding, but please put it into OP_RETURNs. At least we know OP_RETURNs are always unspendable and we can prune them from the UTXO set, we don’t have to keep them around in the minimum state for a full node.

Fast-forward to 2022, or something. The two configuration options, -datacarrier and -datacarriersize, always had been referring to outputs that start with the OP_RETURN opcode, and then push one data push of data afterwards. And someone introduced a PR to Bitcoin Core to properly communicate what output script this configuration option applies to, because it had been applying to that for eight years. So, documenting in your description of configuration options what a configuration option does is just very standard cleanup work. However, in the same year, some people started to redefine history and said, “Oh, -datacarrier always referred to all forms of data carrying. And therefore, this configuration option was always supposed to refer to any forms of embedding data into the Bitcoin blockchain, and clearly changing the configurations documentation to refer only to OP_RETURN is now changing the documentation away from the intended purpose”. I think this narrative is incredibly silly and it is reinventing history in order to give more credence to Luke Dashjr’s PR to Bitcoin Core that tried to apply the -datacarrier configuration option also to inscriptions.

One of the first feedbacks he got was, “Why don’t you introduce a new configuration option for inscriptions, and then that might make sense? People can then configure inscription limits differently than -datacarrier or OP_RETURN limits”. That was right after the feedback, “Maybe add some tests”. So, it’s just, I’m sorry that Stack Exchange seems to be turning into a fact-checking website, but if you look at the release notes of 0.10, it’s quite clear that it refers to OP_RETURN outputs. Multiple other ways of embedding data were known at the time when OP_RETURN was introduced. So, it’s not an oversight that the release notes explicitly refer to OP_RETURN outputs as -datacarrier outputs. And if you are going to go and reinvent history eight years later, that it always meant something else than it had been meaning for almost a decade, that just needs to be laughed out of the room, thank you very much.

Mike Schmidt: Yeah, I mean I think you went through the history, but I think it’s widely, I guess, known or regarded that, yeah, OP_RETURN was the place where the garbage went, because there was garbage in these other places, right? And so, okay, put it there. And so, I guess it would be weird to then have -datacarrier cover these other things. Clearly, there were other things at the time, right, because that’s the reason that things were standardized on OP_RETURN. And so, when the limit was then put in place, it was put in place in an era where these things were known, I guess, would seem the most straightforward.

Mark Erhardt: Yeah, so because blocks were only a seventh full with 140 kB, of course you have the problem that you can, for minimum feerate, fill the rest of the block with data, right? So, putting a limit on it just was reasonable back then so that the blocks wouldn’t be filled up and the blockchain wouldn’t grow faster than monetary use would have implied. It was also limited to a single output at that time, because at least that added a little overhead, you had to make a whole other transaction. There was a very strong dominance by a single software project for the node implementations at that time. Everybody ran that. And this gentleman’s agreement to not propagate OP_RETURNs that were larger or transactions with multiple OP_RETURNs held for a very long time. And that is fortunate. In the last few years, block space has been almost fully demanded throughout. So, limiting OP_RETURN outputs is no longer a means to reduce the growth of the blockchain. In fact, inscriptions using the witness discount would add about four times more data in inscriptions for the same blockspace. So, people, if they were to use OP_RETURNs instead, would grow the blockchain more slowly than what they had been doing with inscriptions.

So, maybe also in 2014, when OP_RETURN was introduced, the OP_RETURN offered a cheaper way to embed a little bit of data than putting it into P2PKH outputs or a multisig, because you not only tell people, “Hey, please put the garbage in the bin right here”, because that would not be a compelling instruction, especially if you label it a garbage bin; but there’s an economic incentive to use OP_RETURN. It became a standard output, so these transactions would propagate fine, and it would be cheaper to put data there than to put it into P2PKH outputs. So, people were incentivized to use it for that purpose if they really had to, ‘had to’ as in choice, but nobody was excited about that. But it mitigated an issue by providing an incentive to do the right thing, an economic incentive.

Fast-forward today, we’ve had inscriptions on the network for a few years, blockspace has been almost fully demanded. Spam or data transactions currently pay about a quarter or less in feerates on average than monetary transactions. So, you can think of it as just buying the leftover blockspace that is under-demanded. Clearly, this is not an economically or as economically motivated use case as monetary transactions right now. So, if blockspace is full all the time, making the OP_RETURN output a little more attractive doesn’t increase the blockchain growth because it takes more blockspace per data to put there, and it seemed completely safe. And for some reason, we’re still debating this very simple fact two years later.

Are chains of 26 unconfirmed transactions prohibited by the wallet in Bitcoin Core 31.0?

Mike Schmidt: “Are chains of 26 unconfirmed transactions prohibited by the wallet in Bitcoin Core?” This is referring to the ancestor/descendant limit, right, Murch, and the fact that the previous architecture of the mempool, I guess, scaled poorly with the number of ancestors or descendants, which was improved with cluster mempools, so now there is no such ancestor/descendant limit on Core that supports cluster mempool. So, the question then is, can you create a transaction in Bitcoin Core that exceeds those previous limits?

Mark Erhardt: So, cluster mempool changed the limits from ancestor and descendant counts and descendant size limits and ancestor size limits to cluster count and cluster size limit. So, the clusters are still limited to 101 kvB (kilo-vbytes), just like the ancestor sets and descendant sets had been, but the count increased from 25 to 64. This limit is fully adopted by recent versions on the node side. It has, however, not been introduced into the Bitcoin Core wallet yet. So, if you’re building a chain of transactions on the Bitcoin Core wallet, for example, a eel chain, or just, I don’t know, sending around funds to yourself, then you will still bump into this 25 limit, because the Bitcoin Core wallet is catching, “Hey, this is a very long chain, and by the ancestor/descendant limits, this looks like it’ll not go into the mempool. So, we’re not going to create that for you now and throw an error”. You can, however, absolutely create such a chain of transactions with Bitcoin Core, just not with the wallet. Or actually, you could. You can configure a higher ancestor limit in the configuration of the wallet. If you set the limit to 64, you can of course continue to create long chains of transactions, even with the Bitcoin Core wallet, per a configuration option. But you could also just do it by creating transactions through the node side, not the wallet. And then, it would work perfectly fine to send 64 transactions.

So, for example, if you have an external software that creates transactions or a companion wallet, or something, if that had adopted a higher chain limit and then submitted such a chain of transactions to a Bitcoin node, it would totally work.

Are there changes in Bitcoin Core 29.0 that affect memory usage?

Mike Schmidt: “Are there changes in Bitcoin Core 29.0 that affect memory usage? Antoine answered this one and I’ll, I guess, paraphrase here and, Murch, you can clarify. But it sounds like in Bitcoin Core 29.0, maybe Bitcoin Core is a little bit greedy about grabbing potential cache space if it’s available, and then releasing that when other processes need it. But it doesn’t necessarily mean that it’s using all of that, it just wants to have it available. Do I have that right?

Mark Erhardt: Yeah, that’s how I understand this. So, I haven’t looked too deeply into this, but my understanding is that you can sort of label how you’re using memory and you can sort of label it low priority or high priority. And then, if other processes come in and want high priority RAM, they will just oust other usage. So, Bitcoin Core just allows the chainstate caching to use more RAM on low priority, and if higher priority use of the memory comes along, it gets freed up. And that means that Bitcoin Core over-reports on how much memory it’s using, but it’s really memory that will be freed up if other processes come along. There was also an issue where the compaction of the UTXO set would take more memory in the recent version, because we changed the flushing of the UTXO set from once per day to once per hour. And apparently, LevelDB’s compaction would then take more memory over time. And this is fixed in the upcoming version, and there will be backports to fix this. So, I think it’ll be fixed in 31.1, which we have an RC for now.

What is Bitcoin Core’s release schedule?

Mike Schmidt: “What is Bitcoin Core’s release schedule?” Murch, I’ve seen some chatter about this, which is quite baffling to me, because I think this schedule’s been in place for quite a while. I know you can clarify the details, but the six-month cadence, it does seem that maybe some of the misconception around this, at least that I’ve seen online, is maybe folks have largely not been a part of, or following, Bitcoin Core or their releases, and now all of a sudden they see one and then they see another and it seems like it’s accelerating, whereas maybe they only saw them every few years when there was a highly notable feature or a soft fork, or something. And now, they’re looking at it closely and maybe they’re thinking things are speeding up. But do you want to add any nuance to that?

Mark Erhardt: Yeah, it seems this classical effect where when you never notice something before, once you notice it for the first time, you see it everywhere. And I think that a lot of people were just never really following Bitcoin Core development that closely. And now, with the filter movement and BIP110 and so on, suddenly this is starting to become part of what people talk about every day. And then, they start paying attention to more things and suddenly they see like, “Wow, these Bitcoin Core releases are coming awfully fast now”. Well, Bitcoin Core has been releasing a major version every six months for, I don’t know, like ten years. There was a slight change in the cadence recently. The definition used to be that after a release, we would schedule the next release six months after. And so, there would be a branch off and a feature freeze, and so on, before that date. But the targeted date would be roughly six months after the previous release. And then sometimes, if there were more RCs than usual, the date would shift backwards. So, over time, the date would drift by a week or two, and we would sometimes reset it a little earlier so we wouldn’t get into the holiday season. And now, we have a fixed schedule where the new release is not six months after the previous release, but it’s early April and early October, which prevents the shifting by a week or two occasionally.

So, yes. Bitcoin Core releases a major version, the one with the new features, every early April and every early October. And then, if there are bug fixes or backports or maintenance releases, they come in with the minor version bumped and they come out as needed. So, you will usually see the new major branch come out and then also maintenance releases for the prior two branches or prior three branches. And yeah, we usually see, I don’t know, a handful or so minor releases between each major release for old and the current branch.

Mike Schmidt: That wraps up the Stack Exchange segment for this week. We’ll move to the Releases and release candidates and Notable code and documentation changes with Gustavo. And I missed something. What’s up, Murch?

Mark Erhardt: No, just we haven’t had anything on Stack Exchange for a long time and being someone that has contributed to that QA page for a very long time, I’m really excited that people have been asking more questions, even if it’s a little bit fact-checky right now. Someone still has to feed the LLMs. So, if you have good questions or you are dissatisfied with what Claude is telling you about Bitcoin, please know that people are still looking at Stack Exchange and you can get expert answers on that website by asking a well-formulated question after doing some of your own research.

Mike Schmidt: Gustavo, the floor is yours.

Gustavo Flores Echaiz: Perfect. Thank you, Murch. I learned a lot of things. That was very interesting. So, we start with the Release and release candidate section. This week, we have two releases from the LDK repo plus one from BTCPay Server.

LDK v0.1.10

So, first, LDK has now released version 1.1 and 2.3 So, these are both maintenance releases. They’re quite similar. Yes, sorry?

Mark Erhardt: This is 1.10 and I think that’s very important. So, the 10th maintenance release on the 0.1 and the third maintenance release on 0.2.

LDK v0.2.3

Gustavo Flores Echaiz: Totally. That is 1.10, thank you for specifying that. So, both of these are maintenance releases with a few bug fixes. The difference between them is that 2.3 has some additional fixes related to features that were in the v2, such as zero-fee commitment channels, splicing, or even the implementation of the LSP specification. But other than that, other than the specific features that are targeted to new features that were part of the v2, they’re quite similar in the sense that they fixed some things. There are also API updates, such as one we covered, where when you generate a blinded message path, it will no longer use a different node as an introduction node. So, there’s no longer receiver privacy for BOLT12 blinded message paths. And as we had discussed in a prior episode, this was because LND had released onion message forwarding, but without being able to forward BOLT12 messages from unknown third parties, which is exactly how this would work if those LND nodes would be chosen as the introduction nodes in those blinded message paths. So, that’s one of the biggest API updates, but there are also multiple other bug fixes. So, if anybody’s interested in details, there’s quite a lot there and they can take a look at the release notes.

BTCPay Server 2.4.0

The other release we have this week is from the BTCPay Server repository. This is a main release, so not just a maintenance one. And it includes multiple new features, such as the one we covered last week or two weeks ago related to a new way to set up a multisig wallet. So, instead of you as a user setting up the multisig wallet fully by yourself, you can now coordinate the setup of the multisig wallet with multiple users of the BTCPay Server. So, each one can upload his own key and BTCPay Server coordinates the whole thing. Another thing that was quite interesting is the addition of passkey authentication to BTCPay Server. So, passkey is becoming a standard on how to authenticate to web applications. So, BTCPay Server has now shipped it as part of this release. This is an addition of already supporting passkey for two-factor authentication, but still requiring a password logging. So, now this new feature allows for fully passwordless passkey authentication.

There are other features included. So, anybody that has interest to that, they can take a look. But in general, we’re talking about more granular wallet permissions, improvements to the subscription and point-of-sale features, and like I said, passkey authentication and a better multisig wallet setup, and multiple other things as well related to Lightning support, and the removal of several deprecated Lightning backends known as LNBank and Lightning Charge. Those Lightning backends are no longer supported. And also, if you use a Boltcards Extension or Shopify v2 plugins, you will need to upgrade to the latest version of those plugins when using this new version.

Bitcoin Core #35070

So, those are the releases of the week, and now we can move forward to the Notable code and documentation changes. This week, also light as the one before, but we start with Bitcoin Core #35070. Here, this is a very specific edge case that only occurs when you have a pruned node, a node that has pruned a lot of its ancestor block data, and you face a deep reorg that goes back to a block that you had pruned. Plus, not only that, when you are reconciling – so, excuse me, let me take a step back. So, when you get the new block that you receive, you will put it into this internal structure called m_blocks_unlinked. The block is kept there until you reconstruct all its ancestors and you can connect it to the chain, right? So, while you are downloading those new blocks, while you’re reconstructing, there could be a second fork in the road. So, in this new chain of the reorg, there are potentially two block candidates. So, when you process each block candidate of this new chain, you could accidentally add duplicate entries of the same block to the structure called blocks_unlinked. And when adding twice the same block to this internal structure, later on, once you have downloaded all the required blocks to connect it to the chain, you would reconsider the same block twice and this could potentially lead to undefined behavior.

So, the fix here is to ensure that you never duplicate an entry in the internal structure for unlinked blocks. And so, for example, AddUnlinkedBlock is a new helper that is added to deduplicate entries, plus CheckBlockIndex() in is also strengthened to ensure that duplicate entries are never present. Yes, Murch?

Mark Erhardt: Sorry, I’ve been spacing out a little, but did you say at what depth of reorg this happens? You’re muted.

Gustavo Flores Echaiz: Yeah, excuse me. It doesn’t necessarily say, from my understanding, the depth, but it would have to be a very long reorg for your pruned block to be unable to connect the block to the blocks you have, right?

Mark Erhardt: Let me jump in there then. So, the minimum prune depth that a Bitcoin Core node will accept is 288 blocks, so about two days of blockchain. So, if you have a full node running with the minimal prune size, you would have to accept experience a reorg of almost 300 blocks in order for this bug to have an effect. Anyone that has lower prune heights would not be affected. Sorry, like, keeps more data around. Anyone that runs a full node would not be affected. But so, I think if we had a reorg of several hundred blocks, people would probably stop believing in confirmations. This could, for example, happen, tying it back to earlier topics here, if hypothetically BIP110 did activate at some point, and then all the hashrate switched over and the entire Bitcoin Core lead would be reorged out. But I guess I’m speaking for myself here, but I don’t think it would be a very interesting thing to work on if stuff like that were happening on the Bitcoin Network.

So, generally, I think if there were reorgs on the Bitcoin mainnet in this day and age, we’ve had some, I think the biggest one was in 2015 on the 0.86 release. There was an accidental incompatibility between 0.86 and 0.85, where the databases behaved slightly differently, that a database under the hood was switched out, and then miners mining on the new version created blocks that wouldn’t be accepted by old nodes, and this caused a fork in the network. I think that was, I want to say, 36 blocks were reorged out. But again, that was when Bitcoin was tiny and the exchange rate was very low. If we had something like that in today’s day and age, I believe that people would very much be shaken in their belief in confirmations and the reliability of the Bitcoin Network.

Gustavo Flores Echaiz: Right, totally. So, yeah, this is a very theoretical edge case, right, where hundreds of blogs get reorged. And not only that, then there are two potential candidates; from that new chain, two potential candidates emerge, right? So, when considering these two potential candidates, that’s when this bug occurs. So, anyways, the fix is simply when you have unlinked blocks, Bitcoin Core ensures that the same block doesn’t get duplicated in this internal structure, so it doesn’t lead to undefined behavior.

Mark Erhardt: Yeah, I was just jumping in here because I’ve seen some reports about this topic in other venues, and people hadn’t picked up on the reorg depth being a requirement. So, it sounded more like a scary thing in a reorg, there might be undefined behavior. This is in a reorg that we hopefully will never see and shouldn’t ever see.

Gustavo Flores Echaiz: Right, exactly. So, the next item we covered at the beginning of the podcast, Bitcoin Core #35182 and #34411, where the libevent-based HTTP server is replaced by an internal implementation.

BIPs #2198

The next one is BIPs #2198, which is an update to BIP360. So, Murch, I believe you are the BIP repository editor, so you maybe want to jump in here.

Mark Erhardt: I am the BIP repository. No, I’m a BIP editor. So, actually, this one I hadn’t looked too much at. Another BIP editor handled this one first. So, this modifies P2MR, or BIP360. One of the concerns people had with the BIP360 proposal was, we talked a little bit already about control block earlier in this recording. So, when you use the scriptpath in P2TR, as a reminder, you reveal the leaf script, and then you have to prove that the leaf script was committed to, the leaf was in the script tree. And you always do that by showing the internal key, which is a public key, that was tweaked by the merkle root of the script tree. So, you can tweak a number into a public key that produces a new public key, the external public key, the one that you see on the blockchain in the output script. And that tweaked key is the product of an internal key, which is an actual key the output script creator picked and tweaked with the tree of the scripts in the script tree.

So, one concern was if you don’t have a keypath spend, as you don’t in P2MR, you would be able to have cheaper leaf scripts. So, specifically in P2TR, if you have a keypath, even if you had a leaf at depth-zero, you would always have to reveal the internal key, which adds 32 bytes, I think, 33 bytes maybe. I let this resolve by commenters. Anyway, you have to reveal some extra bytes. So, people were concerned that if P2MR were adopted, as it had been proposed, people that don’t want the keypath, but always use the scriptpath for their schnorr-empowered leaf scripts, would switch to P2MR not for post-quantum security, but to save the bytes that you need to reveal the inner key for a smaller control block. So, conduition proposed here hey, “How about we never allow use of the depth-zero leaf in the script tree? We make the depth-zero leaf an OP_SUCCESS, basically”. If you use a depth-zero leaf, it is always ANYONECANSPEND with rules to be added in the future to restrict it further as an upgrade hook, essentially. So, if you were to use P2MR, you would always have to go to depth-one, which adds a bigger control block and removes one of these economic incentives to switch to P2MR for legacy usage with schnorr signatures instead of PQ.

The idea is all of the schemes that we have been discussing so far for post-quantum security, the signatures and public keys are much, much bigger than those of schnorr and ECDSA signatures. So, presumably adding 30 bytes to 3 kB is not much of a problem, whereas the incentive of moving over to spend script-paths, when your control block is 32 bytes or 33 bytes smaller, might be quite significant. So, it sort of tries to preserve the signal. If people use P2MR, they are using P2MR in order to be PQ safe, or I should say quantum-safe, quantum-resistant better maybe, not post-quantum, but you know what I mean. And so, it would make P2MR use more of a signal that people are switching to PQ-safe outputs rather than saving money with their scriptpaths.

LDK #4713

Gustavo Flores Echaiz: Precisely. Thank you, Murch. Very interesting edge case here, well, incentive consideration here. So, a good fix for that. The two last items are from the LDK repository. The first one, #4713, adds what is called DoS hardening for Rapid Gossip Sync (RGS). So, LDK has this function called RGS which allows a light client, or just an LDK node, to obtain gossip data but without going through the P2P protocol. So, if you want to obtain the channel announcements, or the latest state of the channel announcements, instead of having to go through the P2P gossip network, you can obtain it from a trusted or semi-trusted server, and you will skip verifying the signatures, even validating the funding transactions for these channels. So, you’re trusting the server to have already validated all that and to have processed all the previous states, and you simply receive a snapshot of the latest date. And this allows you to sync faster with the LN. However, there could be potentially a RGS server that could be malicious and send you nonsensical information.

So, two things are done in this PR. First one is simply updating the documentation to warn that this server is semi-trusted and they could prevent omitting data, and also attempt to bloat your network graph. So, one of the things done is the updated documentation, but the real functional change is some values are now hardcoded inside LDK for the expected number of channels, or the expected number of nodes as well. And when you download the snapshot of data from the RGS server, basically LDK will reject snapshots that are sent with counts that are absolutely nonsensical. And the way it’s able to do that is by comparing it with the new hardcoded values that are now shipped within LDK.

LDK #4684

The next item, LDK #4684, fixes a very rare edge case, where when an LDK node disconnects and then reconnects, and specifically an asynchronous signer is used, LDK has to send a revoke_and_ack message to its peer to update the state. However, if it uses an asynchronous signer, this message will basically be blocked until it receives a response from the asynchronous signer, and it will send a message then. However, LDK could also be thinking that, excuse me, if the channel monitor update hasn’t finished, so LDK, before sending revoke_and_ack, ensures that it is basically protected for recovering funds from this channel through an onchain action, so it’s monitoring the channel and monitoring specifically how it could react in a different edge case to protect itself. So, this is why it’s called the monitor-restored path. So, previously, LDK could send twice the revoke_and_ack message, first when it receives the response from the asynchronous signer, and then when it receives the response from a channel monitor. So, now the fix is to ensure that LDK would simply send revoke_and_ack once, because else it could cause the peer to reject this duplicate secret and foreclose the channel.

So, anyways, that’s the last item of this section, and that completes the newsletter for this episode. Thank you.

Mike Schmidt: Excellent. Thank you, Gustavo. Well, it ended up being a longer one than I think we thought today, but thank you all for continuing to listen. Thank you, Gustavo, for doing the Notable code and Releases section, Murch for co-hosting, and we want to thank our special guests. We had Nishant on, as well as Matthew Zipkin. Hear you next week.

Mark Erhardt: Yeah, thank you very much for your time. And I mean, if you made it here, I guess you’re welcome. Cheers

Bitcoin Optech Newsletter #411

2026-06-26T00:00:00+00:00

This week’s newsletter describes the responsible disclosure of a denial-of-service vulnerability that affected older versions of LND. 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.

News

● LND zero-timestamp gossip DoS disclosure: Nishant Bansal posted to Delving Bitcoin disclosing a denial-of-service vulnerability he discovered through state-machine fuzzing of LND’s gossip handling. Versions of LND prior to v0.20.1-beta could be crashed by a channel_update or node_announcement gossip message carrying a timestamp of zero. Although BOLT7 requires channel_update timestamps to be greater than zero, it does not specify how nodes should handle messages that violate that rule, and LND’s handling of the value led to a crash.

When a vulnerable node tried to process one of these zero-timestamp messages, an internal bookkeeping error left a data structure in an invalid state, causing a runtime panic that terminated the node. An attacker could trigger the bug by broadcasting announcements for either a real public channel or a synthetic channel created by funding a 2-of-2 output the attacker controls, the latter being cheaper to repeat without running a Lightning node.

The vulnerability was responsibly disclosed, confirmed independently by Matt Morehouse, and fixed in LND 0.20.1-beta by rejecting gossip messages with a zero timestamp at parse time, before they reach the vulnerable code.

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.

● Is it a bug that OP_IF is part of the tapscript opcodes? Antoine Poinsot explains that while any spending policy can be expressed as one taproot leaf per path, that is not always the most efficient encoding. Depending on the number of paths and how often each is used, an OP_IF inside a single tapscript leaf can produce smaller spends than splitting paths across leaves or switching to P2WSH.
● Why would forbidding OP_IF in tapscript be a problem? Murch notes that because a taproot output commits to its leaf scripts as a hash, it is impossible to know which existing UTXOs rely on OP_IF, such as miniscript-based degrading multisig wallets. Users with such setups could unwittingly lock up funds received after activation if those spending paths were no longer valid.
● Does a softfork always succeed? Murch walks through a scenario where a soft fork using mandatory signaling is supported by only a minority of hashrate, showing that the signaling chain falls behind on proof of work and stalls rather than forcing the rest of the network to adopt the new rules.
● How to set up Bitcoin Core to mine a valid block after the BIP110 activation in August 2026? Antoine Poinsot notes that Bitcoin Core does not enforce the BIP110 rules and has no feature to build a block template that excludes the transactions BIP110 treats as invalid. A node operator wanting to mine BIP110-compliant blocks would need to select transactions with external block template building software or could mine empty blocks.
● Are BIP110 blocks on a branch with lower difficulty valid? Pieter Wuille distinguishes a chain being valid from being active. Each branch’s difficulty adjustment depends only on its own blocks, so a potentially-slower BIP110 branch is still valid to nodes following the current rules, but they will never make it their active chain unless it accumulates more total proof of work than the main chain.
● What is the story behind Bitcoin test networks? Murch and Antoine Poinsot trace the history of testnet from testnet1 through the proposed testnet5, including the repeated resets after each network was monetized and the 20-minute difficulty exception that led to testnet3’s recurring block storms (see Newsletter #311).
● Why was -datacarriersize redefined in 2022, and why was the 2023 proposal to expand it not merged? Revisiting a question first answered last year, Murch adds a complementary answer documenting that the datacarrier and datacarriersize options have referred only to OP_RETURN outputs since their introduction in Bitcoin Core 0.10.0, citing the original code and release notes.
● Are chains of 26 unconfirmed transactions prohibited by the wallet in Bitcoin Core 31.0? Pol Espinasa clarifies that the mempool itself permits longer chains under the new cluster mempool limits, but the Bitcoin Core wallet still enforces a 25-transaction limit during coin selection, so longer chains must be built without the wallet.
● Are there changes in Bitcoin Core 29.0 that affect memory usage? Antoine Poinsot clarifies that the apparent increase is a reporting artifact rather than higher process memory use. Bitcoin Core 29.0 lets its chainstate database cache more data when free memory is available, and that cache is released when other processes need the memory.
● What is Bitcoin Core’s release schedule? Murch describes that Bitcoin Core releases major versions on a fixed schedule in April and October, replacing the previous practice of targeting six months after the prior release, where timelines might slip. Minor releases continue to ship bug fixes as needed.

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.

● LDK v0.1.10 is a maintenance release of this library for building LN-enabled wallets and applications. It fixes several denial-of-service vulnerabilities and a sanitization issue, plus bugs affecting async channel monitor persistence, Electrum syncing, BOLT12 offer validation, onion-message handling, MPP keysend HTLCs, and route-based payment sending.
● LDK v0.2.3 is a maintenance release of this library for building LN-enabled wallets and applications. It fixes several security issues, including denial-of-service vulnerabilities, reserve calculation errors for anchor channels, and a sanitization issue, along with bugs affecting async channel monitor persistence, LSPS handling, zero-fee-commitment channels, BOLT12 offers, onion messaging, and rapid gossip sync memory use.
● BTCPay Server 2.4.0 is a release of this self-hosted payment processor. It adds global search, passkey authentication, guided multisig wallet setup, more granular wallet permissions, subscription and point-of-sale improvements, wallet transaction search and filtering, plugin ecosystem improvements, and updated Lightning support, while removing several deprecated Lightning backends.

Notable code and documentation changes

● Bitcoin Core #35070 prevents duplicate entries from being added to m_blocks_unlinked, a validation-internal structure that tracks downloaded blocks that cannot yet be connected due to missing earlier block data. Previously, a pruned node facing a deep reorg could accidentally add duplicate entries to this structure, causing the ReceivedBlockTransactions() function to reconsider the same block more than once after receiving the missing data and re-add it to setBlockIndexCandidates after modifying its nSequenceId. This could corrupt the set’s in-memory ordering of candidate chain tips, potentially leading to undefined behavior. The PR routes insertions through a new AddUnlinkedBlock() helper that deduplicates entries and strengthens CheckBlockIndex() to ensure that no duplicates are present.
● Bitcoin Core #35182, #34411 replace the libevent-based HTTP server, used for RPC and REST, with a new HTTP and socket-handling implementation maintained in Bitcoin Core. The new server runs its own I/O thread, handles sockets directly, and dispatches accepted requests to the existing HTTP worker pool. The follow-up PR removes the remaining libevent build, CI, dependencies, and CMake plumbing. These changes continue the project’s efforts to reduce external dependencies and simplify building Bitcoin Core from source.
● BIPs #2198 updates BIP360, the P2MR proposal (see Newsletter #393), so that anyone who knows and reveals the single leaf in a depth-zero script tree can spend the output without that script being executed. This intentionally makes one-path P2MR outputs unsafe: once a user reveals the leaf in an attempted spend, a miner could use the same revealed leaf to spend the output to themselves instead. The change discourages wallets from omitting a post-quantum or other fallback leaf merely to save witness bytes.
● LDK #4713 adds denial-of-service hardening for Rapid Gossip Sync (RGS) (see Newsletter #308), LDK’s format for quickly importing Lightning Network gossip data. The documentation now warns that RGS sources should be considered semi-trusted, since they can prevent successful pathfinding by omitting data and they may also attempt to bloat a client’s network graph. LDK now rejects snapshots with nonsensical node or channel update counts, and skips adding new channel announcements once the graph contains more than ten times the expected number of channels.
● LDK #4684 fixes a rare async signer and channel monitor ordering bug that could cause a duplicate revoke_and_ack to be sent after reconnecting. Previously, if a signer-unblocked path regenerated and sent an owed revoke_and_ack while a monitor update was still pending, the monitor-restored path could later regenerate the same message, causing the peer to reject the duplicate secret and force-close. LDK now clears the monitor-pending revoke_and_ack flag when the signer-pending path returns a revoke_and_ack, since that message also satisfies the monitor-pending resend.

Bitcoin Optech Newsletter #410 Recap Podcast

2026-06-23T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by rkrux, Roland Bewick, and Steven Roose to discuss Newsletter #410.

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

Download audio

News

● Discussion of removing RBF signaling from wallet transactions (0:57)

Changes to services and client software

● Sparrow Wallet 2.5.0 adds silent payments receiving (59:55)
● Bark live on Bitcoin mainnet (29:46)
● Arké Ark wallet announced (32:18)
● Noah Ark wallet announced (31:52)
● Alby Hub v1.23.0 released (15:00)
● JoinMarket NG 0.32.0 released (1:01:02)

Notable code and documentation changes

● Bitcoin Core #35221 (1:02:13)
● Bitcoin Core #35254 (1:06:59)
● Bitcoin Core #35498 (1:09:26)
● Eclair #3318 (1:11:06)
● LND #10789 (1:13:05)
● Rust Bitcoin #6321 (1:14:09)
● LDK #4685 (1:16:14)

Transcription

Mike Schmidt: Welcome, everyone, to Bitcoin Optech Newsletter #410 Recap. Today, we have one News item, which is a discussion about wallets dropping opt-in RBF signaling, and we have a big week for Ark in our monthly Changes to client and service segment. We’re going to be talking about Bark, a couple of Ark wallets, we have Alby, and some other items. We also have our weekly Notable code and documentation changes that Gustavo will walk us through. And we have some guests this week. Murch, Gustavo and I are joined by rkrux. Rkrux, you want to introduce yourself very quickly?

Rkrux: Hi, everyone, I work on Bitcoin Core.

Mike Schmidt: Thanks for joining us. We also have Roland.

Roland Bewick: Hey, I’m Roland, I work on Alby, which is a self-custodial Lightning and Bitcoin wallet.

Discussion of removing RBF signaling from wallet transactions

Mike Schmidt: Awesome, thank you both for joining. We may have one more guest join us later in our recording. But for now, we’re going to jump to the News section and cover that item I mentioned, “Discussing removal of RBF signaling from wallet transactions”. Rkrux, you posted to the Delving Bitcoin forum proposing that wallets should consider stop signaling for opt-in RBF in the transactions that those wallets create. And you also opened a corresponding Bitcoin Core PR to do exactly that. Maybe, rkrux, it would be helpful if you talk a little bit just about what the signaling actually is and why it may not be needed now and why it may actually be a good idea to remove it, or why it might not be a good idea to remove it?

Rkrux: Yeah, sure. So, this RBF signaling was a part of BIP125. And I think it was deployed many years back. It was a way for the users to tell that the transaction is replaceable later if the need arises, by creating a follow-up transaction that spends the same inputs but with a higher fee and feerate. And the way this signaling used to work was that in the sequences of the inputs of the transactions, a certain number was set which was supposed to be less than the max value minus one. And if such a number was seen in the inputs, then it used to act as a signal that this transaction could be replaced in the future. But since, I think, v28 of Bitcoin Core, the full-RBF functionality became the default, in which every transaction was replaceable as a standard. So, this signaling is not required and it’s effectively redundant. So, that’s why I raised a PR in Bitcoin Core that changed the default signaling, or rather that changed the default value of the inputs in the transactions, so as to stop signaling for replaceability. And that’s why I also raised a question in the mailing list asking other wallet developers their ideas and their inputs on whether they intend to stop the signaling as well by choosing a different value for the input sequence numbers.

Over there, I got feedback that the MAX-2 value, which is actually the most common value to signal for replaceability, that is the most common at the moment, more than 75% of transactions do that. And Murch chimed in, along with the Electrum developers, and then I got an idea that maybe since this number should be something that’s accepted by the wide wallet community as the standard or a best practice, so to reduce the fingerprinting vector, maybe we should stick with this value for now. And that’s why I closed that PR on Bitcoin Core, and the default value is unchanged.

Mike Schmidt: Murch, I know you commented on the discussion here, and I know you probably have some thoughts.

Mark Erhardt: Yeah, so basically we introduced, or, well, it wasn’t really that active in 2015. But in 2015, we had the signal that transactions could be marked as replaceable, because RBF was somewhat controversial. So, it was designed to be opt-in. And over time, the signal got a little muddled because miners do have a financial incentive to always accept replacements if they pay more. So, the reliance on just this mempool policy, well, I think we learned a lot about how reliable mempool policies are in the last year, so maybe let’s leave it at that. And over time, there were some nodes that actively allowed replacements, even if transactions had not been marked as replaceable. So, over time, the new default became all transactions are replaceable, even if they are marked as non-replaceable per the BIP125 signal.

So, every input has the sequence field, and you always have to pick a value for the sequence field. Some popular values in the past were zero or maximum, and maximum had become interpreted as marking a transaction final. So (a) that means we’re not expecting that it will be replaced, this is the final version of this transaction; and (b) locktimes are disabled. So, if you want your locktime to be enabled, you would have to set MAX-1 in at least one of the input sequences. So, there’s a sequence field on every input. And if any one of them is set to a value below final, the transaction is not final and locktime is on and it is replaceable – sorry, not replaceable. Replaceable was MAX-2, but now every sequence value is acceptable for replaceability. Per mempoolfullrbf, the default behavior of Bitcoin Core nodes on the network, any transaction that pays more fees will be accepted to replace an original transaction.

So, with people having adopted the RBF, the replaceability signal, so much more over the years, going back to not signaling replaceability would actually be leaving the majority signal. Right now, it’s about 75% of transactions that signal replaceability. All transactions are replaceable. So, some people are trying to express something by not signaling replaceability. And there are some wallets that still always set final. But yeah, the majority of transactions are marked as replaceable per the BIP125 signal. So, just sticking with that seems easier. And I would also recommend that as the best practice going forward for all wallets. So, if you are thinking about what value to set, the default value should probably be MAX-2, which per the old rules, would have marked your transaction as replaceable. But again, any transaction replacements will be accepted if they pay enough anyway.

Mike Schmidt: Murch, you outlined a couple of the extreme values that could be for that field. And then the most common one, 75% being replaceability, after that being the way that you opted in to opt-in RBF BIP125. What else is going on in that design space? Is there anything else? What are the other values used for, if at all, or nobody uses those?

Mark Erhardt: Actually, I haven’t researched it, but dimly I remember that some Lightning implementation uses it to signal something about channel status. But you could set any sequence value between zero and MAX-2 to still be replaceable. And I think that there was some aspect encoded there about maybe their CHECKSEQUENCEVERIFY (CSV) or something. Other than that, I don’t think there’s anything going on there. Rkrux, do you know better?

Rkrux: No, none comes to my mind right now.

Mark Erhardt: Well, anyway, you have a 4-byte field on every input, so presumably someone’s going to come up with making better use of some free data field. That seems to be par of course especially in the last couple of years.

Mike Schmidt: I’m sad, I’m upset that I even brought that up. Who knows what’s next?

Mark Erhardt: Yeah, Mike, how dare you!

Mike Schmidt: Rkrux, you mentioned that you closed the PR in favor of keeping the status quo. Is there any further work or insights here that you would like to articulate for the audience before we wrap up this item?

Rkrux: Yeah, so even though the default value stays the same, but I do intend to remove the replaceable option from the RPCs in Bitcoin Core, because the concept of signaling for RBF is outdated. The default value can stay, but I’m unable to think of a reason why we should provide for such an argument for an RPC request to the end user.

Mark Erhardt: Yeah, I think the default policy is, if we can’t think of a reason in which case an option is used or can make a recommendation how the option should be set in different circumstances, there’s just no reason to have an option. And having too many options that don’t mean anything is not a good practice. So, I second this.

Rkrux: That’s good to hear. I do have a PR open for it. I look forward to reviews on that one.

Mike Schmidt: Do you think we got into the fingerprinting enough, like why it’s a good idea for some wallet to not choose some unique value to show that everyone’s using their wallet onchain? Like, maybe that’s obvious to people.

Mark Erhardt: I hinted at it with saying that we should go with the majority option, but let me explain it a little better. So, Bitcoin transactions are pretty uniform in general by design. There’s the same number of fields for every input and output. There are fixed sizes for those. For a lot of the values, we have defaults that everybody uses. So, most transactions should look somewhat indistinguishable from each other. However, if wallets behave differently on some fields, and especially if there are multiple such fields that wallets behave differently about, transactions might have what we call a fingerprint that identifies which wallet created that transaction. And for example, if there are two parties participating in a chain of transactions and the fingerprint switches midway through from one to the other, you might be able, for example, to tell what the change output is, or you can group transactions to participants, can cluster outputs belonging to the same wallet, things like that.

So, the best practice generally is to try to look exactly like other transactions in any aspect that you control. Obviously, you wouldn’t control when people continue to use old output types that are becoming less prevalent, or if they mix an old output with a new output, and so forth. But stuff like sequence or locktime, signature grinding can be controlled and should be controlled. So, if you’re developing a wallet and haven’t thought about fingerprinting, there’s some research into that. And so far, I think it’s pretty easy to distinguish most wallets from each other. But we could do better there and just try to look more alike.

Mike Schmidt: Yeah, I think in general, people may be offended, “Oh, you want everything to be homogenous and uniform”, but obviously there’s advantages to blending in with the crowd. We had that discussion at the node level with Naiyoma and Daniela about fingerprinting nodes so that you could identify certain things about nodes, which is not good for privacy. But the same applies with wallets. And I think also, I forget who we had on that was doing payjoin transaction fingerprinting work as well, but I think Ishaana has done some wallet fingerprinting work as well. So, maybe that’s to wrap up. We’ll put that in this discussion in a broader context with that. Rkrux, thanks for joining us, we appreciate your time.

Rkrux: Sure. Thanks for having me. Cheers.

Alby Hub v1.23.0 released

Mike Schmidt: We’ll move to our monthly segment on Changes to services and client software. We’re going to jump a little bit out of order, down to Alby Hub v1.23.0 being released. And we have Roland here to talk about that item. I don’t think, other than some mentions in some of these podcast discussions, that we’ve actually formally discussed what Alby is, what is Alby Hub. So, I’m excited to have Roland on to maybe give us the big picture, and then we can talk about some of the JIT (just-in-time) channels that we covered in the experimental Ark backend. So, the floor is yours.

Roland Bewick: Thanks very much for having us on. So, Alby, we do products, tools and services to make it easier for both businesses and individuals to use Bitcoin, which we think is the global native currency of the world. And Alby Hub is our flagship product, which is a self-custodial next generation Lightning wallet. So, Hub is really important here. It’s not like a standard Lightning wallet, where you just scan QR codes and make payments. But it’s really the idea of being a hub connected to all the different apps that you use. And each app has a budgeted permissioned connection to your hub, so you have full control over what other apps are doing connected to your Lightning wallet. So, this enables some really cool things, especially for developing Bitcoin and Lightning apps and makes it really simple. Also in the agent space, which we’re doing a lot of research recently, you can give an agent permissioned and budgeted access to your Lightning wallet to make payments. And we also do a lot of things around improving the developer experience for building simple Bitcoin apps. So, we kind of abstract away the difference between the different Lightning node implementations, so that developers can just focus on building their apps.

So, in the latest release, I think we made a great step to lower the barrier for people who are getting started with the Lightning wallet, two different, separate ways, so JIT channels. So, Alby Hub, first and foremost, is self-custodial, fully open source. And the default implementation is LDK. So normally, when you start Alby Hub, you have to open a channel, so that you can receive or you can send payments. And up until now, the way that that has been done is that we use LSPS1 or I think it’s BLIP51, which is basically you can purchase liquidity in advance. So, when you start Alby Hub, you kind of have to estimate, say, “I’m going to receive $1,000 or $10,000”, or whatever it is, and you would buy a channel to cover that so that you can receive incoming payments. But actually, Alby Hub is a bit different than some other Lightning wallets that work with LSPs, in that we are completely open. So, we’re not locked to just one liquidity service provider. You can even open outbound channels to any node on the network, but we work with about six different LSP partners, which users can choose to purchase liquidity from, and they come with different pros and cons, different prices for the liquidity, how long you can rent this liquidity for.

So, all of this is a bit complex and also, you have to plan it out advance. So, JIT channels kind of simplifies that. So, when you start Alby Hub, even if you don’t have any channels, you can just simply click ‘receive’, generate an invoice, and someone can pay you. And a small fee will be deducted from the payment to actually open your first channel. So, this is great for a UX perspective as well. It’s simpler and also cost of opening the channel is smaller, because the actual size of the channel will only be slightly higher than the amount you receive. So, there’s still a lot of UX challenges here and we need to do some follow-up iterations, I think. And ideally, we want more of our LSP partners to support this. But I think it’s quite exciting. It’s a good direction. And users of Alby Hub still have full control, so they can disable this feature if they don’t want it, and they can open outbound channels or just purchase the standard channel in advance if they like. So, yeah, whatever suits your needs, Alby has all the options there.

Mike Schmidt: Yeah, great explanation. I’m particularly curious, and if you had more on the JIT channels. I’m sorry that I’m interrupting you, but I did want to segue to the Ark piece as well, because I’m curious, as somebody who’s focused on developer usability and sort of abstracting things away, but also being able to integrate with different backends, how are you guys thinking about this Ark thing in combination with Lightning?

Roland Bewick: Yeah, I’m really excited personally. I was the one who worked on the back implementation for Alby Hub. I think it’s our sixth backend now. So, we did some calculations. I think if you’re a beginner or a casual user, Bark is a lot cheaper for you than Lightning, because you have to do the initial investment to open a channel. Whereas Bark, the Ark Service provider, will handle the channels for you. It will cost a bit more on a per payment basis, but in your whole lifetime of sending payments, if you only sent 100 payments or less than that, then actually Bark is a lot better. So, there is a trade-off of course, because Bark is centralized, right? So, Alby Hub, we have a lot of pride in the fact that we’re fully open source, and we’re not dependent on any single party, right? So, you can open a channel to anyone, you can always send payments, you’re never dependent on a single piece of infrastructure. So, this is the trade-off that you have to make. But what I think is really cool about Bark and Second in general is that they see a future where there are multiple different, completely isolated, Ark service providers. And I think, at least personally, I think that’s really important. So, in the future, Alby Hub runners could use a different Ark service provider if they wanted to. And that also means that if one gets shut down, it’s not just like the whole Bark backend is no longer usable, because you can find another one.

Mike Schmidt: And right on queue, you said Bark, you said Second, and look who appears. Hey, Steven.

Steven Roose: Hi, sorry for being late.

Mike Schmidt: Yeah, no problem. We’re actually going through with Roland Alby’s 1.23 release, which had JIT channels, but also this experimental Ark backend. And so, I was picking his brain on how they are thinking about traditional Lightning and Ark. And so, that’s the context that you just jumped into.

Mark Erhardt: What we just heard is that the channel open is, of course, cheaper and more convenient. But over time, the fees are a little higher. So, there are trade-offs here. And I don’t want to put words in mouths, but there was some mention of Ark being of course more centralized. So, I thought that might trigger you.

Steven Roose: Well, it is centralized.

Mark Erhardt: I mean, one thing that I understand is that Ark is of course designed that any participant can unilaterally exit. But especially for smaller amounts that might not be trivial or there are more transactions, there’s more block space to be purchased to exit an Ark. Anyway, how about you join the conversation?

Steven Roose: Yeah, missing a little bit of the context. But yeah, definitely Ark is centralized, but it’s trustless. So, you have a central server, but you don’t have to trust the server to hold your funds or to be nice. If you verify everything the server does, you sign with your own keys; if the server is doing weird stuff, you can always go onchain. So, it’s very important aspect of the protocol. When it comes to fees, you said the fees might be a bit higher. That’s definitely contestable. I mean, liquidity fees should be a lot lower because the liquidity is way more efficiently allocated within an Ark than within channels, right? If you have an LSP-style model, the LSP has to allocate your inbound liquidity and it just sits there for one user at a time. If the user is not doing anything, then liquidity is kind of wasted; while in Ark, the liquidity is kind of allocated on demand. So, if the user needs to receive, the liquidity is used from the server for that receipt. But if the user’s not doing anything, nothing really needs to be allocated, except for a little bit for all the refreshes. But users that refresh really late in their lifetime, so very close to the expiry of their VTXOs, really minimize the liquidity need for the refreshes.

So, that’s two things I already want to mention. Not sure where you want to bring the conversation further.

Roland Bewick: Yeah, just on the fees actually, yeah. Just to mention, so for users who only make a small number of payments, actually it’s a lot cheaper to use Bark than open a Lightning channel themselves, right? So, I think that’s great for onboarding new users, especially.

Steven Roose: Yeah, I think for normal retail users who make a few payments day, I think Ark or Ark-based protocols are going to be a lot cheaper. When it comes to merchants making hundreds or thousands of payments a day, it’s to be seen. I think Ark for them is definitely easier to use and implement because they don’t have to do all the channel stuff. But yeah, having your own Lightning node is probably going to be more efficient for them. But it just comes with the technical maintenance burden of actually doing that. So, I think there’s a trade-off there for those users.

Roland Bewick: One thing I think is also interesting, that Alby Hub is an always-online wallet, right, that it’s actually very well-suited to Bark, especially with the refreshes, that we can basically remove almost all fees because we don’t have to refresh far in advance to estimate the next time someone opens the app on their phone, or something like that. That’s not the case here.

Steven Roose: Yeah, that definitely makes it more trustless, especially we initially wanted all the Ark refreshes to be fully interactive, so the users sign everything during the whole process. But on mobile phones, that was really, really hard to actually make work, especially on iOS, or some of the more managed Android distributions, where you don’t really have a lot of time to do stuff in the background. So, we have these delegated refreshes where you kind of trust a set of co-signers to be there at the signing ceremony every hour, or when you need it to do the signing correctly and actually remove the keys after signing. But in the case of Alby Hub, where you’re actually an always-on device, you can actually fully participate in the interactive process and make sure that all your transactions are signed by yourself, so you have full trustlessness, which on a mobile device is a lot harder to get actually.

Mike Schmidt: Roland, as we transition into some of these Bark and Ark items, is there anything else on the Alby front that you’d like to highlight before we move along?

Roland Bewick: Just one thing, especially regarding Bark as well. So, we’re really impressed with the work the Second team has done. And even their Bark SDK is really easy to build on. I’ve seen people live-coding wallets in a matter of an hour or less. But there’s a new way also opened up with the Alby Hub integration, in that people can build Nostr Wallet Connect (NWC) apps, powered by Bark, through Alby Hub, and that’s a really great way to join quite a large and growing ecosystem of different apps, and really have seamless, automatable payments, which I think opens up a whole number of use cases. And we really need people to spend bitcoin and not just hold it. Right? So, we’re always looking at how to make the UX ten times better than what people have today with fiat payments.

So, if you want to try building, we have different agent skills. So, with a single prompt, you can build a full app with bitcoin payments inside it, powered by NWC, and it’s an open protocol, so it doesn’t work just with Alby Hub, but it works with a whole bunch of different wallets that implement this protocol. So, yeah, really excited for the future. Things are getting easier, the barrier is going down every day. So, this is really the time for Bitcoin to shine, I think.

Mike Schmidt: Roland, thanks for joining us. You’re welcome to hang on, or if you have things to do, we understand, and you’re free to drop.

Roland Bewick: Thank you.

Bark live on Bitcoin mainnet

Mike Schmidt: Steven, we’re going to jump to your item. So, for listeners, we’re jumping back up in the Changes to services and client software segment to the item titled, “Bark live on Bitcoin mainnet”. Second, announced that Bark, its Ark implementation, is now available on mainnet. I think it was a few months ago that we covered the launch on signet. We mentioned the Ark server and the Bark SDK, barkd, but maybe, Steven, why don’t you be the one to walk us through this suite and how things have gone so far?

Steven Roose: Yeah, when you said a few months ago, that’s very generous. But it was probably more like a year ago almost that we were live on signet.

Mike Schmidt: Yeah, I guess it was. Newsletter #346, which was March 21,

Okay, all right, so last year, yeah.

Steven Roose: Yes, last year. Yeah, I mean we’re very excited. It took us longer than we had hoped, definitely, but we’re live on mainnet with our server for a few months. We were first in a private mainnet beta setup with some of our testers, some of our integrators. But when we felt comfortable enough to open it up to the public two weeks ago, we did so. And since then, we had a lot of positive feedback. We also launched a fun anecdote. We launched the same day that Claude opened up their Mythos or their Fable model. So, the first two days went very smooth, there was not a single incident. We were very happy, we were like, “This is very unexpected”. And then, the day after, we had three different people sending us critical vulnerabilities that somehow AIs had found, and we spent the weekend patching those. But other than just spending the weekend patching those really fast, there was not really anything critical that happened. So, yeah, we’re very happy with how it went the last few weeks.

Noah Ark wallet announced

Maybe highlight our two or three main integrators. We already heard from Alby Hub. We also have Noah wallet. So, Noah is the team from the earlier Blixt wallets. They decided to adopt the Ark protocol, built an entirely new wallet based on top of our SDK. It’s called Noah. It works pretty well, works actually very well. They’re working on a UI update. But yeah, it’s been a daily driver for some of our team since they enabled it for mainnet, so it’s pretty solid.

Arké Ark wallet announced

Then, there’s been Arké, built by Christoph from the Bitcoin design community. It’s an iOS-only wallet, but it has some very interesting UI and design implementations. He’s basically trying to put in practice some of the design guide things that the design community has built over time, and he’s using the Bark SDK to do that. He’s a bit of a developer, but he’s definitely not like a professional full stack developer. And it’s been amazing how much and how well he’s been able to build these things using AI and our SDK. The wallet is pretty solid as well, it looks very nice. So, definitely try it out if you’re on iOS.

Mike Schmidt: I have a question about that. Did I see that Arké, does Second have a mobile app that that was based on, or did they just use Bark and put the front end on themselves?

Steven Roose: I didn’t understand the first thing you said.

Mike Schmidt: Yeah, I guess let me jump into the repo where I saw it. It says, “A Bitcoin iOS app based on the Ark protocol prototype”. Okay, so you guys didn’t have a mobile app that they put a nice, clean face on. They actually took the protocol and put the whole app on themselves. Okay, I misunderstood that.

Steven Roose: Yeah. And so, how he started, he started doing a Mac desktop wallet using our bark, or standalone daemon that we also launched. And then, when we released the Swift bindings, that were direct language bindings to our Rust SDK, he decided to use that. And then, he could do it on iOS as well, because on iOS, running the daemon is a lot harder. So, yeah, I just still wanted to highlight we have our SDK live, it’s Rust-based, but we have bindings in Swift TypeScript for both web and React Native. We have a bunch of other languages, Kotlin and stuff. We have barkd, which is a standalone program that you run on server applications for merchants, and stuff like that, that has a REST HTTP interface, so it’s very easy to work with. It does all the background stuff you need to do without you having to do anything. It’s pretty low on configuration. You just call the APIs to make payments, check your balance, stuff like that. And then, we launched ourselves a web wallet based on barkd that we kind of built ourselves. We packaged that for Umbrel. We’re in the process of packaging that for Start9 as well, so that you can run it on your hardware devices that you have at home. And then, we also announced a BTCPay Server plugin, that in one or two clicks, you can receive Lightning payments in BTCPay Server using Bark with minimal setup. That’s also using barkd under the hood.

So, yeah, we kind of announced a bunch of things in the course of this one week. And feedback so far has been good. Obviously, it’s very early, so user numbers have been moderate, but definitely not as many complaints and issues that we had expected. So obviously, some users have gotten themselves into some weird situations with some bugs, but it’s definitely been very positive so far.

Mike Schmidt: Now, given the newness of this, and obviously you guys have been working on this for a while, maybe you have some indication, I’m curious, where are you seeing the uptake in usage? Like, where is Ark really going to shine and be used sooner than later versus other use cases or areas?

Steven Roose: I think definitely our first target audience for this is the self-custodial Bitcoin user who wants to have Lightning. I think Phoenix has been a market leader in this segment of the ecosystem for a very long time. But Phoenix also comes with paying liquidity upfront, sometimes channel closures or channel top-ups, and all that kind of stuff. So, it comes with onchain fees. So, definitely that segment of users is going to be the first adopters of Bark I think. Noah Wallet is a really good alternative to Phoenix. It’s fully self-custodial, it works pretty well. You don’t have to think about channels. It just shows you your balance and you can receive Lightning, you can send Lightning. So, that’s pretty great. And I think we’re seeing a move of all these small-scale custodial wallets kind of realizing that legally, that’s pretty difficult for them to uphold. And a lot of them are looking for non-custodial solutions for their apps to adopt. And we’ve seen, because we were a bit late to launch this, that a lot of them have adopted the Spark protocol. But we’re also hearing some negative feedback sometimes of using Spark, especially payments can be slow. Also, the trust model is a bit difficult for some people to accept. So, I think some of those might adopt Bark as an alternative to Spark, or just some of them have been waiting because they didn’t like Spark enough, and they’ve been waiting for a solution and they might adopt Bark.

So, I think some of those custodial solutions that are trying to uncustodialize, basically, could use this, because the UX is pretty good. It’s very easy to integrate, it doesn’t come with all the UX problems that made people move to the custodial solutions in the first place, channels and capacity and stuff. So, I think it has a lot of potential in any kind of wallet implementation for now.

Mike Schmidt: Yeah, I want to double-click on that a bit. I’ve heard the last 18 months or so, and probably more, and I just am not in this world, but the idea of graduated wallets and folks saying, especially when maybe fees were a bit higher, that there’s a certain threshold where maybe it’s okay for a certain point of funds to be custodial, and then you sort of graduate into a Lightning channel, and then you maybe graduate into onchain or cold-storage Bitcoin. And I think the thought process pre-Ark was that folks could use ecash for that small balance, or that they could use something like Spark for that. And now, it sounds like what you’re saying is maybe perhaps for those smaller balances, they could use Ark. But then I’m curious. If Ark were sort of the cheap entry point, is there a reason to graduate from that? You can just use Ark and interact with Lightning, and maybe then your graduation is into cold storage, if you want to start stacking for the long term. But Ark can maybe satisfy both of those pieces and not just fulfill the ecash Spark area. How are you thinking about that?

Steven Roose: Yeah, I think you hit it spot on. I think with smaller balances, you can definitely use Barg. It’s not going to be as trustless, because if the cost to exit is in the similar range than your balance, it doesn’t make much sense. But at least the server cannot just run away with your money. You can still try to contest it, even if you’re going to burn most of the money in fees. So, there’s still this protection that the server cannot just disappear, take all your money, and go to the Bahamas, or something like that. So, you still have some protection. And when your balance starts to grow, your exit actually becomes reasonable in cost compared to your balance. And then, it just kind of becomes workable for even quite large balances. Obviously, you’re going to want to consider doing your refreshes interactively. But we’re also working on some additional things to make the delegated refreshes actually have a better trust model, by adding third-party cosigners that you can actually trust; either you’re a wallet developer or some trusted parties in the ecosystem, like mempool or something like that.

So, definitely you can get to a pretty good trust model for higher balances with this. Obviously, it’s not called storage, you still need to use something that comes online regularly, so something like a phone. It’s not like it’s safe if you just disappear for half a year and then try to get your balance back. So, you kind of need a device that at least regularly can send some messages to the server. But yeah, I think having Ark for your small to medium-large payments, and then just savings going to onchain or something like that, makes a lot of sense as a model. You can actually directly send from your Ark balance to an onchain address. We call it offboarding, because you get out of the Ark. And so, yeah, actually our Bark wallet and SDK comes with a built-in onchain wallet as well. So, you can receive your onchain funds there if you want and then put them into the Ark. And if you have a lot of balance in the Ark, you can basically offboard them from Ark back into your onchain wallet. But we support third-party onchain wallets. So, wallets that already have an onchain wallet right now can just add Bark on top, and then kind of manage the back and forth with their onchain wallet.

So, I think it makes a lot of sense, yeah, that you can use Bark for any types of payment that you’re doing regularly, just having your savings somewhere else.

Mark Erhardt: I wanted to make a few remarks. The first one is a little far away from when it came up, but a lot of people are maybe aware that many of the Ark projects have ‘Ark’ in the name. So, there’s Bark, there’s hArk, there’s Arké, Noah’s Ark, and so forth. But Spark is not an Ark. Spark is a statechains-based protocol, just to make that clear. And I wanted to also make clear, so what is a little more expensive in the Ark is the unilateral exit, where you have to pay for a chain of transactions, because you have to execute an entire branch in each tree of transactions. But if you just want to exit the Ark, that would be just a regular onchain output that you pay for. So, sorry to talk your book, Steven, but I felt that that was not necessarily coming out clearly. So, the unilateral exit is a little less trustless. You need to have a little more amount ready to pay off that whole tree. And yes, you can contest even with a small amount. So, it might get burned mostly, but the Ark would still look bad there. But if you just want to get out of the Ark, you could just receive an onchain payment out of the Ark and you would probably, presumably, only pay for the output. You can tell me more about that.

Then, I was wondering, so the idea of the Ark came basically out of the idea, how would we have a multiuser Lightning node? And in this case, of course, the Lightning capability, is that based on VTXOs that span Lightning channels, or do you run a Lightning node and then just convert balance received into VTXOs credited to the users? How does paying Lightning into the Ark and receiving it as a new user work?

Steven Roose: Yeah, so currently we, basically do VTXO-to-Lightning swaps conceptually. So, a user creates an HTLC (Hash Time Locked Contract) in the Ark using a virtual output, and it has the same payment hash. And then it tells the server like, “Hey, I have this HTLC coming to you. If you make this payment, there’s a Lightning invoice. You get the preimage, you can give it to me and you can claim the HTLC”. So, it’s basically putting one more HTLC in the Ark and then routing the rest of the HTLCs through the LN. And then, on the receive end, you basically tell the server, “Hey, I have this Lightning invoice that I want to receive. The server will give an HTLC to you in the Ark, and then you give the preimage, the server can claim the money, and then you basically have the HTLC in the Ark”. So, it’s using swaps now. So, every payment creates a new Ark VTXO which, if you do a lot of payments, can cause your exit to be very big.

So, in the future, we’re working on what we call virtual channels, where you actually create Lightning-channel-like things inside the Ark, and then you can do multiple sends and multiple receives from these channels. But at every month, when the VTXO expires, basically you get a free chance to rebalance that liquidity there. So, every time, for example, if the user sent all his money, the liquidity just goes like a normal VTXO, goes to the server, and then the user either doesn’t get anything anymore, or he just asks for some inbounds. There’s definitely considerations to be made there. But definitely for people that have high volumes of payments, high numbers of payments, the virtual channel approach will be a lot better. But for people that don’t make too many payments, there’s actually not really a problem with having the current approach, other than that your exit might be a bit more costly. But you can always refresh and then your exit costs get basically refreshed to the minimal.

So, yeah, it’s essentially a swap from the Ark to Lightning, but we hide all that in the SDK. You just pay Lightning, receive Lightning. You don’t have to be doing preimages and in-swaps, the SDK does all that for you.

Mark Erhardt: It was just reminding me of the Phoenix way of doing it. What do they call their onchain payment channels; PROTEM channels?

Steven Roose: Just in time?

Mark Erhardt: No. When you receive an onchain payment, they receive it to a 2-of-2 multisig HTLC sort of, what was it called, channel approach?

Gustavo Flores Echaiz: Swap-in-potentiam?

Mark Erhardt: Swap-in-potentiam, thank you, that was it.

Mike Schmidt: Nice, that was a good call by Gustavo.

Mark Erhardt: So basically, it sounds like it is a step that follows the Lightning protocol to receive and send funds from the Ark. The VTXOs are HTLCs, so it’s sort of like a submarine swap into the Ark. And if you have that virtual channel that persists for a month, it would be based on a virtual TXO, so it wouldn’t, currently by Lightning standards, be visible on the LN, because channels have to have a funding output that the channel is tied to. But you would essentially get a month-long-lasting channel in the Ark that you could then rebalance automatically every month, because it’s not an onchain UTXO, it only exists virtually. So, rolling it over costs whatever rolling over a VTXO in Ark costs.

Steven Roose: Yeah, and because the channels are so cheap, they just exist in the Ark, and Ark payments currently in our SDK are free. You can just make as many Ark payments as you want. So, the channels are basically free. It means that your Bark SDK can just manage every VTXO being a small channel. So, if you receive any amount, it just becomes a new channel with all the capacity of your sites. And if you need to send, you can just use any of the VTXOs that you have to basically send partial VTXOs out. I think it would be pretty nice. It’s not really hard to manage these channels with ad hoc state, you just have the additional thing that you need to keep the channel state as well. But already in Bark, you kind of need backup of your database to have all your VTXOs. We’re working on some kind of recovery feature using the Ark server, but definitely you shouldn’t rely on the Ark server. That’s the whole point. So, we want to offer it for users that, just like a last resort, lost everything. I just have my seed phrase. We can resurrect your VTXOs. But you should definitely have backups of your database, because VTXOs are kind of like bearer tokens, because if you don’t know the transactions, there’s no way for you to get them, other than someone giving them to you. And then, it would be the server, but if the server doesn’t do it, you cannot really claim your money back. So, yeah.

Then, to go back to your Lightning channel question. So, these are channels between the user and the server, so on the edges kind of channels. But we could also support actual channels between two users inside the Ark and then use those channels also for routing. But, like you said, indeed, these channels, for them to be announceable in the Lightning gossip network, you need to have some kind of funding txid. I was at the last Lightning spec meeting and we talked a lot about how we could extend the gossip protocol to support not-onchain channels in a hopefully very generic way, so that it’s not just made for Ark but it can be made for anything in the future. I think we made a lot of progress with getting on the same idea to go forward basically to make it general. So, yeah, I mean that’s definitely a possibility. I don’t think the two routing channels in the Ark is something that makes a lot of sense, as long as mempool onchain feerates are so low. So, we’re definitely ourselves looking more into the last-resort users having a channel with the server model. But on the longer term, I think the actual routing channels in the Ark might make sense as well.

Mark Erhardt: Well, okay, so maybe the comparison that I made with submarine channels is not helpful, but rather you can think of the Ark as your LSP, and you would have channels with your LSP, and your channel would be private from the network right now, unless there’s some way later to announce channels that do not have an onchain funding output. Okay, and yeah, it would strike me as funny to have a channel between two users on an Ark when sending in an Ark is already basically free and easy. So, yeah, maybe we’ll hear more about that. I was wondering, so Ark’s still a fairly new concept, not fairly new for the people that have been working on it, but they are not that established yet. Could we maybe go a little more into the trade-offs and how it’s run?

So, you operate the Ark, you’re the Ark service provider. My understanding is that to roll over the VTXOs in between you, you sort of have to provide liquidity onchain in order to cover all of the unilateral exits. That was one of my main concerns when the concept was originally proposed by Burak, that the amount of money that you would have to put up to fund all the unilateral exits would become prohibitive. My understanding is you found a way around needing the full amount for liquidity. Do you want to go a little bit into that?

Steven Roose: First of all, on your earlier points, we are currently the only party operating in our server, but our server code is fully open source. Anyone can run and spin up their own Ark server. We definitely hope that people will be doing that, growing the ecosystem. But yeah, for now, we have at Second our own Ark server. Yeah, to answer your question, first of all, it’s what I think people have when thinking about this. Obviously, users bring their own money, right? So, if someone comes into the Ark, the unilateral exit is funded by this user’s money. We don’t have to front that money. So, when someone comes into the Ark, they have their own liquidity that they bring. And then, when they do a refresh, their VTXO is kind of about to expire, it’s going to soon expire. Expiring means that the server has access to the funds. And then, they want to swap it for a new VTXO. And that’s the point where the server has to use some of its own liquidity to create a new VTXO. And then sometime later, it can unlock these funds again from the old VTXO.

So, basically, the amount of liquidity that the server needs to keep continuing this protocol indefinitely is always related to how long users wait for their refresh, right? So, if a user is always refreshing one day before the 28-day expiry, that means that the server needs to front the liquidity for this user for one day, every 28 days. So, that’s 1/28 of this user’s balance the server needs to have as running liquidity. That’s the default behavior that we have for users. We also made it free if you refresh in the very last two days of the window, that you don’t pay for the refresh fees. So, it would mean that the server kind of needs 1/28 of the user liquidity to operate the Ark. We think that’s quite reasonable, especially if you look at LSP solutions. They even sometimes have up to 50%, because the channels are kind of balanced. So, they have a lot higher liquidity requirements.

Obviously then, it gets worse if users start immediately refreshing. So, imagine they have a VTXO that still has more than two weeks to go until expiring. They refresh it, then the server has to front this liquidity and wait two weeks before they can access the old liquidity. So, obviously, we’re going to charge this user a higher fee. We basically have a fee schedule that is progressive with how long your VTXO still has to expire. So, like I said, we have the first two days for free, then we have a fee up to seven days, a fee up to 14 days, and then a fee for more than 14 days. So, yeah, if you’re constantly going to refresh and use up our liquidity, we’re going to charge you basically for this liquidity increasingly. So, currently, there’s no real need for users to do this.

An additional note: if you receive HTLCs because you’re receiving a Lightning payment, so if the server sends you an HTLC, these VTXOs have a way shorter expiration time, so that it’s cheaper for you to refresh them sooner. So, we made them, I think, four or five days. So, if you receive them, you can basically immediately refresh them almost for free, so that people that want to get out of this HTLC trust model, which is a bit different, they can immediately refresh without having to pay the full 30-day liquidity fee. So, yeah, that’s kind of how it works. I think it makes sense. We’re definitely ready for a lot more liquidity than the users that we have right now, but we’re only two weeks in. Let’s see how that goes.

Mark Erhardt: Just one follow-up question. So, if I remember right in Burak’s model, he was talking about a round being every five seconds and then it being refreshed. And my napkin math indicated that one Ark Service provider would take like 30% of the block space. And I thought, “Well, who’s going to pay for that?” And do I understand right that, well, you must have a round at least once a day or so if you’re offering that HTLC’s VTXO’s time-out in five days. So, how often do you do these rounds, and how do they tie into the other status of the VTXOs?

Steven Roose: Once an hour is currently our configuration. We could reduce it a bit, but it definitely depends. I mean, we’re going to have to see how it goes with cost and adoption. Obviously, initially, because there’s so few users, most of the rounds are just one or two users refreshing and we’re basically subsidizing the onchain fee for those users. But as soon as there’s larger amounts of users refreshing, it kind of amortizes the onchain fee to almost nothing, because it’s a fixed onchain fee that can just serve all the users doing the refresh. So, yeah, it’s currently once an hour. Obviously, when no one shows up, we don’t do anything. And this means that in the current behavior, when you have a free refresh in the last 48 hours, it means you have basically 48 chances to get in if you want to do the interactive one. If you do the delegated one, you just send the server your request. You say, “I want to get a refresh”, and the server will do it in the next round.

Mark Erhardt: Okay, awesome. Thank you.

Mike Schmidt: Steven, I’ve got one more. This is like an Ark Q&A day.

Steven Roose: That’s nice.

Mike Schmidt: I suspect that some of our listeners are deep in this. They are developers, they are running several Ark-related wallets on signet, and things like this, and playing around with it. But I suspect there’s another group of listeners to the podcast who are just maybe listening from afar on what’s going on with Ark. And we have not had anybody from Ark Labs on recently, we probably should. But I wanted to maybe have you do your best to articulate the big-pieces difference between what you guys are doing at Second and what they’re doing at Ark Labs, in the most intellectually honest way that you can.

Steven Roose: Yeah, I think I can do that. I think our main differences are not necessarily our implementation. I think we both have small differences in how we interpret or implement the Ark protocol, but both of us are just still doing the Ark protocol in some flavor. I think our main difference is what segment of use cases we’re trying to focus on targeting. We’re exclusively trying to target payment users for now. So, we’re very focused on getting Lightning UX right, while it seems that Arkade is trying to attract developers to build applications on their platform. While they also support payments and Lightning swaps, it seems that they’re more trying to get people to build using their Arkade script, their extended script functionalities to have people build, I don’t know, all kinds of DeFi applications and stuff like that. I think that’s the main difference, it’s more our focus. I can’t speak for their recent, I have not had time to follow some of their developments. So, I don’t know if they made any recent changes to their protocol and stuff like that, but that’s how I interpret it.

Mike Schmidt: All right, that’s fair. Thanks for that. And I think the other Ark items from the newsletter we’ve already touched on, including the Arké wallet, the Noah Ark wallet, and then we had Roland on talking about all these. So, any other parting Ark words, Steven?

Steven Roose: Not really. I would say if you’re a developer, try it out. Like Roland already said, it’s incredibly easy to do when you’re vibe coding. There’s SDK documentation, there’s REST OpenAPI documentation, so you can just feed all this in your Claude, or in whatever agent, and you can just get stuff done pretty easily. So, yeah, we tried to optimize the API to be simple and just, yeah, you can build anything you want. If you’re not a developer, definitely try one of the wallets, Noah or Arké or Alby Hub. If you’re a merchant, you’re accepting payments, we have our BTCPay Server plugin, so you can also try that out. It’s super-easy to use. Yeah, just try it.

Sparrow Wallet 2.5.0 adds silent payments receiving

Mike Schmidt: Great. Thanks for joining us, Steven. You’re welcome to hang on or you’re free to drop if you have other things to do. We are going to jump to the top of this segment and talk about Sparrow Wallet 2.5.0, and there’s a lot here. You can jump into the release notes for this Sparrow release, but the things that we highlighted here, I think the big one is adding silent payment receive support. Now, we covered their silent payment send support a few months ago in their 2.3.0 release. And we’ve sort of had Craig on steps along the way, covering things like Frigate. And we’ve talked, I think Sebastian was on, about some of the worst-case scanning that is required on the receive side. So, we’ve sort of built up a little bit of knowledge around why receiving silent payments is non-trivial and some of the tech that went into that. So, it’s great to see that Sparrow has this actually in a production wallet now. So, very cool.

JoinMarket NG 0.32.0 released

And I think we covered everything else from this segment, except for the last item, which is JoinMarket NG 0.32.0 being released. This is a software fork of the coinjoin implementation, JoinMarket, community-maintained version. And they added support for Neutrino. So, this would be compact block filters on the back end. So, they have this maker-taker model for their coinjoin setup. And that is now integrated at the mempool level for Neutrino, the flavor of compact block filters. I forget if it’s 157 or 158. And there were some improvements to the Fidelity bonds and some other improvements you can check out from the release notes.

Okay we can wrap up that segment that was a good one this month, and we can skip the Releases because there are no releases this week, and jump into the Notable code And documentation changes. Gustavo.

Bitcoin Core #35221

Gustavo Flores Echaiz: Perfect, thank you, Mike, and everyone that did the intro to this episode. Now we’re going to get to the final section. So, this week we have three PRs from the Bitcoin Core repository. The first one, #35221, adds support for a new BIP called BIP434, also called as a peer feature negotiation framework or proposal, which we’ve covered both in Newsletter #386 and #390, first when it was announced in #386 to the Bitcoin-Dev mailing list, and then in #390 when it was assigned a number and it was merged to the BIP’s repository. So now, Bitcoin Core has implemented this BIP by adding a new type of P2P message called feature, that would be exchanged between version and verack, which are the existing P2P messages. And this would allow a Bitcoin Core node to advertise optional peer features that are not yet part of this inclusion, this specific PR does not advertise, or any specific optional feature. It simply creates the message type that would be used and also updates the P2P protocol version number. So, the negotiation mechanism is implemented. Bitcoin Core is also told to ignore invalid feature IDs. Also, the feature message has to be sent between version and verack. So, for example, if it was sent after, then it would disconnect with a peer that either sends it incorrectly after verack, or that sends a malformed message. And yeah, that’s pretty much the intro on this. But maybe, Murch, you want to say something about this?

Mark Erhardt: Yeah, I wanted to explain a little bit about the protocol version number. So, the protocol version number was here bumped to 70017. It usually gets incremented when new messages are added, and this is communicated during the handshake of two nodes. So, when a node says now they speak version 70017, they aren’t now supposed to understand the feature, what was it called? The peer feature negotiation messages. And if they speak an older version of the P2P protocol, they would not be expected to understand it. So, a node that come that connects to another peer and says, “Hey, my version number is this or that”, will indicate now whether they understand the feature negotiation framework or not. Yeah, that’s basically how we’ve been updating the P2P protocol in forever. But that, of course, is a little bit orthogonal to whether you support optional features or not, and so forth.

So, we also have two other mechanisms to communicate about which features a node supports. For example, there are the service bits which are feature flags, where a node can indicate whether they support specific node services, for example, serving compact block filters or whether they have the full blockchain available to serve new IBD (Initial Block Download). And now the peer feature negotiation framework, where peers can communicate not just whether an optional feature is proposed, but which version of an optional feature is preferred. So, they could communicate multiple different versions of a feature that they support, and then the two peers would find out which of them they speak both and maybe support the latest that they both speak.

Mike Schmidt: Does that mean that P2P protocol version won’t need to be updated as often or ever, because you’ll just use the feature negotiation?

Mark Erhardt: Yes, maybe it’ll be not updated as often, but I’m not sure if we’re done with it altogether because there might be some features that we want to roll out generally across all Bitcoin nodes in the future, and that might happen again with the protocol version number.

Bitcoin Core #35254

Gustavo Flores Echaiz: Thank you, Murch, and Mike for that question. Next item is Bitcoin Core #35254. Here, there’s an improvement to ensure that key-derivation material that was kept in memory gets actually wiped off after it’s been used. So, specifically we’re talking about when you are deriving an individual key from, let’s say, a master key from a BIP32 master key, and some not exactly the chain code value, but data that was derived from the BIP32 chain codes when trying to derive an individual key was kept through values not named rkey and temp, which are stack buffers; these were kept in memory unnecessarily after being used. And this applies for both BIP32 key derivation, but also BIP324, which is the v2 P2P transport protocol, so the key material used to generate the encryption keys for the P2P transport, where some of this key material was left in memory, even after usage of it had been done.

So, now, the type of chain code, a specific value, is updated to have memory cleanse the structure, basically ensuring that all this data gets wiped off memory after being used. And like I said, we’re not specifically talking about the chain code, but some values that were derived from that, that were used in the process of deriving these keys. So, now, that is updated. Also, I wanted to mention that in a previous newsletter, #397, we covered some similar work in Bitcoin Core. It was the item #31774. Some similar work had been done in Bitcoin Core. So, this might not exactly relate, but similar work ensuring that a key material that is left pending in memory gets wiped off.

Bitcoin Core #35498

The next item, #35498, here a specific race condition is fixed when trying to fetch a block from a specific peer that simultaneously is disconnecting. So, what could happen here is that a specific thread would start the process of fetching the block, but will not lock the peer state, which would allow another thread simultaneously to proceed with the disconnection of the peer. And then, the initial thread, which is in the process of fetching the block, would basically hit an assertion failure, because it could not be able to fetch the specific peer’s node state, because simultaneously the other thread had removed that node state when processing the disconnection of the peer. So, now, simply the thread that is processing the FetchBlock request locks what is called cs_main, which basically indicates to other threads to not process the disconnection of the peer simultaneously.

So, when trying to fetch a block, if the peer had already disconnected, then that failure would hit. If the peer had not yet disconnected, then the FetchBlock request would process. But this PR ensures that there’s no such race condition, where another thread would simultaneously process the disconnection of a peer.

Eclair #3318

The next item, now we jump on to the Eclair repository. This is item #33318. So, here, there’s an edge case when two peers that are involved in a splicing transaction reconnect. So, the issue here was that the node that would reconnect would send its channel_reestablish message. And before it received the peer’s channel_reestablish message, it would detect, probably by scanning the Bitcoin Network, that the spliced transaction had properly locked. However, because it had not received the channel_reestablish message from the peer before detecting that the splice had locked, it would simply act as if it was offline. It would not send the splice_locked message to the peer. Later on, the peers would realize that they’re sort of out of sync about the funding state, and this would cause a force flow.

So, now, even if Eclair doesn’t receive the channel_reestablish message when reconnecting from the peer, it will still send the splice_locked message, so it will act as if it was online, even if previously it would act as if it was offline because it had not yet received the channel_reestablish message. So, just a specific edge case around when making a splicing transaction with a peer, when locking a splicing transaction, you get disconnected. Now, we ensure that even if the other peer hasn’t yet sent the channel_reestablish message, which is the message you send when reconnecting, you as a node will still send the splice_locked message to ensure that both peers don’t get out of sync.

LND #10789

The next item, from the LND repository, is an interesting one, because last week we covered the release, maybe it was two weeks before, but recently we covered the release of the latest LND version, which the main point from it was the implementation of onion messages, which are required for implementing BOLT12. So, now, we get the first PR related to the implementation of BOLT12, and we don’t yet have a real implementation of BOLT12, but we, for example, get just the basic infrastructure, a message type, a codec package, and even the TLV (Type-Length-Value) infrastructure required for later implementing BOLT12. So, probably in the next few weeks, we will expect more work on the LND repository towards completing the implementation of BOLT12.

Rust Bitcoin #6321

The next item, from the Rust Bitcoin repository, #6321. Here, there’s an edge case where, when receiving a segwit transaction, if something called, which I described here as an element count, but there’s another more correct way of naming this, give me just a second. Yeah, it would be better to say that each input has a witness field, and those witness fields start with a stack item count. And that is basically a preview towards the number of items that will be included in the witness. However, an attacker could send a transaction pretending that there would be more stack elements than there would actually be. So, you could say, “I’m going to have this amount of stack elements in the transaction”. However, there’s way less stack elements in it. So, an attacker could lead Rust Bitcoin into believing that it would have to reserve or force a larger allocation than actually required. So, a few bytes of input could claim a large witness stack and force an allocation of up to 16 MB on Rust Bitcoin.

So, now the change is that the decoder appends the received witness bytes to its actual content, to the actual stack elements that are included before allocating space to it. So, just quite a simple fix here, just ensuring that Rust Bitcoin doesn’t allocate unnecessary space before actually reviewing the stack elements that are present.

LDK #4685

And the final item, from the LDK repository, #4685. Here, LDK prepares towards the implementation of a new BOLT proposal called BOLT12 payment proofs. In Newsletter #405, we discussed how Core Lightning (CLN) added the experimental support for BOLT12 payer proofs, which basically allow a payer to prove that they paid an invoice using the payment preimage image, but also the payer’s signature and the invoicing note signature, so basically saying, “This invoice was paid and was paid by me and was paid to this specific node”. So, LDK wants to also implement this proposal. So, this item in the PR #4685 basically takes the first step by moving the nonce used by payers for BOLT12 invoices. It moves it from the context in the blinded reply path. It moves it from there into the payer metadata. So, actually, LDK initially had included that nonce in the payer metadata. However, it moved it into the offers context of the blinded reply paths when implementing that. But now, LDK finds itself in incompatibility with the upcoming BOLT12 payment proofs proposal. So, it moves back the nonce into the payer metadata so that later, when trying to create a payment proof for a BOLT12 invoice, a payer can regenerate the specific key that was used for that invoice, by not only his internal key state, but also using the nonce, combining the internal key state with the nonce to create the specific key that was used for that specific invoice.

So, this is not really a functional change, other than moving the nonce from one part of the invoice to the other, but we should expect an upcoming feature, which would be the implementation of the proposal of BOLT12 payment proofs, in a future PR. And that is the last item, unless you guys have something to say that would complete the newsletter. Thank you.

Mike Schmidt: No, nothing to add. Thanks for doing that, Gustavo. And we also want to thank rkrux, Steven, and Roland for joining us earlier. Thank you, Murch and Gustavo, for co-hosting and for you all for listening. Hear you next week. Cheers.

Mark Erhardt: Cheers.

Bitcoin Optech Newsletter #410

2026-06-19T00:00:00+00:00

This week’s newsletter summarizes a discussion about wallets removing opt-in replace-by-fee signaling from the transactions they create. Also included are our regular sections describing recent changes to services and client software and notable changes to popular Bitcoin infrastructure software.

News

● Discussion of removing RBF signaling from wallet transactions: rkrux posted to the Bitcoin-Dev mailing list proposing that wallets stop signaling opt-in RBF in the transactions they create. A transaction signals replaceability under BIP125 when at least one of its inputs sets nSequence below MAX-1 (where MAX is 0xffffffff). That signal no longer affects whether a transaction can be replaced since full RBF became the default (see Newsletter #315) and the mempoolfullrbf opt-out was removed (see Newsletter #329). Nodes using Bitcoin Core’s default policy will replace any transaction regardless of its nSequence values. Signaling now serves mainly to fingerprint the wallet that created the transaction, so the post argued that wallets should converge on a single value.

rkrux opened Bitcoin Core #35405 to stop the Bitcoin Core wallet from signaling by default, using nSequence = MAX-1, and asked other wallet authors which value they could standardize on. Murch and Electrum Wallet contributor SomberNight pointed out that MAX-2 is already the dominant value, used by about 75% of transactions according to mainnet-observer and by nearly all Electrum Wallet transactions. Because most transactions still signal, moving Bitcoin Core to a non-signaling MAX-1 would make its transactions stand out rather than blend in, so both favored converging on MAX-2 instead. rkrux closed the PR in light of that feedback.

Changes to services and client software

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

● Sparrow Wallet 2.5.0 adds silent payments receiving: Sparrow 2.5.0 adds silent payments receiving wallets, including airgapped hardware wallet signers, building on the send support added in 2.3.0 (see Newsletter #377).
● Bark live on Bitcoin mainnet: Second announced that Bark, its Ark protocol implementation, is now running on Bitcoin mainnet, with a public Ark server plus the Bark SDK and barkd daemon for developers. Bark previously launched on signet (see Newsletter #346).
● Arké Ark wallet announced: Arké is a native iOS wallet integrating the Ark protocol with onchain (BDK) and Lightning payments, displaying transactions from all three layers in a single combined history. It currently runs on signet with mainnet pending.
● Noah Ark wallet announced: Noah is a cross-platform mobile wallet built on the Ark protocol with Lightning support and a trust-minimized design. It is currently in beta.
● Alby Hub v1.23.0 released: Alby Hub v1.23.0 adds just-in-time channels that open automatically to accept incoming payments and an experimental Ark payment backend, among other improvements.
● JoinMarket NG 0.32.0 released: JoinMarket-NG, a community-maintained fork of the coinjoin implementation, released mempool support for the Neutrino backend so takers can verify maker broadcasts, among other fidelity bond and reliability improvements.

Notable code and documentation changes

● Bitcoin Core #35221 adds support for the BIP434 peer feature negotiation framework (see Newsletters #386 and #390). It adds a feature P2P message that may be exchanged between version and verack to advertise optional peer features, and bumps the P2P protocol version number to 70017. Bitcoin Core currently implements the negotiation mechanism, ignores unknown valid feature IDs, and disconnects peers that send malformed feature messages, send them after verack, or send them without negotiating a compatible protocol version. It does not yet advertise any specific optional feature.
● Bitcoin Core #35254 wipes additional key-derivation material from memory after use. CHMAC_SHA256 and CHMAC_SHA512 now cleanse their temporary rkey and inner-hash temp stack buffers, which may contain data derived from BIP32 chain codes or BIP324 HKDF key material. The type of ChainCode has been changed from a uint256 typedef to a type with a memory_cleanse() destructor, wiping BIP32 chain codes in extended keys and local variables when those objects are destroyed.
● Bitcoin Core #35498 fixes a race condition in the FetchBlock RPC path when requesting a block from a peer that is disconnecting. FetchBlock could obtain a valid peer reference before locking cs_main, but peer cleanup could remove the peer’s CNodeState before BlockRequested() recorded the request, causing an assertion failure. The fix locks cs_main before looking up the peer, ensuring that the peer’s state cannot be removed while the block request is registered.
● Eclair #3318 fixes a splicing reconnection edge case where Eclair could update its local state for a newly locked splice funding transaction without sending splice_locked. This could happen after Eclair sent channel_reestablish but before it received the peer’s channel_reestablish, leaving the peers out of sync about which funding states require commit_sig messages and causing a force-close. Eclair now handles funding lock events while reconnecting and sends splice_locked when needed.
● LND #10789 lays the groundwork for implementing BOLT12 offers: a daemon-independent bolt12 codec package with an Offer message type and supporting lnwire TLV infrastructure. The new codec validates messages before encoding, keeps low-level decoding permissive for diagnostics and fuzzing, and preserves unknown signed-range TLVs so offer_id remains stable across decode and re-encode.
● Rust Bitcoin #6321 hardens segwit witness decoding to prevent attacker-controlled element counts from causing excessive memory allocation. Previously, a few bytes of input could claim a large witness stack and force an allocation of about 16 MB for witness index space. The new decoder appends the received witness bytes to its content buffer and builds the element index in end() after decoding the witness data, removing the old batched allocation path.
● LDK #4685 moves the nonce used for BOLT12 invoice verification back into payer metadata of the invoice request or refund. The nonce had previously been removed because it was also stored in the blinded reply-path OffersContext, but that made verifying an invoice depend on state outside the invoice request or refund itself, which is incompatible with upcoming BOLT12 payment proofs (see Newsletter #405). Outbound offer and refund reply-path contexts now only store the expected PaymentId, which is checked against the payment ID recovered from the payer metadata of the received invoice.

Bitcoin Optech Newsletter #409 Recap Podcast

2026-06-16T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Vasil Dimov to discuss Newsletter #409.

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

Download audio

News

● Draft BIP for testnet5 (0:31)

Releases and release candidates

● LND 0.21.0-beta (17:25)
● Core Lightning 26.06.1 (20:19)

Notable code and documentation changes

● Bitcoin Core #35410 (21:28)
● Bitcoin Core #34779 (38:00)
● Bitcoin Core #32150 (41:36)
● LDK #4647 (45:14)
● BTCPay Server #7218 (51:34)
● BIPs #2186 (53:07)

Transcription

Mike Schmidt: Welcome, everyone, to Bitcoin Optech Newsletter #409 Recap. Today, we have a News item talking about a draft BIP for testnet5 to replace the struggling testnet4; we have one release, which is the LND 0.21.0-beta release; and then, we have our weekly segment on Notable code and documentation changes. We have no guests this week, although we may have a late guest joining, we’ll see. But we’re going to jump into the News section.

Draft BIP for testnet5

“Draft BIP for testnet5”. This is a Bitcoin-Dev mailing list post that we covered, and it links to a draft BIP that was co-authored by Fabian and Pol to replace testnet4 with testnet5. I think if you look at the mailing list that we linked to, the mailing list post, it actually links to a previous draft. But right before publication, we did see that there was an updated PR. So, when we link in the newsletter to that, that’s the most updated one. So, why testnet5? I think it’s been maybe a couple years on testnet4. There were a few justifications given for problems with testnet4. One is the sustained exploitation of the 20-minute rule, also known as the difficulty exception. I wanted to loop in Murch on this one. Murch, what is the 20-minute rule that applies to testnet, but not things like mainnet or obviously signet?

Mark Erhardt: Right. So, the 20-minute rule or 20-minute exception is, once there is a gap of 20 minutes or more between the previous timestamp and your current block’s timestamp, you must use a difficulty of 1 instead of the actual difficulty. And the idea here was this was introduced in testnet2 with a hard fork towards the end of testnet2, after testnet2 had run up a way too high difficulty and made it hard for people to use testnet2. The idea was to enable people to mine blocks with CPUs if they wanted to get their non-standard or not-yet-supported transactions mined in testnet, or if they wanted to mine themselves a block reward in order to have testnet coins. This rule had a bug. Sorry, maybe I should first say, this rule was then also adopted for testnet3 when testnet3 was started in, I think, 2012.

So, in 2012, testnet3 was started with this rule, and people discovered after a while that if the 20-minute exception was applied to the last block in a difficulty period, the difficulty reset would use the last block’s difficulty as the basis of calculating the new difficulty, just as it does in mainnet. But if that block’s difficulty is 1, it would at most multiply the difficulty by a factor 4. So, it would reset the difficulty to, well, if the previous difficulty period had the expected number of blocks to a difficulty of 1, or if it was a little fast, it would reset it to a difficulty between 1 and 4. So, this difficulty is extremely low. It’s so low that a CPU can very easily mine a block, especially more modern computers, can mine blocks very easily. So, if someone points an ASIC at that, they can mine thousands of blocks per minute, which leads to something we call block storms. This caused testnet3 to be at just below 5 million blocks right now. So, for comparison, the Bitcoin mainnet has somewhere around 950000 blocks. So, testnet5, in fewer years, has more than five times the blocks. And actually, testnet3 has had 23 halvings already and the block reward is reduced to 546 sats. So, it got very hard to get block rewards by mining blocks. People for a while exploited the block storm vulnerability on purpose, in order to demonstrate how broken testnet3 is, by just every difficulty period, reusing the 20-minute exception on the last block on purpose, and thereby just creating a lot of blocks very quickly until the subsidy ran out.

So, about two years ago, a new testnet was started with the idea, as always, testnets should be without value; the coins should be freely available; it should be a common good for developers to easily be able to test their software in a mainnet-like environment; and especially for miners to be able to test their mining setup in a mainnet-like environment, because while signet is useful for testing transactions, signet cannot be used for testing mining setups. So, testnet4 fixed the block storm vulnerability by forbidding the 20-minute exception on the first block. The first block always has to use the actual difficulty, and by using the first block of the previous difficulty period as basis for calculating the difficulty for the next period. So, because the first block always uses the actual difficulty and the difficulty is constant across a difficulty period, it doesn’t matter whether you get the difficulty from the last or the first block in a difficulty period.

But in the case of testnet, where the first block has to use the actual difficulty, it would always have the correct difficulty and thereby, the calculation would keep the actual difficulty. It did, however, keep the 20-minute exception for all other blocks, which then led to now there being a lot more awareness of the 20-minute exception. A lot of people started using the 20-minute exception, and then it started to get perpetually used so that almost every block height had five or even ten different candidate blocks at the same height, and testnet4 was suffering from constant reorgs all the time, even multiple times, because people would go and after a block was mined at the actual difficulty with an actual timestamp, they would immediately mine a block at minimum difficulty, just with a timestamp dated 20 minutes to the future, then a second one 40 minutes to the future, a third one 60 minutes to the future, and so forth. So, they could mine up to six blocks in advance because Bitcoin Core accepts blocks up to two hours in the future. So, every time an actual difficulty block would get mined, six blocks would immediately follow by several participants, and you’d have not just reorgs but multi block reorgs all the time.

So, now that it’s been a couple of years – and I should also mention, while the idea is that testnet should be worthless because we keep resetting it whenever it gets value, testnet1 failed when it became the first altcoin and people started trading it for other currencies; testnet2 failed when it became valuable and people started trading it and the difficulty went up; testnet3 eventually got monetized and traded on an altcoin exchange, and some people also immediately started trying to monopolize the block rewards of testnet4 and monetize it on exchanges. To be fair, this made it very straightforward to find out how to get testnet coins. You just go to an exchange and buy them. But the idea is that they’re freely available via faucets, and so it undermined the incentives to run faucets and give away testnet coins, which on the other hand made it more expensive or less accessible for other developers. So, again, testnet coins are worthless. We’ll continue to create testnets every few years whenever that’s necessary. And the idea is for testnet coins to be given away freely on faucets for any developers that want to make testnet transactions. So, if they continue to get monetized all the time, testnets will continue on until monetization stops.

So, let’s get to the actual news item. Testnet5 is proposed. Testnet5 drops the 20-minute exception altogether because clearly it is getting abused all the time. So, it will not be possible to mine testnet5 blocks with CPUs probably. However, this will make testnet5 more like mainnet, because it’ll have its own difficulty and will just get mined by presumably some people’s old ASICs, or whatever hashrate is pointed at it. Testnet5 also has the motivation of introducing the BIP54 rules from block 1. So, because BIP54 has a component that affects miners, where miners need to update how they build blocks, we will activate BIP54, the consensus cleanup consensus rules, starting from block 1. So, any miners that want to test whether they’ve correctly implemented support for BIP54 will be able to use testnet5 for that purpose. Did I forget anything?

Mike Schmidt: I think that the only other thing, maybe you covered it and maybe I missed it, but the minimum difficulty being higher than testnet4. So, not only is that difficulty exception removed that you talked about, testnet5 would take that away, that 20-minute rule; BIP54 rules instantiated from genesis; and then, minimum difficulty higher than testnet4. So, that means, I guess, if there’s very little mining activity on the chain, there’s only still so low that the difficulty would adjust. So, it would maintain a higher difficulty than mainnet rules would allow.

Mark Erhardt: Right, so I believe testnet4 had a minimum difficulty of 1, 1 being I think it’s like 10 megahash roughly, or something, which a laptop can mine that every ten minutes or so. The new testnet5 is proposed to start with a minimum difficulty of 1 million, so significantly higher. I think this is more on the level of an old ASIC, maybe. I don’t know, I won’t speculate, I don’t know the numbers from the top of my head, but 1 million times higher difficulty. This will especially affect the start of the testnet. Usually, if you were to start a new testnet at minimum difficulty 1, of course the first few difficulty periods would blast past. If someone points an ASIC at them, they would probably mine them in, I don’t know, half an hour or something. And then, difficulty would quadruple with every difficulty period. And eventually, it would get to a level where whoever is mining first slows down to a point where other people might actually hear about the block before new blocks are found. So, to avoid this block storm at the beginning of the testnet, the new testnet5 starts with a minimum difficulty of 1 million instead of 1.

Mike Schmidt: Now, part of the reason, I can imagine, for the 20-minute rule would be if somebody ramps up the difficulty and then just drops it, right, and then somebody could jump in and continue to advance the chain. If that’s not present here, I guess there is no prevention of that. Like, somebody could throw a bunch of hash at it for a few periods, ramp up difficulty, and then unplug those machines, and now you get very, very long block times, if at all. Is that a concern?

Mark Erhardt: Yes, that is a concern. Since there’s no special rules regarding the difficulty or difficulty calculation, someone could point some significant amount of hashrate at the testnet5, ramp up the difficulty, and then it would get stuck at that difficulty with slow blocks. Presumably, someone would have to then donate hashrate to mine a block, say, every 20 minutes or so to make the difficulty go back down, and that would be annoying. But I guess we’ll have to see whether someone does that. If something like that were to happen, potentially we would consider having some sort of difficulty decay in testnet 6, where if there’s no block for two hours, or something, difficulty goes down, but not to the minimum, but maybe down by half, or something like that. But we’ll see whether that happens. Again, testnets are not supposed to be valuable, they’re supposed to provide a live network for people to test transactions and mining. And, well, if people keep producing tragedies of the commons, we’ll iterate on that model.

Mike Schmidt: And then, one point that I think was brought up in the discussion, or related discussion was, “Testnet5 or patching testnet4?” And I suppose the testnet5 has the advantages that you mentioned, which is it really cuts off testnet4 coins in terms of people trying to monetize that, or whatnot. And it’s probably simpler to just cut over a new testnet than it is trying to patch something existing. Is that relatively the case against patching testnet4?

Mark Erhardt: Just to be clear, nobody can stop the old testnets. We’re just pointing our own participation elsewhere. I believe testnet1, I don’t know if it’s still going, but it could still be going. Testnet3 is still going, testnet4 will continue to be going, probably. Someone will probably mine it. But testnet5, the idea here is in order to fix the difficulty adjustment of testnet4, to take out the 20-minute exception, or other fixes, would likely require a hard fork. And forking a test network is too much effort. Like, coordinating that, then getting the participation of the miners that are, some of which are actively monopolizing and monetizing testnet4 coins, is just why bother? Just start a new one.

Mike Schmidt: Okay. I think we covered that one pretty well. Murch or Gustavo, anything else before we move along? Okay. Well, I will turn it over to Gustavo for our Releases and Notable code items. Gustavo, the floor is yours.

LND 0.21.0-beta

Gustavo Flores Echaiz: Thank you, Mike. Thank you, Murch, as well. So, this week we have one main release and a maintenance release. The first one, LND v0.21, is a major version of LD. Multiple features are added in this release. The focus is mostly around building the tooling for onion messages, sort of as a preparation for full onion message support, and probably eventually onion message support either on BOLT11 invoices as the LND roadmaps plans, but also probably for BOLT12. So, there’s basic support for onion messaging forwarding, as well as pathfinding support for writing onion messages. However, like I said, this is internal tooling. A technical user could still construct and send an onion message, but it’s not surfaced through other features.

Another big focus of this release is the announcement of production simple taproot channels. So, as we saw in the past few newsletters, simple taproot channels are now part of the BOLTs specification. So now, LND has promoted them to a production support. And with it, it also includes some other features such as, for example, RBF cooperative close for taproot channels. On the other end, some other features that we’ve discussed that are added in this release are, for example, the fast initial synchronization for Neutrino-backed nodes, so a node that doesn’t use a Bitcoin Core node or a btcd node, and instead is a light client that uses Neutrino software. Well, it now can basically point to a local file or a specific HTTP URL to fetch the block filters and the header chains and the block headers, instead of fetching them over the P2P network. It could potentially reduce privacy, but it improves performance considerably.

There’s a lot of work also around the transition within LND from using key-value databases, and migrate towards SQL-based databases, particularly for their payments database. But a lot of internal work is being done and we should probably expect, in other releases, other databases to migrate to the new SQL implementation. So, overall, quite a big release. There’s multiple other bug fixes and improvements. We invite everyone to check out the release notes if they want to have a full picture of what was in it.

Core Lightning 26.06.1

The other release is a maintenance version of Core Lightning, 26.06.1, which follows up 26.06, which I believe we covered in the last week’s Newsletter. Here, bwatch, which is a new plugin introduced to watch the blockchain basically, failed to run at startup time after it had properly been built. The make install code wasn’t properly pointing to the right place. So, just a reorganization of file hierarchy to make it so that it will probably register at startup time.

Bitcoin Core #35410

So, those are the two releases and now we move forward with the notable code and documentation changes. We got about six items this week, so a pretty light week. And I see that Vasil has just joined perfectly in time, because we’re now going to talk about the Bitcoin Core item #35410, which is a major, well at least some sort of big news around a bug that was found in the private transaction broadcast implementation of Bitcoin Core. So, I’m going to stop here. Maybe Murch, Vasil, you guys want to chime in, as you guys have probably looked into it?

Mike Schmidt: Yeah I just wanted to frame this briefly. Vasil, thank you for joining us perfectly in time. We tried to have Vasil on when we originally covered the private transaction broadcast feature to sort of celebrate that merge, and we had technical difficulties and he couldn’t join us. So, maybe one thing that we could do to start this PR off is, Vasil, can you explain what the feature is, and then maybe we can explain the situation that might cause a bug in this feature?

Vasil Dimov: Okay, so the private broadcast is a solution to one specific problem that exists when you send to your own transactions. And the way it works without the private broadcast is that when you have a new transaction to send to the network, your node would send it to everybody it is connected to. And then they would send it to everybody, and then everybody sends it to everybody they are connected to, and this is how the transaction floods the network. The thing is that with this approach, it’s not very good for privacy because if there is somebody who is monitoring many connections or has many connections to many nodes, it’s not too difficult to deduce where the transaction originated, which might mean IP address and geolocation, which is not very nice to have your bitcoins linked to your location. So, the private broadcast is a solution to that, in which we send the transaction not to everybody we’re connected to, but we open a new connection, in the simplest case, to some Tor node. We send them the transaction like normal transactions send, and then we close the connection. So, the only thing that goes in this connection is that transaction, and then this node, like normally they broadcast it to everybody, this is what normally everybody does.

So, in this way, the originator of the transaction is hidden behind the Tor network. And in the Tor network, you don’t have source address. So, the connections don’t have source address or originator. So, whenever somebody receives a connection on the Tor, they don’t know where it is coming from. This is one thing with the Tor network. And the other is that we open a new connection, even if we have already Tor connections to some peers, because in those other connections, maybe we leak some information, too much information. And yeah, it’s not too difficult to link the IP address of my node to my Tor connections. That’s some other aspect which we avoid when we open a new connection, just for sending the transaction. Yeah, so that’s private broadcast. So, okay, I will keep going.

So, this feature is very nice and it was released in the latest Bitcoin Core release. And just a few weeks ago, somebody found a problem with that. And this problem, now I’m going to explain what the problem is.

Mark Erhardt: Can I briefly jump in? So, when we say that private broadcast was released in v31, private broadcast was only introduced for one RPC so far, the sendrawtransaction RPC and it’s off by default. So, only when people explicitly use the sendrawtransaction RPC, they would have an option to submit a transaction via private broadcast, whereas Vasil described your node would make a fresh connection to a Tor peer, handshake, hand over the transaction and disconnect, so that the new transaction would be without any other context. Okay, Vasil, you wanted to get into what the issue was that was discovered.

Vasil Dimov: Yes, I heard most of what you said, not everything, but it was introduced in the latest release and it is off by default, because it’s kind of like a new feature. We don’t want to impose it on by default, maybe there will be bugs, and now this is what we’re going to talk about. So, when we send the transaction, we can choose to send it if the peer has a connection to the I2P network. This is the easiest, like we just send it to the I2P network, to some peer on the I2P network. This is one thing. And that’s kind of isolated, because the I2P doesn’t have connection to the clearnet. I mean, they don’t have exit nodes, so ignore this for now. The Tor network is special because You have Tor nodes that are on the network, and also through the Tor network, you can connect to clearnet in a way that preserves your IP address or geolocation.

So, when we are sending a private broadcast transaction, we could choose to send it to a Tor node, if the node has a connectivity to the Tor network, or to clearnet. By clearnet, I mean IPv4 or IPv6 address. And to do that, we would use the proxy that is normally used for the Tor network, so that the connection would go through the Tor network and through the Tor exit nodes to clearnet, protecting our location. Now, this is new functionality that was not present before. I mean, this is something internal within Bitcoin Core. When it opens connections, you have the proxy configuration, which use this proxy for all connections, like Tor and clearnet. Or you have the configuration proxy for only Tor. So, in this case, for the private broadcast, we wanted to, if we’re sending to clearnet address, we want it to route through the Tor proxy always, regardless of whether it is the global proxy, or whether we would otherwise open directly connections to IPv4 or 6 addresses. And so, this new functionality had the problem that – okay, I’ll step back.

When we open a connection to some peer, if we think they may support v2 protocol, which we call the P2P encryption, if we think they do support that, we try to speak the encrypted protocol to them. And if they do, then we start, the connection is opened successfully. If they don’t support, what happens is that the connection would be closed by them, because they only speak like a v1 protocol, which is not encrypted, and to them, somebody connected and is sending encrypted garbage. So, they would close the connection. And this is indication to us that, “Okay, we were thinking that this peer supports v2, but they don’t; probably they don’t because they closed the connection. So, let’s try v1, retry another connection because the first one is already closed”. So, we have to open completely another TCP connection, trying to speak the v1 protocol. And the problem is that with this private broadcast sending to IPv4 or 6, that if we think that the peer supports v2 and we would try to speak this to them, and if they close the connection and then if we retry a new one, then it would forget to use the proxy, if it is not the global proxy, like if we want to override the global configuration, because this is private broadcast. In this case, it would forget to use the proxy and it would open the connection directly. Which means that peer would see our IP address, and this is breaks the feature, or how to say? This defeats the purpose.

Mark Erhardt: Yeah. So, actually it is worse than not working.

Vasil Dimov: So, we were rehashing what exactly is needed for this to happen, like when would the bug be triggered, or how to say, yeah? And so, first of all, v2 has to be on, on our configuration, which by default v2 transport is enabled. I mean, it has to be enabled because otherwise we wouldn’t try v2 and then v1. The peer must have access to the Tor network and it must not be the global proxy, which means without private broadcast, we would open directly connections to IPv4 or 6 addresses. So further, in our addrman, we keep track of which peer supports v2 and which doesn’t. So, also, the other condition is that when we connect, we have to have in our address database somehow that this peer supports v2. And they must not support that because otherwise, if they do support, the connection would be opened successfully. So, if all this happened, then we would open connection through the clearnet. And the solution is to, yeah, even the v1 retry, to do it through the Tor proxy. This is the fix of the bug. I think I speak enough now.

Mark Erhardt: So, to recap, we added a new feature to Bitcoin Core v31 that was only available on the RPC sendrawtransaction as a new Boolean option off by default. And if your node was configured to use v2 transport and had no global proxy set for Tor, and encountered a peer while trying to do the private broadcast that was advertised as supporting v2 but actually didn’t support V2, and this node was in clearnet, you were trying to reach it through the proxy, then your node, upon downgrading to v1 transport would not reuse the local proxy. Instead, if there was a global proxy configured, it would use the global proxy, which is also off by default, to be clear. But anyway, in these very specific circumstances, their retried connection to do private broadcast would fail to use the proxy, and then your IP address would be directly visible to the receiving node because you would make a clearnet connection where the peer would learn your IP address, and you would send your new transaction and then disconnect immediately, which would be the obvious private broadcast pattern.

The fix for this was to remember to use the proxy when you downgrade from v2 connections to v1 connections, after a node had falsely advertised support for v2. Obviously, this is worse than just not working, because if you had submitted your transaction to all of your peers, like you would usually, at least it could have been received by another node and you were just forwarding it. But with the private broadcast mechanism, you only connect to a single node and it has a distinct pattern where you handshake, hand over the transaction and disconnect. So, there would be reason to believe by the recipient that this was your own transaction and they got your IP address under all of these above circumstances, false advertising, trying to use a proxy to reach clearnet, and using an experimental new Boolean feature on a sendrawtransaction.

So, this bug is fixed. The 31.1 release is coming out soon and will fix this issue. And I think that the idea is to, after this has been taken for a longer spin, to use private broadcast generally for new transactions eventually once we have more confidence in it, and maybe even to use private broadcast for rebroadcasting transactions that we would have expected to be in a block but didn’t see in that block. That would help keep transactions present in the mempool when they should be mined, but apparently weren’t in the mempool for other peers anymore, and also act as camouflage for actual new transactions being sent by private broadcast.

Bitcoin Core #34779

Gustavo Flores Echaiz: Thank you guys for that. So, now we have two more items from the Bitcoin Core repository. The next one is Bitcoin Core #34779, which is basically the implementation of BIP323, which we have covered in Newsletter #405, which the BIP proposes to expand the number of bits available in nVersion nonce space for miners from 16 to 24. So now, this implementation reserves the all the bits 5 through 28 as extra nonce space for miners. And also what it does is that it ensures that a Bitcoin Core node won’t think that this is basically an unknown software signaling. So, all the bit-range monitoring by BIP9 version bits is basically turned off or is reduced to bits outside of the bits 5 through 28 range. But I’m sure, Murch, you have some extra thoughts you would like to add here.

Mark Erhardt: Yes, so the idea here is that people were using time rolling, where they increment the timestamp more often than once per second in order to have extra nonce space. And it would be preferable if block templates were accurately labeled for the timestamp. So, because their version is not used that much, there was this proposal to use eight more bits from the nVersion field for extra nonce space. And so, since the introduction of BIP9, which is version bits, which introduced this method of using bits in the nVersion field to signal readiness for enforcing rules of a new soft fork, the Bitcoin Core would parse any such bits as, “Oh, someone is signaling for a soft fork that I don’t know about”. And because now the Bitcoin Core implementation that’s coming up – this will be released in v32 – will be considering bits 5 through 28 all for an extra nonce, and they will have random values, this warning label is turned off. So, if signals in those bits were set, then they will not be warned about. The bits 0 through 4, so five bits, are still reserved for signaling for soft fork readiness. This is hopefully enough. There are currently several soft fork proposals signaling, or not signaling actually, but well, one is actually getting any signals. But it seems like five soft fork proposals being signaled for at the same time is probably enough at this time. And if not, we can come up with other signals.

Yeah, this is a fairly fresh BIP, but the idea was pretty popular and I think avoiding time rolling is a worthy endeavor to reduce the size of the version bits for.

Bitcoin Core #32150

Gustavo Flores Echaiz: Thank you, Murch, for clarifying that. The next one is an item, Bitcoin Core #32150, that actually, Murch, you were the author behind it. So, no one’s better at introducing it than you would. So, please, Murch, give us the honor.

Mike Schmidt: Yeah, if only we had a special guest for this one!

Mark Erhardt: So, in Bitcoin Core, we use several different strategies to come up with potential input sets for funding transactions. We use these coin selection algorithms on each type of UTXOs. So, if you have a wallet that makes use of different output scripts, they will be run separately on each of those output script groups. So, we use a random draw of the UTXOs. We use the ancient knapsack algorithm that has been around for 12 years, and then we also use something called CoinGrinder at high feerates only to minimize the input set. And this approach is called Branch and Bound (BnB), which is supposed to find changeless input sets. So, this is a branch-and-bound algorithm that explores all possible combinations of the input set, and looks specifically for a combination of inputs that matches the payment outputs exactly so that no change output is necessary. Not only did I write this PR, but this is based on my master thesis from 2016. And last year, I think last year, I looked at this a little more and I offered a refactor of how it is implemented in the Bitcoin Core codebase.

Previously, when you were watching this tree of all possible combinations, tree in the data structure sense, it would use the walking of the tree to update the invariance, like how much money has been selected, what the total weight of the selection currently was, and so forth. And when it backtracked a branch to go to a different branch, it would explicitly visit each of the intermediate nodes. And in this new rewrite of the algorithm, instead of walking all of the intermediate nodes in the tree, it will skip directly to the next distinct input set so that it doesn’t have to revisit nodes that it had previously visited, and it skips over some equivalent input sets. So, with the same number of iterations in the exploration loop, it will now iterate over more different candidate sets and hopefully find solutions in fewer loops; or if it runs out of loop tries, it’ll explore more candidate sets.

Yeah, this was in review for about a year and got merged last week. So, I’m a little excited that it’s finally done.

Gustavo Flores Echaiz: Nice. Very clear. Thank you, Murch. So, that completes the three items from the Bitcoin Core repo. And now, we have one from the LDK, BTCPay Server, and the BIPs repository. We had started to put the BIPs items first, but I’m going to just go in the order as it’s written first.

LDK #4647

So, first, LDK #4647 basically changes how it uses introduction nodes in blinded message paths because of an incompatibility with LND’s onion message support. So, basically, the problem is that because LND has started onion message support, but only partially, it doesn’t fully support, for example, forwarding messages from non-channel peers. However, it can receive a message from a non-channel peer, but it won’t forward it. So, an LDK node could choose an LND node to be the introduction node in a blinded path, but when it would come the time for the LND node to forward the blinded message, the onion message to the LDK node, it would simply not forward it, basically breaking the point of choosing the LND node as the introduction node in that blinded path. So, LDK has basically reverted its functionality to now only choose itself or the recipient as the introduction point for a blinded path. There’s a privacy trade-off here because now, as a sender, you now know that the receiver is the introduction point, so receiver privacy is deteriorated partially. And this is probably just a temporary change made until LND achieves feature-compatibility and could eventually forward onion messages from non-channel peers. However, to not break support, this is downgraded to now on all blinded paths, LDK will just choose itself, the receiver, as the introduction point in blinded paths.

Also in this PR’s discussion, it was analyzed the idea of building a sort of heuristic that if we were going to choose an LND node for this, then maybe skip the LND node and try to choose a node that isn’t an LND node. But the author, Matt, basically went against this idea of trying to build heuristics across nodes, because this has also caused other issues with, like, LSP heuristics, which is another part of LDK. So, it was just chosen to make this change for the time being, so that support for BOLT12 blinded paths doesn’t break when LDK would choose an LND node as the introduction point of the blinded path. So, that’s for the LDK one.

Mark Erhardt: My understanding is, I think we talked about LND last week. And if I remember correctly, I didn’t research this one too deeply, they have a DoS protection mechanism where if they get too many messages, they will receive all of them but drop some of them and only forward partially. And I would assume that this is maybe even more strict regarding non-channel peers, so that there would be more leniency towards a peer that you have a channel with versus a peer that you just peer with for gossip messages. And so, of course, when you receive messages, but not guaranteed to forward all of them due to this DoS protection mechanism, this would potentially cause payment instructions to get lost if the BOLT12 support that depends on onion messages working, if those BOLT12 messages would get dropped. So, I think that’s the context to last week that explains how LND has structured its initial support for onion messages might be an issue here for LDK.

Gustavo Flores Echaiz: Yes, that is exactly right actually, Murch. I just looked at the release notes of LND v21, and one of the items that I didn’t mention in detail before. But yes, with the introduction of incoming onion messages, LND implements strong rate limiting and channel-presence gate, which is exactly what this is about, right? So, for example, the notes say, “Incoming onion messages from peers with no fully open channel are also dropped at ingress as a Sybil-resistance layer; pending channels are excluded”. So, yes, it is about rate limiting and preventing some sort of spam of onion messages, which by the way, I think we’ve discussed in this podcast that that also introduces some other issues. But yes, that is exactly related to why LDK has to make this change, because LND has implemented this rate limiting and gaining of onion messages from non-channel peers.

Mark Erhardt: And maybe also for context, I think at least a past number was that about 85+% of all nodes on the Lightning Network are LND. So, with LND rolling out this new feature, probably a lot of the peers that advertise onion messaging would actually implement it in this manner. So, this means that if you just randomly pick peers based on the advertised flags, you might hit an LND in more cases than not.

BTCPay Server #7218

Gustavo Flores Echaiz: Right, perfect. Next item, BTCPay Server #7218 adds a guided setup flow for multisig wallets. So, what does this mean? Previously in BTCPay Server, you could use a multisig wallet. However, it was one user that would create the multisig wallet by himself, and the signing would occur externally from the BTCPay Server platform, for example through PSBT signing. However, what is introduced here is a new guided flow where multiusers participate. So, for example, I as a user, as a store owner, I choose the signing policy, and then I invite users to become store users who will then submit their signer keys through the guided flow. So now, this is basically multiple users can collaborate in the creation and then the signing of a multisig wallet within BTCPay Server. And they can do this by bringing signer keys manually, or also through the plugin called BTCPay Server Vault, which allows you to connect a hardware wallet to BTCPay Server. So, quite a big user experience improvement, and something that was also being worked for a little while already.

BIPs #2186

Next and final item comes from the BIPs repository #2186, where BIP77 is updated to specify basically compatibility between a payjoin v2 receiver and a payjoin v1 sender. So, for example, what is described here, and maybe, Murch, you know more detail about this, but from my understanding, what is described is that in payjoin v2 BIP77’s normal response path, a sender provides the receiver with a reply key and the receiver can provide its response and encrypt it with the reply key and deliver it to the sender-derived reply mailbox. However, from my understanding in BIP78, these reply keys simply don’t exist, or senders at least don’t provide them receiver. So, the receiver doesn’t necessarily encrypt the message and there’s no such thing as a sender-derived reply mailbox, so the receiver will instead write its response in his own mailbox where the sender had originally posted the original PSBT. And when we’re discussing messages, we’re talking about the signing of PSBTs. But please go ahead, Murch, if you have something to add here.

Mark Erhardt: Yeah, let me start by explaining a quirk here. BIP78 is payjoin v1. The actual title is, “A Simple Payjoin Proposal”. And we will refer to this as v1. And BIP77, with the lower number, is v2, “Async Payjoin”, or also known as payjoin v2. I think that derives from originally BIP79 being assigned a payjoin-like construction, and then counting down for some reason. We generally otherwise try to at least have follow-up BIPs that build on other BIPs to have higher numbers, because that feels more natural. But in this case, 77 is actually the follow-up to 78. Okay, now that we have that out of the way, 77 is asynchronous payjoin in the sense that when you use payjoin v1, BIP78, you had to run a server. And this server would allow a collaborator to communicate and build a transaction with the receiver together. So, the receiver would host a server where they would offer their PSBT with their own input and their own output. And then, the sender would pick it up there, add their inputs and change output potentially, put it back in the same spot. They would encrypt it, but use the same encryption key. And then, the receiver would pick it up again, finalize it and submit it to the network.

In asynchronous payjoin, neither of the two parties has to run their own server. They use a third-partied mailbox system that is encrypted in two separate steps, so that one party is responsible for the data hosting and the other party is responsible for either the key exchange or either way, the third party cannot read the content. Oh yeah, the IP address is separated from the data storage. So, one party cannot see who is participating and the other party cannot see the data. And because this is a third party now that uses some fancy moon math to encrypt everything and make it very private, you can run this without running your own server as the receiver, which is the big innovation of payjoin v2. And payjoin v2 users should be, of course, compatible with payjoin v1. And to achieve this compatibility, they have to behave in the way payjoin v1 expects, because payjoin v1 nodes, of course, don’t know about payjoin v2; versus payjoin v2 knows about how payjoin v1 works.

So, in order to achieve this backward compatibility, the BIP77 clients behave as BIP78 payjoin v1 would expect, and put the data back where the receiver originally put their PSBT, and respond in the manner that the old protocol worked. And that was apparently not fully documented before in the v2 payjoin BIP and was now added to it.

Gustavo Flores Echaiz: Perfect. Thank you, Murch. Well, that completes the final item and the whole newsletter.

Mike Schmidt: Awesome. Thanks, Gustavo, and thanks, Murch, for getting us through an interesting Notable code segment this week. We also want to thank Vasil for joining us for one of those Notable code items, and we want to thank you all for listening and we’ll hear you next week. Thanks guys.

Mark Erhardt: Thanks for your time.

Bitcoin Optech Newsletter #409

2026-06-12T00:00:00+00:00

This week’s newsletter describes a draft BIP to replace the testnet4 test network with a successor. Also included are our regular sections announcing new releases and release candidates and describing notable changes to popular Bitcoin infrastructure software.

News

● Draft BIP for testnet5: Pol Espinasa posted to the Bitcoin-Dev mailing list a draft BIP, co-authored with Fabian Jahr, to replace testnet4 with testnet5. The proposal is motivated by testnet4’s low reliability, which stems from sustained exploitation of the difficulty exception (also known as the 20-minute rule). This rule allows CPU miners to mine blocks at difficulty 1 once 20 minutes have passed since the previous block, enabling “block storms” in which large numbers of low-difficulty blocks can be mined in a short time (see Newsletter #311).

The draft BIP proposes removing the difficulty exception rule so that testnet matches mainnet behavior as closely as possible. Testnet5 would follow the same consensus rules as mainnet except for two changes: activating BIP54 (the consensus cleanup soft fork) from block 1, and setting the maximum proof-of-work target to 0x1a0fffff (a lower maximum target than testnet4, i.e. a higher minimum difficulty).

Espinasa invited other developers to provide feedback on the proposal. Discussion on the mailing list thread centered on applying patches to testnet4 instead of spinning up a new one, the possibility of pre-mining testnet coins, and the best minimum difficulty for the new network.

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.

● LND 0.21.0-beta is a release of the next major version of this popular LN node implementation. It adds basic onion message forwarding, production-ready simple taproot channels with support for RBF cooperative closes, reorg protection for channel closes, faster initial sync for Neutrino-backed nodes, an optional native-SQL payment store migration, plus multiple bug fixes.
● Core Lightning 26.06.1 is a maintenance release for the current major version of this popular LN node. It fixes a bwatch plugin registration failure after running make install.

Notable code and documentation changes

● Bitcoin Core #35410 fixes a bug that could cause a private transaction broadcast retry to connect directly to an IPv4 or IPv6 peer instead of using Tor or I2P. When sendrawtransaction was used with -privatebroadcast=1 (see Newsletter #388), Bitcoin Core forces transaction broadcast connections through a Tor or I2P proxy. If one of those connections attempts BIP324 v2 transport but fails, it retries v1 transport. Previously, the retry could forget the private broadcast proxy override on nodes that otherwise made direct IPv4/IPv6 connections. The proxy override is now stored and carried through v2-to-v1 reconnections.
● Bitcoin Core #34779 implements BIP323, reserving block header nVersion bits 5 through 28 as extra nonce space for miners (see Newsletter #405). Previously, these bits were part of the range monitored by the BIP9 version bits warning logic for unknown soft fork signaling. Bitcoin Core now excludes the BIP323-reserved bits from that warning logic, preventing miners who use them for nonce rolling from triggering unknown soft fork warnings.
● Bitcoin Core #32150 rewrites the branch-and-bound coin selection algorithm to avoid walking back through parts of the search tree that only reproduce equivalent input sets. Instead of repeatedly backtracking and retesting the same selection prefixes, the new search tracks the next UTXO to try, cuts branches that can’t reach the target, shifts directly to the next useful candidate, and skips duplicate or more wasteful UTXOs with the same effective value. This allows the wallet to use its iteration budget on more distinct candidate selections.
● LDK #4647 stops using remote introduction nodes for BOLT12 blinded message paths to avoid incompatibility with LND’s opt-in onion message support, which may receive but not forward messages from non-channel peers. LDK now uses the announced recipient itself as the introduction point, improving interoperability but reducing receiver privacy.
● BTCPay Server #7218 adds a guided setup flow for BTC multisig wallets. Store owners can choose a signing policy, invite store users to submit signer keys manually or through BTCPay Server Vault, review generated addresses, and create the wallet once the necessary keys are collected.
● BIPs #2186 updates BIP77 to specify how a payjoin v2 receiver replies to a BIP78-compatible sender. BIP77’s normal response path uses a reply key provided by the sender to encrypt the proposal PSBT and deliver it to a sender-derived reply mailbox, but BIP78 senders do not provide reply keys. Instead, the receiver writes the base64-encoded proposal PSBT back to the receiver’s mailbox where the sender posted the original PSBT. The receiver uses an OHTTP-encapsulated PUT request to the directory. This documents the backwards-compatible response path used by implementations.