Bitcoin Optech

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

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

Want more?

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

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.

Bitcoin Optech Newsletter #408 Recap Podcast

2026-06-09T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Pyth and Ademan to discuss Newsletter #408.

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

Download audio

News

● A post-quantum path for BIP324 (37:15)
● Discussion of QR signing payloads for miniscript wallets (1:27)

Changing consensus

● CTV-only vault proof of concept (13:08)
● Post-quantum Lightning discussion (43:41)
● Quantum attack game theory (47:24)
● BIP54 64-byte transactions and potential legitimate uses (49:15)

Releases and release candidates

● Core Lightning 26.06 (1:11:15)

Notable code and documentation changes

● Bitcoin Core #35269 (1:15:42)
● Bitcoin Core #34644 (1:20:45)
● Bitcoin Core #34198 (1:22:21)
● LND #10813 (1:26:32)
● Rust Bitcoin #6250 (1:28:05)
● BOLTs #1338 (1:36:06)
● BOLTs #1326 (1:37:23)

Transcription

transcription coming soon

Bitcoin Optech Newsletter #408

2026-06-05T00:00:00+00:00

This week’s newsletter summarizes ideas to make BIP324 transport encryption quantum secure and describes a proposal to standardize QR-based signing payloads for miniscript wallets. Also included are our regular sections summarizing proposals and discussion about changing Bitcoin’s consensus rules, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

● A post-quantum path for BIP324: Olaoluwa Osuntokun posted to the Bitcoin-Dev mailing list his thoughts on possible upgrades needed to make BIP324 quantum secure. BIP324 introduced transport encryption for the P2P protocol, enabling peers to exchange messages on the network with improved privacy and security, and it is designed in such a way that the initial handshake and the whole traffic look completely random for an external viewer. According to Osuntokun, modifying the P2P protocol does not require widespread agreement as a consensus change does, and could be an easier first step to make Bitcoin quantum secure.

Before proposing a formal BIP, Osuntokun invited discussion on two main design points. The first one covers which Key-Encapsulation Mechanism (KEM) should be used, either a hybrid approach or a pure post-quantum one, both leveraging a new primitive called Module-Lattice-based KEM (ML-KEM). The second design point addresses the question of whether the initial handshake should still be indistinguishable from a random byte string or not.

On the first point, the author specified that a hybrid approach, combining the current ECDH algorithm and ML-KEM, could provide better guarantees, since it would provide protection in case either of the two algorithms is broken. In fact, while ECDH could be broken by a future Cryptographically Relevant Quantum Computer (CRQC), quantum-safe algorithms have not been battle-tested yet and could still fail due to mathematical flaws.

On the second point, Osuntokun provided possible alternatives, in case the requirement for a handshake to be indistinguishable from a random byte string needs to be maintained. The first approach would use the current BIP324 handshake first to open a classical channel to be used to negotiate the post-quantum one. Another approach, based on Outer Encrypts Inner Nested Combiner (OEINC), would use an outer KEM to encrypt another inner KEM, achieving a post-quantum channel in a single step.
● Discussion of QR signing payloads for miniscript wallets: Pyth posted to Delving Bitcoin a proposal to standardize the data payloads exchanged between wallet coordinators and air-gapped signing devices over QR codes when using miniscript-based spending policies. While existing QR-based protocols handle standard m-of-n multisig, miniscript’s variable policies require additional capabilities that current schemes do not cover. His proposal defines payload types for retrieving xpubs, registering a descriptor, verifying addresses, and signing. Pyth is seeking feedback from signing device and wallet developers on the proposed payloads.

Changing consensus

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

● CTV-only vault proof of concept: Ademan announced on Delving Bitcoin the 0.1.0 release of his CTV (BIP119) vault project called MCCV (More Complicated CTV Vault). MCCV implements several ideas about how full featured vaults (less simple than James O’Beirne’s simple-ctv-vault, see Newsletter #191) can be built without more complex opcodes such as OP_VAULT (BIP345) or OP_CHECKCONTRACTVERIFY (BIP443). Specifically, MCCV uses a directed acyclic graph (DAG) of CTV transactions to implement a single-UTXO vault which can exist for many interactions before eventually becoming spendable by the vault’s recovery keys. Using a taproot script tree of possible withdrawal scripts, each with different amounts and timelocks, MCCV implements rate limiting. Also in the script tree are deposit CTV hashes which allow additional funds of various amounts to be added to the vault. MCCV avoids one of the fundamental problems solved by BIPs 345 and 443 of combining vaulted inputs by using a single vault UTXO which is expanded and contracted, rather than a collection of vault UTXOs. Like all CTV-based vault designs, the amounts which can be deposited or withdrawn must be precise and enumerated at creation, which BIPs 345 and 443 do not require. However, MCCV’s rate limiting is not fully possible in multi-UTXO vaults. MCCV can also be implemented with OP_TEMPLATEHASH (BIP446).
● Post-quantum Lightning discussion: Olaoluwa Osuntokun (roasbeef) posted to Delving Bitcoin a breakdown of how a post-quantum Lightning Network might look, layer by layer. Osuntokun outlined the landscape of available post-quantum cryptosystems and the layers of the Lightning Network to match cryptosystems to each required cryptographic primitive. Post-quantum Lightning can retain its overall structure, but will likely have to give up the single node key that it currently relies on. No single post-quantum cryptosystem or key can provide all of the primitives required. Osuntokun found that lattice-based cryptography is best suited for certain Lightning Network functions, including key exchange. He also notes that due to the large size of post-quantum cryptographic elements, it would likely make sense to continue using elliptic curve cryptography in parallel to provide security in case of a weakness in the several post-quantum schemes.
● Quantum attack game theory: Jameson Lopp posted to Delving Bitcoin his blog post about the game theory of a quantum attack. Lopp describes the potential incentives and actions of various market participants if a quantum computer is built which can reveal Bitcoin secret keys from public keys. The potential scenarios he describes are unpredictable, as quantum attackers might rapidly gain access to large amounts of Bitcoin without the proof of work and capital investment associated with other large holders.
● BIP54 64-byte transactions and potential legitimate uses: Jeremy Rubin wrote to the Bitcoin-Dev mailing list about potential legitimate uses for 64-byte witness-stripped transactions. The consensus cleanup (BIP54) proposal includes a change to make 64-byte witness-stripped transactions consensus invalid. This change is intended to make a class of merkle tree vulnerabilities impossible and therefore make implementing simplified payment verification wallets and similar header-based payment verification schemes safer. Because a 64-byte transaction can have at most 1 input and 1 anyone-can-spend output, the authors of BIP54 had considered them not worth protecting. Rubin proposes several potential scenarios where present or future protocols might make use of such transactions.

Releases and release candidates

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

● Core Lightning 26.06 is a major release of this popular LN node implementation. It adds new graceful, sendamount, and xkeysend RPCs, begins the pay deprecation cycle in favor of xpay, and adds experimental BOLT12 payment proof support. See the changelog for additional details.

Notable code and documentation changes

● Bitcoin Core #35269 fixes MuSig2 PSBT signing by including each participant’s public nonce in Bitcoin Core’s internal MuSig2 signing session identifier. Previously, calling walletprocesspsbt more than once on the same nonce-less PSBT could generate a new public nonce but the same internal session ID, triggering an assertion meant to prevent nonce reuse. The new session identifier distinguishes signing sessions with different public nonces, but still crashes if the same nonce appears to be reused to prevent a private key leak.
● Bitcoin Core #34644 adds a submitBlock method to the Mining IPC interface (see Newsletters #310 and #323), allowing Stratum v2 clients to submit a fully assembled block for validation and processing. This is useful when a Stratum v2 job declarator receives a solved block for which Bitcoin Core lacks a corresponding BlockTemplate object, making the existing submitSolution method insufficient (see Newsletter #325). The new method is similar to the submitblock RPC, but it returns a boolean result and rejection details for duplicate, inconclusive, or invalid blocks. Unlike the RPC, IPC callers must submit a complete block, including the coinbase witness when a witness commitment is present.
● Bitcoin Core #34198 fixes a migration failure affecting very old legacy wallets created before wallet best block records were added in 2011. It is now possible to migrate a wallet with an empty best block locator to a descriptor wallet, but a full chain rescan is required before the migration is complete.
● LND #10813 removes support for producing Tor v2 onion services, which were deprecated in LND 0.20 (see Newsletter #375). The deprecated tor.v2 option is removed, however v2 addresses are still preserved in peer announcements so existing gossip messages can still be verified and rebroadcast. Tor v2 onion services have been obsolete since October 2021; users should use Tor v3 instead.
● Rust Bitcoin #6250 starts validating that the coinbase input contains a 32-byte witness reserved value whenever the coinbase transaction includes a witness commitment, aligning rust-bitcoin’s block validation with BIP141. Previously, rust-bitcoin only performed this check when the block contained other segwit transactions, so it could accept a block with a coinbase witness commitment but no coinbase witness reserved value.
● BOLTs #1338 updates BOLT2 to require nodes to wait at least 100 blocks before sending channel_ready if the channel funding transaction is a coinbase transaction, preventing a miner from immediately using an immature coinbase output to open a channel.
● BOLTs #1326 updates BOLT4 to allow final nodes, not just forwarding nodes, to return invalid_onion_version, invalid_onion_hmac, or invalid_onion_key errors. Previously, these errors were incorrectly placed under a rule that final nodes must not use. The PR also clarifies that forwarding nodes must not handle already-paid payment hashes as final recipients do.

Bitcoin Optech Newsletter #407 Recap Podcast

2026-06-02T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Chandra Pratap to discuss Newsletter #407.

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

Download audio

News

● Core Lightning assertion DoS disclosure (0:47)
● Bitcoin Core developer meeting transcripts (14:34)

Releases and release candidates

● Eclair v0.14.0 (20:30)
● Core Lightning 26.06rc2 (23:01)

Notable code and documentation changes

● Bitcoin Core #33966 (24:14)
● Bitcoin Core #34917 (28:04)
● Bitcoin Core #35017 (30:52)
● BIPs #1944 (35:25)
● BIPs #2108 (36:14)
● Eclair #3192 (39:28)
● LDK #4584 (40:28)
● LDK #4628 (41:27)
● LND #10552 (43:35)
● LND #10820 (48:52)

Transcription

Mike Schmidt: Welcome, everyone, to Bitcoin Optech Newsletter #407 Recap. Today, we’re going to talk about the disclosure of a vulnerability in Core Lightning (CLN) nodes and its responsible disclosure; we also are going to cover some transcripts from a recent Bitcoin Core in-person developer meeting; and we have our usual weekly segments on Notable code and Releases. This week, Murch, Gustavo and I are joined by Chand. Chand, do you want to introduce yourself?

Chandra Pratap: Yeah, sure. Thanks, Mike. I am Chand, a grad student of mathematics at NIT Surat, India, and a Summer of Bitcoin 2025 alum where I worked on fuzzing CLN. And I’m a participant in this year’s Summer of Bitcoin as well. So, yeah, that’s about me. It’s great to be here.

Core Lightning assertion DoS disclosure

Mike Schmidt: Awesome. Thanks for joining us, and we’ll jump right into your news item titled, “Core Lightning assertion DoS disclosure”. Chand, you posted to Delving Bitcoin about disclosing a DoS vulnerability in CLN, and you mentioned that that was discovered during your Summer of Bitcoin 2025 internship. The vulnerability affected any CLN node that accepted incoming channels. Maybe we can get into what the vulnerability is. Talk about maybe the process of channel opening, and then how the vulnerability fits into that process.

Chandra Pratap: Right, yeah. So, how CLN works is basically it’s a multi-daemon architecture. So, there’s a master daemon, which is called the Lightning Daemon, and it works as a demultiplexer for different types of messages. So, for open channel flows, for flows that open channels, there’s the opening daemon for gossiping, there’s the gossip daemon, there’s the onchain daemon for onchain operations, and stuff like that. And this vulnerability was basically found in the opening daemon, which handles all, I guess, operations pertaining to open channel operations. And what happens is basically a remote peer, after it connects, it completes the initial Noise handshake and initiates the standard open channel procedure, which is sending an openchannel message followed by receiving the acceptchannel from the peer. After it does that, it creates, you need to send a funding_created message. But what’s special about this funding_created message is that if you set the funding_txid, which is a parameter in this message, so to say, if that is completely zero, that basically crashes the node.

How that works is basically, CLN relies on HSMD, which is the Hardware Security Module Daemon, for all its cryptographic operations. And the opening daemon parses this funding_created message to the HSMD to verify for correctness. And there was an overtly strict assertion in the HSMD, which basically asserted for this funding_txid to be non-zero. The developers assumed this was an impossible state to reach over the wire, but apparently it was not. And because the assertion fails, there’s an abort signal, and the HSMD basically errors out. And because Lightning Daemon relies on the HSM Daemon for all critical cryptographic operations, it cannot safely continue without it, and it has to become offline as soon as HSMD is offline, which in turn takes out the whole node. So, that’s how that vulnerability works.

Mike Schmidt: Okay, so it’s an assertion error somewhere in the CLN codebase that was assumed to not be something that would be relayed over from a peer, or at least it wouldn’t get to that lower level of the stack. And if it did, it essentially crashes the CLN node. And so, all CLN nodes were vulnerable to essentially being taken offline through this vulnerability?

Chandra Pratap: Right, yeah. The potent part of this vulnerability is the fact that it is fully remote and permissionless. So, any public node that accepts incoming channels could be instantly crashed by an interested peer before any sort of capital is locked.

Mike Schmidt: Wow. Yeah, that’s a big one. Good find. Maybe if Gustavo or Murch have questions on the vulnerability, we can get into that. But I was also curious about the discovery of this. So, how did you find this? You mentioned fuzzing earlier.

Chandra Pratap: Yeah, so my entire project was about writing advanced, well, hopefully advanced, but basically improving the fuzz testing suite for CLN. And that involved writing new harnesses, fuzzing harnesses for the program. And while I was writing the harness, I was working on the project, I decided to take it step by step. And the opening channel flow is one of the first things that occurs when you open a channel on any Lightning Network. So, that’s the part that I decided to test first. And I created a custom fuzz target for it, it’s called fuzz-open_channel. So, what the target basically does is it randomly alternates between feeding complex, raw, random data or structurally valid but semantically random messages. So, randomized feature bits, flags, TLVs, stuff like that into fundee_channel(), which is basically the handler for openchannel messages in CLN. By mixing this structure of valid messages with random content, the fuzzer navigated past the outer protocol guards and struck an edge case in the deep logic that resided within the HSMD. And the sanitizer caught the crash, and that’s where the fuzzer basically tripped up.

Matt Morehouse, who was my acting mentor at the time, he then verified the vulnerability using a custom attack script, which is basically a malicious Lightning peer that sends the malicious funding_created message to the node. And that’s how we came to be sure of the fact that this was a vulnerability, and later disclosed it to CLN security.

Mike Schmidt: It’s interesting, you mentioned Matt Morehouse. Listeners of this show and readers of the newsletter will know that he made several appearances on the show, I believe it was in the last year or two, coming up with vulnerabilities that he discovered on his own. And he consistently had the message calling out to people that there needed to be more people doing more fuzz testing on Lightning implementations. And it sounds like he put his time where his mouth was, in terms of being a mentor for you during The Summer of Bitcoin program. And now, you’ve done this fuzzing last year and discovered this. So, it’s interesting to see that sort of go full circle. Murch, do you have any comments or questions on this, or Gustavo?

Mark Erhardt: Maybe just a great find. And that sounds like a big one, because just randomly crashing nodes remotely is, of course, pretty debilitating. And especially if you can just send a message directly to one peer by contacting it and handshaking, and then it crashes. That’s like the definition of a critical vulnerability. So, glad that that was fixed. I see that it was disclosed in July last year, and then it was fixed in August. So, I take it that all of the current CLN versions that are in use are secure against this bug now?

Chandra Pratap: Correct. The latest version, which was, I think, 26.04 of CLN, fixed this bug, and everyone that’s operating is advised to upgrade.

Mike Schmidt: For listeners who may be curious about fuzz testing and what it takes to get in and write a harness or start poking around, maybe you can articulate a bit of your experience before the Summer of Bitcoin program, and what level of effort or knowledge was helpful in ramping up with that fuzz testing with Lightning, and maybe other folks can maybe hear a pathway to doing something similar?

Chandra Pratap: Yeah, sure. I mean, I think fuzz testing is actually a pretty great entry point into Lightning and the Bitcoin ecosystem in general, because it doesn’t require a lot of domain-specific knowledge. You can get started with writing targets for very simple message parsers if you want. And again, you don’t need very complex domain knowledge, the different protocol flows, how they interact with each other, different messages, to get started with it. Me personally, I did not know about fuzz testing or Bitcoin development, any of it before my Summer of Bitcoin 2025 internship. But I ramped up through my phase of writing the proposal for the project. And throughout the project, I was able to take up whatever was necessary to see it to completion on a good level. So, yeah, I think it’s a pretty good entry point. And for anyone that’s looking to get into it, I think the best way to do that would be to start right away. Lightning Network still, fuzz testing is something that the entire ecosystem is lacking in. There’s a lot of implementations, a lot of them are written in different languages. So, whatever you’re comfortable with, you can dive right in, start implementing, writing fuzz targets in whatever language you’re comfortable in, and that’s a great entry point. So, yeah, I think that should be a good roadmap for anyone that’s looking to get into it.

Mike Schmidt: Yeah, thanks for commenting on that. What are you doing during your 2026 internship? You mentioned you were doing it this summer as well.

Chandra Pratap: Right. So, this is, I guess, in a sense, a continuation of my previous work. I am working on building Smite, which was basically started by Matt again. And it’s a snapshot fuzzing framework for the Lightning Network. So, instead of targeting a specific Lightning implementation, we’re building a sort of generalized framework that attacks a specific lightning implementation from a high level, and trying to find deeper stateful vulnerabilities that way. And that’s what I’m working on for this summer.

Mike Schmidt: Very cool. Murch, I saw you kind of had your hand up there.

Mark Erhardt: Yeah, I just wanted to double-down on the fuzzing being a good entry point. Basically, fuzzing treats functions as black boxes, so you really only need to know what goes into a function. And then, you write a routine that just generates random, Well, not random, pseudo-random values depending on the seed. And so, as someone that’s also written a few fuzz tests, you get to basically just exercise all of the possible parameters that can go into a function, or in case of whole software pieces, like the entire API surface or the web traffic surface. And that allows you to find edge cases very easily, because the fuzzer explores specifically in the directions of where it finds progress. So, whenever the software executing the input diverges on its execution path, it notices and then it’ll start using that bit that it just flipped more. So, you basically randomly go over a huge amount of different dimensional inputs, but you double-down on the ones that actually lead somewhere. So, it tends to be very good at finding edge cases. And it is fairly easy to get into because you only, to write such a routine, have to sort of understand how the function is called.

Mike Schmidt: Chandra, anything else that you would leave for the audience as we wrap up this item?

Chandra Pratap: Yeah, sure. I mean, you mentioned Matt. He’s been on here more than a couple of times, and I’m pretty sure he’s said this already. But security across the Lightning Network is something that I think is undervalued as of now. And I don’t want to call out CLN in particular, but the time that they actually took between implementing the fix and actually shipping the fix code was pretty huge. And it points to me that it’s not very reliable for its operators. So, just fuzz testing in general, security in general, is something that Lightning needs to take more seriously in general. And that’s because ultimately, developers are humans. We cannot account for every edge case. And fuzz testing is sort of a barricade against these types of issues. So, it should definitely be something that Lightning should invest more in. I know Bitcoin and Bitcoin Core already value it a lot. It would be nice to see that happening across Lightning as well. And yeah, I think that’s what I want to leave it.

Mike Schmidt: Awesome. Thank you for responsibly disclosing that and working your summers on Bitcoin, and for joining us today to talk about it all. Appreciate your time, Chandra.

Chandra Pratap: Right. Thanks, everyone.

Bitcoin Core developer meeting transcripts

Mike Schmidt: Next news item titled, “Bitcoin Core developer meeting transcripts”. And this is an item we’ve seen before in past Optech Newsletters. We sort of note and cover the fact that this in-person Bitcoin Core developer happens every six months or so. And in an effort to provide some transparency to bitcoiners and folks curious about the technicals, many of the Core developers themselves volunteer to write transcripts during some of the sessions. And that ends up being published publicly on the btctranscripts.com website. And then, if you look, there’s a category for these Core developer meetings under Bitcoin Core Dev Tech. And then, there’ll be an entry for May, which was the meeting covered this week in the newsletter. You can see a bunch of different topics. We highlighted a few, but I think there’s something like 20 or 30 in there that have notes, and then another dozen or so that just have notable mentions. So, we covered SwiftSync; talk about cluster mempool; talk about Erlay; package relay; silent payments; the idea of the TCP hole punching that ended up being a discussion in Newsletter #406, and is ongoing on the Delving Bitcoin forum; private broadcast; discussion of a modern crypto library; mutation testing; and a bunch of other things.

We could obviously talk about any one of these topics for an entire newsletter, but you can see what the Core developers are talking about by looking at the individual transcripts. Murch, do you have any color commentary on this item?

Mark Erhardt: Yeah, maybe just a few comments on why we get together to meet in person. So, Bitcoin Core is a very loosely-organized project. I’m sure some people have noticed that there is not a spokesperson or a president or a boss of the project that will take questions publicly or roll out their roadmap, or anything like that. Especially for new members of the team, it’s therefore not trivial to get a sense of what’s going on and what people are working on. And we find that getting together in person and putting faces to nicknames, when most of our communication is written on the internet, really helps with establishing some mutual trust, and just helping people interpret each other’s review and comments as charitable. Just having met people seems to flip a switch that you have an idea how they could mean stuff better, and so forth. So, we get together twice a year for a few days to just talk through what people are working on, to get input, to review PR together. This is an un-conference-style event, so we don’t have an agenda usually before, but people just put some items on the calendar after we get there if they want to have sessions on topics. And yeah, it’s especially great for new contributors to get a sense of who everyone is and what they’re working on, but also for established contributors to get vibe checks on ideas, or to get some review on things that had been in flight for a long while, or for going through old PRs and checking which ones should get some more review or can be closed because they’re no longer relevant.

So, yeah, we do try to not make big decisions on the direction of the project or anything in person, because we don’t want to exclude people that want to participate but cannot be there. So, those still happen in the IRC meeting, on the Internet Relay Chat on Thursdays, which is open to the public and for which you can also find the logs on various websites that collect them.

Mike Schmidt: I would add maybe just one more note here that I’ve seen on social media people talking about Bitcoin Core developers all being in an office or all being in offices, and things like that. And by my guesstimate, there’s probably 15 to 20 people who are in an office across four or more offices. And there’s probably, in a given year, if you count regular-ish, or maybe multi-commit, multi-review contributors, maybe something like 50 to 60. So, the majority of folks are not in an office. And I think it’s a good opportunity, Murch mentioned, for newcomers to meet some of the nyms that they interact with online. But it’s also a good opportunity even for seasoned engineers to get a chance to see people that they maybe don’t regularly see, but twice a year. So, I just wanted to make that note as well.

I think we can wrap up that News item and the News section as a whole, and move on to Releases and release candidates. And the author of this segment and the Notable code segment is Gustavo. And so, we’ll have Gustavo, who’s back, to walk these items for us. Thank you, Gustavo.

Eclair v0.14.0

Gustavo Flores Echaiz: Excellent. Thank you, guys. So, this week we have two releases. The first is Eclair v0.14.0, which is a major release, not an RC. Here, we have the final versions for splicing and simple taproot channels. However, zero-fee commitment (0FC) channels, those are still on the experimental version. So, that’s also been added in this release. We also have experimental peer scoring, and also the latest implementation of channel jamming mitigation that is now called channel attribution. Maybe that’s not exactly the name. HTLC (Hash Time Locked Contract) accountability, excuse me. So, that is now also part of this release. It was previously called something else, but now Eclair has updated to the latest spec proposal.

There’s also something called plugin validation of interactive transactions. So, basically, a user can use some external plugins to perform validation of remote inputs and outputs. So, for example, if you’re building a splicing transaction or some sort of other interactive protocol, you can use an external plugin to validate the remote inputs and outputs being added in your interactive transaction. So, for example, you can see that a peer would add an input that you don’t want to participate in. So, you can simply refuse to participate in that, or to broadcast that splicing transaction after you’ve validated those inputs. So, quite a big release. I think it was interesting to observe that they’ve now made it possible to add 0FC channels in this release, because that’s also an item that we’re going to cover in the Notable code and documentation changes. So, that was squeezed in at the last minute, but overall, very interesting release.

Also, another important thing to specify is that Bitcoin Core v30 or above is now a requirement for Eclair to benefit from v3 transactions and ephemeral dust, which is required for 0FC channels. So, that’s also very important for Eclair users to be aware about.

Core Lightning 26.06rc2

The next release is the second RC of CLN. So, CLN, as we know, has this habit of making multiple RCs before getting to the official release. So, this was a release with a few new RPC endpoints, as we discussed, I believe, two newsletters ago. Also, the deprecation cycle of a popular plugin called pay, now deprecated in favor of xpay. And also, the RC v2, the difference with the first RC is that the BOLT12 payer-proof protocol has now been updated to the latest proposal. Some changes were made to that proposal in between RCs. So, this one has some additional bug fixes, but also the experimental payment-proof implementation is updated to the latest draft. Any comments here? No.

Bitcoin Core #33966

So, we move forward to the Notable code and documentation changes section. This week, we have three items from the Bitcoin Core repository. The first one, #33966, refactors how mining block template options are parsed. Basically here, the problem was that an external client that was requesting a block template through the Mining IPC interface could pass on a mining option, for example, blockreservedweight, that would conflict with startup mining options of the node. For example, if an external client that was requesting a block template would set a value at runtime for blockreservedweight that would be in conflict with blockmaxweight, for example a value that would exceed the maximum block weight, well, Bitcoin Core would previously simply ignore the invalid value that was being parsed at runtime and silently adjust it to a valid range value. So, that was, let’s say, one of the initial problems.

So, the refactor here, the goal was to create a sort of shared object between the startup options from the node and the runtime options passed by an external IPC client, to ensure that these can live in perfect harmony. The main goal was to resolve the conflict between specifically the value of blockreservedweight and blockmaxweight. So, now, this refactor allows for these values to live more coherently. But also, some other additions that are made in this PR is that at startup, taking a step back here and ignoring the IPC client at startup, previously you could set a blockreservedweight value that would be in conflict with a blockmaxweight value. So, now, even at startup, you ensure that the blockreservedweight value makes sense, and it would be rejected instead of being clamped later. And also, if you enter a negative value for blockmaxweight, it will now be parsed as zero and then rejected instead of overflowing into a garbage signed value.

So, a bit of a refactor for the benefit of IPC clients, and also some internal mechanics fixed for the conflict of some values for startup mining options. Yes, Murch?

Mark Erhardt: It’s a little surprising how hot stitched the IPC interface still is. Yes, it was rolled out as experimental recently, but I mean also, this means that you have actively put in incorrect values to run into these issues, or conflicting values, right? But it seems that with the IPC interface being released last cycle, there is still a lot coming this cycle to follow up on it. So, I assume that these things will also get backported to the previous release.

Gustavo Flores Echaiz: That makes sense. Yeah, definitely. I think we’ve covered every week almost findings that were discovered through the Mining IPC interface, and adjustments that were done later, and this is just the latest one.

Bitcoin Core #34917

So, the next item, Bitcoin Core #34917. This is a maintenance PR. So, if anybody was still using the bip125-replaceable field in RPCs that are related to the wallet, such as listtransactions, listsinceblock, and gettransaction, this field has now been deprecated, although it can still be requested with the deprecated RPC option. The PR also deprecates the walletrbf startup option, and now emits a warning that this will be scheduled for removal in the next release. Yes, Murch?

Mark Erhardt: I just wanted to make it very clear. Obviously, nothing changes in the software you’re running already. So, if you are now using it, that’s totally fine. It is going away in the next release, as in, it is marked as deprecated in the next release, and then presumably it’ll be properly removed in the release afterwards. So, the background here, of course, is that mempoolfullrbf was adopted across the network a few years ago, which means that Bitcoin Core and presumably other implementations too will accept replacements regardless of whether they have set the replaceable flag on the original or not. So, previously, BIP125 required that transactions were marked as replaceable for a node to accept replacements of that. And now, any replacement that pays more attractive fees, as in a higher absolute fee and a higher feerate, will replace the original transaction without the original, even if the original was not marked as replaceable.

So, we had actually just gotten the option for the wallet to signal RBF, I don’t know, not that long ago, also a few years ago. I think just around the time when mempoolfullrbf was happening or the discussion was happening. And now, we’re removing it again because it no longer makes sense to signal replaceability on transactions when any transaction can be replaced simply by RBFing it.

Gustavo Flores Echaiz: Thank you, Murch, for that extra context. Yes, and the mempoolfullrbf option was removed in November 2024. So, yeah, this was long due. Perfect.

Bitcoin Core #35017

The next PR is #35017. So, here, this is a bit confusing. So, basically, if you are submitting a package that has, for example, a parent and a child, but then follow-up descendants, you could be in a situation where, for example, your initial package is submitted and a further child is also submitted. While some transaction checks are still running on the initial transactions, you have already submitted a second descendant to Bitcoin Core. And, for example, if a later consensus script check denies the child of the initial package, not the subsequent child, at a later stage, Bitcoin Core would properly remove the package, but Bitcoin Core wouldn’t properly remove the later child that was added in the meantime those consensus script checks were running. So, now, this update ensures that when a package transaction submission fails due to a later check, all subsequent transactions that remained in the mempool and were previously not properly removed, they are now all removed; all the subsequent childs are now properly removed. So, not to say that the initial package transaction submission, that was properly handled, it was the subsequent childs that were ignored if only in the specific case, where a further, like a final consensus script check would remove one of those transactions.

Mike Schmidt: Murch, question for you on this one. What would happen in the operation of a Bitcoin Core node by having this sort of dangling child remaining in the mempool after the parent is removed?

Mark Erhardt: Well, if nothing gets confirmed, it would just stick around the mempool for, I think, two weeks and then get dropped. But if there were a conflict, I think we would notice the conflict and then remove conflicts and their dependent transactions. So, if a different transaction spends some of the same inputs, we would still remove it. But I think the biggest issue is if there were a conflict with the parent, we would not notice, because the parent is not present in the mempool. So, children can obviously only be valid if the parent exists, because they spend an output created by the parent. And if we had a child in the mempool but its parent wasn’t there, and then there was a new transaction added that would have been in conflict with the parent, we would just put that in the mempool and then not realize that dependent of the non-existent child should have been removed too, because it became invalid. So, maybe some feerate checks, where we were supposed to check for the entire chain that gets removed, would not run at all because the parent isn’t present.

But so overall, that doesn’t sound like a huge issue. Maybe a few bytes of memory occupied unnecessarily. And if other transactions came through or made it into blocks especially, that wouldn’t cause an issue. And it sounds like this is only possible if you submit a package locally to your own node, so you would be putting things into your own node’s mempool accidentally. This doesn’t sound like it’s an issue that can be triggered by handing stuff over the wire, so overall not a big issue probably.

Gustavo Flores Echaiz: Thank you, Murch, for that extra context. So, those are the first three items of this list from the Bitcoin Core repository. And next, we have two items from the BIPs repository. We have two new BIPs, #449, and #450. Murch, do you want to do the honors for these two items, please?

BIPs #1944

Mark Erhardt: Sure. So, BIP449 is OP_TWEAKADD. This allows you to add a 32-byte value and a public key to the stack, and they get combined into a tweaked public key. This is intended to be used with, well, sort of covenant constructions, but it’s pretty small, of course. But it would allow you, for example with OP_CHECKSIGFROMSTACK (CSFS), to check signatures from the stack against the tweaked key. So, this would maybe enable oracle signing and similar things. This has been open for a while, but it’s published now. If this sort of thing interests you, maybe give it a read.

BIPs #2108

The second one is BIP450, called Formosa. This is a similar style proposal as BIP39 mnemonic seed phrases. So, Formosa takes the idea behind the mnemonic seed phrase a little further, in that the mnemonic seed phrase is just random words, and humans are not very good at remembering random words. So, instead of just rolling random words of a list with 2,048 words, it constructs sentences that are themed. So, for example, there could be a science fiction or a fantasy themed sentence. And the same entropy, per a grammar that they define in their BIP, is used to generate a sentence, actually multiple sentences to encode an entire – I think it’s four sentences for one mnemonic story that encodes a seed phrase. So, such a phrase could, for example, be the king serves the wine to the queen in the dungeon, which humans can remember much more easily because it has context and puts subject, object, and verb in the context of something that humans can easily remember. Obviously, you still should not make up your sentences yourself and then check how they would be encoded in order to generate seed phrases. That’s a great way to lose your money. But this is maybe more useful for someone trying to keep something in their mind for some period of time or travel, or whatever, because you now have to remember a few phrases that you can picture in your mind more easily. And then, you can regenerate your wallet from that.

Obviously, I would recommend that you have a backup somewhere because humans are very good at forgetting stuff or mixing up stuff or changing their memories. So, generally, brain wallets are still a terrible idea. Anyway, if you’re interested in seed phrases, a wallet developer, you might find this one interesting. It seems to be a little easier to, for example, read to someone and transfer it that way, or to remember for a while because of the context.

Gustavo Flores Echaiz: Thank you, Murch. Yeah, I think it’s interesting too. I think it lengthens, from what I understand. Like, for example, three, four words would become like six, seven words. I’m not sure, but so it would lengthen, but it would be more memorable. Interesting.

Eclair #3192

The next ones are from the Lightning implementations. So, as I was saying in the Release sections for the Eclair v0.14.0, this item from the Eclair repository, #3192, 3192 adds experimental support for 0FC channels. As discussed in Newsletter #404, this is now part of the BOLTs specification, and is also present in the LDK implementation. So, Eclair follows up to LDK as the second implementation to implement 0FC channels, which is why Eclair now requires Bitcoin v30 to be used with Eclair. However, this feature is disabled by default, remains experimental, but can be turned on for users that are interested in trying out.

LDK #4584

The next two are from the LDK repository, a bit related, both around the payment_metadata field. So, the first one, #4584, builds the plumbing required to add payment_metadata maps not directly to the BOLT12 invoice, but to the BOLT12 blinded message and payment path contexts. So, this is simply a plumbing PR. It basically lays out for us that this will later be added as an optional feature that can be used by users. But for now, it’s simply an internal plumbing that is required for that then to make it available as an option to users. So, like I said in the write up, this building offers with metadata is not yet supported. And it also is built in a way that it will allow multiple independent pieces of data to be attached to the same payment. So, it’s an implementation that could be quite flexible for multiple use cases.

LDK #4628

The next one, LDK #4628, is related to the item we covered in Newsletter #405, where we announced that the BOLT11 payment_metadata was now committed to the inbound payment HMAC (Hash-based Message Authentication Code). So, it basically ensured the integrity of the payment_metadata disabling or removing the ability for a payer to corrupt the payment_metadata that was inserted by the payee. So, now, this PR serves as a follow-up, where the payment_metadata is not only committed to the HMAC, but it can also now be encrypted by the payee to ensure that the payer doesn’t have access to that invoice metadata, and to simplify the encryption layers so that, for example, previously a payee could handle encryption themselves externally. Now, it can all be handled directly within LDK.

There was also a bit of a discussion internally of how to obtain the required nonce, also called initialization vector, or nonce, that was required to encrypt this value. So, there was a bit of an exchange there to find the exact way to implement it correctly. But it was found that when creating the payment hash, LDK already generates a sort of initialization vector nonce that could be used for encrypting the payment data. So, that is what’s being used instead of adding additional values that could consume additional space in the payment_metadata. The initialization vector created when sending the payment hash is also reused here.

LND #10552

So, now, the next one is from the LND repository, the item #10552. Here, this is work done on the Neutrino-backed LND nodes. So, if you’re not using Bitcoin Core, LND has this function that allows you to use compact block filters, that allows you to obtain a bunch of block filters so that you can later scan them, find your transaction history within those block filters, to then request specific blocks that have the information that you need. This is a privacy protocol for light clients to obtain transaction data. So, Neutrino has existed in LND since the beginning. However, there’s now a new fast, initial synchronization mode that allows an LND node to either import pre-built Bitcoin block headers and compact filters from a local file or from an external HTTP source. In the PR description, block-dn.org is presented as one of those options that users can connect to, to download headers from a trusted source, instead of fetching them one by one from peers. This could reduce initial sync time from hours down to minutes, and after that, LND would resume syncing from the P2P network upwards of a certain chain tip that was obtained from either the local files or from the external HTTP source.

So, there’s some new options: neutrino.blockheadersource and neutrino.filterheadersource that must be configured together for this to work. And imported headers are validated locally, and then Neutrino fetches any headers, like I said, after the imported tip from network peers. So, I would have thought this was already in place within LND, but this is a great addition for improving initial sync time for users to reduce that time from potentially hours down to minutes, although there is some trust involved here, but I think the validation makes it that it’s quite minimized.

Mark Erhardt: I think I would want to add a few things. So, Neutrino is the implementation the Lightning Network Daemon, LND, uses to implement BIP157, 158, which is the compact block filter protocol. So, the compact block filter protocol allows people to get sort of a table of contents of blocks that they can search on their end rather than giving – okay, let’s add a little more history. Before the compact block filter protocol, the common way of how light clients got information about transactions from full nodes was per Bloom filters, where they would create a filter and then give it to the full node, and the full node would run it on their data and then return hits. The idea was that it would be a little fuzzy and find things that don’t actually meet the filter, but it would always be a superset of the things that the light client was interested in. So, the light clients essentially gave away what they were interested in regarding their wallet.

Compact block filters turns this around so that the light client does the searching. And what they use is they get back a representation of the content of the blocks, the compact block filters, and they can search those filters like a table of content, “Is something about my address in here, or is something about my UTXOs in here?” It does this a little slow and computationally-intensive, and presumably only a small portion of full nodes serve compact block filters, so it could take a while to get them. I don’t think that it is a privacy improvement for LND to get the compact block filters from a website, because now, when they hit the website, they actually share their IP address with the website and thereby say exactly what blocks they were interested in to a single party that can keep statistics on which IP address downloaded what compact block filters at what time, right? So, if you get them from the public network via peer messages, it would probably be more private. But just getting all of the information at once is probably a speed-up and that seems to be the motivation here.

LND #10820

Gustavo Flores Echaiz: Thank you for that extra context, Murch. Very valuable. So, the next and final item is also from the LND repository. This is item #10820, where after the simple taproot channels implementation in LND, well, after turning it on into production mode, if two nodes would want to open a public channel between them, and if both nodes supported the simple taproot channels implementation, LND would try to open that type of channel. However, as we announced in a previous newsletter when we talked about the simple taproot channel implementation being added to the BOLTs repository and LND promoting it to the production bit, well, taproot channel announcements have not yet been specced, and LND of course has not yet added support for it. So, trying to open a public channel, use a public simple taproot channel, is not possible and naturally fails. But the developer team at LND hadn’t considered that. So, this PR fixes this edge case where both nodes would support this type of channels, and they would try to open a public channel that would ultimately fail, right? The opening of the channel would simply get rejected.

So, now, simple taproot channels must be explicitly requested, since only private channels of this type can be opened. And implicit negotiation, so basically an automatic public channel opening, still selects the lower level, like the next type of channel that both nodes support, either anchor channel types or previous types of channels. Yes, Murch?

Mark Erhardt: Yeah, so maybe to put it a little more simply, currently you can’t tell people that you have a simple taproot channel. So, even when both sides support it, trying to open a public channel with simple taproot channels is not possible. So, it has to downgrade to the next one. And instead of defaulting to it and then failing to open a channel, it will now correctly downgrade. And it still, and has before, supports private simple taproot channels.

Gustavo Flores Echaiz: Precisely. Also, this PR also has some additions, some things that were missed when promoting simple taproot channels to the production bit, and moving it from experimental to production. For example, the lncli openchannel – command, if you chose the channel_type=taproot, it would still try to open an experimental type of channel. So, now, that is also fixed in this PR, to complete the transition from experimental to production for simple taproot channels in LND. And that is the last item of this section, and that completes the newsletter.

Mike Schmidt: Great. Thank you, Gustavo. We also want to thank Chandra for joining us earlier in the News segment, I want to thank Murch for co-hosting as well, and for you all for listening. We’ll hear you next week. Cheers.

Gustavo Flores Echaiz: Thank you.

Bitcoin Optech Newsletter #407

2026-05-29T00:00:00+00:00

This week’s newsletter announces the responsible disclosure of a vulnerability that allowed a remote peer to crash Core Lightning nodes and links to transcripts from a recent Bitcoin Core developer meeting. Also included are our regular sections announcing new releases and release candidates and describing notable changes to popular Bitcoin infrastructure software.

News

● Core Lightning assertion DoS disclosure: Chandra Pratap posted to Delving Bitcoin disclosing a denial-of-service vulnerability discovered during a Summer of Bitcoin 2025 internship. The vulnerability affected Core Lightning nodes that accept incoming channels.

During the channel-opening handshake, a remote peer sends a message containing the txid of the proposed funding transaction. Core Lightning performed an assertion check requiring a non-zero txid. When a peer sent an all-zero txid instead, the assertion failed and crashed the node. Since any peer can initiate a channel-opening handshake and send the malicious message, this allowed a remote attacker to reliably crash any vulnerable node that accepted inbound channels.

The vulnerability was responsibly disclosed and discovered through fuzzing. At the time of the report, Rusty Russell had independently been working on a separate crash bug and his fix incidentally resolved this vulnerability as well. The vulnerability was fixed in Core Lightning 26.04.
● Bitcoin Core developer meeting transcripts: many Bitcoin Core developers met in person in May, and transcripts from the meeting have been published. Topics included SwiftSync, post-cluster mempool, an Erlay redesign, package relay, silent payments, TCP hole punching (see Newsletter #406), private broadcast, a modern crypto library, and mutation testing, among others.

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.

● Eclair v0.14.0 is the latest release of this popular LN node implementation. It includes the final versions for splicing, simple taproot channels, and zero-fee commitments, removes support for non-anchor output channels, and adds experimental peer scoring for liquidity and routing optimization.
● Core Lightning 26.06rc2 is a release candidate for the next major version of this popular LN node which includes new graceful, sendamount, and xkeysend RPCs, begins the pay deprecation cycle in favor of xpay, and adds BOLT12 payer-proof RPC support.

Notable code and documentation changes

● Bitcoin Core #33966 refactors the way it handles mining block template options for the Mining IPC interface (See Newsletters #310 and #323). Previously, startup mining options such as blockmaxweight, blockreservedweight, and blockmintxfee were handled separately from the runtime options passed by IPC mining clients. Now, these options are parsed into a shared BlockCreateOptions object and merged when creating or updating block templates. Invalid combinations, such as a reserved block weight that exceeds the maximum block weight, are now rejected instead of being silently adjusted to a valid range value.
● Bitcoin Core #34917 stops returning the deprecated bip125-replaceable field in wallet transaction RPCs listtransactions, listsinceblock, and gettransaction, though users can still request the field with the -deprecatedrpc=bip125 option. The PR also deprecates the -walletrbf startup option, which now emits a warning and is scheduled for removal in the next release. See Newsletter #403 for previous removal of RBF-related fields.
● Bitcoin Core #35017 updates the package transaction submission process to prevent later transactions from remaining in the mempool after an unexpected validation failure. During package submission, transactions are processed sequentially, allowing later transactions to spend earlier ones that have already been added to the mempool. Previously, if one transaction failed a late validation check (such as a consensus script check), Bitcoin Core would only remove that transaction. Now, it also removes all subsequent transactions in the package, preventing children from remaining in the mempool after a parent has been removed.
● BIPs #1944 adds BIP449, a draft soft fork proposal for OP_TWEAKADD, a tapscript opcode for computing a tweaked x-only public key (see Newsletter #370). Given a 32-byte x-only public key and a 32-byte scalar tweak, the opcode pushes the x-only key for P + tG. This would allow scripts to directly verify key-tweak relationships, enabling constructions such as tweak-reveal scripts, proof of signing order, and signing delegation protocols.
● BIPs #2108 adds BIP450, Formosa, a draft specification for encoding BIP39-compatible wallet entropy as story-like mnemonic phrases. Instead of using random BIP39 words, Formosa uses theme-defined word lists to encode entropy, producing short, structured sentences. These stories can be decoded back into the original entropy and converted into a standard BIP39 mnemonic before seed derivation, thus preserving compatibility with BIP39.
● Eclair #3192 adds experimental support for zero-fee commitment (0FC) channels, following the specification covered in Newsletter #404. The feature is disabled by default and can be enabled with eclair.features.zero_fee_commitments = optional.
● LDK #4584 adds payment_metadata maps to BOLT12 blinded message and payment path contexts. This adds the plumbing to carry recipient-side metadata through blinded paths and recover it when the payment is received, similar to BOLT11’s payment_metadata. Building offers with metadata is not yet supported. The metadata is stored as a map from numeric keys to byte arrays, allowing multiple independent pieces of data to be attached to the same payment.
● LDK #4628 starts encrypting BOLT11 payment_metadata when creating inbound payments, building on the metadata commitment covered in Newsletter #405. After verifying the payment, LDK decrypts the metadata, enabling applications to access invoice metadata without exposing it to the payer or implementing encryption themselves.
● LND #10552 adds a fast initial sync for Neutrino-backed LND nodes by allowing them to import prebuilt Bitcoin block headers and compact filters from local files or HTTP(S) sources before resuming normal P2P sync. The new neutrino.blockheaderssource and neutrino.filterheaderssource options must be configured together. Imported headers are validated locally, and then Neutrino fetches any headers after the imported tip from network peers.
● LND #10820 prevents LND from implicitly selecting simple taproot channels when opening public channels because taproot channel announcements are not yet supported. Previously, if both peers advertised support for this type of channel, LND could select it and then reject the open. Now, simple taproot channels must be explicitly requested, while implicit negotiation can still select legacy, static remote key, or anchor channel types. The PR also updates lncli openchannel --channel_type=taproot to select the production simple taproot channel type.

Bitcoin Optech Newsletter #406 Recap Podcast

2026-05-26T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Oliver Gugger and 0xB10C to discuss Newsletter #406.

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

Download audio

News

● Significant updates to BIP322 Generic Signed Message Format (1:17)
● TCP hole punching for Bitcoin nodes behind NATs (17:39)

Changes to services and client software

● Ibis Wallet announced (40:15)
● LDK Server announced (41:10)
● Mempool.space v3.3.0 released (42:06)
● peer-observer P2P monitoring tooling (32:28)

Notable code and documentation changes

● Bitcoin Core #29136 (43:27)
● Bitcoin Core #34893 (47:24)
● Bitcoin Core #34860 (48:20)
● Bitcoin Core #31298 (53:52)
● Bitcoin Core #28802 (57:04)
● Eclair #3298 (58:52)
● LDK #4575 (1:02:08)
● LND #10814 (1:03:13)
● Rust Bitcoin #6191 (1:04:35)
● BLIPs #42 (1:06:20)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optec Newsletter #406 Recap. Today, we’re going to be talking about a couple of news updates, one to BIP322’s generic signed message format, and another one talking about TCP hole punching for accepting inbound connections on your node. We also have our monthly segment covering four Changes to services and client software, as well as our weekly segment on Notable code and documentation changes. This week, Murch, Gustavo and I are joined by two guests. We’ll have them introduce themselves briefly. Oli?

Oliver Gugger: Yeah, thanks for the invite. I’m Oli, also known as guggero on GitHub, former developer with Lightning Labs, now working on a new project, currently undisclosed, not published. And I came across some to-do’s on BIP322, and that’s, I guess, why I’m here, to talk about that. So, thanks for the invite.

Mike Schmidt: Awesome, thanks for joining us. And 0xB10C.

0xB10C: Hi, I’m 0xB10C, I work on Bitcoin monitoring with the Bitcoin Network Operations Collective.

Significant updates to BIP322 Generic Signed Message Format

Mike Schmidt: Awesome, thank you both for taking the time. We’re going to jump into the News section. First item titled, “Significant updates to BIP322 Generic Signed Message Format”. Oli, you posted to the Bitcoin-Dev mailing list about your work making several updates to BIP322, known as the Signed Message Format Proposal, Generic Signed Message Format Proposal, I should emphasize. That proposal’s sort of been sitting open for a long time. Maybe, Oli, you could perhaps give listeners some of the long-ish history of BIP322, and then you can let us know how you came to start working on it.

Oliver Gugger: Sure. I hope I can represent the full history because I wasn’t really involved before.

Mike Schmidt: Maybe abbreviated, yeah. You can give us an abbreviated version.

Oliver Gugger: So, yeah, I think it was in 2018 by kallewoof, what’s his full name, with the idea to be able to prove to someone that you have the ability to spend from a certain address, usually involving a cryptographic signature, but as we’ll see later on, doesn’t necessarily need to be a cryptographic one. And often, the use case is for KYC. Yeah, we all don’t like KYC. I wish there were better options, but instead of doing something like a Satoshi test to prove to an authorized broker that you own the recipient address, you could use a signed message or sign a message that proves that you are the ultimate recipient. So, I guess that’s the whole purpose for the BIP. There are other use cases, interestingly enough. The Ark protocol uses it for the virtual transaction signing, to prove you own the UTXO. So, it’s not limited to that single use case.

But yeah, the history is that it was opened as a draft in 2018. Then, there were two Bitcoin Core PRs. Both of them were closed due to lots of discussion with seemingly no resolution and open items. Yeah, so it felt like the BIP was stuck for a while, for a long while. I mean, it’s been eight years. And then, yeah, I’ve seen some requests on the LND and btcd repos to support it. And then, yeah, I started this new project where we actually require it, and that was the final straw to sit down and implement it in Golang. And while implementing, I discovered all the open questions. Instead of just trying to do a workaround, or whatever, I thought, “Hey, I’ve worked with BIPs, I’ve read a couple of them. Why not try to get it over the finish line?” So, I gathered all the open questions, all the discussions, and tried to address them, either by just text or by actual changes to the spec itself. And so, yeah, then I got lots of review, specifically from Murch as well. So, thank you very much. And the final process was pretty quick. So, it was merged within three weeks, or something, and it’s now status complete 1.0 which is cool.

Mike Schmidt: And so, what were the big pieces that remained from that initial work, and then lingering over those eight years to what you got across the finish line in the last few weeks? What are the big things that people should be aware of that you put your time into?

Oliver Gugger: So, there are several ones, one of them being a breaking change, or I guess two of them. So, I want to mention them up front. So, first is that there are three different variants of a signature, and they all use a different internal encoding, which makes it hard for implementers, that you basically have to try each encoding and see which one doesn’t fail to find out what variant it is, which isn’t super-nice. So, I proposed a human-readable prefix, just three letters, that indicate which version it’s actually supposed to be, and then the parser can directly use that. And because of the prefix, you can’t just base64-decode it anymore, it will fail. So, you have to update your parser if you already have an implementation. There is a small backward-compatibility fix in there that if you don’t supply a prefix and it’s the simple variant, then you’re supposed to allow it just so that all the existing implementations don’t break. But other than that, it’s a breaking change.

And then, the second one, which is definitely a change to the format, is the proof-of-funds variant, which allows you, in addition to proving that you can spend from a certain address, you can also prove that you can spend some set of UTXOs. So, you can point to UTXOs and provide a signature or a witness script to solve them, and with that, proving that you have the ability to spend them, which is used for proving that you own a certain amount, or that you haven’t spent something, or for exchanges to do with actual proof-of-reserve stuff. Although I don’t know if any of the exchanges actually use this protocol. There, a remaining issue was that information about the UTXOs was not part of the signature. So, you, as a validator, you had to fetch the UTXO set, or be able to get access to it, to be able to even cryptographically verify without telling that it’s spent or not. Just even verifying the signature required you to be online, and that is not super-practical. So, I decided to propose turning the signature into a PSBT because a PSBT can hold that information that is required. So, long story short, proof-of-fund variant now is a full PSBT instead of just a signature. And that at least allows a verifier to verify the witness stack offline. And then, only if they require to find out if the UTXO is still unspent, then have to query the blockchain or the mempool, or whatever. But at least you can verify the signature offline.

Oh, yeah, and what was also missing was just the process, how would you go ahead and create the valid signature for a multisig address, maybe using cold storage devices? Would you use PSBT? How would the flow look like? And I described a proposed flow as well so that hardware wallet manufacturers can easily implement it in their software and know how it should behave and what format should follow.

Then last, there were some just text clarifications on what the BIP is supposed and not supposed to be able to prove. So, there was a lot of discussion around, yeah, can you even prove that you own something or not own something? And so, I just rounded off the wording there to make it clear what the purpose is and what definitely isn’t list of purpose. I guess that’s it, or did I forget anything, Murch?

Mark Erhardt: Did you talk about what the situation was before this was updated and completed? You talked very briefly about the history. So, maybe just for context, that there was a signing format, but it only existed for P2PK and P2PKH, so the legacy style addresses. And then, with new output types coming out over the years, people were coming up with workarounds like, “Oh, I’ll sign with the key in a P2PKH, but actually my output script is a different one”, or they implemented some variants of 322 that they came up with themselves that weren’t documented. And then, I think there, we found out meanwhile that COLDCARD had implemented 322 earlier this year, but so far 322 had had very little adoption otherwise, as far as we know. And so, there were just too many open questions, or the format was maybe a little underspecified in some aspects. So, now that it is rounded out and completed, the controversy still exists. Obviously, some people were very against this, because it would enable more KYC. But clearly there’s demand for it in some ways, like people trying to prove funds before they participate in multiuser constructions or Lightning channels or proof of funds, and so forth. So, as many tools, it’s a double-edged sword. You can do useful stuff with it, but it might also get used for stuff that we are not so fond of.

So, anyway, with the generic signed message format, you can now sign with any output script, because you basically just replicate signing for that UTXO, and thereby you can just sign for anything that you otherwise would be able to sign for. So, multisig is covered, taproot is covered, anything where you can spend funds, you can now also sign for.

Mike Schmidt: Murch, you mentioned some stopgaps and some workarounds over the years that people have put in place. Actually, one of the software that we highlight later in the newsletter, I saw one of the features they touted was support for BIP137. Are you familiar with that BIP? And what is its relation to 322, if at all? I think it’s basically the segwit version of message signing. Is that something that’s on either Oli or Murch’s radar?

Mark Erhardt: Is that Steven Roose’s? No, that was 127, right? Steven Roose had proposed a different proof-of-funds or proof-of-reserve scheme in 127 before, and signatures of messages using private keys. I’m not familiar with 137, to be honest.

Mike Schmidt: Okay.

Mark Erhardt: That was also created in 2019, or something, but it looks related.

Mike Schmidt: Yeah, it was interesting that it had come up later in the newsletter, and I hadn’t seen it, or if I had, I had forgotten about it. But it would seem like BIP322 is more comprehensive, in that it covers other address types, other output types.

Oliver Gugger: Yeah, I also didn’t come across 137. I guess one downside, or I guess disadvantage of BIP322, is that because you can prove any type of script, you also need a full script interpreter, right? So, on the validation side, you need to be able to run the full Bitcoin Script stack-based engine and signature verification, and that might be a bit heavy for a browser or even a signing device. So, there is a downside and 137, because it seems to, from a quick glance, only do the actual schnorr or ECDSA signature, it’s probably lighter to implement. But still, BIP322 is also futureproof by its construction. It will support any future version of segwit that we might add in the soft fork later. So, yeah, it’s pros and cons everywhere.

Mike Schmidt: Well, I mean that’s a huge advantage to being futureproof to new types, obviously, because like Murch mentioned, the original Bitcoin Core software or earlier Bitcoin Core software had support for certain address types. And then there’s 137, which seems to have segwit support. And so, it would be sort of painful to continuously do this. And so, 322 is futureproof. So, I mean, that’s a great benefit. How’s reception been, Oli, from the wider community?

Oliver Gugger: Not too sure. Nothing negative so far, which is nice. I haven’t done a lot of research. I just saw that Sparrow already updated to the new version, which is awesome. Interpreting from the message from COLDCARD that Murch mentioned, I assume they’re also upgrading and hopefully add support for the new version in their next firmware. I myself created a PR for the BitBox to implement it, haven’t heard anything back there. Otherwise, not that much direct response, but I guess it’s still early, hasn’t happened so long ago. So, yeah, but anyone has comments, the mailing list thread is still open. Yeah, let me know if you have questions.

Mark Erhardt: Maybe then just here another call to action. So, anyone that had implemented a scheme for signing for UTXOs in their Bitcoin project, if that was based on 322, you should probably take a look at this update to see whether you’re still compatible, or whether you want to make updates or leave some feedback before it’s out there too long. If you have used a different scheme, we would probably still want to know. I wasn’t particularly aware of other projects, like 137, apparently. And yeah, currently it’s proposed now, and a few people have started adopting it. But if more feedback came in, now would be the best time before everybody forgets about it and has had it in their projects for years, and it’s always harder to get everybody on the same standard further down the road.

Mike Schmidt: Oli, thanks for joining us. We appreciate your work on this and for joining us to speak about it.

Oliver Gugger: Yeah, thank you very much, and also for the coverage in the newsletter. Cheers.

TCP hole punching for Bitcoin nodes behind NATs

Mike Schmidt: Next news item, “TCP hole punching for Bitcoin nodes behind NATs”. 0xB10C, you posted to Delving Bitcoin about this idea to help more Bitcoin nodes behind home routers, for example, to accept inbound connections. Maybe a good place to start would be you can help us recap for the audience why are there challenges, and what are they around getting inbound connections to your node, if you’re running at home, for example?

0xB10C: Right. So, currently, I guess we have two types of nodes on the network. We have the listening nodes, which are able to receive inbound connections. Usually, these are hosted in cloud providers in other houses, and they don’t have a firewall in front of the HTC port. And mostly, the nodes at home, the unreachable ones, are behind a router that either blocks the access to the port by a firewall or because they’re behind NAT. And there have been discussions and ideas around this for a while. So, with the release of v30, one idea to open up more inbound connection slots on home nodes was to make something called -natpmp=1 by default. And now, after the release being out for a little more than half a year, I revisited this, and we were looking at if the number of reachable nodes in the residential ISPs increased since the release of v30m so since people have been upgrading. And by making this a default, the actual expectation was it would see a big increase in the number if it’s working. But so far, it hasn’t really had the big uptick we had hoped to see. And this sparked some discussions on other ways we could allow home nodes, nodes behind the NAT, to have inbound connections.

So, this came up in a discussion while hanging out with a few other Bitcoin developers a few weeks ago. And one idea that came up was hole punching. And hole punching is a technique that you can use if you’re behind a NAT, or if two people are behind a NAT. They can coordinate with a third party and from there can say, “Okay, we open a connection through our NATs at the same time. And this tricks our NATs into accepting the package from the other side”. This is commonly done in UDP protocols, but the Bitcoin traffic we have on the network right now is not UDP, it’s TCP. So, we first looked into if it’s actually possible on TCP, and it turns out it is, and people are actually doing it. So, very roughly, the idea would be, okay, we have two nodes, two home nodes on the network. Both are unreachable from the broader internet, but we have some reachable node somewhere. So, Alice and Bob are the unreachable ones, and Charlie is the reachable one. And for some reason, Alice and Bob connect to Charlie, and Charlie is able to coordinate between Alice and Bob that they should open, at a certain time point, these connections to each other, and then they punch through their home nets and are able to make a connection.

This sniped quite some people, so we had quite some discussion about this in person, and I posted to Delving to continue the discussion there, and also just to write down what we have thought about and what could be a potential option going forward. But this is very far from having a proposal or a standard. At the moment, it’s mostly an idea and it’s something that is possible, it seems possible, we’ve been testing it out in different networks, so different hotel networks, for example. Hotel Wi-Fis seem to allow it. Many people at home said it’s possible for them, or in the office it’s possible. We also got someone to test it from a plane, so it’s possible there. So, these are places where you now could accept inbound connections to your nodes. How that’s going to look like on the implementation side, we don’t know yet. And also, we don’t really know who’s going to implement this and what exactly are we going to implement.

Mike Schmidt: Makes sense. 0xB10C, maybe just taking a step back, and I’m sure Murch will get into some of the technicals, which I think are interesting, but maybe just conceptually, why is an inbound connection desirable, and it’s worth going through these hoops to jump through?

0xB10C: Right. So, each node is making outbound connections, and you need to have some inbound slots for these available on the network. And if we don’t have any inbound slots available on the network, we can’t make outbound connections. So, that’s a big reason why we want to have a certain number of inbound slots available on the network, depending on how many nodes are running, also depending on how many are offering inbound slots and not. But inbound slots are also a limited resource. You want to limit it for memory reasons and DoS reasons and bandwidth reasons, and so on. So, there is a limited number of these on the network right now. And if we could have more inbound slots, then we could make more outbound slots, which would, for example, help with partition resistance, and so on, on the network, but also just offer better connectivity across parts of the network that might not be well connected at the moment.

Mike Schmidt: Is there a particular industry or type of software that does this sort of hole punching currently that people could maybe relate to, because it sort of feels a bit hacky?

0xB10C: Yeah. So, hole punching is quite commonly used in, for example, one-to-one voice or video chats. So, that’s using UDP. But it’s very commonly used. So, one example is, for example, Signal. If you do a Signal video call or a Signal voice call, it’s probably trying to hole punch. And if your carrier or your home browser is allowing it, you have a direct connection to the other person. And if hole punching doesn’t work, it’s using a relay in between. But these relays are obviously expensive to run, because they use up quite a bit of bandwidth and CPU, for example, Signal. And so, ideally, it’s using hole punching, and I think they have seen quite good numbers. And in general, they’ve seen quite good numbers on hole punching in general. But I’m not so sure who is using TCP hole punching. There are some projects using it, there is a big library using it, but I haven’t dug into who exactly this is and what for.

Mike Schmidt: So, even though we’re, I think you used the phrase, ‘tricking’ these firewalls or these routers, this isn’t some obscure technique. Signal and others are using it.

0xB10C: Right, yeah, we’re not coming up with this on our own. There’s other people. I think there’s actually at least some parts of this are documented in RC or so, but obviously not all routers support it, depending on how they configure their NAT.

Mike Schmidt: Murch, have you been following along with these conversations?

Mark Erhardt: Just a little bit. I mean, I wanted to expand a little bit on the inbound slots issue. So, our nodes by default are listening, but not all of them, of course, are reachable from the open internet. And we make eight outbound connections by default. So, every full node tries to pick eight peers to download new blocks from, and picks them themselves. But then, for example, a lot of the light clients, other projects, not Bitcoin Core, they only consume, they don’t actually provide inbound slots themselves. So, we allow up to 115 inbound slots. So, if you are a listening node and reachable from the open internet, you will provide these inbound slots where light clients and other software can get information about the current state of the Bitcoin Network.

So, if we want as many people as possible to be (a) running their own nodes, and (b) as well connected as possible, the eight outbounds, they just take slots away from the available slots. And if the more nodes we can get to add inbound capacity from there, the better connected the network will be. So, if we had a way of getting a node that is about to kick off some inbound connections because they’re getting new connections, to instead hand them off to each other and make a match between them so that they have a pseudo inbound connection, which they usually wouldn’t be able to do by themselves, we would be able to interconnect the network better and give these nodes more connectivity without using slots from the listening nodes. So, yeah, that was basically the idea. Let’s say you have 115 inbounds already, someone connects to you and it would kick someone else off. What if you just connect those to the one that you would be kicking off and the new connection to each other, or something like that? That’s just more in the background.

0xB10C: I think that’s one of the ideas that we were thinking about making this work. So, there could be some handoff going on. So, if two nodes connect to Alice, Alice could say, “Okay, I’m actually full, I’m going to hand this off”. But we also have been thinking about different ways. So, there could also be a matchmaker node who is just responsible to matchmake two peers that are actually looking for this hole punch inbound and outbound connections. And there has been some discussion on making this a coordinator-less or like a coordinator light version of this, so maybe going through Tor and coordinating on a Tor endpoint which might be reachable, or which is reachable on the Tor network, to get rid of this third party in the middle. And also, there have been some questions on how malicious can the third party be and what can it do to break this? Could it only give you connections to maybe some kind of spy node entity or so? Or could it filter out certain IP addresses so you never hear about these IP addresses you might want to connect to? But that’s all still ongoing.

Mike Schmidt: It sounds like this is a newish idea, there’s some prototyping going on. I suspect Optech listeners, there are probably a handful of networking nerds that might be interested in this topic. 0xB10C, where can people follow along with helping to build this idea and contribute to the prototype, or test on their particular network or machine, or whatever? Where can they follow along?

0xB10C: So, I guess the best option is the Delving thread. There is some work done by sipa. He built like a chat server. There’s also some tooling for testing if your home router supports this, or your VPN supports this, or your whatever company network would support this. And posting information about this would be interesting, especially from different vantage points. And there has been some work, so for example, Will Clark posted about testing with a sidecar for Bitcoin Core. That’s basically like a separate process that manages this hole punching. So, the implementation in this version isn’t in Bitcoin Core itself, but in a third-party sidecar that you run alongside it, just to figure out if it’s working and what’s working and how successful it can be with this. But yeah, most of the discussion is happening in the thread by now. There is no other place, no issue, no repository yet.

Mike Schmidt: Okay, listeners, check out the Delving thread if you’re curious about this. This seems like an interesting place to tinker and help provide feedback. And it’s very early in the idea stages, so it sounds like feedback is welcome. So, anything else, 0xB10C, before we move along in the newsletter?

0xB10C: Nope.

peer-observer P2P monitoring tooling

Mike Schmidt: Okay, great. Well, that wraps up the News, but we also have 0xB10C and some of his work highlighted in the Changes to services and client software segment, our monthly segment. So, we’ll jump a bit out of order and cover, “peer-observer, P2P monitoring tooling”. And 0xB10C, you posted again on Delving, I think it was an update to a thread that we’ve covered previously, outlining some of the open-source components behind your peer-observer platform. And I thought that it was worth highlighting here, even though maybe those pieces aren’t downloadable and executable pieces of software like some of these other pieces, like wallet software, and whatnot. I thought it would be appropriate for this audience to highlight those. Maybe you can just remind everybody what peer-observer is as a broader platform, and then maybe you’d like to highlight a couple of components that you called out in your post that could be interesting for the audience?

0xB10C: All right. So, peer-observer is a monitoring tool, and the idea is you’re attached to different interfaces of the Bitcoin Core node, and you can monitor for attacks and anomalies on the network that reach your node. And as a part of the broader peer-observer platform, I run a bunch of honeypot nodes that I hope people connect to and do funny stuff with, but I’m not publishing the IP addresses. So, the hope is that an attacker would connect to this, or these nodes would run in a configuration where they see some kind of anomaly happening. And anomalies are usually bugs that we might want to fix and have data on. And so, what the peer-observer tooling does and the extractor does is it connects to a bunch of interfaces. So, for example, it connects to the node via the tracing interface, but also via the P2P interface. It reads from log messages, so a log interface. And obviously, the RPC interface is being used a bunch. And recently, we added support for something called an IPC extractor, which is in the very early stages, but it reads from the IPC interface.

All these extractors collect events, and these events are passed into a big message bus and can, on the other side, be processed by different toolings. And so, one tooling is, for example, just showing metrics on the Grafana dashboard for a bunch of events. But recently, we also have been working on something called an archiver that archives all of these events to disk for long-term storage, and there has been some work going on there. And also, in general, improving anomaly detection here and there, making it more automatic, but also having some predefined sets of heuristics that we want to alert on. So, there’s an alerts tool that’s using metrics we’ve previously been thinking about and saying, “Hey, if this happens in the network or on the node, that would be interesting to alert on”.

There has been a bunch of work going into this. I’ve been seeing a bunch of new contributors coming online and helping out with this. So, I’m quite happy with the progress here and there.

Mike Schmidt: Great. So, if listeners need to, I guess, reuse any of those components, this is all open source, right, 0xB10C, so these extractors for the different interfaces, the work on archiving that information, and then you mentioned heuristics and dashboards. I think it would be interesting for listeners to pursue just contributing to some of your efforts more broadly. But obviously, if they have projects that they’re working on that may necessitate any of those components, they can grab that open-source code as well.

0xB10C: Right. And everything is open source. It’s on github.com/peer-observer, and there is code for running the infrastructure, and there is code for these tools and extractors. And there is also a demo infrastructure that is public for anyone to explore. Obviously, these node IP addresses are public, and so people might mess with them or they might not mess with them. And on the infrastructure side, we also have been working on, for example, doing some continuous profiling on these nodes, so we can actually see in which areas of the Bitcoin Core codebase the node is spending most of its CPU time in, which is, for example, very helpful if you want to detect DoS attacks on these nodes as well.

Mike Schmidt: Maybe you can tie this work into what you mentioned, I think, in your introduction, which is your open collective, BNOC, and what you guys are doing there?

0xB10C: Yeah, right. So, I’ve started something called the Bitcoin Network Operations Collective. Currently, that’s primarily a forum on bnoc.xyz, and there is a bunch of discussion about people making observations of the network, posts about, like, “Today I saw this”, and then other people may chime in and say, “Oh, yeah, I saw this with my node as well”, or, “Yeah, I’ve been seeing this for the last two years”, and so on. But there’s also some data sharing with researchers going on. So, recently we got a data share and we’ve been uploading stuff here and there and sharing it with researchers. So, one use of the forum is as well to go there and say, “Hey, I actually have some data I can give away for others”, or, “I want to have some data from someone and I don’t know who exactly has this data”, but maybe someone will see the post and comment there, and stuff like this.

So, the idea is to have some kind of collective that’s taking care of what’s happening on the network, similar to what maybe a network operations center would do in a company. But yeah, we’re not really a company in Bitcoin open-source development. So, it’s more like a collective of people coming together from various places in the world and companies.

Mike Schmidt: So, if listeners want to be a Bitcoin Network watchdog, you all should check out what 0xB10C is up to with BNOC. And even if you’re not, I think there’s been some interesting discussions surfaced there recently, so encourage folks to check that out. Anything else, 0xB10C?

0xB10C: I think that’s it. Thank you for having me.

Mike Schmidt: Okay. Thanks for joining us, 0xB10C. Cheers.

0xB10C: Yes, thank you. Bye.

Ibis Wallet announced

Mike Schmidt: Back up to the first item from the Changes to services and client software, is Ibis Wallet being announced. This is a new Android wallet. It supports a bunch of Bitcoin Optech goodies, coin control, fee management using RBF and CPFP, there’s Tor integration, silent payments, some silent payment support, hardware device signing, multisig, I think they’re multi-wallet. We talked about BIP137 earlier, which was interesting. And also, this wallet supports second layers in sort of an opt-in way. So, turn on and off things like Spark, Liquid, and Ark. There is not native Lightning support, but it’s provided BOLT11 and BOLT12 support through its Liquid and Spark integrations.

LDK Server announced

Mike Schmidt: Next piece of software we highlighted was LDK Server being announced. Spiral, and I think benthecarman in Las Vegas, announced LDK Server, which is an API-first Lightning node built on LDK Node, which itself is sort of an abstraction over LDK library. And so, they’re calling this LDK Server, and it’s meant to be sort of API-first. So, this is things like gRPC, it uses MCP (Model Context Protocol) for AI integrations for folks doing AI stuff with Lightning. And then, behind the scenes, there’s a BDK embedded wallet as well. I think there are some slides and maybe some posts on this. So, if folks are curious, they can check that out.

Mempool.space v3.3.0 released

Mike Schmidt: And our last piece of software is mempool.space v3.3.0 being released. There is a slew of features. We pulled out a few that we highlighted here. There’s some visualizations for taproot script trees, so you can actually visualize some of what we talk about when we’re talking about tapscript tree structures; updated PSBT previews; there’s improved fee estimation; ephemeral dust support; there’s interesting sighash icons now, so you can sort of visually identify the sighash; there’s stale block comparisons, which is helpful for understanding what happened maybe during a block race; and I think I mentioned ephemeral dust, but ephemeral dust support as well. And like I said, if you check out the release notes and some of the details there on their GitHub, you can see there’s a bunch of stuff that went into this release. So, pretty cool.

We did not have any Releases or release candidates this week. So, we jump right to the Notable code and documentation changes. And I’ll hand off to Gustavo, who was the author of this segment. Hey, Gustavo.

Bitcoin Core #29136

Gustavo Flores Echaiz: Hey, Mike, thank you so much for the intro. So, we start this week with five different items from the Bitcoin Core repository. The first one and the most significant is the addition of a new RPC command called addhdkey, that allows you to import or generate one if you don’t specify one to import, a BIP32 extended private key. However, it won’t be used to produce any output scripts. So, for example, if you wanted to add BIP32 extend private key for later use, such as in a collaborative multisig script, but you don’t want to immediately generate addresses from it, you would use this RPC command. What is useful about it is that when you export through listdescriptors RPC command, when you want to export all the descriptors and the keys from your wallet, this new key will appear through a new descriptor type called unused(KEY), so you can say back up this key that is unused for now that could later be used. Yes, Murch?

Mark Erhardt: Just to be clear, I think listdescriptors by default does not list the private key, or listdescriptors in the most common use would only tell you about the descriptors and their public descriptor portion. If you want the private keys, I think there’s a flag, and for backing up keys, just back up the wallet file. That’s the Bitcoin Core idea, at least.

Gustavo Flores Echaiz: Right. Thank you for specifying that. And yeah, I believe it’s the internal flag that is used if you want to expose the internal or external descriptors, but I’m not 100% sure there.

Mark Erhardt: Internal and external refers to whether it’s a receive address descriptor or a change output descriptor. So, Bitcoin Core’s wallet has a bit of an interesting design there. We have slots by address type. So, whenever you have a descriptor that fits into a slot, for example your P2TR slot, you will only have one of those P2TR descriptors be the active descriptor. So, usually when you add a new descriptor for P2TR, you can specify that it becomes the active one. And then, when you do getnewaddress P2TR, it’ll give you new addresses from that descriptor. But you can have any number of descriptors in a wallet. So, sometimes you might need to find out, “Okay, which descriptors did I have?”, and listdescriptors will give you a description of all of the descriptors. And so, this unused(KEY), for example, would show up if you create one to set up a multisig descriptor or a watch-only wallet, or something like that; It would show up as an unused(KEY). Internal or external refers to a change output or receive an address type.

Gustavo Flores Echaiz: Understood. Okay, so I just checked. So, yeah, there’s a private flag that you could use if you wanted to expose the private descriptors. And also, this new key added to this RPC command would show up when using the gethdkeys command separately, that also has an option for retrieving private or non-private keys. Perfect. Thank you, Murch, for adding that extra context.

Bitcoin Core #34893

Gustavo Flores Echaiz: So, we move forward with Bitcoin Core #34893, which updates the RPC command called combinepsbt, so that it properly preserves BIP174 proprietary fields. So, when combining PSBTs, previously this command would silently drop the proprietary fields without displaying that this had happened. However, decodepsbt was properly handling, parsing, and serializing those fields, so you could expect that combinepsbt was following the same logic as decode, but it wasn’t. So, now, it will make sure to always preserve those fields and not drop them silently.

Bitcoin Core #34860

Gustavo Flores Echaiz: So, another item from the Bitcoin Core repo #34860, this one is a bit of a long story. So, in short, the option called include_dummy_extranonce is now dropped from the CreateNewBlock() method. What does this mean and what is this related to? So, in Newsletter #392, we covered the addition of this option. And the problem there the goal was to solve for, when an IPC client connects to Bitcoin Core and he wants to obtain the coinbase transaction, Bitcoin Core could hand the coinbase transaction with a dummy extraNonce it had added. And those dummy extraNonces are added at heights 0 to 16 to satisfy a consensus rule related to the scriptSig length in coinbase transactions, that at heights 0 to 16 requires an extra dummy extraNonce.

So, in Newsletter #392, we covered that Bitcoin Core #32420 had added an option called include_dummy_extranonce that was set to false by default in the IPC codepath, so that when an IPC client requested a coinbase transaction, it would not include that dummy extraNonce. So, an IPC client wouldn’t have to unnecessarily receive that data and then strip or ignore that data. And it seemed fine. However, it wasn’t the proper solution. The proper solution was to always append a dummy padding or that dummy extraNonce at heights 0 through 16 and never after the height 16, and to never expose as well that extra padding in the getCoinbaseTx() endpoint that was exposed to IPC clients. So, instead of having an internal option that could either be set to true, and if it was set to true, this padding would get added at any height, and if it was set to false, it would never get added, instead of having this option that would either make it true or false at all heights, now Bitcoin Core has updated its internal logic to completely remove this option, only apply the padding when needed, which is block heights 0 to 16, and never expose it through the getCoinbaseTx() endpoint. However, an IPC client that calls getblock will receive the full block and if it’s at high 0 to 16, it will have that extra dummy padding in that coinbase transaction.

Mark Erhardt: I think if we zoom out a little bit, the important part is the scriptSig field, or also called the coinbase field in the transactions that generate the block reward, has a minimum of 2 bytes’ length, just 2 bytes. So, in order to have at least 2 bytes, you have to put first the height of the block in this field. And now, if you start a new blockchain, for example, on regtest or your own signet, or maybe another testnet or something, or your own shitcoin that is forked from Bitcoin Core’s codebase, on the first 16 blocks, or rather before the 16th block, 15 encoded as hex will take fewer than 1. Or I guess starting with 16 bytes, it’s at least 2 bytes, right? And you will naturally have a minimum length, the minimum length that is required for your scriptSig. Before block 16, you would not have the minimum length, and that’s why you need the padding.

I think the point here was that it didn’t make sense for the user to need to be aware of that. If this is the case every time for these blocks, let’s just automatically generate the padding and then not generate the padding after that. I think that’s the summary.

Gustavo Flores Echaiz: Yeah, that’s the summary. Thank you for taking a step back and presenting it in a different manner. So, yeah, just to clarify as well that if you’re using the Mining IPC interface, you will not get that internal padding when fetching a coinbase transaction when you fetch the coinbase transaction by itself, even at those heights. However, when you fetch the full block at height 0, it will appear. If it includes the dummy padding at height 0 through 16, it will be included, but not after those heights.

Bitcoin Core #31298

Gustavo Flores Echaiz: So now, the next item is Bitcoin Core #31298. Here, another RPC command is updated, called combinerawtransaction, where if you’re trying to combine or merge two unrelated transactions, it will now throw an error indicating that these transactions do not match. Previously, you were not getting an error if the transactions were unrelated, only the first one of the two unrelated transactions you were trying to merge would get returned, and it would simply ignore the second one. Now instead, you’ve got the proper behavior, where you get told that these transactions don’t match because Bitcoin Core has compared the resulting unsigned transactions’ hashes after stripping the scriptSigs and the witnesses from each transaction. Bitcoin Core can tell whether there’s an error, they don’t match, and it will properly surface that error to you. Yes, something you guys want to add?

Mark Erhardt: Yeah, I was just wondering, do you know, is combineraw used during combining PSBTs, or is it sort of a predecessor to PSBTs? Like, you would have two raw transactions where someone had signed the first input on one and someone had signed the second input on the other. And with combinerawtransaction, you can generate a single raw transaction that has both signatures. That’s how I interpret it from your description.

Gustavo Flores Echaiz: Yes, that’s it. It’s related in the sense that they work similarly, but they are two transaction types. So, it’s not a PSBT type, it’s just a hex legacy transaction type.

Mark Erhardt: Yeah, sure. But it’s sort of the predecessor to PSBT in, how do you generate a transaction with multiple users, and how do you get all the information then into a single transaction? You could do this manually, of course, if you know exactly what bytes to cut and paste, but obviously that is a lot more effort and more complicated. So, this RPC takes two partially-signed raw transactions, not PSBTs, and would take the signatures from all of them and maybe other fields that can be picked by the signers, like the nSequence, and combine them to one construct. And so, it sounds like it was buggy. If you handed it two unrelated transactions, it would just return the first one because there was nothing to combine. But now, much more appropriately, it fails because the two transactions cannot be combined. And if you call a function called combine and it can’t combine stuff, then it should throw an error rather than just return the first one.

Bitcoin Core #28802

Gustavo Flores Echaiz: That’s exactly it. So, next item #28802. This is the last one from Bitcoin Core. We are adding support for command-specific options to the ArgsManager, Bitcoin Core’s CLI arguments parser and manager. So, previously, if options were not declared to specific commands, now they are. So, for example, this PR first builds the structure to add support for command-specific options, but also applies it to bitcoin-wallet’s -dumpfile option, which is now registered only for the dump and createfromdump commands. So, for example, if you try to apply this -dumpfile option when using other commands, it will understand that -dumpfile is registered only for dump and createfromdump commands, so it will naturally return the correct message, indicating that this option only applies to these commands.

So, now, ArgsManager, the Bitcoin Core’s CLI argument parser can list the specific options that are registered for the commands. So, if you, for example, use the CLI and you want the help output, it will let you know what options apply for these specific commands. And before, it would have a more general approach; now we have a more granular approach.

Eclair #3298

Gustavo Flores Echaiz: So, the next item, Eclair #3298, is highly related to things we’ve discussed in Newsletter #400 and Newsletter #404. So, in Newsletter #400, we covered that LDK updated its internal RBF logic to be not only compliant with the BOLT2 rule around the increase of fees when replacing a transaction, but also with BIP125 replacement rules that specifically targets very low feerates. So, if you were only following BOLT2’s rule that says that you have to multiply by 25/24, which is about you have to add a 4% increase to your fee at very low feerates, that could fail to comply with BIP125’s rule, which is applied by Bitcoin Core’s relay policy. So, that happened in Newsletter #400 for LDK. Then, in Newsletter #404, it got updated at the BOLT specification level. So, now Eclair is updating its internal logic to also comply with that specific rule. And that is first to comply with, like I said, Lightning specification, but also ensure that the transaction relays properly.

I would also add, because you made some comments about this, Murch, in previous newsletters, so I wanted to circle back on this, this kind of ignores the absolute fee rule that if, let’s say, you were to increase the transaction size, you also have to increase the absolute fee, not just the relative fee. So, this doesn’t really talk about that, neither at the specification level nor the implementation level. But it is kind of implied that you would have to ensure that your transaction properly relays and not only follows Lightning-level rules, but also relay-level rules. Yes, Murch?

Mark Erhardt: I think actually the issue appears when you make the transaction smaller. If you replace an original transaction that is bigger with a smaller transaction, you might even increase the feerate, but you would potentially end up with a smaller absolute fee. And Bitcoin Core requires you to both increase the absolute fee and the feerate. So, in this case, you would potentially underpay and it would not propagate.

Gustavo Flores Echaiz: Understood, okay. Thank you for specifying that. But yeah, I wanted to say that there’s nothing about this that talks about that, but it is kind of implied that you would have to comply to ensure that your transaction gets relayed.

LDK #4575

Gustavo Flores Echaiz: Now, we have two more from the Lightning specifications. So, the next one is from the LDK repository #4575. Here, a new API endpoint called splice_in_inputs is added to allow you to manually select UTXOs when splicing funds into a channel. So, it was previously not possible to manually select UTXOs. You would have to enter an amount that you want to splice-in, and LDK would automatically select those UTXOs. Now, you can manually select UTXOs. However, the requirement is that the selected UTXOs will be fully consumed with their value, minus obviously the transaction fee, but all their value will get added to the channel and no change output will be created. So, now you can have those two different methods for splicing in funds. However, they cannot be combined or mixed, so you either have to choose one or the other when splicing in funds using LDK.

LND #10814

Gustavo Flores Echaiz: And the next item is an item that we can surface very quickly, because it simply removes some endpoints that had been deprecated way earlier. So, in Newsletter #340, we covered how LND had moved from V1 endpoints to V2 endpoints, specifically endpoints related to sending payments, SendToRoutes, SendPayment, and TrackPayment as well. So, now users are not only encouraged to migrate to the new V2 methods, but they’re kind of forced because they’re going to be deleted in the next version. However, this had been deprecated for multiple releases already. We covered it initially, like I said, in Newsletter #340 in February 2025, but now they will be fully removed. Another one that had been previously deprecated and is now removed, is the single-channel outgoing-chan-id field, that now is called outgoing-chan-ids. So, it now implies multi-channels instead of single channels.

Rust Bitcoin #6191

Gustavo Flores Echaiz: And finally, we’ve got Rust Bitcoin #6191. So, here, there’s support being added for encoding and decoding P2P messages, called sendtxrcncl. These are used in the Erlay protocol and the same support had been added to Bitcoin Core way earlier. We covered that in Newsletter #223, so that was October 2022. So, now Rust Bitcoin has parity with Bitcoin Core to be able to encode and decode these messages. However, this doesn’t mean that Erlay transaction reconciliation support is implemented. This is simply a first step that now Rust Bitcoin has done and Bitcoin Core as well. But none of those have added additional support for the Erlay protocol. And just to add that the Erlay protocol is a proposal to improve the bandwidth efficiency of relaying unconfirmed transactions between Bitcoin full nodes. And I believe a simple idea is simply for nodes to reconcile what unconfirmed transactions they have already received in order to ensure that you don’t send a transaction to a peer that already has it.

Mark Erhardt: Yeah, it just reconciles the send queues between two nodes as to the reconciliation is on the list of things they would be sending to each other.

BLIPs #42

Gustavo Flores Echaiz: Precisely. And the final item is in the BLIPs repository, we have PR #42, which adds BLIP42, also the same number, which is the specification for BOLT12 contacts. So, because BOLT12 offers are reusable payment instructions, they can be stored within wallets as contacts. So, the main goal here is to define a new field that payers can include when making a payment, that basically includes their contact secret, their own offer, or a BIP353 human-readable name that abstracts their BOLT12 offer. The protocol also specifies how wallets should implement the contacts related to this protocol, but it mostly centers around the field that the payer includes when making a payment to basically display their contact information, so receivers can add them as contact and later pay them back. But yeah, like I said, wallet behavior around contacts is also minimally defined. And that is the last item from this section, and that covers the whole newsletter.

Mike Schmidt: Great. Thanks, Gustavo. We also want to thank our guests earlier, Oliver and 0xB10C, who joined us this week. And also want to thank Murch and you all for listening. We’ll hear you next week. Cheers.

Bitcoin Optech Newsletter #406

2026-05-22T00:00:00+00:00

This week’s newsletter links to a discussion of updates to BIP322’s generic signed message format and describes an idea to use TCP hole punching to help Bitcoin nodes behind NATs accept inbound connections. Also included are our regular sections describing recent changes to services and client software and summarizing notable changes to popular Bitcoin infrastructure software.

News

● Significant updates to BIP322 Generic Signed Message Format: Oliver Gugger posted to the Bitcoin-Dev mailing list about his ideas on how to round out BIP322. As Gugger had been implementing support in btcd, he had noticed several open questions and gaps in the proposal. He proposed three major amendments to the proposal:
- Human-readable prefixes to distinguish the three signature variants.
- Inclusion of UTXO information in the “Proof of Funds” variant.
- Support for PSBT-based message signing.
After some discussion and incorporating feedback on the PSBT construction, the update to BIP322 was published (see Newsletter #405). Gugger advanced BIP322 to Complete, indicating the specification is now considered stable and ready for implementation. Since the update, it resurfaced that Coldcard had shipped support for BIP322 in March.

Projects that previously implemented support for earlier versions of BIP322 should review their compatibility with the updated specification, which introduced breaking changes including a new human-readable prefix and a revised proof of funds signature format.
● TCP hole punching for Bitcoin nodes behind NATs: 0xB10C posted to Delving Bitcoin about an idea to make more nodes behind a home router NAT accept inbound connections. The initial concept comes from the observation that setting -natpmp=1 by default starting from Bitcoin Core v30.0 did not increase the number of reachable nodes in residential ISPs as expected.

The idea leverages hole punching, a technique that allows two hosts behind certain types of NATs to connect directly, without relaying traffic through a server. The process works like this: two unreachable hosts, Alice and Bob, exchange their public endpoints (i.e. IP address and port) through a third party and simultaneously initiate a connection to each other. This creates a mapping in the NATs, allowing the hosts to complete the handshake and establish a connection. Since the proposed technique works on TCP, which requires precise synchronization between nodes, it produces higher failure rates compared to a similar technique using UDP.

0xB10C mentioned multiple approaches for an implementation using Bitcoin’s P2P protocol. A first set requires a bridge, referred to as a rendezvous server, to allow Alice and Bob to exchange endpoint information. The server could either provide a matchmaking service, to allow unreachable hosts to offer their connection slots, or it could decide to hand off one of its existing connections to another peer instead of evicting it due to a lack of free inbound slots. He also described a way to perform hole punching directly under Tor/I2P, bypassing the need for a third-party server to establish the connection. In this approach, Alice would start listening on a dedicated Tor/I2P endpoint, to which Bob would connect and start the hole-punching process.

The proposal has not been formalized yet, and many questions remain unanswered. 0xB10C asked for community feedback and invited discussion to address many open points, such as how to classify hole-punch connections, reliability of TCP hole punching, possible attacks, and implementation efforts.

Changes to services and client software

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

● Ibis Wallet announced: Ibis Wallet is an Android wallet built on BDK supporting coin control, RBF and CPFP fee management, multisig, hardware signing device integration using QR codes, silent payments, and Tor integration. It also supports optional second layers, including Spark, Liquid, and, in the future, Ark.
● LDK Server announced: Spiral announced LDK Server, an API-first Lightning node daemon built on LDK Node for payment processors and wallet providers. It provides a gRPC interface, an embedded BDK-based wallet, and a Model Context Protocol (MCP) server for AI-agent interactions with the node.
● Mempool.space v3.3.0 released: Mempool v3.3.0 adds taproot script tree visualizations, updated PSBT previews, improvements to fee estimation, ephemeral dust support, stale block comparisons, sighash icons, and a merkle-proof API, among other features.
● peer-observer P2P monitoring tooling: 0xB10C outlined some open-source components used by his peer-observer platform, including infrastructure for extracting events from Bitcoin Core nodes using IPC, logs, P2P, and RPC sources. He also describes ongoing development around archiving, anomaly detection, and alerting tools.

Notable code and documentation changes

● Bitcoin Core #29136 adds an addhdkey RPC that imports a specified BIP32 extended private key, or generates one if none is specified, without using it to produce any output scripts. This allows a wallet to store a signing key for future use (e.g. for a multisig script), without immediately generating addresses from it. The PR also adds a new unused(KEY) descriptor type, which is returned by listdescriptors, so the stored key can be included in wallet backups.
● Bitcoin Core #34893 updates the combinepsbt RPC to preserve BIP174 proprietary fields (see Newsletters #72 and #181) when combining PSBTs. Previously, combinepsbt would silently drop the proprietary fields, resulting in the loss of application-specific PSBT metadata. The decodepsbt RPC already parses, serializes, and displays those fields properly.
● Bitcoin Core #34860 removes the include_dummy_extranonce option from the CreateNewBlock() method (see Newsletter #392). Bitcoin Core now always appends dummy padding to the internal coinbase scriptSig when creating blocks at heights 0 through 16, where the BIP34 height encoding alone is too short to satisfy the consensus minimum scriptSig length. However, the padding is not included in the scriptSigPrefix field of the CoinbaseTx struct exposed to Stratum V2 clients connected through the Mining IPC interface (see Newsletter #310 and #388).
● Bitcoin Core #31298 updates the combinerawtransaction RPC to reject unrelated transactions, instead of silently returning the first one and not reporting that they could not be merged. Bitcoin Core now strips input scriptSigs and witnesses from each transaction, compares the resulting unsigned transaction hashes, and returns an error if they do not match.
● Bitcoin Core #28802 adds support for command-specific options to ArgsManager, Bitcoin Core’s CLI argument parser. Commands can now declare which options apply to them, allowing ArgsManager to list those options under the relevant command’s help output and automatically reject invalid command-option combinations. The PR applies this to bitcoin-wallet’s (see Newsletter #32) -dumpfile option, which is now registered only for the dump and createfromdump commands.
● Eclair #3298 updates its internal RBF logic to follow the new BOLT2 feerate bump rule, which is designed to ensure compliance with BIP125’s replacement rules at low feerates. Instead of only applying the previous 25/24 feerate multiplier, Eclair now uses whichever is larger: that multiplier or an additional 25 sat/kw. This matches the LDK behavior covered in Newsletter #400 and the BOLT specification update covered in Newsletter #404.
● LDK #4575 adds a splice_in_inputs API that allows users to manually select UTXOs when splicing funds into a channel. The selected UTXOs are fully consumed, with their value minus fees added to the channel, and no change output is created. This complements the existing amount-based splice-in flow, in which the caller specifies the amount to be added and the wallet selects the inputs. However, the two input selection flows cannot be mixed in the same funding contribution.
● LND #10814 removes the deprecated SendPayment, SendPaymentSync, SendToRoute, SendToRouteSync, and TrackPayment endpoints, which were scheduled for removal in version 0.21 (see Newsletter #340). Callers should use the V2 replacements: SendPaymentV2, SendToRouteV2, and TrackPaymentV2. The PR also removes the deprecated single-channel outgoing_chan_id field, requiring callers to use the multi-channel outgoing_chan_ids field (see Newsletter #33).
● Rust Bitcoin #6191 adds support for encoding and decoding the sendtxrcncl P2P message used for Erlay transaction reconciliation. Bitcoin Core added support for this message as an early part of Erlay support (see Newsletter #223). However, full Erlay transaction reconciliation is not yet implemented.
● BLIPs #42 adds BLIP42, a specification for BOLT12 contacts. Since BOLT12 offers can be reused as static Lightning payment instructions, wallets can store offers as contacts. The BLIP defines optional invoice_request fields that payers can include when making outgoing payments to a contact, such as a contact secret, their own offer, or a BIP353 name. This allows recipients to recognize payments from known contacts, add new contacts, and send funds back to the payer without additional interaction.

Bitcoin Optech Newsletter #405 Recap Podcast

2026-05-19T00:00:00+00:00

Mark “Murch” Erhardt and Mike Schmidt are joined by Fabian Jahr to discuss Newsletter #405.

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

Download audio

News

● Bitcoin Core script interpreter remote crash disclosure (22:00)
● BIP proposal for UTXO set sharing over P2P network (0:42)

Releases and release candidates

● Core Lightning 26.06rc1 (34:58)

Notable code and documentation changes

● Bitcoin Core #35209 (36:44)
● BIPs #2116 (38:20)
● BIPs #2141 (44:13)
● Core Lightning #9116 (48:35)
● Core Lightning #9110 (50:27)
● LDK #4598 (52:10)
● LDK #4528 (53:30)
● LND #10612 (54:37)
● BTCPay Server #7354 (57:12)
● BDK #2195 (58:10)
● Bitcoin Inquisition #100 (1:00:00)
● BINANAs #20 (1:02:42)

Transcription

Mike Schmidt: Welcome to Bitcoin Optech Recap #405. This week, we’re going to talk about a disclosure of a Bitcoin Core security vulnerability; we also have a News item talking about a draft BIP for sharing the UTXO set over the Bitcoin P2P network; we have a Core Lightning (CLN) RC; and we have our weekly Notable code and documentation segment. This week, it’s just Murch and I, and we are joined by one guest, Fabian. Fabian, you want to introduce yourself?

Fabian Jahr: Yes. Hi, I’m Fabian, I work primarily on Bitcoin Core and some Bitcoin protocol ideas, and yeah, I’m sponsored by Brink.

Mike Schmidt: Thanks for joining us. For our listeners, we’re going to just go slightly out of order. We’re going to do Fabian’s item first, which is titled, “BIP proposal for UTXO set sharing over P2P network”. Fabian, you posted to the Bitcoin-Dev mailing list about a draft BIP for sharing the UTXO set using Bitcoin’s P2P networking. The goal, well maybe you could talk a little bit about the goal, but the goal would appear to be to improve the assumeUTXO feature by letting nodes receive the UTXO set from peers, rather than having to go download torrents or going to maybe some other websites. Maybe you could talk a little bit about the status of assumeUTXO, and how you think that this BIP could make assumeUTXO even better, and how that relates to end users and the impact?

Fabian Jahr: Yeah, sure. So, first of all, this idea of having a way to share the UTXO set over P2P was basically part of the initial proposal for assumeUTXO right from the start. However, it was kind of deemed to be a little bit out of scope for the first version of including assumeUTXO in Bitcoin Core. And so, that part was deferred. And then overall, like sometimes it happens, the assumeUTXO project took quite a long time, and by the end, much the primary developer, James O’Beirne, left Bitcoin Core and stopped mostly contributing to it. So, it actually took quite a bit of additional time to refactor the code a little bit, iron out some bugs, and then it was actually made usable on mainnet. There was a period where it was only usable on testnet in between. And since then, the assumeUTXO feature is out there, it is usable. It, I think, was not adopted as quickly or as widely as I personally expected and some other people expected, I think. So, my personal go-to project that I think of basically is these pre-packaged nodes, like an Umbrel, Start9, RaspiBlitz. For those to get started quickly, this is something that is very helpful, especially if you have limits in terms of bandwidth or the hardware that you’re working with. This allows you to just get started a lot more quickly, which is typically something that users would like to see. We always say patience is a virtue in Bitcoin more or less, but a lot of people are not that patient, either because they don’t want to or because they actually have economic incentives that cause this.

So, for example, Start9 has it implemented. Many others have this out as a feature request and see it as something that they would like to do, but they just haven’t gotten around to do it. And part of that is the availability problem. You need to get this UTXO set dump from somewhere. If you have a full node, it’s a simple RPC call that allows you to generate this. On a more or less modern computer, it takes something like 15 minutes or so to generate this, and then there’s several sources that allow you to download it from some websites, and there are torrents available to get to it. However, these are single sources that are somewhat trusted and especially, if you just download a huge file from just any website where you don’t know who controls it, it could get away at any moment, it’s kind of hard to build on top of that. And I think that contributed to the fact that this feature isn’t used as widely as it should be.

So, this has been on my extended to-do list for quite a long time, to explore this and see what the protocol could look like to make it available to get the UTXO set through the P2P network, like originally it was envisioned; and this way, make it basically just as easy as have a startup parameter for Bitcoin Core to get started with assumeUTXO. That’s basically the outline and how it relates to assumeUTXO. However, the proposal itself, while assumeUTXO is the main motivation, it doesn’t really talk about assumeUTXO, so it’s a little bit of a weird situation right now, where I’m mostly facing feedback that is just feedback on the assumeUTXO itself, and not so much the proposal that I’ve actually written up.

Mike Schmidt: How much data are we talking about? What is a relatively recent size of a UTXO snapshot?

Fabian Jahr: It’s about 10 GB.

Mike Schmidt: Okay. And so, this would involve, well, I guess there’s two approaches. There’s the approach that you outlined, but I think Antoine Riard suggested maybe building on top of the peer feature negotiation, that I believe AJ is working on. So, how do you think about deployment in either of those scenarios?

Fabian Jahr: Yeah, so this is one question which is an interesting question to me, but it has kind of gone into the background almost because of all this other conversation on the assumeUTXO. So, right now, the BIP includes a signal via service bit, and the nice part of this is that it allows you to easier discover which nodes on the network actually have this feature and connect to them, and then you can actually get it to them. And the alternative would be to build it on top of a BIP434, where you first have to connect, and only then you discover that this node actually has this feature enabled. So, there’s ups and downsides to it. I think we’re a bit sparse of how we want to use service bits. So, that’s why I can understand that there’s a bit of a pushback on the usage of the service bit for something that, I guess so far, not that many people are completely convinced that we need it. And BIP434 is definitely interesting. So, I would say I haven’t made a final decision yet, and I’m definitely looking for more feedback there.

But there’s also a bit the question of, like, what’s going to be the availability guarantees of these UTXO sets? So, for example, with the assumeUTXO right now, we have these snapshots that we put into the binary, but also there’s the idea of a node could keep always, for example, just the UTXO set from 1,000 blocks ago, or whatever, and always could have that, something like that. And that would be then ideally secured as well, that this is one of the nodes that can provide this. And this is something where definitely, I think BIP434 would be ideal to show this. If it’s been discovered that this is a node that has snapshots that it’s serving, this way it can then, after connecting, signal that it has these very recent ones as well. But I’m kind of proposing right now that this is not something that I would specify in the current BIP draft, but rather I would put it into an extension of the BIP.

Mike Schmidt: Now, I think we’ve talked so far about what I think you intended to talk about on the mailing list, but you mentioned the discussion has sort of spawned around assumeUTXO more generally. Maybe we can get into that. What have people brought up in terms of assumeUTXO specifically, as opposed to this particular proposal?

Fabian Jahr: Yeah, I think there are two broad categories, I would say. So, first of all is about the trust model. That’s particularly something that Eric Voskuil, for example, has brought up on every channel, but particularly on the mailing list is where we have actually had a conversation on it. And his opinion is that assumeUTXO is trusted and nodes should not use it basically, because whatever you want to do with your node, it’s not safe to basically rely on the trust model that assumeUTXO has. And his counterargument is that syncing IBD (Initial Block Download) doesn’t take that long. I think his perspective is from a perspective of having better hardware available, having very good bandwidth. I think that came out in his arguments. And of course, Libbitcoin is very much optimized for this kind of environment, where you have, for example, 32 GB RAM is kind of the minimum that they assume, and US-level consumer internet connection. And so, for this scenario, it’s of course then debatable if you would still need it, if you can do IBD within a couple of hours.

But I think the reality is, and that’s my counterargument, is that lots of people in the world don’t really have this availability of that many RAM, of that internet connectivity. And they still may want to get started faster, especially if IBD takes one or two weeks for them on their hardware with the bandwidth that they have available. And in these cases, assumeUTXO can help them a lot and they can get started quicker. And this is also something that is highly motivating for if you, for example, want to convert a shop to run their own node. And this is why, for example, BTCPay Server is one of these projects that has even done their own assumeUTXO version. Basically, they call it Fast Sync and it’s been around even before assumeUTXO, because in order to get a shop converted to run their own node on a Raspberry Pi or so, you kind of have to give them an experience that is similar to, I don’t know, some block terminal, or whatever that you would usually use. It’s just not so easy to tell them like, “Okay, you just have to wait a couple of days and then it’s ready, and then you come back to it”. So, this is the one string.

The other string is on the PR itself, so that’s more of a Bitcoin-Core- specific conversation where, this was kind of new to me, but a couple of people really don’t like assumeUTXO as part of the Bitcoin Core project. They say that it’s causing quite a bit of headaches, in terms of the work that they are doing there. And there’s more of a general sentiment against assumeUTXO, which then extends to, does this need to be added on top of it into the repository?

Mike Schmidt: Is part of the latter objection related at all to this proposal for SwiftSync that is being worked on, that could result, in I guess I’ll just say it, Libbitcoin-like IBD, aka just sort of faster and thus obviating the need for assumeUTXO; or do you think the objections to assumeUTXO are independent of that work?

Fabian Jahr: At least I haven’t seen it come up in the conversation at all so far, so it’s not an explicit counterargument definitely. And then, I haven’t really read up on the latest proposal, but from what I’ve seen in terms of like a triplet of BIPs that are being proposed to basically fulfill the promise of SwiftSync, and part of that proposal is sharing the undo data over P2P. And that would be a lot more data to share than would be the UTXO set to share. And it’s also not something that can be validated if you want to actually have this speed-up. So, you have a lot of undo data that is then sitting there. You have to send it over the network, but you haven’t validated it. But you may still use it for rolling back blocks, for example. And so, that to me doesn’t really strike me as a great trade-off, but I don’t want to judge it. I think it’s still a very interesting idea and I think there’s also potentially ideas to combine it with assumeUTXO if that were to get enough interest. But yeah, I think especially the counterargument, or many of the counterarguments that I’ve been hearing on assumeUTXO or the proposal would also apply to this latest version or to this triplet of the BIPs that I’ve seen, as far as I understand them.

For example, an argument I’ve also had a couple of times, although I would say this is not one of the more forceful ones, is that there is an additional requirement for downloading data. So, if you have a problem with syncing the 800 GB of data overall, then you add 10 GB to it on top. “How is that an improvement?” was one of the critiques. And then, this undo data sharing, I think, would of course make this counterargument even bigger.

Mark Erhardt: With SwiftSync, you still download the entire blockchain, right? You just process it more quickly, because you don’t actually write out the UTXO set while you’re syncing. So, actually, if the bandwidth amount is a blocker for you, SwiftSync will not solve the problem. But with assumeUTXO, you would immediately have a usable node, even if it then takes you weeks to download 800 GB in the background to actually sync yourself up. So, I think that you can actually make a stronger case here that assumeUTXO is more compatible with low bandwidth than SwiftSync, if you have a limit on how much you can download, rather than the speed. Yeah, I would say I would characterize it as the SwiftSync still scales quite a lot with the available bandwidth and with the hardware that you have, and also, over time, it will necessarily still take longer because there’s more blocks to sync; whereas with assumeUTXO, you have, depending on what kind of structure you use, but if you, for example, take this more advanced BIP extension that would be possible, then you would max sync something like 1,000 blocks or so, or you would sync 1,000 blocks, and then you are basically ready to start with your assumeUTXO data set load.

Mark Erhardt: Right. So, you would always basically onboard in constant time, and then your security model would change over time as you process the blockchain in the background. Whereas with SwiftSync or regular IBD, you would have to download and process the entire blockchain first before you’re up.

Mike Schmidt: What about this idea that I think I saw from Josie this morning? I think he said something like, “Hey, why not just put it in, or have it downloadable as part of the executable, or download it from the same place where you get your Bitcoin Core binary? I think he said something along those lines. Do you have thoughts on that, other than it being a very large download?

Mark Erhardt: I think it would be a very different server plan that we’d need versus serving a 10-MB or 5-MB binary to serving, what is it now? 700, 800 GB of blockchain from a website. So, maybe the torrent, magnet but I think that’s already available. Maybe you can correct me on that, Fabian. But yeah, serving 800 GB of data from a website is a very different proposal than just serving the binary.

Fabian Jahr: Yeah, torrent downloads are available certainly, and I think some people use that. And I’m not sure if many people want to install the torrent client on the computer that they use as their node. I think that’s the main issue I have with just saying, “Okay, we only rely on this”, or, “This is the recommended way to do it”. Having some Bitcoin Core download site where you can get the UTXO set, I think a lot of people would like that and they would probably accept it. I’m not sure if Bitcoin Core wants to do that and wants to carry that responsibility. I think there’s a certain issue with privacy and with regards to having such a server, and also servers are hackable. You never really want to make very transparent who has these keys. So, there could also be malware hidden behind these files. That is just something where, yeah, the main motivation or one of the main motivations for me to do this is that I think ideally, we would not want to have this responsibility rest on one person’s shoulders. And that’s why I think it’s not great.

But I think, yeah, if somebody wants to do this on Bitcoin Core, someone on Bitcoin Core as a project wants to do that, I certainly don’t want to maintain that server. But if somebody wants to do it, I think people would like that and it would probably help this adoption. There’s other websites, centralized websites from people that are more or less anonymous where you can download them.

Mark Erhardt: So, just to clarify, currently as implemented, assumeUTXO will only accept a UTXO set that commits to a specific hash to the UTXO set? So, even if some random party were to serve the UTXO set data, if it doesn’t match byte-for-byte with the expected data, you could at best waste the downloader’s bandwidth; they would not import it? So, just to clarify the trust assumptions there around the data that is being consumed.

Fabian Jahr: Yes, that’s correct.

Mike Schmidt: Fabian, as we wrap up this item, maybe you can give the audience some calls to action. Obviously, there’s the mailing list post, there’s the draft BIP that people could take a look at. What else would you encourage people to do, or feedback that you’re looking for?

Fabian Jahr: Yeah, so the mailing list, the BIP and the Bitcoin Core PRs are all open and I’m very much looking for feedback. I think it will be very much interesting to hear both if people like the idea of adding it, or don’t like the idea of adding it. I think one question that was raised where it’s hard to actually give a clear answer is usage. So, I think it would both be interesting if people speak up that say, “Okay, this is something that would be helpful, or would have been helpful for me when I started my node”, or, “I actually started my node with assumeUTXO”, or, “I recommend to other users to start a node with assumeUTXO because of these circumstances that we’re living under”. So, that, I think is something that, because Bitcoin Core doesn’t track any usage and the assumeUTXO is not on the P2P network yet, so we cannot really see nodes offering it or using it, that’s a question that is very hard to answer and where people have raised doubt about the usage. And so, that would be interesting to hear.

Otherwise, we didn’t really talk much about the content of the proposal, but I think it’s a comparatively simple BIP. Honestly, I was a bit surprised of how simple it was when I wrote it. That was also part of the motivation for me to do something where there’s new message types being defined, something that I hadn’t done before. And so, if you want to read something that is a BIP with new message types, but it’s still a quick read, I think it’s like 250 lines, I think that’s something that is interesting to review. The core PR as well, even if there’s quite a lot of conceptual questions being raised about it right now, it’s a very self-contained piece of code. So, if you are interested in reviewing something like that, that’s also I think interesting to check out for people that are interested.

Mike Schmidt: Fabian, thanks for joining us. We appreciate your time. You’re free to drop.

Fabian Jahr: Thank you very much. Cheers.

Bitcoin Core script interpreter remote crash disclosure

Mike Schmidt: We’ll jump back up in the newsletter to the first News item titled, “Bitcoin Core script interpreter remote crash disclosure”. And there was a post to the Bitcoin-Dev mailing list by Niklas, announcing the responsible disclosure of CVE-2024-52911, which is a vulnerability affecting Bitcoin Core versions 0.14 to 29 and before 29.0, so after 14 and before

Murch and I are going to riff a little bit on this bug. We don’t have Niklas or Cory who was the one who discovered and disclosed it here, so we’ll try to explain it for you all. But the bug is essentially when Bitcoin Core is validating a block, it speeds things up by doing multiple script checks in parallel using background threads. And in order to do that efficiently, it pre-computes some data related to the transaction, and then shares it across those different threads that it’s spawned. And then, the vulnerability was that that shared pre-computed data could be cleaned up and freed from memory before all of those threads, who may be using that data, had actually finished using it. And then, the effect is for a specially crafted block that could cause a background thread to try to read memory where it thought that that data was, and it had actually already been released. And this is known in computer science as a use-after-free bug.

I’ll pause there to get some input from Murch, and then there’s a few different things we can talk about based on this.

Mark Erhardt: Yeah, so so far, I fully agree. The important caveats here for this bug were that it required an invalid block to be constructed. So, the block would not be accepted by the network. It required the proof of work to be valid in order to get to the point where this bug would be triggered. So, what made the block invalid, I think, had to be in a very specific script check. Then theoretically, because the data would get read after it was released, you would be able to craft this invalid block, and then put in that very specific spot that would be read by a script after it was freed, a remote execution code. But that, I think, would have had to pass as valid transactions or at least well-formed transactions before. So, the likelihood that that could actually be used in that way was considered low, but you could definitely crash a node that encountered that, if you constructed a block specifically to do so. And you had to spend the proof of work for a valid block.

Mike Schmidt: Yes, so instead of crafting a valid block, you create one essentially to crash other nodes, would be the point. And so, I suppose if I were an attacker and I knew about this and I wanted to do this, I would, I guess, connect to as many nodes as possible, including maybe well-known mining related nodes, waste my proof of work on an invalid block such that I take down a large – because obviously, those blocks aren’t going to propagate on their own, especially because the nodes are going to crash. So, I need to have connections to all these people to send them these blocks, right? And then, I send out these blocks, a huge percentage of the network goes down. Maybe I’m a minor and my competitors go down, and now I maybe have some time while they’re getting their operations back to mine freely. Is that sort of the idea?

Mark Erhardt: I think because blocks are forwarded before they’re processed complete. Well, actually the transaction itself would be invalid, right, so it would probably not be eligible for compact block really. So, yes, you would have to probably serve the block directly to all the nodes you want to crash, because they crash when they process it and wouldn’t forward it directly, because they only forward blocks for which they have all transactions. So, yeah, this was classified as a high severity bug. The disclosure policy of Bitcoin Core is such that they distinguish four different levels of vulnerabilities. Low severity is disclosed two weeks after the first fix is released in a major version, and medium and high are disclosed two weeks after the last affected version goes end of life. That was the case here. This high-severity vulnerability was disclosed two weeks after v28 went end of life with the release of 31. Bitcoin Core always maintains the last three major versions. 28.x was up for end of life when 31.0 was released.

For critical, the fourth class of vulnerabilities, the process is ad hoc, they are more severe, and usually require specific handling, either immediate disclosure for people to update, or later disclosure because they might affect other networks too. So, anyway, yeah, that was disclosed because 28.x is end of life. And the point of these disclosures is (a) that people should be aware that software has bugs and we want to dispel the illusion that software is flawless, that Bitcoin Core is flawless, and (b) it allows everyone to learn from the bugs and it incentivizes responsible disclosures by the people that disclose the bugs getting credit for it. Did you have more on this?

Mike Schmidt: Yeah, I wanted to just maybe articulate the timeline and weave that into what you’ve sort of outlined here. November 2nd, 2024, the bug is reported privately, I assume on the security mailing list that anybody can disclose a bug to. Within a couple of days, there was a fix opened in a PR, and less than a month later, that PR was merged. Based on Bitcoin Core’s release cycle, that December merged PR didn’t make it into a released version until Bitcoin Core version 29, which was in April of 2025. And then, when the last vulnerable version went end of life, that was April of this year, and then within a couple of weeks, the public disclosure was made, which was basically a week and change ago. And so, when I’m looking at that timeline, it seems like everything was kind of done almost as soon as it could have been done. There was a couple of days and then there was a fix, and then a month later, it merged. It went into the release that was upcoming and it was disclosed right after that version went end of life.

So, I see some people talking on social media about how there’s some conspiracy here or they’ve known about this for 18 months, or whatever the figures are. I guess the criticism can’t be in the way that this specific bug was handled, and it would have to go towards, “Hey, the disclosure policy should change”, or, “Bitcoin Core should somehow support more versions than just the last two”. And that’s where I guess criticism could be directed, although there’s of course objections to changing those as well. Does it make sense, Murch?

Mark Erhardt: Yeah, maybe just on the release schedule, again, people have been claiming, “Oh, there’s faster releases in Bitcoin Core now”, or, “The disclosures are trying to make people update”. I think there is an element here that is definitely, the public is informed so that they can use this information to make their decision whether or not to upgrade. But the disclosure follows exactly the disclosure policy. And in case you haven’t noticed, the Bitcoin Core releases are on a fixed schedule. There’s always a major release in April and in October, and they haven’t gotten faster. The major releases of course contain new features, and then any minor releases in between only contain bug fixes or backwards for consensus updates, if any are adopted. So, the release cycle is fixed. The disclosure policy is public and has been followed to the dot here. So, I also would push back on the conspiracy theories here.

Also, just a small correction. So, we currently maintain three versions. So, this is 31, 30, and 29.x, the major branches after 29.x was released in spring last year, I think April last year. It’s now getting minor releases still. 28.x, as you said, was released in October 2024, about one-and-a-half years ago. So, when this April 31.0 came out, 28.x had been declared end of life. And up to that point, it was considered maintained and was still getting updates with minor releases.

Mike Schmidt: And obviously, instead of just two older versions and one current version, you wanted to support three or four older versions, obviously there’s a lot of work that would go into doing that. You would double the amount of work you’re doing at least. And in some cases, probably it’s harder to go back and fix some of these vulnerabilities without it being more obvious. Are those the two factors? There’s the manpower and then there’s the difficulty in security vulnerabilities in terms of backporting them. Is that the considerations that go into why not support 10 versions back, like people seem to want?

Mark Erhardt: Yeah. Backports generally mean that you have to make a fix work in the reality of half a year, a year and one-and-a-half years ago. So, if the code changed in the area of where the fix is introduced, that can increase the overhead significantly. And then, because the patch is applied to a different state of the codebase, it requires fresh review. And I think the review burden on the back ports is part of it. And then also, if you were to maintain more versions, the window for the disclosures would probably have to be longer, because the maintained versions should probably not have disclosed bugs. So, not only would you have to propagate back to the undisclosed bugs further, but you would also disclose them more slowly. And one of the criticisms is that the disclosure policy is already giving a lot of time until some of the bugs are disclosed. In other types of software, it is common for bugs to be disclosed within 90 days. But Bitcoin Core does not do this, because the ecosystem updates much more slowly to new versions of the nodes. I think there’s maybe barely 20% to 30% of all nodes are on the latest major version at any time, at least of the Bitcoin Core nodes. So, if we disclosed much more quickly, we would basically force users to run the newest version much more quickly, and I think that is not intended.

Mike Schmidt: And of course, there’s no auto-update feature, which is unspoken, but probably known by listeners why that’s the case. Anything else on this item, Murch? Okay, we will jump to Releases and release candidates.

Core Lightning 26.06rc1

We just have the one, Core Lightning 26.06rc1. This week, this is the first RC for this next major version of CLN. There are a few key changes that we outlined. Obviously, anyone using CLN wants to jump into the release notes, there’s a nice change log that outlines everything. We did call out some new RPCs. One is this graceful RPC, which is a graceful shutdown for CLN nodes, which allows a bunch of in-flight operations to complete before stopping. There is a sendamount RPC. I think we may get to it later in the Notable code segment, but the ability to pay an invoice but lets you specify the total that you want to spend with the routing fees included, rather than paying an invoice and discovering that the final cost after routing fees are added on top, which is a little bit different.

They’ve also, in CLN, started the deprecation cycle for the pay RPCs, and they’re moving to xpay, which has already been around, but they’re moving to default to xpay and slowly deprecating the pay set of payment invocations. And then, there is another item that we highlighted, which we cover later in the newsletter, which is BOLT12 payer-proof RPC support. And we’ll jump into that when we get to that PR. But obviously, if you’re a CLN user, take a look at this, take a look at the release notes and give the team feedback before it gets released.

Bitcoin Core #35209

Notable code and documentation changes. We do not have Gustavo with us this week, so Murch and I are going to sort of jump back and forth. We sort of grabbed a handful each, and we’ll iterate back and forth on these. We’ll start with Bitcoin Core #35209.

Mark Erhardt: Yeah, so this one covers the overt fix for the bug we just discussed at the beginning, or rather after Fabian’s item, the overt fix of this data being available to be read, or it being possible for the data to be read after it was freed up. The covert fix had been that the early exit that enabled that was prevented and the function always ran to its end. The overt fix here is that the data is constructed in the correct order so that any reads would not be able to access the freed-up data anymore, because the data is correctly destroyed and detected to be destroyed after it’s freed, and cannot be read anymore. So, this is basically the cleanup for the covert fix from 29.0.

Mike Schmidt: So, doing it the right way because it’s already public that this vulnerability is out there. So, you don’t need to shim in some, I guess, less straightforward way of doing it.

Mark Erhardt: Yeah. Basically, the covert fix had been there for this whole time in order to prevent that the data can be read after it was freed up. But now that the bug has been disclosed, they went back and cleaned it up in the proper way so that the data cannot be read after it’s freed up in the first place.

BIPs #2116

For the next one, we have an update to the BIPs repository. This is BIPs #2116. BIP #2116 publishes BIP323, “24 nVersion bits for general purpose use”. So, as some of you might be familiar, we don’t really use the version field on blocks for the intended purpose very much, only versions for 0 through 4 are used at all. And I believe version 4 actually indicates that some of the bits should be read as signals to be ready to enforce a new soft fork. This was defined in BIP9 and an alternative interpretation was offered by BIP8. So, recently, we have been seeing that some miners had started rolling nTime again. As you might know, the nonce field in the block header is 32 bits and 32 bits only gives you something like 4 billion possible iterations on the same block candidate until the nonce field is used up. So, in order to continue to use the same block template, just with different headers, this had been changing bits in the time field, which then would cause the times to be a little shifted from the actual time that the miner was processing a block candidate.

The idea behind the BIP323 is an extension of BIP320, where we had already a proposal to use 16 bits of the version as extra nonce space, where you could increase the entropy of the block header by just putting random data in half of the version field. It expands that to 24 bits now, which then would give a total of 56 bits of entropy to the block header, which is equivalent of being able to do 72 petahashes, 72 times 10^15 candidates – sorry, I should be specific. So, you make one block template that has all the transactions, and you especially have a coinbase transaction that pays you in your block template. All the rest of the transactions might be the same as another miner, but your coinbase transaction makes the block template unique to you. And now, you need to iterate over block candidates, which are different in some manner, because as soon as you change at least one bit in the block, you will get a different result for the hash and may get a low enough hash to produce a valid block. So, in order to iterate over as many as possible block candidates for one block template, so you don’t have to change anything about the transactions in the block, you want to have a lot of entropy in the block header. Baked into the block header is the nonce field, which has 32 bits, or 4 bytes, and that only gives you 4 billion different attempts, which is only like 3 megahashes per second. And that is obviously not even enough for a laptop. And with the additional 24 bits that are now proposed to be usable for extra nonce space in the version field of the header, you would have a total of 56 bits that you can flip and flop in every direction. And that would allow you to do 17, what is that? Quintillion, quadrillion? 72 quadrillion block candidates per second. So, you would only have to update the time stamp on the block once you’ve gone through those. I think the most powerful ASICs are somewhere around 20 petahashes at this point. So, at this time currently, you would no longer need to time-roll at all if this BIP got adopted. Okay, now I think I covered it.

Mike Schmidt: I have a question. So, the reason to not roll nTime, or to avoid it, is obviously not a performance thing, the performance will be the same regardless. It’s just more that by rolling that, that timestamp moves in a way that is away from potentially reality and you might get into trouble there, whereas when you’re rolling the version bits, there’s not really any harm in that drifting around.

Mark Erhardt: Yeah, not really any harm, it’s just weird. It might lead to odd effects such as a block being found before its predecessor, according to the timestamp; or if it were applying to the last or the first block in a difficulty period, it might slightly shift the difficulty adjustment for the next difficulty period. Generally, it would just be neater if the time matched as closely as possible to the wall clock time. Yeah, we’re very lenient in what we accept in timestamps for blocks. So, they can generally be up to one hour in the past and two hours in the future. So, it shouldn’t really create any issues if you do nTime-rolling, but having a dedicated space where people expect random numbers would be cleaner and lead to more expected timestamps.

BIPs #2141 and BIPs #2155

All right. Actually, it’s still me. We have more BIPs work. Next item is about the BIPs PRs #2141 and #2155. Some of you might remember the BIP322 generic signed message format, which was proposed in 2018, eight years ago. So, the old style of message signing had only ever been properly defined for P2PK and P2PKH outputs. So, if you wanted to prove, for example, that you owned a specific output script and wanted to commit to some message as the owner of some UTXO, you could sign a message with the previously defined signed message format for legacy outputs, and people could verify that you actually were the owner of that UTXO. This has been considered a useful building block for numerous things, such as, for example, committing to having funds for, I don’t know, Lightning channels, JoinMarket, or other constructions. But also, people had been worried about it being used for KYC or for people demanding to learn what your UTXO pool might be. So, either way, it got a little pushback back then when it was proposed and there was still some unaddressed feedback and a bunch of open questions. It lost steam at that point.

This year, someone picked it up back up. Oliver Gugger took a good new look at it, fleshed out the proof-of-funds construction that can be used to show or to prove a UTXO pool or a single UTXO, and also he built out the signature format and protocol for all types of UTXOs. So, this is generic. If you can sign for a transaction, you can also sign a message for the same UTXOs now. This update to the BIP has some breaking changes. First, it adds a human-readable prefix to the signed message format. Two, it changes slightly how the proof-of-funds construction works, if I remember correctly. And then, it adds PSBT for allowing people to sign messages together. And it adds a new reference implementation and a bunch of test vectors. This BIP has now also been moved to complete. As a reminder for BIPs, the BIPs workflow is that first you have an idea, you propose that maybe to the mailing list and discuss that with other interested parties. Then you write up a draft. The draft means that you have formalized the idea well enough that you can completely, comprehensively describe it, and it is published to facilitate a broad discussion in the ecosystem. And then, when your planned work is finished and you feel that the proposal is ready for adoption by the ecosystem, you may move it to complete in order to propose it for adoption.

So, the authors of this BIP now think that it is ready to be adopted. So, people that are interested in signing messages with any types of UTXOs should maybe take a look. I know that there are a bunch of other projects that have been using their own constructions to do so. It would be great if the developers of those projects took a look at this BIP and check whether it satisfies their needs and whether they had any feedback before it gets too broadly adopted to make it hard to change things about it.

Mike Schmidt: Yeah, I know there’s been a lot of community interest in something like this over the years, and people have rolled their own, people have just not done certain things because this wasn’t available, so I think a good chunk of people will be happy to see this in complete status.

Core Lightning #9116

We’re going to cover some Lightning PRs now. Core Lightning #9116. This is related to the RC we talked about earlier as experimental BOLT12 payer proof support, and that is actually something that is in a draft BOLT right now, it’s in BOLT #1295 as a PR. And maybe some context what this payer proof support is. For example, when you have BOLT11 invoices, a payment preimage by itself can prove that a payment was made, but it doesn’t prove who made that payment. BOLT12 payer proofs go a little bit further and allow a payer to cryptographically show that they’ve specifically are the ones that authorized payment. And this is useful for disputes or subscriptions or audits, or any situation where a merchant or a counterparty needs to verify, “Yes, this specific party was the one that paid this specific invoice”. And you can jump into the details, but the payer proof allows a payer to demonstrate that they were the one to pay it. There’s a couple of pieces of information. There’s the payment preimage, the node signature, payer signature. And so, look at the details there.

But I think the interesting piece is that there are selected invoice fields that can be omitted for privacy reasons. So, you have this proof, but you’re not giving up too much privacy-related information. And so, this PR is a draft and experimental implementation of that payer proof support. And so, there’s some common functions for creating and validating these sorts of proofs under the bolt12-cli. But I will note again that this is experimental and it may change. But this is in that RC that we mentioned.

Core Lightning #9110

Core Lightning #9110. This is a fairly substantial PR. Looking at it, it had 43 commits, 4,900 lines of code added, and 3,000 removed. So, this is a meaningful piece, and you’ll see why. This has to do with the deprecation that I mentioned in CLN of the older RPCs for payments. So, the pay RPC, paystatus, keysend, getroute, renepay, renepaystatus are all moving to deprecated state. And there’s a phased deprecation. It looks like it’s starting in this 26.06 that we spoke about, and then removal scheduled for 27.03. So, that would be next year in March-ish. And so, not only there’s the deprecation of those existing RPCs, but then there’s these xpay and xpay-related RPCs that are sort of being, I guess, defaulted in. And maybe a question might be, why are they getting rid of pay and moving to this xpay? I think xpay, other than being newer and not having a lot of the legacy below it over the years, it was also written from scratch to be multipath-native. It uses that renepay routing, probabilistic routing that we’ve talked about previously in other podcasts, although I don’t have those podcasts handy. Look for where we spoke with René Pickhardt, you can get some details on that.

Yeah, so you can see they’re overhauling how they’re handling some of their core RPCs and defaults and deprecating. So, that’s why there’s so many commits it seems.

LDK #4598

Switching to LDK, we have LDK #4598. This is a bug fix in the component in LDK that’s responsible for sweeping funds back to a user’s wallet after a channel closes. This could include time-sensitive things like HTLC (Hash Time Locked Contract) outputs that have deadlines for being claimed. Previously, the code in LDK used a flag to prevent two sweep attempts from running at the same time. But the problem was, if a sweep was canceled in the middle for whatever reason, rather than completing normally, that flag actually never got cleared in certain situations, which means with that flag being stuck, then every subsequent sweep would then quietly do nothing. So, the node would just keep queuing these outputs to sweep, but none of them would actually get processed because that flag was still set. It would actually restart, it would reset that flag when the node itself was restarted. But as you can see, that could potentially result in issues, because some of those HTLC outputs with deadlines could expire while the node was just appearing to function normally, and that can result in fund loss. So, fixing this PR ensures that that flag is always cleared, regardless of what happens during a different sweep.

LDK #4528

LDK #4528 makes a change. This is related to metadata that could be included in an invoice. So, some BOLT12 invoices include this optional metadata fields that the recipient attaches, that they expect to see sort of echoed back or mirrored back to them when the payment actually arrives. And previously, LDK didn’t enforce that that payment actually carried the same metadata that the invoice specified. And that means that a sender could silently or maliciously, or whatever, drop or alter that metadata without the recipient knowing that. And LDK essentially made a change now that it verifies that that metadata matches. And I think there’s an opt-out for compatibility with older senders.

It was noted, I would encourage LDK users to look at this PR. There’s some notes about compatibility, like when you’d be upgrading and things in flight, and whatnot. So, I would encourage users to take a look at that to make sure that when you upgrade, you sort of know what might be happening here in terms of a compatibility perspective.

LND #10612

LND #10612. This is an addition to LND in that LND can now find a path for onion messages through the network, and so it can fully initiate onion message start to finish. Whereas previously, LND would only forward onion messages that it got from other nodes, but it couldn’t actually originate onion messages itself, because it didn’t have a way to create a route to the destination without it being handed to them from some external source. This is obviously nice for things like BOLT12 offers, which rely on onion messages, so it’s good to see that. I think the only other note I had on this one was that, yeah, so the pathfinding that they’re using obviously doesn’t use anything related to fees or liquidity like you normally would use for binding. It’s just about reachability, because you’re just routing these onion messages, not actually value. Yeah, Murch?

Mark Erhardt: Question. So, graph-based pathfinding, does that refer here to channel network? Because I think that onion messages can also be forwarded to other Lightning node connections, where the two peers don’t necessarily have to have a channel open. But here it sounds like graph-based might follow the channel network. Do you happen to know?

Mike Schmidt: I don’t think so. My understanding is that LND will search the graph for nodes that advertise onion message support and then construct a route to the destination automatically based on that. So, it doesn’t appear that it has to be related to having a channel.

Mark Erhardt: Right, but then a node would know its own peers, of course, but hopefully would not know the peers of other nodes. Maybe the first hop is just its own peer and then after that, it follows the channel network. So, I was just wondering whether you saw information on that.

Mike Schmidt: That’s a good point. I only have what I just said. I am not sure how then, once you determine that you found this node that supports onion messages, like how the routing then works based on that. So, yeah, not sure.

Mark Erhardt: Well, if you have a channel with another node, clearly you must be talking to them. So, presumably the channel network does provide a set of minimum connections that are available. But yeah. So, my interpretation would be it follows the channel network. Maybe someone can tell us in the responses to our podcast tweet what the details are here.

BTCPay Server #7354

Mike Schmidt: Yeah. Let us know. BTCPay Server #7354 is a fix for a security issue where in some cases, certain users could accidentally be exposed to private wallet key information that they should not have access to. I think this was a result of some changes made to BTCPay server’s wallet permissioning system that was recently added. And there was a gap in that which users that had permission to sign transactions, but not permission to view the wallet seed or change certain other settings, could actually end up seeing the individual address level private keys generated from the master seed for specific addresses during the signing process. And so, the fix here is to change how that hot wallet access is handled internally. I think they’ve done some separation there to make sure that those permissions stay intact throughout the signing flow.

BDK #2195

BDK #2195. This fixes a bug in BDK, where BDK could fail to sync transaction history when working with an Electrum server backend, if a transaction’s first output was, for example, an OP_RETURN which is unspendable and not indexed by Electrum. This is because BDK was looking up a transaction’s confirmation status using the first output’s address, but OP_RETURN does not have such an address, so Electrum would return nothing. And then, BDK would treat the transaction as if it didn’t exist. So, the fix is that now BDK will skip any unindexed outputs and uses the first output that Electrum would actually track, and then falling back to an input address if needed.

Mark Erhardt: When I read that, I was confused. Why don’t they just ask for the txid?

Mike Schmidt: I’m not sure about the mechanics there. But for whatever reason, they’re querying based on outputs and they just picked the first output, which apparently is not great. As to why they didn’t just use the txid, not sure.

Mark Erhardt: I mean, if they know the output, they must know the txid, because the output’s unique identifier is the txid plus the vout position. And I’m pretty sure that Electrum would index by txid. So, I’m just confused by this item, but I haven’t looked into it.

Mike Schmidt: We’re giving our listeners all kinds of homework for us. So, yell at us in the responses to the Twitter thread here. And Murch, I know you’re going to take Inquisition and BINANAs. Maybe I’ll spelunk in this BDK PR comments to see if I can find something in the meantime.

Bitcoin Inquisition #100

Mark Erhardt: How about you do that? The last two items are Bitcoin Inquisition #100. This one implements BIP446, which is the template hash proposal, on signet. So, if you were chomping at the bit to play around with OP_TEMPLATEHASH on a mainnet-like network, OP_TEMPLATEHASH is now available on signet, I think. I don’t know if it’s activated yet, but it is implemented. So, presumably, it would be activated very soon, if not already. There’s also a bunch of tests that get added to Inquisition. Inquisition is a project fork of Bitcoin Core that extends the rules for signet with proposed consensus changes and other proposals so people can play around with them on a test network; the test network being here the signet, where blocks are signed into existence by the operators. So, yeah.

Mike Schmidt: I think I saw some people going back and forth on X the other day, and I think that this was about to be activated. And the reason that I saw that is someone was asking for it similarly on Mutinynet, and Mutinynet, I guess, sort of takes its cue from Inquisition. And so, there was a sort of a countdown going on. So, maybe somebody else can yell at us about that one, or you can check Inquisition yourself and see.

Mark Erhardt: Yeah, I did see also that Mutiny had activated it. Mutiny is a different signet, and it is different in that I think it has a shorter block interval, I think half a minute. And that makes it faster for developers to test with, but it doesn’t try to replicate mainnet as closely. All right. Also, you can run your own signet if you want a test network. But of course, if other people are doing the heavy lift on the consensus changes, that might be easier. So, you can just grab Inquisition and change the challenge in the signet and run your own signet with it too.

Mike Schmidt: I think this is something that I’ve seen people miss. Yeah, you can run your own signet. There is a sort of, I guess, standard-ish signet, but you can run your own. So, don’t think because there is a group running that particular network that all such signet things are permissioned. You can have your own version.

BINANAs #20

Mark Erhardt: Right. So, finally, BINANAs #20 assigns BIN-2026-0002 for the implementation of OP_CHECKCONTRACTVERIFY (OP_CCV). So, in the Inquisition deployments, the deployments are guarded by a public identifier. These are the BINANA numbers, I think there’s always a BINANA number, even if a BIP has been assigned already. They’re just used in the deployment. So, it looks like, OP_CCV is also coming to signet pretty soon. OP_CCV is an opcode that allows you to specify how the amount of a UTXO has to flow from that UTXO to other UTXOs by encumbering, for example, a minimum amount that has to be spent to a specific output script, or by specifying that it has to go to the same output script again, like a quine. This is especially useful in constructions for things like vaults. And yeah, looks like that is also coming to Inquisition. Generally, in the past few weeks, we’ve been seeing a lot of discussion about covenants again. It seems to me that OP_TEMPLATEHASH and debundle rebindable transactions has been getting some attention lately as a new attempt to get CTV-like (CHECKTEMPLATEVERIFY-like) features.

So, if you’re excited about covenants, I guess our next consensus change feature will be pretty laden with information.

Mike Schmidt: Just also a quick note that the BIP443 PR to Inquisition has been open since mid-December, and I know that the author is looking for feedback there. So, if you look at the Bitcoin Inquisition GitHub, that would be PR #102, which is open and getting feedback. I see Salvatore, I see AJ and Antoine in here talking. So, if you are curious about BIP443, CCV, take a look. Feedback welcome and wanted from the author. All right, Murch, we did it.

Mark Erhardt: Yeah, hear you next week.

Mike Schmidt: #405’s in the bag. We want to thank Fabian for joining us. Murch, thanks for co-hosting and working on the Notable codes segment with me. And we’ll hear you all next week. Cheers.

Mark Erhardt: Cheers.