Bitcoin Optech

Bitcoin Optech Newsletter #400

2026-04-10T00:00:00+00:00

This week’s newsletter includes our regular sections summarizing a Bitcoin Core PR Review Club meeting and describing notable changes to popular Bitcoin infrastructure projects.

News

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

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting.

Testing Bitcoin Core 31.0 Release Candidates was a review club meeting that did not review a particular PR, but rather was a group testing effort.

Before each major Bitcoin Core release, extensive testing by the community is considered essential. For this reason, a volunteer writes a testing guide for a release candidate so that as many people as possible can productively test without having to independently ascertain what’s new or changed in the release, and reinvent the various setup steps to test these features or changes.

Testing can be difficult because when one encounters unexpected behavior, it’s often unclear if it’s due to an actual bug or if the tester is making a mistake. It wastes developers’ time to report bugs to them that aren’t real bugs. To mitigate these problems and promote testing efforts, a Review Club meeting is held for a particular release candidate.

The 31.0 release candidate testing guide was written by svanstaa (see Podcast #397), who also hosted the review club meeting.

Attendees were also encouraged to get testing ideas by reading the 31.0 release notes.

The testing guide covers cluster mempool including new RPCs and cluster limits (see Newsletter #382), private broadcast (see Newsletter #388), an updated getblock RPC with a new coinbase_tx field (see Newsletter #394), a new txospenderindex which tracks which transaction spends each output (see Newsletter #394), an increased default -dbcache size (see Newsletter #396), embedded ASMap data (see Newsletter #394), and a new REST API blockpart endpoint (see Newsletter #386).

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 #33908 adds btck_check_block_context_free to the libbitcoinkernel C API (see Newsletter #380) for validating candidate blocks with context-free checks: block size/weight limits, coinbase rules, and per-transaction checks that do not depend on chainstate, the block index, or the UTXO set. Callers can optionally enable proof-of-work verification and merkle-root verification in this endpoint.
● Eclair #3283 adds a fee field (in msats) to the full-format responses of the findroute, findroutetonode, and findroutebetweennodes endpoints used for pathfinding. This field provides the route’s total forwarding fee, eliminating the need for callers to compute it manually.
● LDK #4529 enables operators to set different limits for announced and unannounced channels when configuring the total value of inbound HTLCs in flight, as a percentage of channel capacity. The defaults are now 25% for announced channels and 100% for unannounced channels.
● LDK #4494 updates its internal RBF logic to ensure compliance with BIP125’s replacement rules at low feerates. Instead of only applying the 25/24 feerate multiplier specified in BOLT2, LDK now uses whichever is larger: that multiplier or an additional 25 sat/kwu. A related specification clarification is being discussed in BOLTs #1327.
● LND #10666 adds a DeleteForwardingHistory RPC and an lncli deletefwdhistory command, enabling operators to selectively delete forwarding events older than a chosen cutoff timestamp. A minimum age guard of one hour prevents the accidental removal of recent data. This feature enables routing nodes to delete historical forwarding records without resetting the database or taking the node offline.
● BIPs #2099 publishes BIP393, which specifies an optional annotation syntax for output script descriptors, enabling wallets to store recovery hints, such as a birthday height to speed up wallet scanning (including for silent payment scanning). See Newsletter #394 for initial coverage of this BIP with additional details.
● BIPs #2118 publishes BIP440 and BIP441 as Draft BIPs in the Great Script Restoration (or Grand Script Renaissance) series (see Newsletter #399). BIP440 proposes the Varops Budget for Script Runtime Constraint (see Newsletter #374); BIP441 describes a new tapscript version that restores opcodes disabled in 2010 such as OP_CAT (see Newsletter #374) and limits script evaluation costs per the varops budget introduced in BIP440.
● BIPs #2134 updates BIP352 (silent payments) to warn wallet developers not to let policy filtering, such as for dust, affect whether scanning continues after a match is found. Treating a filtered-out output as if there were no match can cause the wallet to prematurely stop scanning and miss later outputs from the same sender.

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 April 14. The discussion is also recorded and will be available from our podcasts page.

Bitcoin Optech Newsletter #399 Recap Podcast

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

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Armin Sabouri, Pyth, Conduition, and Jonas Nick to discuss Newsletter #399.

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

Download audio

News

● Wallet fingerprinting risks for payjoin privacy (44:15)
● Draft BIP for a wallet backup metadata format (1:04:26)

Changing consensus

● Compact Isogeny PQC can replace HD wallets, key-tweaking, silent payments (24:23)
● Varops budget and tapscript leaf 0xc2 (aka Script Restoration) are BIPs 440 and 441 (1:13:24)
● SHRIMPS: 2.5 KB post-quantum signatures across multiple stateful devices (02:02)

Releases and release candidates

● Bitcoin Core 31.0rc2 (1:22:07)
● Core Lightning 26.04rc2 (1:23:32)
● BTCPay Server 2.3.7 (1:24:04)

Notable code and documentation changes

● Bitcoin Core #32297 (1:26:29)
● Bitcoin Core #34379 (1:28:54)
● Eclair #3269 (1:30:37)
● LDK #4486 (1:32:59)
● LDK #4428 (1:35:00)
● LND #9982 (1:37:13)
● LND #10063 (1:39:00)

Transcription

transcription coming soon

Bitcoin Optech Newsletter #399

2026-04-03T00:00:00+00:00

This week’s newsletter describes how wallet fingerprinting can damage payjoin privacy and summarizes a proposal for a wallet backup metadata format. 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

● Wallet fingerprinting risks for payjoin privacy: Armin Sabouri posted to Delving Bitcoin about how differences in payjoin implementations make it possible to fingerprint payjoin transactions and can damage payjoin’s privacy.

Sabouri states that payjoin transactions should appear indistinguishable from standard single-party transactions. However, there can be artifacts of collaborative transactions:
- Intra-transaction
  - Partition inputs and outputs by owner within a single transaction.
  - Differences in input encoding.
  - Inputs length in bytes.
- Inter-transaction
  - Backward: Each input was created by a prior transaction that carries its own fingerprint.
  - Forward: Each output may be spent in a future transaction, revealing fingerprints.
He then reviewed three payjoin implementations: Samourai, the PDK demo, and Cake Wallet (sending to Bull Bitcoin Mobile). In each of these examples, he finds a few discrepancies which make it possible to fingerprint these implementations. This includes but is not limited to:
- Differences in encoded input signatures.
- SIGHASH_ALL byte being included in one input but not the other.
- Output value assignment.
Sabouri concludes that while some of these wallet fingerprints are trivial to eliminate, others are intrinsic to a particular wallet’s design choice. Wallet developers should be aware of these potential privacy leaks when implementing payjoin into their wallets.
● Draft BIP for a wallet backup metadata format: Pythcoiner posted to the Bitcoin-Dev mailing list about a new proposal for a common structure for wallet backup metadata. The draft BIP, available at BIPs #2130, specifies a standard way to store various type of metadata, such as account descriptors, keys, labels, PSBTs, and more, allowing compatibility between different wallet implementations and a simpler wallet migration and recovery processes. According to Pythcoiner, the ecosystem lacks a common specification and this proposal aims to fill this gap.

From a technical perspective, the proposed format is a UTF-8 encoded text file containing a single valid JSON object representing the backup structure. The BIP lists all the different fields that could be included in the JSON object, specifies that each is optional, and notes that any wallet implementation should be free to ignore any metadata not deemed useful.

Changing consensus

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

● Compact Isogeny PQC can replace HD wallets, key-tweaking, silent payments: Conduition wrote on Delving Bitcoin about his research into the suitability of Isogeny-Based Cryptography (IBC) as a post-quantum cryptosystem for Bitcoin. While the elliptic curve discrete logarithm problem (ECDLP) may be rendered insecure in a post-quantum world, there is nothing fundamentally broken about elliptic curve mathematics in general. Briefly, an Isogeny is a mapping from one elliptic curve to another. The cryptographic assumption of IBC is that it is difficult to compute the Isogeny between one elliptic curve of a specific type and another, while it is easy to produce an Isogeny and the curve it maps to from a base curve. Thus IBC secret keys are Isogenies and the public keys are the mapped curves.

Like ECDLP secret and public keys, it is possible to compute new secret keys and public keys independently from the same salt (e.g. a BIP32 derivation step) and have the resulting secret keys correctly sign for the resulting public keys. Conduition refers to this as “rerandomization” and it fundamentally enables BIP32, BIP341, and BIP352 (with some additional cryptographic innovation, probably).

To date, there are no signature aggregation protocols for IBC like there are in MuSig and FROST, and conduition issues a call to action for Bitcoin developers and cryptographers to research what may be possible.

Keys and signatures in known IBC cryptosystems are about twice the size of keys in ECDLP-dependent cryptosystems. Much smaller than hash-based or lattice-based cryptosystems. Verification is costly even on desktop machines (on the order of 1 millisecond per verification), in the same ballpark as hash-based and lattice-based.
● Varops budget and tapscript leaf 0xc2 (aka “Script Restoration”) are BIPs 440 and 441: Rusty Russell wrote on the Bitcoin-Dev mailing list that the first two BIPs of the Great Script Restoration (or Grand Script Renaissance) have been submitted for BIP numbering. They subsequently received BIP numbers 440 and 441 respectively. BIP440 enables the restoration of previously-disabled Script opcodes by building an accounting system for the cost of each operation that ensures the worst case block-level script validation cost cannot exceed the cost of validating a block containing the worst case number of signature operations. BIP441 describes the validation of a new tapscript version which restores the opcodes disabled by Satoshi in 2010.
● SHRIMPS: 2.5 KB post-quantum signatures across multiple stateful devices: Jonas Nick writes on Delving Bitcoin about a new semi-stateful hash-based signature construction for post-quantum Bitcoin. SHRIMPS takes advantage of the fact that SPHINCS+ signature sizes scale with the maximum number of signatures for a given key which can be produced while retaining a given security level.

Similar to the SHRINCS design, a SHRIMPS key consists of two keys hashed together. In this case, both keys are stateless SPHINCS+ keys, but with different parameter sets. The first key is only secure for a small number of signatures and intended to be used with first (or first few) signatures from each signing device the key is used with. The second key is secure for a much larger number of signatures (effectively unlimited in a Bitcoin context) and each device falls back to that key after some (potentially user chosen) number of signatures from that device. The result is that in the common Bitcoin use-case where any given key (of which many can be derived from a single seed) only signs a small handful of times, nearly all signatures can be < 2.5 KB while still having no effective limit on the total number of signatures if a key ends up being reused many times, at the cost of the later signatures being ~7.5 KB. SHRIMPS is semi-stateful in that no global state must be retained, but each signing device must record a few bits of state for each SHRIMPS key it signs with (as little as a single bit if only the first signature from each device-key tuple takes advantage of the small signature).

Releases and release candidates

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

● Bitcoin Core 31.0rc2 is a release candidate for the next major version of the predominant full node implementation. A testing guide is available.
● Core Lightning 26.04rc2 is the latest release candidate for the next major version of this popular LN node, continuing the splicing updates and bug fixes from earlier candidates.
● BTCPay Server 2.3.7 is a minor release of this self-hosted payment solution that migrates the project to .NET 10, adds subscription and invoice checkout improvements, and several other enhancements and bug fixes. Plugin developers should follow the project’s .NET 10 migration guide when updating.

Notable code and documentation changes

● Bitcoin Core #32297 adds an -ipcconnect option to bitcoin-cli so it can connect to and control a bitcoin-node instance via inter-process communication (IPC) over a Unix socket instead of HTTP when Bitcoin Core is built with ENABLE_IPC and the node is started with -ipcbind (see Newsletters #320 and #369). Even when -ipcconnect is omitted, bitcoin-cli tries IPC first and falls back to HTTP if IPC is unavailable. This is part of the multiprocess separation project.
● Bitcoin Core #34379 fixes a bug where calling the gethdkeys RPC (see Newsletter #297) with private=true failed if the wallet contained any descriptor for which it had some but not all of the private keys. Similar to the fix for listdescriptors (see Newsletter #389), this PR returns the available private keys. Calling gethdkeys private=true on a strictly watch-only wallet still fails.
● Eclair #3269 adds automatic liquidity reclamation from idle channels. When the PeerScorer detects that a channel’s total payment volume in both directions falls below 5% of its capacity, it gradually lowers relay fees toward the configured minimum. If fees have been at the minimum for at least five days and volume still has not picked up, Eclair closes the channel when it is redundant with that peer. Channels are closed only if the node holds at least 25% of the funds and the local balance exceeds the existing localBalanceClosingThreshold setting.
● LDK #4486 merges the rbf_channel endpoint into splice_channel as a single entry point for both new splices and fee bumping an in-flight splice. When a splice is already in progress, the FundingTemplate returned from splice_channel carries PriorContribution so users can RBF the splice without new coin selection. See Newsletter #397 for related splice RBF behavior.
● LDK #4428 adds support for opening and accepting channels with zero channel reserve via a new create_channel_to_trusted_peer_0reserve method for trusted peers. Zero-reserve channels let the counterparty spend their full on-chain balance in the channel. This is enabled for both channels using anchor outputs and zero-fee commitment channels (see Newsletter #371).
● LND #9982, #10650, and #10693 harden MuSig2 nonce handling on the wire for taproot channels: ChannelReestablish gains a LocalNonces field so peers can coordinate multiple nonces for splicing-related updates, lnwire validates MuSig2 public nonces at TLV decode for nonce-carrying messages, and LocalNoncesData decoding validates each nonce entry.
● LND #10063 extends the RBF cooperative close flow to simple taproot channels using MuSig2. Wire messages carry taproot-specific nonce and partial-signature fields, and the closing state machine uses MuSig2 sessions with a just-in-time nonce pattern across shutdown, closing_complete, and closing_sig (see Newsletter #347 for background on the RBF cooperative close flow).

Bitcoin Optech Newsletter #398 Recap Podcast

2026-03-31T00:00:00+00:00

Mike Schmidt and Gustavo Flores Echaiz are joined by Dusty Daemon to discuss Newsletter #398.

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

Download audio

News

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

Selected Q&A from Bitcoin Stack Exchange

● What is meant by Bitcoin doesn't use encryption? (28:44)
● When and why did Bitcoin Script shift to a commit–reveal structure? (30:26)
● Does P2TR-MS (Taproot M-of-N multisig) leak public keys? (31:50)
● Does OP_CHECKSIGFROMSTACK intentionally allow cross-UTXO signature reuse? (33:24)

Releases and release candidates

● Bitcoin Core 28.4 (35:05)
● Core Lightning 26.04rc1 (36:19)

Notable code and documentation changes

● Bitcoin Core #33259 (37:51)
● Bitcoin Core #33414 (39:49)
● Bitcoin Core #34846 (41:38)
● Core Lightning #8450 (13:39)
● Core Lightning #8856 (22:08)
● Eclair #3247 (44:21)
● LDK #4472 (25:00)
● LND #10602 (47:25)
● LND #10481 (49:38)
● BOLTs #1160 (0:51)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #398 Recap. Today, we have some Selected questions and answers from the Stack Exchange in our monthly segment; we have Releases and release candidates; and we also have some Notable code and documentation changes, including the splicing BOLT being merged into the Lightning spec. This week, Gustavo and I are joined appropriately by Dusty. Dusty, who are you? What have you been doing the last few years?

Dusty Daemon: I’m Dusty Daemon, I’ve been doing splicing for years now.

Mike Schmidt: Well, I guess you’re the right person to have on today then.

Dusty Daemon: I like to think so, I’ve been doing longer than anyone else. So, yeah, let’s go.

BOLTs #1160

Mike Schmidt: All right. Well, for those listening along, we’re going to actually jump down to the very last item in the newsletter, which is under the Notable code and documentation changes, BOLTs #1160, which merges the splicing protocol into the Lightning spec. Dusty, people are very excited about this. We’ve had you on before, we’ve also talked about splicing, people maybe even using tooling and wallets that have splicing. So, what does it mean that it’s now in the spec? Why is it there now? Maybe give us the lay of the land and you can maybe do a quick overview of what is splicing and why people are excited.

Dusty Daemon: Absolutely. So, the specs in Lightning are a little different than the other places. When the spec gets merged, it’s different than the BIP process. When a spec gets merged, it’s because it’s actually implemented and tested cross implementations. So, the analogy would be like browsers, right? If you have a certain new HTML feature that works on two browsers at least, then it goes into the spec. So, the spec merging is like the final process. It’s like, spicing’s done, it’s out there. We actually got three to go through with this one, which is awesome, more than the two that’s normally required. So, the spec’s fully in. You want me to go into what is splicing? Should I just do a high level on that?

Mike Schmidt: Yeah, I think a high level would be good.

Dusty Daemon: Cool. So, in the beginning, there were Lightning channels, the very beginning. I’m going to gloss over how Lightning works, cause that can get a little complicated, a little tangent-y. But Lightning works through channels. So, when you are entering the LN, you make a channel to somebody, and then you use the channel hops to get places in Lightning. And the thing about these channels is you have to put bitcoin in the channel. So, the amount of throughput the channel can handle is limited by how much bitcoin you put in. And so, from the beginning, there was this idea of like, “Hey, what if we want to change that throughput number?” It turns out it’s just really complicated. It’s kind of like changing the size of the wings on a plane while it’s flying, sort of deal. So, it got kind of got pushed off and pushed off until eventually, a consensus was reached on a solution.

Splicing, at its core, allows you to change the size of a Lightning channel. You could simplify the explanation down to just that. But that does hide some of the awesome, magical things that become possible. And just to go real quick over one of them, as an easy example. So, if you wanted to, say, make an onchain payment to a Bitcoin address from your Lightning funds, you could do that by reducing the size of your channel for the amount of onchain payment you want to do, and also vice versa. So, even though all we’re doing is changing the size of the channel, it exposes a bunch of really cool features, and that’s just a taste. There’s plenty more that are possible afterwards.

Mike Schmidt: Awesome. Well, I know you’ve spearheaded a lot of the work here, and so I guess even though, like you said, splicing has sort of been rolled out to several implementations already, this is a nice celebration for you, and I’m sure listeners can hear your excitement. Are there other interesting uses? I mean, you gave the splicing-out, I guess, example. You could splice-out and make a payment. Given that this has been around now and some people have been toying with it for a while, what are the most common cases? Is it LSPs, rebalancing channels and things like that? What have you seen to the degree that you’ve heard feedback or observed?

Dusty Daemon: So, knowing what’s most popular is always hard because Lightning is so private. So, you’ve got to do some speculation, right, there’s some guesstimation here. But there’s two major ones I would point to. One is the Phoenix iPhone wallet, which is an app for you to be able to have a Lightning wallet that makes payments. And before integrating splicing, they were trying to make a seamless process. So, whenever you ran out of funds and you wanted to add some funds to your Lightning balance, you’d have to send some funds in, it would open a new channel. I remember looking at one buddy’s app and I was looking in the settings, and you can see how many channels he had. He had like 20-something channels for one little wallet, and that’s a lot to manage. The chain fees start adding up, and there can be complicated issues with keeping that many channels open when you’re just trying to do a payment.

So, Phoenix integrated splicing, and now they have one channel. So, in the back end, it just simplifies all kinds of things. But for the user, that translates to it’s cheaper. Like, when they announced it, they actually literally cut their fees in half, I believe. And it runs faster and more smoothly. There’s less weird cases you can get stuck in. So, that’s a big one that I think is pretty huge. It’s just Lightning wallets get a lot better with those collection of features. And on the other side is, if you’re a big Lightning routing node and you’re doing a lot of throughput, those people have to do a lot of work balancing all their channels. So, they’re the guys in the background making sure payments can actually get through the entire network. And they constantly are trying to analyze where it’s going, try to move the channels to be in the right spot, get liquidity where it needs to be, and they have to open and close channels and move funds around quite a lot, particularly when you have one-way flows.

So, imagine a scenario where people are making remittance payments from the US over to El Salvador, or something. You get a lot of one-way flows. One-way flows are the hardest demands for those guys. And splicing, well, it doesn’t solve that problem completely. It is a massive tool. You can more than double your ability to throughput more bitcoin through your channels that are going one way, with the same amount of funds, without having to go as crazy. So, I think those are the two categories today that I’m sure are happening in mass. And I think we’re going to see a lot more coming up, which is actually just jumping ahead a bit. That’s what I’m getting ready to work on now. Now that splicing is done, ratified in the spec, there are a lot of other cool ancillary things we can start to do that I’m going to be working on soon.

Mike Schmidt: Are these things that you’re looking at, these next things, is this more like things using splicing as it is today, or is this like splicing v2?

Dusty Daemon: Splicing as it is today. It’s kind of like how, if we use taproot as an example in Bitcoin, and it enabled a whole bunch of stuff to be done, there’s a lot of things in taproot we haven’t even used yet that are possible to use. Splicing is in a similar state. There’s a whole lot of things we can do with it that are possible now that it’s on the network and major implementations have it and it’s getting deployed, that I want to start tackling. One big one is I want to start merging more transactions. Splicing is written in an open transaction sort of protocol, where we can add arbitrary inputs and outputs to them, and this allows us to start merging all kinds of things. The easiest example would be merging two splices. So, if I want to splice two channels at once, that can be one transaction, there’s no need for it to be two. And that’s actually something I got in the last Core Lighting (CLN) release, is now you can start doing n splices at once, which is awesome.

But things I’m ready to do is start adding in channel opens and also arbitrary transactions. Like, if you’re doing an onchain payment, maybe one day, like, a payjoin, there’s no reason that can’t also be a splice. There’s a theoretical world where every onchain transaction is also merged with the splice. Everything’s a splice at some point, right? These are some possibilities. But even if we get 10% of the way there, like if 10% of blocks are one single splice, that’s an awesome world. We’ve added more privacy, we’ve made transactions cheaper, more efficient chain usage. And the other thing that I think is not obvious at first is, if you can make it cheaper to join a coinjoin-like transaction, you’re going to get a larger set of people doing it that are just doing it to save money. And that makes the anonymity, I can never say this word right, the anonymity set, it makes that set much better and bigger by having more people in it, making the privacy gains a lot more awesome.

So, that’s some of the things, and there’s some other little things too. And I’m really excited to both celebrate splicing that’s done and look ahead to what’s possible to do now, and some other stuff too.

Mike Schmidt: I can interpret that a lot of users are listening to your energy and your cool ideas and saying, “Well, like what? What are these projects called? Where? Is there an umbrella thing that this guy’s working under? How do I jump in on this?” And so, is there a place to point people to yet, or is this sort of still in your head?

Dusty Daemon: Well, it depends on the level you want to go. You can follow my GitHub, read my PRs, maybe review them. I’m always looking for more reviews of PRs. But of course, that requires a level of technical deep competency. But to follow it, I think just keep posted. These are all still in the heavy dev stage, a lot of these ideas, and eventually they’re going to start becoming – there’s a little bit of PR work that has to be done, right? Like, I’d love to get payjoin involved, I’d love to look at, I don’t know, JoinMarket, what they’re doing, I haven’t really looked through those very much; and eventually, get wallet providers. So, those are some things. I think the way this stuff is, this is really like core infrastructure stuff. This is the foundation of things. And other code will end up using it to build the building on top of the foundation. So, it’s kind of hard to be too much of a layman. I mean, I guess just follow content like this if you want to. That’s probably one of the best places I can think of for that.

Mike Schmidt: I have a bit of a curveball for you here.

Dusty Daemon: Okay, I’m ready. All right, curveball, let’s go.

Mike Schmidt: Where’s the quote? Okay, so we had ZmnSCPxj on a couple of months ago. And he says, “Yeah, so basically my opinion here is that we got nerd-sniped with splicing, but we should probably have focused on swapping first. Because it turns out, if you go down to it, it’s actually much smaller in block space to use swapping than splicing, even this mythical batch splicing, which is theoretical, but which is probably not going to get implemented anytime soon”. So, there’s a few different ways to go with that. But the reason that I actually just brought that up while we’re talking, because I remember him saying critical, I don’t know, things about splicing. And I wondered if you are familiar with his thoughts beyond just that quote, and what your take is on that?

Dusty Daemon: Unfortunately, I’m not too familiar with his opinions on that, but I love his comment that it’s this mythical thing that mythically one day, we’ll have these joined splices. And in a certain sense, he’s absolutely right, it’s a difficult goal to get to. And there are some problems to solve along the way that there’s no clear solution, particularly like reputation. So, if somebody starts joining splices and they’re a bad actor, they could, say, add inputs and outputs to a transaction that they never signed, right? It’s a form of DDoS sort of, it’s different than DDoS, but it’s got that vibe to it. That’s a problem has to be solved. And one of the issues is because everything’s so private, forming reputation is difficult. Like, I might be doing a splice with Mike, who is doing with someone else, and that person is adding in malicious inputs and outputs. I can’t tell if it’s Mike or that guy. This is a real problem to be solved. And I think in the sense that he’s saying it’s a long way off and it’s hard to get to, he’s absolutely correct. I still think we can, it’ll just take a while.

The first part, I’m not sure what benefits he’s hoping for from the swap over splice. I’d have to see a little more detail.

Mike Schmidt: It sounds like onchain space maybe.

Dusty Daemon: I’d have to look at it more. I’m not familiar with anything like that, but it’s entirely possible that maybe one day, with the splice merge, something he’s talking about would be better than splice, but it’s not today. But without more details, I couldn’t really speak to it, you know.

Mike Schmidt: Okay, yeah, sorry, I didn’t mean to curveball, and we don’t like to necessarily do throwdowns here on Optech, but I figured I would bring that up, because I knew you’d be a good sport about it.

Dusty Daemon: All good!

Mike Schmidt: Okay, well I think we will incidentally get into some of the technicals around splicing, because there are a few PRs this week that are around splicing. And of course, Dusty did not author all these PRs and is not familiar with all these implementations’ nuance, but he can maybe provide some color commentary. So, maybe we’ll just quickly pivot and Gustavo can pull out the splice-related PRs, do his summary, and then we can have the color commentary from Dusty.

Dusty Daemon: Great, yeah, my first time seeing them. So, this is going to be a fun, genuine reaction.

Core Lightning #8450

Gustavo Flores Echaiz: Perfect. All right, so this week we have a few PRs related to splicing, a few that you actually authored, so we have three about CLN, one on LDK and, yeah, that’s it. So, the ones on CLN which you authored, and which we’d like you to give us a bit more details are, the first one is #8450 which I think that’s the extension of the scripting engine of CLN, that allows it to then implement the splicein and spliceout commands that are in the follow-up PRs, right? But here, there are a few concepts that are interesting that we would like you to go more into, one being cross-channel splices, which you kind of already discussed about; but the other one being multi-channel splices. Some people maybe don’t understand the difference between these two concepts, if there is any. Maybe they’re closer than they would be. And also, I think an interesting problem that was solved by this PR was the dynamic fee calculation, because you kind of get into a loop and into a circular dependency when you add additional inputs, so you increase the transaction weight for the required fee, but then you might require additional inputs to pay those fees. And that’s basically what this PR is about. So, please tell us, help us understand the difference between these concepts and how this worked, since you are the author behind this PR.

Dusty Daemon: Absolutely, I love that summary. So, starting from the top there, a cross-channel splice would be splicing funds from one channel to another; and a multi-channel splice would be a larger concept that cross-splice would be one of. So, multi-channel splice just means there’s more than one channel involved. So, it could be a cross-splice, it could be two cross-splices, it could be a triple. So, you could do something, for example, like take funds from one channel, splice it into three other channels, right? Or you could, say, take funds from two channels and then make an onchain payment and put some funds in your cold storage. That’s not necessarily across two channels, but it’d be a multi-channel splice.

Multi-channel splicing is really what really tests your splicing code, can it handle this, because there’s so much interleaving of complex steps that have all been theorized, but in practice are quite difficult to get right. So, that’s something really exciting in this PR, is it’s adding the cross-channel abilities to the splice group. Then, of course, building test cases for that, is basically the ultimate rigorous test of the entire splicing system. So, I’m really excited to get this in and have it working as well as it is.

Then, you were asking about, what was it again? Oh yeah, fee calculations. Weirdly, it was probably the hardest problem of this whole thing. You’d think fees, whatever, you attach them, some sats on the end of it, who cares? But I wanted to make it so we could have the user say what feerate they wanted and honor it, or at least get as close as possible to honoring it; sometimes you get to round a sat here or there where you have some dust limit issues, but do our best to honor the feerate. And it turns out that gets it gets very complicated because this is a problem regular onchain wallets have, is if they want to pay an amount and they need just a little bit more to pay the fee, they have to add another input to the transaction. And people are familiar with this tech probably already, not in their head, of course, they already know this. But if you aren’t familiar, adding more funds to a transaction makes the transaction bigger, which means then you have to pay more fees to the transaction. You can get in this loop, as I was saying, where by adding funds to pay for the fee makes it so expensive, you have to add more funds, which makes it bigger, making it more expensive. You can see how this can easily iterate out of control.

This has been well solved in onchain wallets, but splicing has the same problem, but different, where we have to figure out the feerates in a transaction that also has channels flying around and onchain funds coming in, onchain funds going out, and solve all that. And the goal of this splice engine that I built here, side note, it turns out this engine was really important. And specifically, my goal is to build it in a way, I’m building it with as least dependency on CLN as possible. Maybe one day when the other – I do suspect the other implementations are going to come around to this problem and realize, “Oh, crap, this is really, really hard”. And so, I’m trying to make it its own standalone library. And it does exist outside of the main Lightning implementation. It just needs access to a certain set of RPC calls to manage splices, and it can manage this quite complex state. But I figured it was worth it solving it for all cases.

So, this engine can solve every kind of splice that can exist, go through, get the feerates right, get balances going where they’re going to go, also handle things that sound simple but are quite complex, like, “I want to do a percentage amount. Maybe I have a million sats that I’m putting in, I want you to divide them equally between these five channels”. Or, “I want you to put half in this channel and the rest over the other four”, stuff like this. You start getting these circular dependency problems where the actual sat amounts require multiple passes over the information to get the correct amount out, and other things too. Like, maybe you want to take half of my available funds to this channel, whatever that number is at the time, which is constantly changing. I think every time you run the splice, it’ll be a different amount than it could be a minute later, because payments went through.

So, I’m going to implement the hard thing and implement it as well and as elegantly and tested as I can, and then come back and implement things like splicein and spliceout. And one of the awesome things about this is, after this PR, I made the splicein and spliceout PRs that the actual functional code is like one to two lines, because it’s just calling into things in the splice script, right? And this engine allows us to do much more complex splices; and importantly, it allows it to do it where the user doesn’t have to know very much. Like, in theory, all the stuff splice script does, you could do by hand, but you’re going to be managing a lot of PSBTs. Like, the amount of times that a PSBT mutates in a simple splice can easily be, like, five potentially. And if you’re doing cross-channel splices, It doesn’t just become ten. It actually gets, I don’t know the exact number off hand, but it’s more than ten if you’re doing two channels. And it starts growing quite ridiculous amounts, the more stuff you’re doing. And there are actually ways for users to screw it up and lose funds. Like, some people like to put a PSBT into an online website that will parse it for them or change something about it, and then download it back in. A very clever website could take your PSBT, recognize this for a splice, inject your funds into the PSBT, paying them, for instance. And you’d have to be aware of this as a user to not let that happen, because your node might just go and sign that, and then just give them all your money.

So, that’s one footgun that you kind of got to worry about. And by using this system, I can find all the footguns and just prevent them from happening. You’re not going to fall into any of these footguns that I’m aware of by using this system. So, a bunch of those sorts of benefits. And I’m excited for the future after. This is the core functionality of splice script going. There’s also future awesome things that are coming down the pipe, particularly around things like automated Lightning nodes, which we haven’t really talked about. I’m going to talk a lot here. Please jump in, I’m talking too much. I’m getting excited. But the automated Lightning bots have always been sort of a dream from the beginning of Lightning, and they’ve always been terrible. They’ve always just been terrible. And over the years, we’ve gotten some decent ones coming through. Like in CLN, we got a CLBOSS, right? But there’s not a lot of options. And part of the reason is because they’re very hard to build. And with splice script, once we add channel opens to it and closes and a couple other features, you could build something like CLBOSS, a Lightning management thing, with much less overhead code, where you’re just managing complicated channel state and much more prescriptive, like, “This is what I want the node to do”. And then, all of the complex stuff is handled inside of this engine.

So, that’s what I’m excited about. That’s what this PR is about in, I guess, not a nutshell, a long shell. But yeah.

Mike Schmidt: Awesome, Gustavo, I know you have a couple more.

Core Lightning #8856 and #8857

Gustavo Flores Echaiz: Yes, perfect. Thank you so much, Dusty, that was great. So, the next one is a quick follow up to that PR, is #8856 and #8857, which in conjunction, they add two new RPC commands to CLN splicein and spliceout splicing, which, well the name kind of tells it. Splicein allows you to add additional funds to a channel, while spliceout allows you to remove funds from a channel. Or even, the spliceout also basically says that you can remove funds into another channel. So, it becomes effectively a cross-splice. And this was all possible before, right, with the experimental dev-splice RPC. But now, you’re moving it beyond experimental, if I understand, and you’re making it more accessible? Can you please give us a little background on that?

Dusty Daemon: Yeah, absolutely. And those are really good points, and you’re nailing exactly what’s exciting with those PRs. I’ll cover your last question first. There’s a lower level. In CLN, we always make lower-level APIs, RPC commands for doing stuff, and then we build the higher-level ones. So, this is building the higher-level one. There’s a low level API. It’s like splice_init, splice_update, splice_signed, things like that. There’s a couple of these commands that you can combine together and mutate your own PSBTs and do this stuff. Quite difficult to do and error-prone. This is a command that just does it like one shot. Like, “Hey, just give me an amount and I’ll splice it in, give me an amount and I’ll splice it out”.

One of the awesome things about the splice, so splicein, spliceout, just to explain it for those that aren’t familiar with this, is you’re adding funds from some onchain source into your Lightning channel. So, typically, it’d be your onchain Lightning wallet, you store some excess funds that are ready to use for Lightning kind of in a staging area, but not used. You splice them into the channel, now your channel has that extra balance inside of it. And then, spliceout would be the reverse flow. You have funds in a channel, you want to take it out, you want to bring it back onchain. And one of the awesome things about the way this is architected is because of this splice script engine, spliceout lets you specify the destination as your onchain wallet or another channel, and then just auto-magically, you can get a cross-channel splice using the spliceout command. A little spoiler, what’s coming soon is actually you can add a Bitcoin address to there too. So, spliceout ends up being this sort of magical command where you can move the funds wherever you want it to, creating this sort of elegant, much more elegant, I think, simple user experience. I’m really excited about it. I think we’re starting to see the awesome, more mature stages of splicing appear.

LDK #4472

Gustavo Flores Echaiz: That’s awesome. It really seems like we’re finally reaching the point we’ve been looking at for years, and so that this can actually become effective and powerful. Well, that’s great. Those were the two PRs that you covered. There’s another PR on LDK, which maybe you don’t have the exact background, but maybe you have extra thoughts to add. So, it’s LDK #4472. Here, there was a potential funds-loss scenario that is fixed, where basically the tx_signatures message could be sent before the counterparty’s commitment signature was durably persisted. So, this would allow to broadcast and the splice transaction to confirm. But then, if your node crashed without having properly persisted your counterparty’s commitment signature, then you would kind of lose ability to enforce the channel state. So, this fix defers releasing the tx_signatures until you have ensured that you have properly updated your channel monitor and have persisted the commitment signature from your counterparty. So, maybe you have some extra thoughts to add to this.

Dusty Daemon: Oh yeah, this is so easy to have happen. I’ve done the same code in CLN. So, the way in general Lightning is architected is we build transactions and sign them that are pre-empting future, things you can call justice-y transactions, and then we sign the initial transaction. So, it’s the reverse order of what people are used to. Like, if you have transactions that go onchain in order ABC in Lightning, we sign it CBA. And each time we confirm, “Was C signed correctly?” “Yes”. “Okay, now we can sign B”. “Okay, was B signed correctly?” “Yes”. “Now we can sign A”. So, what the commitment is, is you’re signing the equivalent of the justice transaction before you go over and sign the splice thing.

So, when you’re doing a splice, you’re taking the existing channel state and you’re building a transaction that moves that channel state over to a new UTXO. And before you can do that, you must first sign the justice transactions on that new future UTXO. So, that’s sort of what’s happening here. It’s easy to accept, very important that you get the commitments before you sign the tx, absolutely. And one of the other challenges is that, one thing I noticed, if you’re doing multichannel splices with a lot of channels, you have to actually sign much earlier than you think, because you might need to parse that signed transaction state from one channel to another over your own local RPC. So, you have to actually sign before you send the signature. So, you need to have special code that handles when you send the signature and make sure that you have the correct children signatures already signed. So, I can’t load it here on GitHub. GitHub’s going down. What isn’t going down? Is everything vibe-coded these days? Oh, I got it up. Okay, just checking it out. Yeah, I’m not going to look through it now, it’s a big PR. But good that they found that, excellent thing to find. And I could totally see it happening. Easy little thing to slip in.

Mike Schmidt: Awesome. Well, Dusty, I think you’ve served your tour of duty on the Optech Recap here and helping us through some of these PRs. We appreciate all your work on splicing. It sounds like there’s some exciting things coming. People should follow your work on GitHub and try to get involved wherever their technical and interests lies. So, thanks for your time, Dusty.

Dusty Daemon: Hey, thanks so much, thanks for having me. Have a good rest of the Optech. Take care.

What is meant by Bitcoin doesn’t use encryption?

Mike Schmidt: Cheers. We are going to jump back up to the Stack Exchange Q&A. We have four this month that we highlighted. First one is, “What is meant by ‘Bitcoin doesn’t use encryption’?” And this person I think saw some communication from Adam Back talking about probably quantum, and mentioning that Bitcoin doesn’t use encryption. And this thing somewhat comes up a lot. And I think it’s good to sort of remind ourselves of this conflation between encryption and using other types of cryptography more generally. So, encryption, and I think Pieter Wuille answered this one, encryption is specifically about hiding information from a third party. In Bitcoin, your transactions are fully public, so there isn’t something that you’re hiding or concealing. What Bitcoin is actually using is digital signatures, so both ECDSA as well as schnorr can prove that you’ve authorized a spend without revealing your private key. So, it’s using cryptographic math, but it’s different than encryption. So, Bitcoin itself does not use encryption.

Maybe it’s important also to note that with encrypted transport, which is what Bitcoin Core added in the last year or two, encrypted communication between nodes, previously all that was in plain text. That can now be encrypted when you’re communicating with your peers. So, Bitcoin Core does use encryption in that regard, but Bitcoin more broadly, the protocol does not. Anything to add there, Gustavo?

Gustavo Flores Echaiz: No, I think that was great.

When and why did Bitcoin Script shift to a commit–reveal structure?

Mike Schmidt: I’ll jump to the next question from the Stack Exchange, “When and why did Bitcoin Script shift to a commit-reveal structure?” This is a nice little ‘history of Bitcoin Script’ question. And that evaluation happened gradually over many years, different iterations. Satoshi’s original design had folks paying directly to raw public keys, so raw pubkeys. It was just sitting right there in the output for anyone to see. Then you had P2PKH, which was sort of a first step towards a commit-reveal kind of scheme. You hash the public key in the output, and then you only reveal that public key at spend time. And then you have P2SH, which extended that sort of pattern into more arbitrary scripts, not just the pubkey that you’re hashing; but you commit to a hash of the spending conditions, and then you reveal that full script when you spend. And then, segwit and taproot continued refining that approach, and with taproot being the most private version in that you can commit to all these different spending conditions and only the one that you actually spend, if you’re using the scriptpath, is actually revealed.

So, you can see how this evolution added also to privacy in some regard, in that the spending conditions weren’t revealed till spend time. And in the case of taproot, not all spending conditions were revealed.

Does P2TR-MS (Taproot M-of-N multisig) leak public keys?

Next question, “Does P2TR multisig, or P2TR-MS, leak public keys?” And the short answer to this one is yes, and maybe it’s worth understanding why. In P2TR-MS, where you have this M-of-N multisig in one of the single-leaf taproot scriptpaths, all of the public keys are exposed when you spend. And maybe we don’t need to get into it, but there’s a mechanical reason for that. Both OP_CHECKSIG and OP_CHECKSIGADD require the public key. It corresponds to that signature to be present in the script, and so there’s no way to hide unused keys. This was actually answered by our usual co-host, Murch, who isn’t here today, who would probably elaborate on that. But if you’re looking for more private ways to do multisignatures, you can use MuSig2 keypath spending. That’s probably the best and most cost-efficient way. And there’s folks working on things like FROST and threshold signatures, which would be another good way. But this P2TR-MS is something that’s available today as well if you want to do threshold signatures without waiting for FROST.

Gustavo Flores Echaiz: Makes sense. And this is, of course, if you spend this specific path, right? So, if you had spent a different path, this wouldn’t be revealed.

Does OP_CHECKSIGFROMSTACK intentionally allow cross-UTXO signature reuse?

Mike Schmidt: Right, exactly. And our last question this week from the Stack Exchange, “Does OP_CHECKSIGFROMSTACK (CSFS) intentionally allow cross-UTXO signature reuse?” And this kind of connects back to our discussion last week on BIP446 and BIP448, when we were talking about OP_TEMPLATEHASH and re-bindable transactions. So, sort of riffing off of that, normally, Bitcoin sighashes, you’d bind to a specific UTXO, and so you can’t take a valid signature then from one input and then reuse it elsewhere; whereas CSFS deliberately does not do that. The signature is over some arbitrary message rather than a specific input to a transaction. And that might sound initially like a security issue, but that’s sort of the whole point. So, with something like OP_TEMPLATEHASH, you can build re-bindable transactions. So, that same commitment can be applied to a new UTXO. And that idea is sort of the foundation for L2 or LN-Symmetry. The potential next version of Lightning could use something like that. In that update mechanism, you have the channel state updated, and the old state doesn’t become a punishment vector the way it does in current Lightning. Anything to add there, Gustavo?

Gustavo Flores Echaiz: No, that makes sense. Thank you, Mike.

Mike Schmidt: Great. Well, we can pass it back to you, Gustavo, for the Releases and the remaining Notable code items.

Bitcoin Core 28.4

Gustavo Flores Echaiz: Yes, thank you Mike, perfect. So, now we have this week two releases. Bitcoin Core v28.4 is a maintenance release of a previous major release. So, here, a few bug fixes are backtracked around the whole unnamed legacy wallet migration failure that affected v30. So, some fixes that were later added when 30.2 was released to fix what was the vulnerabilities of 30 and 30.1, well now these are also backtracked to the v28. So, you can find in the release notes about three different PRs that address these issues. And additionally, there’s other build and CI changes, and the removal of one of the DNS seeds that was covered in the PR #33723. Luke Dashjr’s DNS seed was removed because it wasn’t compliant with the requirements for a DNS seed. You can find the release notes directly on the newsletter to have more details around that.

Core Lightning 26.04rc1

Next one is Core Lightning 26.04rc1. So, this one has all the changes we were just discussing with Dusty around splicing, so the new ability to do cross-splices between two channels, and the new commands, splicein and spliceout. There’s some other different additions as well. One important one is now being able to include fronting_nodes as an option when you create a BOLT12 offer. This allows you to specify preferred peers that help route payers to your invoices and offers. And actually, this can apply to both BOLT11 and BOLT12.

There’s multiple other highlights for users and for developers, since this is also a developer-heavy release which has multiple improvements for developers. So, please check it out if you want to test it. If you want to learn more about it, you can find more details on the RC announcement on GitHub. And there’s also the changelog, which would give you the full picture of the PRs and the comments that are part of this release. So, that completes the Release section.

Bitcoin Core #33259

So, on the notable code and documentation changes, we have three PRs on Bitcoin Core, so we’ll start with them. The first one, #33259, is a new field that is added to the getblockchaininfo RPC response, that is called backgroundvalidation, and is built for nodes that use assumeUTXO snapshots. So, what this new field does is that it gives you the snapshot height, the current block height and hash for background validation, median time, chainwork, and verification progress. So basically, if you have an assumeUTXO node that has synced from the snapshot block towards the tip, and you have fully synced to the tip, now you will do background validation. That means validating all the blocks that came before the snapshot. You can do that while you are, let’s say, synced to receiving new blocks as well.

So, previously, getblockchaininfo wouldn’t give you any info on your background validation. It would simply indicate that IBD (Initial Block Download) was completed and verification was completed, because it wasn’t specifying additional information for assumeUTXO nodes. So, it was just assuming it was a regular node and it would see you had synced to the chain tip. So, it would just tell you that IBD was complete. However, your node was still running background validation. So, this new field now gives you all the info you need while you’re in background validation as an assumeUTXO node, which now gives you more visibility into the current status of your node.

Mike Schmidt: Makes sense. Yeah, pretty good usability addition there, pretty straightforward.

Bitcoin Core #33414

Gustavo Flores Echaiz: Exactly. Next one is Bitcoin Core #33414. Here, Bitcoin Core enables what are called the Tor proof of work defenses. So, this was a concept that was added to Tor a few years back, where basically an onion hidden service can require clients that connect to it to make some proof of work before being able to connect to it. So, it’s a way to distinguish real users from attackers, and it’s a defense that can be added to onion services. So, now this PR enables these proof of work defenses for automatically created onion services when supported by the connected Tor daemon. So, if you have a Tor Daemon that has the version that supports proof of work defenses, and Bitcoin Core automatically creates this onion service, it will automatically enable the proof of work defenses. But this only happens when your Tor daemon has an accessible control port and Bitcoin Core listenonion setting is on, which it is by default. So, this will make Bitcoin Core automatically create a hidden service, and it will enable the proof of work defenses.

For those that are manually creating onion services, it’s suggested that the users add to their Tor config the required setting to enable proof of work defenses, but this PR is about enabling, by default on, automatically-created onion services.

Bitcoin Core #34846

The next one is Bitcoin Core #34846. Here, two new functions are added to get the locktime and the nSequence of an input, so the transactions and locktime field, and the inputs and sequence field, which are the timelock fields. This is added to the libbitcoinkernel C API that we had introduced in Newsletter #380. So, libbitcoinkernel has been discussed multiple times before, and it basically allows external software to simply leverage the internal code of Bitcoin Core and not have to use things that are not part of the internal kernel. So, now this new libbitcoinkernel C API has additional functions that allow you to get the timelock fields. And this is specifically important when you want to check BIP54 rules, such as the coinbase transaction nLockTime constraints, without manually deserializing the transaction. So, you can directly just obtain these fields without having to do additional work.

However, the other BIP54 rules still require separate handling. This is specifically about the coinbase nLockTime constraints in BIP54, also known as the consensus cleanup soft fork. So, this is about fixing the duplicate transaction vector that could affect some early coinbase transactions, and this basically enables to remove the enforcement of the BIP30 checks that were previously required. With the consensus cleanup soft fork, we can basically remove that requirement. And this PR that I’m just discussing allows an external software using the libbitcoinkernel C API to access these fields more easily.

So, the next two PRs, or three PRs that we cover are those from CLN, which we discussed earlier on with Dusty. So, that was the extension of the CLN’s splice scripting engine that would enable it to handle cross-channel splices, multi-channel splices, and dynamic fee calculation. That was #8450, which Dusty gave a lot of details about that. And the next ones, #8856 and #8857 were combined into one item, which are the new splicein and spliceout commands.

Eclair #3247

So, next one is Eclair #3247, where this was highlighted as an important change, because it adds an optional peer-scoring system that enables a node to track forwarding revenue and payment volume per peer. So, this is disabled by default but when it’s enabled, it periodically ranks peers by profitability, and could then optionally automatically fund channels to top-earning peers, or automatically close unproductive channels of peers that are not making forward revenue to our node. There’s also other automatic settings, such as the automatic adjustment of relay fees based on volumes. And this can all be very much configured. You can start with visibility only before opting into automation. But this was a missing piece for specifically people that will use nodes for routing payments and earning forwarding income, to now have full visibility on the statistics specific to each of their peers in each of their channels, and then the capability to take automatic actions to further optimize their revenue.

LDK #4472

So, the next one is LDK #4472 which Dusty also gave us a bit of explanation around it. So, this was a potential fund-loss scenario that affected LDK, because there was a sort of lag of how you had already released the tx_signatures without having persisted the commitment signature of your counterparty, which made it that if your node would crash, then you could lose the ability to enforce the channel. But now, the fix, like Dusty explained, defers releasing this tx_signatures until you’re absolutely sure that you have persisted that counterparty’s committing signature. And that means that you would be absolutely sure that you can enforce your channel state. Because in Lightning, if your peer does a unilateral exit, you want to be able to contest directly on the Bitcoin Network that if your peer tries to cheat and tries to publish a previous state that was invalid, you want to be able to have your counterparty’s commitment signature to be able to contest that. But if you hadn’t persisted it effectively, then you would lose that ability. So, this PR ensures all the steps happen in the right order to avoid fund-lost scenarios.

LND #10602

So, the next two are from LND. The first, LND #10602, is a new RPC that is added to the switchrpc subsystem. So, this new RPC is called DeleteAttempts. But before explaining that, I’m going to maybe give a background on what this switchrpc system is. So, in Newsletter #386, we discussed the introduction of an experimental subsystem called switchrpc, which allows an external controller software to handle pathfinding and payment lifecycle management while using LND for HTLC (Hash Time Locked Contract) delivery. So, that means that in that coverage, we included BuildOnion, SendOnion, and TrackOnion RPCs. So, this basically allows external software to do the pathfinding, to find the route for the payment, and then to simply tell LND, “Hey, can you build this onion, send it, and then track it?” So, this was covered in Newsletter #386.

Now, there’s been a few additions ever since, but the one we’re covering in this newsletter is the ability to delete an attempt that was either successful or failed, so that LND doesn’t have it anymore in its attempt store records. So, you have to ensure, as an external controller software, to have properly persisted, or to no longer have a need for LND to track the attempts that you had dispatched previously with the SendOnion RPC in the switchrpc system. So, this is just an additional command that is added to the system so that people can better manage the records that are kept in LND’s attempt store. All good, Mike? Perfect.

LND #10481

So, the next one is LND #10481. Here, a new bitcoind miner backend is added to LND’s integration test framework. So, as you might know, the team behind LND is also the team behind the btcd implementation of a Bitcoin node in Go. And a lot of the code in LND used to be heavily dependent on having btcd as the Bitcoin backend of the LND software, or as some call it, the chain backend. So, previously, before this PR, lntest, which is LND’s integration test framework, was assuming that a btcd-based miner was going to be used, even when bitcoind was used as the chain backend. So, what this PR does is it adds or creates a new bitcoind miner backend that can be used in LND’s integration test framework when bitcoind is used as a chain backend. So, it’s basically extending the support it has for btcd to bitcoind, which is Bitcoin Core.

So, this change allows tests to exercise behavior, specifically on the miner side of things, that depend on Bitcoin Core’s specific features, such as v3 transaction relay and package relay. So, everything that touches mempool and mining policy that only exists in Bitcoin Core can now be properly tested within LND with this new addition.

Mike Schmidt: Awesome. Thanks, Gustavo. Thanks for co-hosting this week as well. We missed Murch, but it was great to have Dusty on as a guest this week. And we thank you all for listening and we’ll hear you next week. Cheers.

Gustavo Flores Echaiz: Thank you.

Bitcoin Optech Newsletter #398

2026-03-27T00:00:00+00:00

This week’s newsletter includes our regular sections with selected questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

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

Selected Q&A from Bitcoin Stack Exchange

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

● What is meant by “Bitcoin doesn’t use encryption”? Pieter Wuille distinguishes encryption for purposes concealing data from unauthorized parties (which Bitcoin’s ECDSA cannot be used for) from the digital signatures Bitcoin uses for verification and authentication.
● When and why did Bitcoin Script shift to a commit–reveal structure? User bca-0353f40e explains the evolution from Bitcoin’s original approach of users paying directly to public keys toward P2PKH and then to P2SH, segwit and taproot approaches, where spending conditions are committed to in the output and only revealed when spent.
● Does P2TR-MS (Taproot M-of-N multisig) leak public keys? Murch confirms that a single-leaf taproot scriptpath multisig exposes all eligible public keys on spend since OP_CHECKSIG and OP_CHECKSIGADD both require that the public key corresponding to the signature is present.
● Does OP_CHECKSIGFROMSTACK intentionally allow cross-UTXO signature reuse? User bca-0353f40e explains that OP_CHECKSIGFROMSTACK (BIP348) deliberately does not bind signatures to specific inputs which allows CSFS to be combined with other convenant opcodes to enable re-bindable signatures, the mechanism underlying LN-Symmetry.

Releases and release candidates

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

● Bitcoin Core 28.4 is a maintenance release for a previous major release series of the predominant full node implementation. It primarily contains wallet migration fixes and removal of an unreliable DNS seed. See the release notes for details.
● Core Lightning 26.04rc1 is a release candidate for the next major version of this popular LN node which includes many splicing updates and bug fixes.

Notable code and documentation changes

● Bitcoin Core #33259 adds a backgroundvalidation field to the getblockchaininfo RPC response for nodes using assumeUTXO snapshots. The new field reports the snapshot height, the current block height and hash for background validation, median time, chainwork, and verification progress. Previously, getblockchaininfo’s response would simply indicate that verification and IBD were complete with no information on the background validation.
● Bitcoin Core #33414 enables Tor proof of work defenses for automatically created onion services when supported by the connected Tor daemon. When a Tor daemon has an accessible control port and Bitcoin Core’s listenonion setting is on (default), it will automatically create a hidden service. This doesn’t apply to manually created onion services, but it’s suggested that users add HiddenServicePoWDefensesEnabled 1 to enable proof of work defenses.
● Bitcoin Core #34846 adds the functions btck_transaction_get_locktime and btck_transaction_input_get_sequence to the libbitcoinkernel C API (see Newsletter #380) for accessing timelock fields: a transaction’s nLockTime and an input’s nSequence. This allows checking BIP54 (consensus cleanup) rules such as coinbase nLockTime constraints without manually deserializing the transaction (other BIP54 rules, such as sigops limits, still require separate handling).
● Core Lightning #8450 extends CLN’s splice scripting engine to handle cross-channel splices, multi-channel splices (more than three), and dynamic fee calculation. A key problem this solves is the circular dependency in fee estimation: adding wallet inputs increases transaction weight and therefore the required fee, which may in turn require additional inputs. This infrastructure underlies the new splicein and spliceout RPCs.
● Core Lightning #8856 and #8857 add splicein and spliceout RPC commands for adding funds from the internal wallet into a channel and for removing funds from a channel to the internal wallet, a Bitcoin address, or another channel (effectively a cross-splice). The new commands avoid operators having to construct splicing transactions manually with the experimental dev-splice RPC.
● Eclair #3247 adds an optional peer-scoring system that tracks per-peer forwarding revenue and payment volume over time. When enabled, it periodically ranks peers by profitability and can optionally auto-fund channels to top-earning peers, auto-close unproductive channels to reclaim liquidity, and auto-adjust relay fees based on volume, all within configurable bounds. Operators can start with visibility only before opting into automation.
● LDK #4472 fixes a potential funds-loss scenario during channel funding and splicing where tx_signatures could be sent before the counterparty’s commitment signature was durably persisted. If the transaction confirms and the node then crashes, it would lose the ability to enforce its channel state. The fix defers releasing tx_signatures until the corresponding monitor update completes.
● LND #10602 adds a DeleteAttempts RPC to the experimental switchrpc subsystem (see Newsletter #386) to allow external controllers to explicitly delete completed (succeeded or failed, not pending) HTLC attempt records from LND’s attempt store.
● LND #10481 adds a bitcoind miner backend to LND’s integration test framework. Previously, lntest assumed a btcd-based miner even when using bitcoind as the chain backend. This change allows tests to exercise behavior that depends on Bitcoin Core’s mempool and mining policy, including v3 transaction relay and package relay.
● BOLTs #1160 merges the splicing protocol into the Lightning specification, replacing the draft in BOLTs #863 with updated flows and test vectors for edge cases that motivated the rewrite (see Newsletter #246 for discussion when that draft was under active development). Splicing lets peers add or remove funds without closing the channel; negotiation begins from a quiescent state (BOLTs #869, Newsletter #309). The merged BOLT2 text covers interactive construction of the splice transaction, continuing to operate the channel while a splice is unconfirmed, RBF of pending splices, reconnect behavior, splice_locked after sufficient depth, and updated channel announcements.

Bitcoin Optech Newsletter #397 Recap Podcast

2026-03-24T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Matt Corallo, Gregory Sanders, and Sebastian van Staa to discuss Newsletter #397.

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

Download audio

News

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

Changes to services and client software

● Cake Wallet adds Lightning support (1:06:09)
● Sparrow 2.4.0 and 2.4.2 released (1:13:15)
● Blockstream Jade adds Lightning via Liquid (1:15:33)
● Lightning Labs releases agent tools (14:49)
● Tether launches MiningOS (1:17:38)
● FIBRE network relaunched (1:35)
● TUI for Bitcoin Core released (1:19:34)

Releases and release candidates

● Bitcoin Core 31.0rc1 (28:24)
● BTCPay Server 2.3.6 (1:20:55)

Notable code and documentation changes

● Bitcoin Core #31560 (1:21:55)
● Bitcoin Core #31774 (1:23:35)
● Core Lightning #8817 (1:25:12)
● Eclair #3265 (1:27:41)
● LDK #4427 (22:36)
● LDK #4484 (23:45)
● BIPs #1974 (49:52)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #397 Recap. Today, we have our monthly segment on Changes to services and client software, which this month includes the relaunch of the FIBRE network, and we also are going to talk about the L402 protocol. We also have our Releases and release candidates segment, and this week we’re going to talk about Bitcoin Core v31.0rc1; and we also have our weekly Notable code and documentation changes, where we touch on a BIPs PR around OP_TEMPLATEHASH. This week, Murch, Gustavo, and I are joined by three guests. We’ll have them introduce themselves quickly. BlueMatt, who are you?

Matt Corallo: Hey, yeah, thanks for having me. Yeah, I wrote the original FIBRE network, so I guess that’s why I’m here today.

Mike Schmidt: That’s right. Instagibbs?

Greg Sanders: I’m at Spiral. I do various things, including looking at respective soft forks, and I’ve done other things like Lightning. Yeah, that’s about it.

Mike Schmidt: Sebastian.

Sebastian van Staa: Hi, thank you for having me. I’m a developer, I’ve been developing things for a long time. I’ve been following Bitcoin for a long time and now I’m getting started contributing to Bitcoin Core full time.

Mike Schmidt: Awesome. Thank you three for joining us. For those listening along at home, we’re going to go just a touch out of order in deference to our guests. So, I hope you guys can handle that.

FIBRE network relaunched

We’re going to jump into the Changes to services and clients segment, jump down to, “FIBRE network relaunched”. Matt, your network, what was the FIBRE network? Why did it get shut down? And then, what is this new incarnation?

Matt Corallo: So, FIBRE stands for the Fast Internet Block Relay Engine. That’s the British spelling for those of you Americans. And it exists to allow miners or other groups to forward blocks very, very quickly. So, it’s really important for miners. If you’re a miner and there’s a block found somewhere in the world, you want to make sure you get that to your nodes as fast as possible so that your nodes can start mining on the new tip and you’re not trying to do a reorg, which you might very well lose. So, it’s a patch set to Bitcoin Core. It was written quite a number of years ago. It was written around the time of compact blocks, and compact blocks is built kind of as a part of FIBRE. I ran a kind of “production network” on it, so offering basically just running these nodes, connecting them to each other to relay blocks very quickly between them, which was available for any pool or any miner to connect to, some number of years ago, basically when it was originally written. But there was limited uptake.

So, today, mining is mostly large pools. Some of them have their own relay logic. They’re hosted on large servers that they rent that have really good connectivity and, and, and. And so, they do fine on relay. They could be better. And in fact, when the original FIBRE network got shut down, we did see a little marginal increase in block orphans, or sorry, not orphans, Murch is going to yell at me.

Mark Erhardt: Stale blocks.

Matt Corallo: Stale blocks, thank you! So, it helped a little bit, but not materially, and pools kind of didn’t care very much. But now, there’s this kind of resurgence in attempts at re-decentralizing mining. So, that’s Stratum v2, that’s P2Pool v2, that’s Braidpool, that’s DATUM, that’s all these new attempts to say, “Okay, actually we’re going to select blocks at the edges, which is the critical part for Bitcoin. We’re going to actually do transaction selection at the mining level”. But for that to work, edge miners that might not have perfect connectivity and might not have people on staff to ensure they have perfect peering, somehow need to have a good way to get blocks very quickly. And so, a public FIBRE network offers them a potential avenue to get blocks. Now this just supplements the existing P2P network. Obviously, they’re still going to make normal P2P connections, they’re still going to run a normal node. But it’s important to have something that is well-optimized. And if they don’t have the resources to do careful optimization, it’s nice to have something that exists just kind of out of the box. They can just go to their bitcoin.conf, they can addnode one of these nodes, and they’ll probably get blocks a little faster.

So, Localhost spent a bunch of time rebasing the old FIBRE patch set, which had gotten quite stale, into modern Bitcoin Core, and stood up a production network with better monitoring and dashboards, and whatever the original one never had, to offer this to miners as a part of some of their other work helping to re-decentralize mining.

Mark Erhardt: Yeah, I want to add a couple of things. So, my colleagues have been working on this for the past few months. You can think of the FIBRE network essentially as one big node that has multiple IP addresses in different regions, but synchronizes block and transaction data as quickly as possible between the instances, and disseminates it to the peers it’s connected to from all of these IP addresses. So, essentially, it’s just sort of a highway to get the blocks to all of the regions on the planet and spread it from there. And one other, I think, inspiration or goal here was, in the last year, we’ve seen a couple of different reasons why the mempools have gotten a lot less homogenous between different nodes on the network. So, on the one hand, miners suddenly started accepting low feerate transactions. For 12 years or so, the minimum feerate had been 1 sat/vB (satoshi per vbyte), and suddenly miners started accepting lower feerates. So, we had a huge spike of transactions that most nodes didn’t have in their mempools. And we can see that in block propagation statistics, having increased mostly, like, the time that it took for blocks to arrive with most of the nodes, but not the 50% threshold, just a little bit on the latter. So, blocks were still spreading quickly, but not reaching the entire network as quickly as before. And the other one, of course, being people feeling very strongly about what other users may do with the Bitcoin Network and filtering some transactions out of their mempools.

So, blocks were just propagating a little slower than usual in 2025, which also made people think, “Well, let’s have this parallel highway where we also propagate blocks quickly”. Matt?

Matt Corallo: I don’t think I have anything else to add there.

Mark Erhardt: Maybe one more thing, currently it’s in beta still, so we’re still experimenting a little bit and figuring out exactly how we let other people connect, make inbound connections, because of course it hinges on being able to communicate quickly between its own nodes. And if suddenly thousands of nodes were to connect it, that might DoS it or weigh it down. So, it’s currently a beta and hopefully will be fully live very soon.

Mike Schmidt: Well, that touches on one of my questions. From what Matt explained, it sounds like the big boys maybe have this sort of architecture set up, maybe not at this exact topology, but some optimizations in place. And this is maybe for the medium or smaller long tail set of miners. And that leads to my question, which is riffing off what you said, Murch, which is, is FIBRE network going to have to support all of this long tail, or is it sufficient to just get some nodes in some regions that would sufficiently speed up propagation, or is everyone going to be connected on FIBRE?

Matt Corallo: Sadly, I think a big challenge with P2P networks generally is you have this trade-off. So, when we’re talking about just engineering – and I promise I’m working towards your question – when we’re talking about just designing the layout of the Bitcoin P2P Network, there’s this kind of trade-off between robustness and low latency. So, you could imagine Bitcoin Core nodes aggressively connecting to peers that had low latency, that they were close to, to try to structure the topology of the Bitcoin Network such that it’s actually kind of geographically topographical, so you’re kind of connected only to peers that are close to you. But this would absolutely wreck reliability, right? That means you’re only connected to peers who are close to you and no one ever connects to peers who are far away, and then blocks never get to you to begin with. So, it not only has trade-offs, but it’s also kind of fundamentally very, very difficult and nigh impossible to lay out the P2P network in such a way that it optimizes for low latency block propagation.

So, to your question, there’s not really a great way to say, “Okay, well, just one node in a region is going to get a block quickly and then other miners are going to connect to it”. You kind of have to just say, “Look, if you’re mining, you should be able to connect to this public network in some way to get blocks quickly”, so that anyone who’s mining has that kind of fair shot, without having to spend the engineering resources to build their own relay network. Of course, Localhost has done a good job. They wrote up whole documents about how to run your own FIBRE network if you wanted to. So, they do make it easy. You just kind of take the code and you get servers all around the world, and then you’ve got to somehow make sure they peer with other miners. So, they did try to make it easy, but there’s still some effort involved there in having globally-distributed servers and getting peers with other miners, etc.

Mark Erhardt: Yeah. So, for example, mining organizations could run this themselves as well, if they wanted to. The code is open, of course. And one of the ideas that we’ve been discussing is that we might have some border nodes. So, the border nodes would be the things that you connect to, and then the FIBRE nodes themselves connect to each other and the border nodes. So, you get sort of this one hop in between to insulate it against DoS attacks, but make the border nodes publicly known. But I’m not directly working on this, so take this with a grain of salt. I’m not speaking for the people running FIBRE directly. Either way, the idea is just getting the blocks to more peers more quickly will help everyone, because the more peers have the blocks quickly, the more nodes will propagate them to others. It’s sort of like opening a second cash register, even if the person is super-slow, will make the customers flow through the cash registers faster, right?

Mike Schmidt: How do we quantify it? What metric do we quantify? Like, if there’s a medium- or small-sized miner that’s listening and they’re like, “Do I need to get on this or not?” how would they think about what they get by being on it or not, if they wanted to be directly peering with one of these?

Mark Erhardt: I mean, hopefully the FIBRE network would be the source of bringing the block to them first very often, so they would see just marginally faster block announcements.

Matt Corallo: Yeah, it should be basically free, right? It’s purely additive. There’s just an extra connection you make in your Bitcoin node, and if it happens to beat the P2P network, which it basically always will, great, you’ll get your blocks a little faster. If it doesn’t, shame.

Mark Erhardt: Maybe also to clarify, I think a lot of people misunderstand this. FIBRE nodes are just regular Bitcoin nodes from the perspective of other nodes. From the outside, they behave exactly like any other Bitcoin node. You wouldn’t be able to tell that they’re different, except internally they stream the blocks faster by using Forward Error Correction and UDP, and then pushing out blocks to all of their peers that elected the FIBRE node to be high-bandwidth peers. And the main idea is, Bitcoin Core elects nodes to be high-bandwidth peers when they provide information early often. Like, if you’re often the node that first announces a block, the peer will say, “Hey, would you like to be my high-bandwidth peer and just give me the block before you even validate it?” This is an aspect of the compact block relay scheme. And so, the idea would be that the FIBRE node would be organically elected to be the high-bandwidth peer to a lot of peers often because it has the block first, and that way it would get to peers very quickly.

Mike Schmidt: Anything else listeners should know about FIBRE? Where should people go, other than referencing the newsletter, the Localhost blog?

Mark Erhardt: Yes, and I think, well, there should be a website with the dashboard.

Matt Corallo: Yeah, I think bitcoinfibre.org has been updated to point to the Localhost instance now.

Lightning Labs releases agent tools

Mike Schmidt: All right. Well, we have another Client and service item that I think Matt can help us with before we have him also help us with some LDK PRs. The title of this one is, “Lightning Labs releases agent tools”. This covers Lightning Lab’s open source toolkit for AI agents to operate on the LN without human intervention or API keys. We mentioned the L402 protocol. Matt, I think you’ve been beating the drum on this the last few weeks as well. What is everyone excited about? What’s changed here? What is L402? How do we get the AIs using Bitcoin?

Matt Corallo: Yeah, so there’s a plethora of different payment protocols for agents, right? So, AI agents can’t really directly use a credit card. There’s a lot of fraud liability questions around who’s responsible for fraud if an agent screws up. Obviously, LLMs today screw up quite often. And so, who’s responsible for that, has some major questions. As a result, Visa and MasterCard are pushing their own agentic payments spec that is different from their traditional credit card flows, requires more manual intervention by the human, which limits the agentic-ness of an agent, and kind of defeats some of the point. So then, on the flip side, a lot of people are concluding that the alternative of crypto is somehow better. And so, this has basically been a story of Bitcoin via stablecoins. Stablecoins have large corporate backing, of course, Coinbase, PayPal, kind of everyone has their own stablecoin now, especially with the law change to get some clarity in the US. Now everyone wants to issue a stablecoin, I think we’re going to see a lot more stablecoins in the near future. And then it’s all that versus Bitcoin.

So, Bitcoin has, I think, a strong potential here as something that’s neutral and open and not tied to some corporation that could take your money from you, that can freeze your assets. And also, that is getting the interest and has potential to increase fees in the future, once they’re kind of the dominant player. But ultimately, it’s all about having agents holding the same currency, or at least being able to pay in the same currency that merchants want. So, it’s the same classic chicken-and-egg problem that we’ve had with Bitcoin payments in the past. The only difference is this time, everyone’s in the same boat. So, Visa and MasterCard don’t have some ready-built solution for this, merchants have to upgrade to support it. Same with Stablecoins, same with Bitcoin. Everyone has the same chicken-and-egg problem. So, this puts us kind of on an even footing for the first time for Bitcoin payments. And so, I think it’s really exciting that we have an even footing and that we have a real shot here. But there’s a lot to build to get there and we have to really convince merchants to start taking Bitcoin Lightning payments.

L402 and the myriad of other protocols, most of which support Bitcoin, certainly not all of them, are a great start there. And Lightning Labs has this tool, two of them actually, L402 and the new one that Tempo did, I’m blanking on the name of it. I don’t think it supports Lightning over x402, which is a separate thing, some billion specs here, but it supports a few things and it’s a useful tool to be able to test these things and pay them. I would note, I think, agents generally, like LLMs, don’t have a problem writing some code really quickly to pay something, right? If it tries to fetch a website and the website returns a 402 with a text string that just says, “Pay this invoice and then refresh the page”, an agent will have no problem figuring out like, “Oh, I have a Bitcoin wallet, let me pay it. Okay, now I can pay it, now I can refresh the page”. It doesn’t really matter what the specific protocol is.

So, there’s kind of a, I don’t know how to phrase this, let’s call it a Web 2.0 obsession with owning the protocol and defining the standard and the API, and LLMs don’t care. The specific API doesn’t matter anymore. It just matters that it’s simple and readable and that you can describe it in a few sentences, so the LLM can just write some code really quick to call it; and more importantly, that the LLM actually has access to a Bitcoin wallet. So, Lightning Labs has done some cool work, but there’s also moneydevkit and Alby Hub and phoenixd skills that you can add to your agent. And also, there’s some Cashu wallets that are agent-first that you can add to your agent. You can give your agent access to a Bitcoin wallet and give it some small amount of money; you don’t give it all your coins! And then, it will have the ability to pay for things in Bitcoin. And there’s a slow but growing number of merchants who offer that.

Ryan Gentry, formerly of Lightning Labs, also launched a 402, what’s it called? The 402 Registry, I think he called it, that just lists a bunch of merchants that accept payments, both stablecoins, but also Bitcoin, using these standardized 402-based protocols, of which there are at least three, maybe four now, and that agents can use to find merchants that will take stuff so that you can just text your OpenClaw and say, “Hey, buy me some whatever”, and it’ll show up at your door and you don’t have to think about it, and it’ll just figure itself out.

Mark Erhardt: Wait, so you’re saying that Bitcoin might be the native currency of the internet?

Matt Corallo: I’m saying we have a shot, but we have a lot to build and a lot of merchants to convince to integrate Bitcoin before we get there.

Mark Erhardt: Right. But in this case, I think very specifically what makes this attractive is having an agent control a Bitcoin wallet where you don’t have to interact with a bank or credentialed institution that KYC’s you, and so on, makes the setup on the agent side, I think, much more straightforward. So, hopefully not just an equal footing, but it makes sense for this application.

Matt Corallo: Yeah, entirely. Yeah, there’s all kinds of issues with why just giving your agent your credit card number or something doesn’t work. And again, that is why Visa and MasterCard are trying to build new things that I think are all very short. And so, it’s really just Bitcoin via stablecoins. And I do think actually, people see these wild claims of how many merchants take stablecoins. It’s really not that high. They’re not used that much, especially in the West, for more traditional commerce. Bitcoin is actually taken by, I would say, more merchants. It’s hard to get good numbers really. But there are merchants who think Bitcoin is cool and then want to take Bitcoin, and then there are those who take stablecoins. But no one is like, “Oh, stablecoins are awesome. I love stablecoins”. They’re like, “The future, and I have a strong buying with stablecoins”. It’s like, “No, who cares? They’re just dollars on tokens, right?”

So, we do have a bit of an advantage, but we have to play to it, we have to drive it forward as quickly as we can, we have to actually get merchants to take Bitcoin.

LDK #4427

Mike Schmidt: Awesome. Thanks, Matt. We want to move down to the Notable code segment, because Matt is involved with LDK and we have two LDK PRs that he could walk us through. Matt, if you still have time, LDK #4427 titled, “RBF splice funding transactions”. What’s happening?

Matt Corallo: Yeah, so we shipped splicing in our last release, 0.2, but we didn’t actually have support for RBFing those transactions. So, you do a splice, basically you have all your money in a Lightning channel, you do a splice to make an onchain payment or receive some onchain funds, you add it to your Lightning channel, and then it doesn’t confirm because you didn’t pay enough fee, and now you’re stuck. So, we finally have logic landed to support RBF. We’re still finalizing cleaning up the API and hoping to get a release out relatively soon with support for it formally. But yeah, it’s the final piece of the splicing logic, basically.

Mark Erhardt: Luckily, for the moment, the fees have been incredibly low, so your standard fee will probably suffice. Almost every block, fees are still around 0.14 sats/vB to be in the next block. So, this is forward-looking. For the most part, hopefully that will work out of the box right now.

Matt Corallo: Yeah, that’s true.

LDK #4484

Mike Schmidt: And we also have LDK #4484, “Set max channel dust limit to 10,000 sats”.

Matt Corallo: Yeah, and this is an old limit. So, early-ish in Lightning’s history, some number of years ago, Lightning nodes didn’t explicitly limit their dust exposure. So, this is basically, if you were to force close the channel, how much money actually just gets burned to fees because the HTLCs (Hash Time Locked Contracts) were too low to be onchain, or because there’s some attacks where maybe your counterparty set the fee really high because they’re a miner so they can try to claim that money; basically, money that you might lose in a force closure that you thought you had. And one way to limit this is nodes fixed the HTLC dust limit to say basically, if an HTLC is over this limit, it will appear onchain, it will be in an output, and they set that to basically the minimum value that was non-dust onchain.

At some point, nodes realized this wasn’t sufficient and started more explicitly limiting their dust exposure. So, when the channel gets updated, they take a look at the commitment transaction, they say, “Okay, well if I were to force close this, I would lose this much to fees”, and they would say explicitly like, “No, that’s too high. I’m not going to accept this update”. Now that they do that, we have we can go back and remove the original limit, because there’s no reason for it anymore. We can just say, “Okay, well we have the explicit monitoring of dust exposure, so we don’t have to fix the HTLC dust exposure”. And Phoenix wanted to actually deploy this, or Eclair wanted to deploy this in production, so that they stop getting these 300-sat HTLCs that appear onchain, which they can’t really economically claim, it’s not really worth it, and they’d rather just let them disappear. But other nodes have to stop enforcing this old rule in order to allow them to do so.

Mark Erhardt: So, this is actually an increase of the limit rather than a decrease or tighter limit?

Matt Corallo: Correct. Yes, we are increasing the limit. We didn’t keep a limit, just because it wasn’t clear why anyone would want it to be too high and you never know. But yeah, we’re substantially increasing the limit from 300 or something to whatever it was, 1,000 or 10,000.

Mark Erhardt: So, sorry, you as a node operator would set this limit and this is the sum of the amounts that you have in your channels; or is this per single HTLC or per single channel?

Matt Corallo: No, this is per single HTLC. So, you don’t set this manually, this is actually hardcoded. And it’s just, okay, technically, so your peer sends a limit and says, “Hey, if I end up force closing, the transactions that are built for me to force close should not include any HTLCs below this number”. And when the channel is set up, that number is defined, each peer gets to set their own number. And the counterparty has to look at that number and decide whether to accept it. And it used to be that we would only accept a counterparty setting exactly the bare minimum, which was 300 or whatever sats, to make a transaction standard. And now, we allow a counterparty to set a much higher potential number if they want. Obviously, they don’t have to.

Mark Erhardt: Okay, so basically, you allowed the other party to be more restrictive on small HTLCs than before?

Matt Corallo: Yes.

Mark Erhardt: The other party can require a larger minimum HTLC?

Matt Corallo: Yes, that’s correct.

Mark Erhardt: Okay, cool. Thank you.

Mike Schmidt: We referenced PR to the BOLTs repository #1301, dust_limit_satoshis, as a relation to this PR. I don’t know if you mentioned that, but is that true? Is this related to that PR?

Matt Corallo: Yes. That PR more explicitly updated the specs to reflect the desire to be able to set this.

Mike Schmidt: Okay, Matt, thanks for joining us. We know you have to jump, so thanks for your time.

Matt Corallo: Yeah, thanks for having me.

Bitcoin Core 31.0rc1

Mike Schmidt: We’ll jump to Release Candidate for Bitcoin Core 31.0rc1. And we didn’t get into the details of what’s in this release just yet. But we do reference a testing guide, which was authored in part by Sebastian, who’s joined us. And maybe Sebastian can outline some of the features in this RC, as well as how to test them. Maybe to start, Sebastian, how did you come to be one of the authors of this testing guide?

Sebastian van Staa: I took part in the BOSS Challenge this year and I got into the final round, and I was asked to do some more contributions. And this was one of the things that got me started to actually write the release testing guide, together with Jan B. And yeah, it was one of the tasks. It was a fun experience for me. I used to be on the other side of this for a long time, just testing stuff. And it was very, very educative and fun. To say, I think this is mainly educational content. It adds a bit to the test coverage, but it’s also designed being not too hard, not too tough, to draw people into it who are technically inclined and want to just dive a little bit deeper. Of course, the release doesn’t rely on this alone. This would be very bad. We’ve got the continuous integration, we’ve got the code reuse, but this is also like an education. It’s one thing on top to get to know the new features, get your hands dirty and play around with it.

The biggest change this time was, of course, the cluster mempool. It didn’t get as much room in the release as it should have, being the major change it is. We are starting off very slow, so with the cluster mempool new RPC, we are, for example, creating a parent and a child transaction. The child transaction has a higher feerate, so basically the child pays for parent and we check that this ends up in one chunk. We do the other thing, we have a more valuable parent and a less valuable child, so that ends up in two chunks, and you get the idea. So, very basic tests, if the cluster mempool is actually doing what it’s supposed to do, chunking the transactions.

Mark Erhardt: Oh, so there’s a new RPC here called get mempool cluster and you parse a transaction, and then it will tell you about the cluster this transaction belongs to. Is that roughly the way it is?

Sebastian van Staa: Yes, yes, roughly that’s the way it is. Also, there’s another RPC for the feerate diagram, and you should get this linearized feerate, which is very nicely explained in Pieter Wuille’s slides, but it will be difficult to explain it in this context for me in a way that people understand it. Let’s just say you can get the feerate diagram by RPC.

Mark Erhardt: I can give it a shot, if you don’t mind.

Sebastian van Staa: Thank you, yeah, go for it.

Mark Erhardt: So, in cluster mempool, we take all the transactions that are related to each other and they form a cluster. So, parents, children, and their children and parents. And then, we group them by the packages that we would pick into a block template together, which we call chunks. So, the feerate diagram is basically a diagram over fee to weight, and it just has the points of the chunks. So, each chunk that will be picked into the block together forms a point on the diagram, and that way you get sort of an overview of how much weight and how much fee will get into the block template together from this cluster.

Sebastian van Staa: And the important part here that it’s linearized, so it’s ordered. So, you’ve got to choose your targets first, and when you fill your block, you start with those. And I think that’s a very big thing, the linearization of the cluster. It’s algorithmically difficult. And so, the feerate diagram seems to be a graph which is rising to the right, yeah.

Mark Erhardt: Yeah, I should correct myself. This is not on one cluster, this is on the entire mempool. And this is getmempoolfeeratediagram, judging from your testing guide, I’m just reading that on the side here!

Sebastian van Staa: Okay! And we also have one test where a chain of transactions is created of 64, and we check that this ends up in one cluster, which is the new cluster limit. And we check that a chain of 65 transactions with a child-parent relation do not end up in one anymore. So, that’s the new cluster limit at 65 transactions.

Mark Erhardt: Right. That replaces the former limit on descendants or ancestors. We just have a cluster limit now. So, instead of just going downward or upward, just the entire group, the cluster is viewed and limited together.

Sebastian van Staa: Yes. Yeah, exactly. I think the cluster before was a lot smaller, I think it was 15 or was it 25?

Mark Erhardt: 25, yeah. 25 ancestors and 25 descendants, which because some descendants of ancestors could be different than your own, could mean that clusters were actually not limited in size. Clara and I did some block-template-building research a few years ago, and we found some clusters that had over 1,400 transactions.

Sebastian van Staa: Wow! That’s big. Okay, let’s continue on the list with another big change. Not as big, but still notable. It’s the private broadcast by Vasil Dimov. He’s been fighting for this for a long time. The idea here is that you can make sure a new transaction gets sent out over Tor or I2P, which means private. And we also have a small test for this. It would have been nicer to really test it, but on regtest, most of this runs, we don’t have Tor support. So, we can just check that it fails to use this flag on regtest. We thought about cooking up a bigger test case on testnet4 with Tor and stuff, but we kind of decided against it. But if anyone is interested, you should definitely set that up and check that this transaction gets sent out. If he has Tor and this flag, and if he has Tor turned off with that flag, it’s going to fail.

So, what else have we got? A small one. We’ve got the getblock RPC was updated, so the coinbase_tx field was extended a bit. Now we have one more field, which is actually the coinbase, very small change.

Mark Erhardt: Yeah, I think the main difference here is that the coinbase used to only be provided at verbosity level 3, which provided all of the transactions. But now, with work on BIP54, the consensus cleanup, people are more interested in the content of the coinbase transaction, because they wanted to see whether a coinbase transaction set the locktime, as proposed by BIP54, which would make them forward-compatible to BIP54 activating. This is a fix to ensure that coinbase transactions are unique. And so, the coinbase transaction is now provided at verbosity level 1 and 2 as well. I thought it was only 2. I might be mistaken here. So, at level 3 is everything, and level 2 already provides the coinbase transaction, and according to your testing guide, also on level 1. Yes, okay, you are correct. So, anyway, you’ll see the whole coinbase transaction in getblock now.

Sebastian van Staa: Yes, excellent. Thank you for clearing that up. We’ve got one more thing, the txospenderindex, which is a new feature as well, one more index now. It basically serves an RPC and it gives you back the TXO that gets spent. This is especially useful for L2 implementations. We saw that I think it used to fail if it wasn’t in the mempool, and now it can be looked up in the index, and we’ve got some examples of that.

Mark Erhardt: Right. So, it’s super-easy for a transaction to know where the parent came from, because of course in the input, we define the outpoint of the UTXO we’re spending, which is the txid and the vout vector. So, we always know what transaction created an input. But on the other side, it’s very difficult. From the transaction that created an output, we have a hard time telling which transaction spent that output later, because that’s of course not information that is available at the time that the output is created. And previously, that was not tracked. So, transactions like LN transactions, that are invested in tracking the channel anchors and seeing where they get spent, they are very interested in being able to track where specific UTXOs are spent. Or also, if you want to do a light wallet that is, for example, Electrum-based or so, that is an interesting index to be able to jump from the transaction that created an output to the one that spends it, which was previously much harder.

So, there’s an optional index that Bitcoin Core will start having, if you turn it on, and might make it easier to build Electrum-like software on top of Bitcoin Core, or to support Lightning as the backend better.

Sebastian van Staa: Yes, correct. Exactly. We’ve got one more thing, the dbcache. We’ve got the -dbcache setting, which is the coin’s cache. It used to be at 450 MB standard. So, now the standard or default value has been increased to 1,024. It’s quite a very simple test to check for that line on node startup, how much cache was allocated. If you don’t set the flag, it will be 1,024 altogether. This can be seen in the testing guide.

Mark Erhardt: Well, so just the dbcache is just keeping the UTXOs in cache and the latest created and the ones that were spent by transaction in the mempool are in this cache. And so, 450 had been the default for, I don’t know, ten years or so, and I think computers just generally got a little more powerful in average since then. So, we’ve increased the default here. This helps especially during IBD (Initial Block Download), but is useful also while nodes are running. This will only be increased on nodes that have a minimum of 4 GB, and it will only be increased on architectures with 64 bits, because 32-bit architectures generally cannot access more than 4 GB of RAM. So, in these 32-bit architectures, the limit will still be 450 by default, and only on machines that have more than 4 GB and are 64-bit architecture, it’ll be increased by default.

Sebastian van Staa: Yes, exactly. Thanks for the details. I think I was just booted, but you didn’t really notice, I’m back now. But I think I got most of your explanation about the 32 and 64-bit systems, which seems entirely correct.

Next point, a bigger change. We’ve got the ASMap, or whatever you pronounce it. I think, I’m not really sure, I’m going to call it ASMap. So, this is the first time – so AS was, dang, I forgot again, what was it again?

Mark Erhardt: Autonomous systems.

Sebastian van Staa: Autonomous systems, that was it, yeah, exactly. So, it’s basically mapping out the internet to make sure that the nodes get a very diverse range of partners. So, it makes it more resistant to Sybil attacks, it even more difficult to Sybil a node if it really chooses its coordinates from all over the internet. So, this used to be experimental. This is the first time the ASMap is actually baked into the binary. We did a collaborative testing run two weeks ago, where ten people ran a client that would try to map this out, which is, the whole thing is very volatile. Even if you have ten people start at the same Unix time, you will have maybe four or five people agreeing, so you can basically hash some data and compare the hashes. The process is now, I think, if five people agree, this is going to be the valid solution, it’s going to end up baked in the binary.

So, before, the -asmap flag would look for a particular file on the disk and just fail silently if it goes there. And now, if you set the -asmap flag, it will just take the data baked into the binary. And I think Murch wants to give some more detail how this works.

Mark Erhardt: Right. I wanted to tie this back briefly to the FIBRE point earlier. So, the autonomous systems are sort of the regions of the internet rather than, well, there’s the IP ranges and then on top of the IP ranges, there’s the autonomous systems. So, for example, Google will have multiple different IP ranges and an autonomous system map will show that all of those IPs belong to the same autonomous system. And Bitcoin Core uses this autonomous system map to make sure that it connects to a wide variety of autonomous systems to get its peers. And this sort of counteracts having low latency, because if you connect to an autonomous system in Germany and one in the US and one in China and generally try to distribute this as widely as possible, some of the peer connections that you have will be very quick, because they’re close to your own internet region where you have a low latency, but a lot of the other ones are going to be distributed all over the planet and might have a round trip time of 150 milliseconds or 200 milliseconds.

So, in a way we make ourselves very well protected against Sybil attacks, because we will not be connected to peers in one data center at the same time, but it makes us slower in latency to receive blocks, and so forth. So, the ASMap is basically a snapshot of the internet topology at the time that it is created, but it decays somewhat quickly, because autonomous systems keep announcing, “Oh, this IP is now mine”, or, “To route to that internet region, you should go through me now instead of someone else”. So, over time, these ASMaps get less accurate. So, we will provide new ones roughly, probably on every release, we’re going to provide a new snapshot. They do decay a little bit, but I think some people estimated about 1% per week or so, or no, that would be too quick. Anyway, I don’t remember the exact details. But these maps are good and in the broader picture, tend to stay somewhat correct for half a year, a year, but they need to be refreshed quickly to the point that when you take that snapshot, even if ten nodes, as Sebastian said, start at the same time, only five of them will get exactly the same ASMap at the same time.

Mike Schmidt: And we had Fabian on in Podcast #394, where we covered one of the PRs associated with this. And he walked through cartograph and the process of creating this file. And so, if you’re curious about some of the processes and the networking involved there, jump back to that one. Back to you, Sebastian.

Sebastian van Staa: Yes. One last point. There’s a new REST API endpoint, which is called blockpart. So, you can actually request parts of a block by giving the blockhash the starting offset and the size in bytes that will be handed back, which is also tested in the testing thing.

Mark Erhardt: Do you remember what the context is in which this was proposed?

Sebastian van Staa: Actually, I was just trying to remember, but I don’t. I’m just going to open the PR and see what the context was.

Mike Schmidt: I will stall for a second while you look into that. This is the caveat that Murch and I like to add when we do these testing guides and RC testing. This is sort of the caveat, and I think Sebastian sort of referenced this already, which is this is not comprehensive. This is just an idea to get your feet wet on some of these pieces of what is new. Obviously, everybody uses Bitcoin Core a little bit differently. If you use this RC in the way that you normally use it, and then report any issues you see, you may see things that are different or that aren’t even covered in this. And so, you don’t have to strictly just follow this. Yeah, Murch?

Mark Erhardt: I think, yeah, Sebastian, go ahead.

Sebastian van Staa: I just looked it up. I mean, as always, the idea is to save time and bandwidth. So, indexes like Electrs, they often have to look up the whole block or they have to use a method to get a certain index, like an RPC method. And just grabbing the bytes directly out of the block data is a lot faster. So, that’s the thing.

Mark Erhardt: Right. So, this PR was opened by, I think, a person involved in Electrs. And the main issue here is if you are getting a transaction, even if you have a txindex on Bitcoin Core, it sort of has to go to the right block file, then look up the offset from the start of the block, read out the transaction data and provide it. And if you’re consuming large parts of the blockchain with a secondary software for which the Bitcoin Core node is just the backend, you might want to consume whole blocks or chunks of blocks. That seems to be the context.

Sebastian van Staa: Yes, exactly. And that was the last point in the testing guide for today.

Mark Erhardt: Maybe just a call to action here would be if you’re interested in getting your feet wet, like Sebastian said, you can go through the testing guide. It walks you through playing around with some of the new features and updates. But also, this could be your next release. You could write the testing guide if you get involved in Bitcoin development, or you could help do Guix builds, where you just follow the instructions how to build the code from scratch in Guix. Or, you could help create the next ASMap.

Sebastian van Staa: Yes, and also, I almost forgot, there will be a PR Review Club on this on 8 April. So, usually, PR review means PR review, but this time, we’re just going through this release guide again together. I will answer questions, so please, if I got you interested, show up to the PR Review Club on 8 April.

Mike Schmidt: Awesome. So, test the RC, jump into the PR Review Club, anything else before we wrap this one up, any other calls to action? All right. Sebastian, thanks for putting this together, and thanks for joining us to walk us through it.

Sebastian van Staa: Thanks for having me. Cheers.

BIPs #1974

Mike Schmidt: We’re going to jump deep into the notable code segment and talk about a PR to the BIP repository #1974. This includes BIP446 and 448. We have OP_TEMPLATEHASH. We have TRT. Is that what we’re calling this? TRT? TNRT? THash?

Greg Sanders: TRT is Testosterone Replacement Therapy, right?! We really struggled to find a good acronym that wasn’t begging the question, you know.

Mark Erhardt: All right. Tell us a little bit about Taproot-native (Re)bindable Transactions, and TEMPLATEHASH, please.

Greg Sanders: Sure. So, these ideas are not new. Prior efforts were done. So, one example, is it still not good? Unfortunately, I can’t change my mic while recording. For some reason, the software doesn’t let me.

Mike Schmidt: I can hit buttons. It’ll be louder in production.

Greg Sanders: I’ll try talking closer. So, there’s been these ideas for years where if you can commit to the next transaction in script, so you know what you want your next transaction to be, you can take a hash of that transaction, stick it in a script output, and then the money can only be spent a certain way, right? So, there are a bunch of use cases for this, but over time, there actually ended up being more use cases for this. So, a classic use case here would be for Ark, which is before users are possibly even online, you have this coordinator build a tree of transactions that pays out users. They seed this tree and then users come online and do a little song and dance to get their copy of it. And this allows, on the average case, for the block space usage to be constant, while the number of users be growing. So, the vbytes usage does not grow linearly with users. So, that’s kind of one of the key things. So, there’s also the other use case, where if you know after the fact what you want to commit to, you can do that as well with counterparties. So, there’s, “We want to bind the next transaction either before or after the fact” based on the use case, and this is where this proposal comes in.

So, the first BIP, BIP446, is the TEMPLATEHASH, which is a kind of a taprootification, I’d say, of CTV (CHECKTEMPLATEVERIFY). It’s aimed at the exact same use case as CTV. And then, it’s bound up together with the CSFS (CHECKSIGFROMSTACK) proposal, which I don’t have in front of me, BIP348. And then, as an extra bonus, INTERNALKEY, BIP349. So, the key ones here are #446 and #348. Those are kind of the one-two punch of functionality that is being offered. And #349 is a simple cleanup, which reduces the kind of vbytes penalty when you do scriptpaths. Since you already have the internal key in your control block, you don’t have to pay for it twice in vbyte space. So, that’s kind of it. That is the high level pitch. I’ll pause for a second.

Mark Erhardt: Right. So, INTERNALKEY basically just gives you the internal key from the control block again.

Greg Sanders: Yeah, exactly.

Mark Erhardt: It allows it to be pushed on the stack so you can consume it, in order to do a CSFS.

Greg Sanders: Yeah. So, from that, you could do something like an L2-style channel, where counterparties agree to the next version of the transaction using TEMPLATEHASH. They both sign it.

Mark Erhardt: L2 here standing for LN-Symmetry, just to be clear.

Greg Sanders: Sorry, LN-Symmetry, yeah.

Mark Erhardt: Because L2 sounds just like eltoo.

Greg Sanders: Yeah. And then, the counterparties agree on the next state and both sign it. Then, they combine their signatures and then put it on the stack and use BIP348, CSFS. That validates the next state transition. An internal key can be reusing the same exact key, because they already agreed to the inner key. So, these three together, that’s the common kind of operation.

Mark Erhardt: So, to look at it from the outside a little bit, if this proposal, or these proposals, would be adopted in a soft fork, we could probably do LN-Symmetry style channels, which we’ve been talking about for, I don’t know, seven years, probably longer. And then, we could also do all of the use cases that had been proposed with CTV, except the ones that rely on legacy script being able to use CTV. So, this is taproot-only opcode rather than CTV proposed to activate it both on legacy script and on taproot. And there’s a couple of minor details that are different too. But as far as I understand, this would basically give access to all of the use cases that have been discussed in the context of CTV. And so, how did this come to pass?

Greg Sanders: So, I had long been somewhat ambivalent about CTV as an idea just because the use cases didn’t seem there. But I became more convinced as I understood how Ark worked, and became more convinced of the ability for it to reduce the requirement of interactivity in these protocols. So, instead of needing all feature participants on ahead of time, we were able to defer that to much later. And in a mobile-first kind of world, this makes a lot of sense. So, I started digging into this, being more convinced of it. I also did work on LN-Symmetry, as you know. So, that was a slot-in replacement for APO (ANYPREVOUT). I did swap it out in my in my proof-of-concept codebase; it works just fine. So, it’s just a conceptual drop-in for that.

I was talking to Antoine at Chaincode and basically he wanted to be convinced that there was something there. He wasn’t. And over time, he was convinced of it. So, we joined up along with Steven Roose, who works at Second Tech, to work on, well, the CTV proposal hadn’t changed in like five years, and we felt that being unchanging isn’t necessarily a sign of health one way or another. So, we kind of went back to the drawing board and said, “How would you do it with modern-day tooling, with taproot? How would we justify the change? How do we bundle it or not?” and went through all these steps, justified every field that we hash from first principles, or attempted to, and then basically gave what we felt was the best effort proposal. And so, there’s been a moderate amount of communication about it on the gist of the GitHub. But also, I mean it’s mostly just differences in the hash, right? So, there’s discussion about annex and stuff like that, but that’s not really the important part yet.

So, that’s the BIP portion of it, and it’s got merged. Thanks for all your back and forth with us, Murch, and I’ll talk a little bit about next steps, but I’ll pause there.

Mike Schmidt: Yeah, that’s where I was going too, is next steps. Maybe feedback that you’ve gotten that you think is notable for the audience. Can people play with this yet? Inquisition? These sorts of things.

Greg Sanders: Right. So, our first thing we did, we designed this, put this in draft. And then we said, first of all, is this a good place to stop? Because Bitcoin Script is very basic at today, very limited. And maybe there’s a better place to stop, so it should be going further. So, one example is Steven Roose’s other proposal, OP_TXHASH, I don’t know the number of that one off the top of my head, which is like a programmatic version of CTV. So, you can basically parse in arguments to this hash and it hashes in all the transaction data that you asked for pretty much. So, it’s kind of a programmatic version. So, why not go that far? Why not go all the way to Rusty’s great script restoration? Why not do, like, AJ’s bllsh, Russell O’Connor’s Simplicity? And so basically, tried to justify to ourselves and to others in public forum that we think this is a good set of functionality that has no known steep downsides, except for the fact that you have to go scrimp and beg for a soft fork, right?

Mark Erhardt: Yeah, maybe let me jump in here and give you my antagonistic view here. So, every week we get a new covenant proposal. We have OP_TXHASH, BIP346; we have CCV (CHECKCONTRACTVERIFY); we have CTV, of course; we have LNHANCE, which packages CTV together with PAIRCOMMIT and INTERNALKEY and CSFS. What is your sales pitch or, yeah, I forgot even some TAPLEAF_UPDATE_VERIFY, and so forth. Why is this, in your opinion, the way to go forward, with the context of all of these other proposals before?

Greg Sanders: So, it’s a multidimensional kind of thing. Unfortunately, it’s hard to bumper-sticker this. But I would say Bitcoin Script is really weird, really flawed. And so, in my opinion, we either do small, as principled as possible, scoped things in Bitcoin Script to really enhance use cases we truly understand could work today; or we probably should think about going all the way and throwing out script. And by throwing out script, I mean, great script restoration, Simplicity, bllsh, something like that, where we say, “You know what? Let’s start kind of from scratch. How would we want to build them from scratch?” And that’s one dimension, right? The other dimension is what has been proven to be useful. I guess it’s part of that dimension. And I think presigned transactions is pretty straightforward. We understand how those work, we do those kind of everywhere, it supports payments of various kinds.

One kind of hopefully killer use case that I’ve been focusing on lately is composing the LN with Ark itself. I’m not going to get into all of that. I’ve started work on it, I have an end-to-end working demo with full functionality. But the point is, it’s using the same kind of mental model we already have in Bitcoin. And future capabilities, for the most part, the only one that I’ve really seen that’s very compelling is trying to get zero-knowledge proofs in Bitcoin. And that is one other functionality that’s very orthogonal to this, right? And then, it also begs all these questions of, how exactly do you want to do these things? So, I think that’s one attempt at explaining. So, I don’t want to go down a laundry list why I like or don’t like certain things. LNHANCE is very close to this. That’s basically functionally equivalent. CCV has very interesting ideas. I’m not sure that we keep trying to extend Bitcoin Script like that. It seems principled in some ways and unprincipled in others. I’m not going to get too far into this, but I think it’s a function of like, we don’t know what Bitcoin Script should be in some ways, I would say.

Mark Erhardt: So, maybe one of the things that I’ve seen on the mailing list recently was that you are building demos. I saw Antoine work on that, you work on that. Of course, Steven is involved in building one of the Ark implementations. So, you very specifically show, in the use cases that you already have, how this would be useful. And you have working demos that you can show to people.

Greg Sanders: So, I can give a little more detail. So, I have LDK channels working on top of Steven’s Ark software stack. The one caveat here is that if you want to be a mobile user, you won’t be able to sign that new tree when you’re batching channels together. It’s just kind of infeasible on mobile. And so, TEMPLATEHASH, this kind of next transaction commitment scheme, slots in there basically transparently to the user.

Mark Erhardt: Basically, the issue here is that mobile phones fail at the interactivity requirement, right? They are only intermittently online, they cannot be reliably woken up. So, being able to have these ways of committing to things out of order or on your own time allows you to participate in these constructions.

Greg Sanders: There’s been testing on this. Even if they’re online, it’s a lot of signatures floating around. And if you have one user out of a hundred accidentally drop a packet or something, everyone has to start over again. So, this is very punishing versus just saying, “Hey, I’m the coordinator, I made this for you. Do a couple signatures with me and you’re good to go”, which is night and day difference. So, yeah, for next, it’s we’re thinking on proof of concepts. And I’m working hard on this side of thing because it’s also useful outside of TEMPLATEHASH, but also would benefit greatly from it. We’ve got a list of other ideas. And I’d say the call to action is, if you have interest in working on these things, proof of concepts, interested in understanding more about what this enables, that you can reach out to us either on GitHub or email or Delving.

Mike Schmidt: I was just going to plug, we had a previous episode that Antoine came on, when we talked about the different tooling and PSBT and miniscript around this bundle as well, so if people are curious about that. And so, it’s more than just writing a bit. There’s infra and support tooling that is advantageous to have the work put in initially. So, if folks want a reference back to that, check out the podcast page, look for Antoine.

Greg Sanders: We also have an open PR on Bitcoin Inquisition. Now that we have a BIP number, it’s easier to get the PR up in shape. And so, once we have that up, we can run simultaneous signet infrastructures. People can actually play around with, like, Lightning on Ark, and things like that, and with fake money on a realistic test network. So, that’s kind of another big milestone we want to hit soon.

Mark Erhardt: All right, that was going to be my next question. So, I think you got me covered.

Greg Sanders: Yeah, it’s all open source. It’s easy to stand up, which is nice, unlike some other competing systems.

Mike Schmidt: Greg, thanks for your time. Thanks for hanging on and walking us through this and for your work on this. We appreciate your time.

Greg Sanders: My pleasure. Thanks.

Cake Wallet adds Lightning support

Mike Schmidt: Cheers. We’re going to jump back up to the Changes to services and client software segment and jump into the first item, which is Cake Wallet adding lightning support. Cake Wallet, I believe it’s a mobile only wallet, but they announced Lightning support using the Breez SDK and also a Spark integration. We’ve talked about Spark before briefly, but it’s a statechain type, I guess, side system. And Cake also has Lightning addresses. And I know there was some discussion and debate online about Spark and the trustless nature or not of it. You’re free to dig into that yourselves. I don’t know if, Murch, you want to resurrect any of that discussion here.

Mark Erhardt: I mean, I think I can explain a little bit what a statechain is, maybe.

Mike Schmidt: Excellent, yeah.

Mark Erhardt: So, in the LN, you have locked up funds between two parties and you renegotiate how it will be paid out. And that enables you to have very quick settled transactions between the two peers. And by having more peers, you get a network and can forward payments, right? In the statechain, you have a coin, a fixed amount that is locked up with an operator. So, there’s a central party to a statechain. And then, the user and the operator together own a fixed UTXO, and you hand off control of the UTXO to other users of the same statechain by re-splitting the key and giving one shard to the new owner and the operator holding the other shard. So, this is similarly quick as the LN in that you only have to renegotiate between the participants of the transaction. You can immediately pay any other person on the internet, rather than any other participant of the LN, because they get access to this UTXO, so they don’t have to set anything up in advance. So, that’s a big advantage.

The trade-off is that the operator and any former owner of the same UTXO can cheat by going back in time and spending it with the two shards. So, you are trusting that the operator is properly deleting the old shards after control has been handed over to a new owner of the UTXO. Either the operator or the old owner has to reliably remove the shard, or you have to trust them not to cheat, or just switch out of it after you hold it through Lightning, or whatever. So, you get very quick payments, you don’t have the onboarding hurdle that you have with LN, but you have a bit more trust in the operator of the statechain at that point.

Mike Schmidt: And, Murch, we had BlueMatt on and I think he was the one that outlined this idea to me quite a while ago, but this idea of a graduated wallet, where it’s sort of this end-user facing wallet. You know, maybe you have an onchain balance and a Lightning balance. And then, for small amounts, maybe you use ecash or maybe you use Spark, or something like that, where the trust assumption is a little bit different. And as you build that balance, then maybe you move to Lightning and/or onchain Bitcoin as well. And I think that’s a bit of what Cake is doing, and that’s what seems to be a strong use case for Spark as well.

Mark Erhardt: I think that’s generally the big theme in the ecosystem right now. Essentially, all of the things we’ve talked about I think today, well, not FIBRE, but Ark and statechains and another one that we’ll talk about with the Liquid Blockstream in a couple of points, all of these are trading off a slightly different trust model for more convenience or different convenience for the payment flow. And yes, I think that we’re getting very quickly to the point where we can make Lightning payments feel transparent to the end user from the mobile phone, where it just works. It happens instantly, people are satisfied that the payment is sufficiently settled. And then, under the hood, you might have swapped a little bit of money into a statechain, or it flows for an Ark, or you use ecash tokens or you use the submarine swaps to LBTC. From your point of view, the majority of your coins are in Lightning. The vast majority of your coins are in a cold wallet, on a hardware wallet, or air-gapped system, or however you have that set up. And your pocket money is in a semi-trusted but super-convenient cheap way, like ecash or statechains cost nothing basically to transfer, whereas even Lightning payments have fees. And with the onchain fees being so low, Lightning payments have actually, at some point, for many amounts, been more expensive than onchain payments. But they’re instant, so that is the advantage there.

So, anyway, that seems to be an ecosystem theme in the last couple of years or so. And all of these big system upgrades or these big projects have been taking a long time, and now they’re coming to fruition, and they allow people to build more convenient, more usable end-user wallets. So, Cake, I think, is very good at just taking what works and being very conscious of the user experience and I think that’s the main point of their blog post, if you dig into it a little bit, is yes, Lightning is cool and it works, but when your channel closes down, you have fees; and the setup and so on makes it less usable for an end user. Whereas the way they found now, they could integrate and make payments to the LN through Spark. It works for the end user. You probably want to limit your exposure to the trust assumptions to whatever you feel comfortable with, but this is pretty cool. Also, you might have heard Cake Wallet in the context of supporting silent payments already. So, a little shout out to them in that regard too.

Sparrow 2.4.0 and 2.4.2 released

Mike Schmidt: Next piece of software that we highlighted was Sparrow. And we have two releases from Sparrow that came out that we wanted to highlight things from. One was in 2.4.0, Sparrow added BIP375 PSBT fields to verify DLEQ proofs for hardware wallet support when sending to silent payment addresses. It also, in that 2.4.0, added Codex32 importer functionality. And then, Sparrow 2.4.2 added v3 transaction support, specifically noted as support for loading v3 transactions in the transaction editor. There’s a list of other things in each of these releases in addition to whatever was in 2.4.1, so if you’re a Sparrow user or these things are interesting to you, obviously jump into those release notes for more.

Mark Erhardt: Yeah, so I also see a bunch of new hardware wallets that are now supported by Sparrow in the 2.4.0 release. And I wanted to give a shout out to Craig. He’s been on the show recently. But also, he’s been not only implementing a bunch of BIPs to support them with Sparrow, he has been driving a bunch of BIPs lately in order to drive forward the PSBT format of silent payment. Sorry, he’s been helping on using the silent payments in PSBT and he’s been driving the descriptor format for silent payments. And he’s been working on an annotation for descriptors to add, to make a format that uses descriptors more usable to use as a backup. So, we have two or three BIPs now from Craig in flight, and he’s been also just implementing a bunch of them. So, this is pretty cool. We BIP editors always love when people contribute to the BIPs repository, not only as authors, but reviewing other BIPs, and he’s been doing a great job helping a few other BIPs in related topics get more review.

Blockstream Jade adds Lightning via Liquid

Mike Schmidt: Blockstream Jade adds Lightning via Liquid. So, there’s a few different moving pieces here. So, Blockstream has its Jade hardware signing device. There’s also the Liquid sidechain and then there’s Lightning. There’s also the Green app, which is sort of the app how you can interact with your Jade hardware wallet. And then, so I guess the top-line feature here is if you’re using all of these pieces, you can actually interact with Lightning using submarine swaps, and that will actually convert Lightning payments into Liquid Bitcoin, so LBTC on the Liquid sidechain, and it allows you to keep your keys offline during that process. Go ahead, Murch.

Mark Erhardt: Yeah, so I read a little bit of this on the train earlier today. The idea here is, as a mobile wallet user, receiving Lightning payments is complicated. There is various solutions that are in flight. For example, LDK uses the asynchronous payments and has been driving that largely. It looks like Core Lightning (CLN) has found an in-house solution for that. Instead of requiring the mobile wallet to be online, you receive it as an LBTC payment to the Liquid sidechain. So, the Lightning payment comes in, gets swapped by Boltz to an LBTC payment, and then you hold some LBTC, which is Blockstream’s token, like voucher for Bitcoin, and you can swap that easily for actual Bitcoin of course. So, if you hold a little bit of your balance in LBTC, again, just like we said, your pocket money or smaller amount or however you feel comfortable about it, you can make Lightning payments from a basically onchain wallet by swapping through LBTC to the LN.

Tether launches MiningOS

Mike Schmidt: Tether launches MiningOS. So, Tether, yes, that Tether launched this open-source operating system for managing Bitcoin mining operations, and it is under the Apache 2.0 license. I believe it’s agnostic to whatever sort of hardware you’re running, and so I think we covered something similar from Block. They had a series of things as well under, I think, the Proto banner, but I think this is largely a welcomed thing in the mining ecosystem.

Mark Erhardt: Yeah, the big issue is that most of the mining control software, as in the pool software that runs the actual mining hardware, is closed source, right? So, every mining pool invents the wheel fresh. It takes time for them to support new features on the network, maybe to start including new transaction types on their mining pool. With now two different systems that make this open source, it becomes much easier for the ecosystem to update quickly. People can just come and contribute to the open-source software, well, assuming they take external contributions, but I would hope so. And so, features roll maybe out more quickly and maybe mining pools are up to date to the network reality a little quicker. Maybe less work has to be done on the mining pool side, making it easier for new mining pools to enter the fray and compete. So, yes, this is very welcome. I haven’t looked too much into the details here, but this is the general context.

TUI for Bitcoin Core released

Mike Schmidt: And we have a TUI for Bitcoin Core that was released, a Terminal User Interface for Bitcoin Core. So, if you want to interact in your terminal and feel very cypherpunk and have that sort of vibe to your interactions with the Bitcoin Core node, this connects to your Bitcoin Core node using the JSON RPC, and it pulls in a bunch of different information, metrics about the blockchain and network, looking at the mempool. And then, I guess there’s transaction search and you can broadcast and manage your peers there as well. It’s kind of fun. I haven’t tried it myself, but the screenshots look kind of cool. I think many people are spending maybe a little bit more time in the terminal than they have previously doing things with Claude and whatnot. And so, if that’s your jam, then maybe check out Bitcoin-tui.

That wraps up our Changes to services and client software. We touched on a Release item and some Notable code items, but we also have Gustavo to take us across the finish line. Gustavo, what haven’t we done from releases? We have BTCPay Server 2.3.6. You want to pick up there?

BTCPay Server 2.3.6

Gustavo Flores Echaiz: Yes, thank you, Mike and Murch. Yeah, so we have alongside Bitcoin Core 31.0rc1, we have a BTCPay Server with a minor release. This has some API and wallets features. For example, the get invoices endpoint now retrieves all the payment method data for specific invoices. So, you don’t have to make multiple calls. You can just retrieve payment data with one single API endpoint call. Another one is allowing filtering of when labels exceed more than 20, you can basically just filter labels when searching for your wallets. So, nothing crazy but just a few improvements on the user experience, and a couple other bug fixes as well. So, minor release for those that are using BTCPay Server, not a huge revolutionary change.

Bitcoin Core #31560

What’s interesting about this week’s notable code and documentation changes are two changes to Bitcoin Core. First, we have Bitcoin Core #31560, where the dumptxoutset RPC, which is used to dump the UTXO set to disk, can instead of being written to disk and then being read by another program, it’s now enabled to be written to a named pipe. This means that the output can be streamed directly into another process, bypassing the need to write it to disk and then reading it again by another program. So, the use case here presented was mostly enabling to create, let’s say, a SQLite database of the UTXO set, combining with another tool called utxo_to_sqlite.py, that was introduced in Newsletter #342. So, with one simple command, users can use the UTXO set for other use cases and, for example, build a database directly from that command.

As a reminder, dumptxoutset is used to create assumeUTXO snapshots, so that use case was always previously covered. But this makes it useful for external tooling to convert it to other formats, and not waste time and processing power into writing it to disk and then reading it again. It can just be done in one command.

Bitcoin Core #31774

The next one, Bitcoin Core #31774, is a security improvement when you’re using a password to secure your wallet. The key material was wiped out of memory using a method called memset, that sometimes could be optimized out by the compiler, meaning it was removed from the final compiled code. So, this meant that your key material could be swapped to disk or linger in memory. So, for example, it would be swapped to disk when your system is running low on memory, it could be swapped to disk. However, now the new change is that the key material is now protected using secure_allocator to prevent it from being swapped to disk and to zero it from memory when it’s no longer used. So, in the PR, you can find an issue that was associated to it, where someone basically told the story of how this wasn’t being securely erased from memory because it was using memset, and how memset can be optimized out by the compiler at some points. So, this is changed to make sure that it’s securely erased from memory and never swapped to disk. Any extra thoughts, Murch, Mike, here? No, perfect.

Core Lightning #8817

So, the next one is Core Lightning #8817. So, here, there’s a couple fixes that are included into CLN to make it interoperable fully with Eclair. So, I believe as of today, the splicing PR has been merged. So, this was obviously in preparation towards merging the BOLT specification splicing PR. There was fixes made in multiple implementations to arrive to an interoperable point and to fully reflect that the implementation is fully implementing the protocol as defined by the splicing spec PR. So, what are those issues that have been fixed? The first one is announcement signature retransmission crash. So, if Eclair missed a signature from CLN and asked for it again when it reconnects, CLN would send it correctly the first time. However, if Eclair asked for it a second time, then CLN would send an error and force close the channel. So, those type of issues were happening. Another one is where Eclair would send a channel_ready message at a point where CLN didn’t expect it, and this would cause CLN to reject it with an error about getting an incorrect message. And there was also some other crash and misalignment on different issues.

Then, what’s interesting about this PR is that the maintainer from the Eclair team, t-bast, created custom branches that deliberately misbehaved so that you would test how CLN would react if Eclair would misbehave. So, this was a good stress test that allowed this PR to finally, for the third time, to achieve interoperability with Eclair. You can see Newsletters #331 for the first time CLN had achieved interoperability, and #355 for the second time. It’s just that Eclair kept updating to the changes in the specification more frequently than CLN did, which is why CLN had to update to then maintain its own interoperability with Eclair.

Eclair #3265 and LDK #4324

So, the fourth item we have in this list is a combination of two PRs, one in Eclair #3265 and one in LDK #4324, where both implement what we covered in past Newsletter #396, which was a change in the BOLT specification, where it was clarified that the offer amount in BOLT12 offers must always be greater than zero when present. So, these two PRs ensure to start rejecting BOLT12 offers when the offer amount is set, but it is set to zero. So, this aligns it to the changes in the BOLT specification.

I believe the last three newsletter items have already been covered at the beginning of the episode, the two on LDK, one about adding RBF fee bumping on splice funding transactions, and the second one about raising the maximum accepted channel dust limit to 10,000 satoshis for zero-fee HTLCs in anchor channels; and finally, the merging of two draft BIPs, BIP446 and BIP448, that basically specify OP_TEMPLATEHASH, and the second one that groups OP_TEMPLATEHASH with OP_INTERNALKEY and CSFS. So, these were covered earlier in the episode. Thank you.

Mike Schmidt: Awesome. Thanks, Gustavo. We want to thank our guests for today’s show, BlueMatt, instagibbs, and Sebastian. And thank you, Gustavo, for walking us through the Releases and Notable code items, and thank you, Murch, for co-hosting and for you all for listening.

Mark Erhardt: And thank you, Mike, for organizing this every week.

Mike Schmidt: No problem. We’ll hear you next week, except Murch, maybe.

Mark Erhardt: Yeah, I’m not here.

Mike Schmidt: All right. See you all, hear you all next week, except Murch. Bye.

Bitcoin Optech Newsletter #397

2026-03-20T00:00:00+00:00

This week’s newsletter includes our regular sections describing changes to services and client software, announcing new releases and release candidates, and summarizing recent changes to popular Bitcoin infrastructure software.

News

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

Changes to services and client software

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

● Cake Wallet adds Lightning support: Cake Wallet announced Lightning Network support using the Breez SDK and a Spark integration, including Lightning addresses.
● Sparrow 2.4.0 and 2.4.2 released: Sparrow 2.4.0 adds BIP375 PSBT fields for silent payment hardware wallet support and adds a Codex32 importer. Sparrow 2.4.2 adds v3 transaction support.
● Blockstream Jade adds Lightning via Liquid: Blockstream announced that Jade hardware wallet (via Green app 5.2.0) can now interact with Lightning using submarine swaps that convert Lightning payments to Liquid Bitcoin (L-BTC), keeping keys offline.
● Lightning Labs releases agent tools: Lightning Labs released an open-source toolkit enabling AI agents to operate on Lightning without human intervention or API keys using the L402 protocol.
● Tether launches MiningOS: Tether launched MiningOS, an open-source operating system for managing Bitcoin mining operations. The Apache 2.0 licensed software is hardware-agnostic with a modular, P2P architecture.
● FIBRE network relaunched: Localhost Research announced the relaunch of FIBRE (Fast Internet Bitcoin Relay Engine), previously shut down in 2017. The reboot includes a Bitcoin Core v30 rebase and monitoring suite, with six public nodes deployed globally. FIBRE complements compact block relay for low-latency block propagation.
● TUI for Bitcoin Core released: Bitcoin-tui, a terminal interface for Bitcoin Core, connects via JSON-RPC to display blockchain and network data, featuring mempool monitoring, transaction search and broadcasting, and peer management.

Releases and release candidates

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

● Bitcoin Core 31.0rc1 is a release candidate for the next major version of the predominant full node implementation. A testing guide is available.
● BTCPay Server 2.3.6 is a minor release of this self-hosted payment solution that adds label filtering in the wallet search bar, includes payment method data in the invoices API endpoint, and allows plugins to define custom permission policies. It also includes several bug fixes.

Notable code and documentation changes

● Bitcoin Core #31560 extends the dumptxoutset RPC (see Newsletter #72), enabling the UTXO set snapshot to be written to a named pipe. This allows the output to be streamed directly to another process, bypassing the need to write the full dump to disk. This combines well with the utxo_to_sqlite.py tool (see Newsletter #342), allowing a SQLite database of the UTXO set to be created on the fly.
● Bitcoin Core #31774 starts protecting the AES-256 encryption key material used for wallet encryption with secure_allocator to prevent it from being swapped to disk by the operating system when running low on memory, and zeroes it from memory when no longer used. When a user encrypts or unlocks their wallet, the passphrase is used to derive an AES key that encrypts or decrypts the wallet’s private keys. Previously, this key material was allocated using the standard allocator, meaning it could be swapped to disk or linger in memory.
● Core Lightning #8817 fixes several splice interoperability issues with Eclair that were discovered during cross-implementation testing (see Newsletters #331 and #355 for previous interop work). CLN now handles channel_ready messages that Eclair may send during splice reestablishment before resuming negotiation, fixes RPC error handling that could cause a crash, and implements announcement signature retransmission via new channel_reestablish TLVs.
● Eclair #3265 and LDK #4324 start rejecting BOLT12 offers where offer_amount is set to zero, to align with the latest changes in the BOLT specification (see Newsletter #396).
● LDK #4427 adds support for RBF fee bumping of splice funding transactions that have been negotiated but not yet locked, by re-entering the quiescence state. When both peers attempt to RBF simultaneously, the quiescence tie-breaker loser can contribute as the acceptor. Prior contributions are automatically reused when the counterparty initiates an RBF, preventing the fee bump from silently removing a peer’s splice funds. See Newsletter #396 for the base splice acceptor contribution support that this builds on.
● LDK #4484 raises the maximum accepted channel dust limit to 10,000 satoshis for anchor channels with zero-fee HTLCs, including zero-conf channels. This implements the recommendation from BOLTs #1301 (see Newsletter #395).
● BIPs #1974 publishes BIP446 and BIP448 as Draft BIPs. BIP446 specifies OP_TEMPLATEHASH, a new tapscript opcode that pushes a hash of the spending transaction onto the stack (see Newsletter #365 for the initial proposal). BIP448 groups OP_TEMPLATEHASH with OP_INTERNALKEY and OP_CHECKSIGFROMSTACK to propose “Taproot-native (Re)bindable Transactions”. This covenant bundle would enable LN-Symmetry as well as reduce interactivity in and simplify other second layer protocols.

Bitcoin Optech Newsletter #396 Recap Podcast

2026-03-17T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Jonathan Harvey-Buschel to discuss Newsletter #396.

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

Download audio

News

● Collision-resistant hash function for Bitcoin Script (0:30)
● Continued discussion of Gossip Observer traffic analysis tool (8:58)

Releases and release candidates

● BDK wallet 3.0.0-rc.1 (28:04)

Notable code and documentation changes

● Bitcoin Core #26988 (30:39)
● Bitcoin Core #34692 (32:22)
● LDK #4304 (33:21)
● LDK #4416 (35:41)
● LND #10089 (38:01)
● Libsecp256k1 #1777 (39:46)
● BIPs #2047 (42:39)
● BOLTs #1316 (46:42)
● BOLTs #1312 (47:26)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #396 Recap. Today, we’re going to talk about a collision-resistant hash function for Bitcoin Script that is quite wild, and we also have some discussion following up a previous item that we covered, Gossip Observer for the LN, analyzing some of the traffic there. This week, Murch, Gustavo and I are joined by JHB.

Collision-resistant hash function for Bitcoin Script

We’ll do the first news item first, “Collision-resistant hash function for Bitcoin Script”. This was a Delving post referencing a paper written by Robin Linus. You may be familiar with his work that we’ve covered previously. We’ve had him on also to talk about BitVM, BitVM 2, 3, and some of the work around bridges. This time, he posted to Delving about this whitepaper about Binohash which, without any consensus changes, does enable some limited transaction introspection, so the ability to look at the actual transaction itself using only the existing script primitives. And for Robin’s use case, he’s thinking about BitVM and he’s thinking about these BitVM bridges, where coins are sort of locked and then accessible on some sort of second layer side chain. But there is some interactivity with the layer 1 Bitcoin, and it’s advantageous for things like BitVM bridges to be able to see certain things like, “Did this certain payout happen?” etc, within the transaction. There’s no good way to do that now, so they have different schemes to compensate for that lack of introspection, which could be provided by something like covenants, but we don’t have covenants in bitcoin. So, he’s worked around that with this Binohash proposal. Murch, I know you’ve looked at the paper a bit. Do you want to get into some of how that is achieved, how this introspection is achieved?

Mark Erhardt: So, it looks like it uses some weird construction that is based on bare multisig, and it uses the FindAndDelete opcode, I guess, to delete some of the signatures out of that, which allows it to have some covenant-like properties. I did not have time to fully read the paper, but it sounds to me like it uses a lot of data to achieve some fairly low security with a lot of grinding on top of it. I skimmed a bit through the paper and I saw some figures. I don’t know if that was the right figures, but it looked like 8,000 bytes for about 50 bits of security, although the paper does overall say it achieves 80 bits of security. But it looked to me like it would basically write a pretty big blob of data. And then, the setup also requires grinding for about $50 worth of compute to set it up. So, I think we’re sort of in this arc, as in story arc, where a lot of people are inventing covenant-like constructions that can be done without consensus changes right now, presumably because people feel that there’s little hope that a covenant will actually manifest anytime soon. And this is interesting and it’s cool that it works, but extremely blockspace inefficient and apparently also computationally inefficient.

So, from my very superficial understanding – and I hope next time we have Robin or Liam on, they can expound on this – this seems like another proof-of-concept sort of thing that does work, but doesn’t seem very practical in production. I also saw that it’s based on lamport signatures. So, that’s a very old quantum-resistant signing scheme that is based on big blobs of data that you can only use once. But anyway, it seems more like a proof-of-concept academic sort of paper, rather than something that will be rolling out to the network anytime soon.

Mike Schmidt: So, it uses bare script and you noted some of the quirks of the approach. Does this mean this would not be something that would be relayed? This is a non-standard transaction, and it would have to be mine separately?

Mark Erhardt: Oh yeah, very explicitly this is non-standard because it uses FindAndDelete, I think, which I don’t remember whether that was the reason it’s non-standard, but it basically is non-standard for multiple reasons. On the policy level, it is consensus-valid. But there’s also the problem that it operates just below the maximum number of opcodes and the maximum script length for scripts to not be invalid generally, which is 10,000 bytes for legacy script. So, I think it’s sort of squeezing into the corner on a bunch of the limits. Non-standard transactions, definitely.

Mike Schmidt: Large transaction, you’re going to spend tens of dollars in fees even at current feerates, you’re going to spend fifty dollars grinding to get the appropriate hash, it sounds like. So, expensive, but maybe for these bridges, that’s worth it to them. And then obviously, there’s the concern about not being able for this to be actually relayed. So, then you’re talking about out of band to slipstream or whatever else. But obviously, interesting quirks being used here. An exotic protocol, but maybe not practical?

Mark Erhardt: I’m also wondering now, as you were saying, all the signatures and legacy script. So, of course, we have the quadratic hashing problem in legacy script. And if you’re writing 10,000 bytes of signatures, well, again, I didn’t dive very deep, sorry. I wonder whether this might be sort of getting close to the poison transaction sort of constructions that are extremely expensive to validate. So, overall, there are many open questions here, I would say.

Mike Schmidt: There is a funny note in the acknowledgments of the paper itself, “We apologize to Pieter Wuille for abusing the Bitcoin Script interpreter so badly”. So, that was kind of funny to see in a whitepaper like that. I think we’ve done all that we can do on this item. What do you think, Murch? All right. We’ll bring back in JHB. JHB, do you want to introduce yourself real quick for the audience and we’ll move into your news item?

Jonathan Harvey-Buschel: Sure, yes. Jonathan. I’ve been working on various kind of projects running in the LN for a while, and this latest project is basically just looking, trying to collect some data on like how the LN gossip layer is working right now, and from that trying to see what issues may exist, compared to items or complaints I hear from actual node runners, like can I find evidence of those issues, and then use that to inform some upcoming kind of protocol changes or design decisions.

Continued discussion of Gossip Observer traffic analysis tool

Mike Schmidt: Well, thanks for joining us. The news item’s titled, “Continued discussion of Gossip Observer traffic analysis tool”. And we did cover Gossip Observer a few months ago, I think we covered it in a Client services monthly segment and not necessarily a News segment. But this thread, I believe, on Delving has grown and we decided to revisit it, and that was a good opportunity to now bring you on to actually talk about it instead of us talking about it on your behalf. You sort of touched on it a bit, but what exactly are you looking for and why? Gossip Observers, so Lightning gossip messages, but is there an end goal that you have out of this? Obviously, collecting the data will give you a lot of information, but did you have sort of an angle you’re working towards?

Jonathan Harvey-Buschel: Yeah. Well, I guess the name sort of half gives it away because it’s similar to the names that 0xB10C uses for his monitoring projects. It was intentional. But there’s sort of two main goals. One is to have something similar to mainnet observer, where if I’m collecting a bunch of data in the background, maybe we can start to have some sort of detection of anomalies of like, “Hey, these metrics that we’re looking at every day or every hour just changed a lot. Maybe something’s going on and maybe that’s a problem or that’s some network issue that could be looked at”. The primary goal is really to inform gossip changes that are coming up with the introduction of taproot gossip. The gossip is already changing to support taproot channels and there’s been some interest for a while in also changing how messages are actually propagated in the network, alongside changing the message format.

So, the message format is changing and people are interested in also changing like, should these messages be flooded to your peers in the same way they are now? Will the current mechanism be able to keep up with the size of the network as it grows or if we keep adding channels or new nodes, will we start to have even more issues with what we have now? So, we should look at some alternative. The proposal right now is trying to use minisketch in some way to save bandwidth, similar to the old Erlay paper, and some ongoing work I know from other people. I think Sergi is looking at that for Bitcoin Core these days. So, something in that direction of trying to inform some actual PR on the BOLT repo, like this is what we should do with these parameters, because they get informed by this data that is being collected.

Mike Schmidt: Okay, so a few different potential uses for the data. One is informing set reconciliation or minisketch. People may know Erlay-based gossiping versus just the flood method now, as well as this transition to simple taproot channels and changes along with that, and then observing those; in addition to potentially, even if those weren’t happening, general observations and maybe being a little bit of a watchtower over the network. If something gets interesting, you could report on it and potentially more proactively engage with whatever that threat or anomaly is. Are you running one server? Maybe talk a little bit about the setup.

Jonathan Harvey-Buschel: Sure. So, it’s, I think it’s 21 different LN nodes that are collecting data from other LN nodes. I think 6 of those have channels, so that means that I can send to channel-update messages. You can’t send a gossip message in the LN without having a channel, so I need to open some channels for that. But basically, looking at just the nodes and the payment channels they already have, the public channels, I tried to split up the network in some way based on, this group of nodes, they all have channels to each other, and this other group of nodes over here only makes channels to 1ML, or something like that. And then, after I had these sort of communities or this split-up of public nodes, just connect to each group that I had, each community, and collect data from those, and then I’ve got some big Postgres database that’s ingesting all of that. And then, I can run some queries over that later and try and use a metric.

Mark Erhardt: You said you are running 21 nodes, 6 of which have channels, so 15 do not have channels. I’m just curious, is that a monoculture or are you running different types of LN nodes?

Jonathan Harvey-Buschel: Yeah, I have a small fork of LDK node that’s just, I picked that because it seemed like the easiest implementation to actually have a small patch on so I could directly collect raw messages from the wire. Because if I’m collecting the message with the signature, that’s also useful for playing back messages in some future simulation situation. Since the messages all have to be signed, it can be useful to just have the message without any filtering or other changes that other implementations may make. There’s some other techniques people have used in the past to try and collect this data, but I figured a fork of LDK would probably be easiest. So, yeah, I may try and deploy some fork of LND at some point, but right now it’s just all LDK now.

Mike Schmidt: Are you the only collector of this information, or I know historic information for 0xB10C’s projects, people have provided additional data and even historical data in some cases for certain things; is that something that you’re open to or are doing, or is this sort of you want to be guarded with the data that you’re collecting at this point?

Jonathan Harvey-Buschel: So, right now, I guess for this system, the Gospel Observer project, all the nodes that are collecting data that gets stored by me are just under my control. But there are two other people that appeared on this thread that I also talked to outside of the thread that collected data with a slightly different methodology. But I think one of them, Fabian, he’s collecting data in an ongoing basis. He’s running Core Lightning (CLN) nodes for that. And then, someone else, Jan-Philipp, I think, who collected data for a specific period of time. I think he was using a custom fork of LND. So, I’m talking to them to kind of see, maybe even if all the data doesn’t necessarily end up in public, just being able to kind of compare and try and have some conclusions from just intersecting our data sets to see what differences appear. I know for Fabian’s infrastructure, for example, he’s just running stock CLN and it makes its own choices on which peers to connect to, using the defaults, which is not what I’m doing. So, that’s interesting in terms of like, are his timing observations very different from mine, or he has some other interesting metrics about how different the graph view is for the two nodes he’s running. Just something I’m also looking into, but kind of a work in progress.

There’s one other concern node operators have is like, “Are my messages really getting to all the nodes they’re supposed to get to, or is there some pocket of nodes that maybe they’re missing my messages and they don’t know my channel exists, or they don’t know my current feerate, so they wouldn’t be able to tend to payment over my channel?” It’s a problem we definitely want to address in any gossip changes.

Mark Erhardt: So, I attended a BitDevs recently, where this topic was discussed. And one of the things that I thought was very interesting was that we touched on how the LN gossip is very different from the gossip on the Bitcoin Network. And so, because I thought that was interesting in this context of, “Do messages go to places? Is everybody hearing my messages? Do they know about my channel?” could we maybe talk a little more about how the gossip on the Bitcoin Network and the gossip on the LN differ?

Jonathan Harvey-Buschel: Sure. So, for the Bitcoin Network, if we just think about how transactions are intended to be propagated, ideally the network as a whole doesn’t know exactly where the transaction came from. So, the privacy of the source of the broadcast or of the message is really important. But you also have this competing priority, which is that you want the transaction to propagate as fast as possible, right? The transaction, you intend to get into a block and you don’t want it to take, I don’t know, an hour. Ten minutes maybe is an acceptable number, but ideally, it would be fast. So, that’s the situation there, you have privacy and speed. Whereas for the LN, all the messages are already signed by the node generating them, and they’re intended to be public. You want them to be as widespread as possible, but there’s not really a privacy concern about where they’re coming from. That node is already announcing an IP address or a Tor address, it’s already signing everything, so you don’t really have this privacy concern.

There is a separate consideration where if I’m announcing a change to my feerate, I’ll actually still honor the old feerate for a few minutes. So, they don’t need to propagate necessarily as fast as possible, but you do need to get these messages to propagate eventually, because if they don’t, you may cause failed payments or just bad routing decisions by other people because they have stale information on your channels. But yeah, it does simplify a lot of the kind of design choices, because you don’t need to worry as much about privacy.

Mark Erhardt: Right. So, the transaction relay in Bitcoin is a best effort but not reliable necessarily. We don’t have to guarantee that every transaction reaches everyone. Blocks obviously have to reach every node and they are propagated extremely quickly. In LN, the channel announcements and channel updates, they should also be received by everyone, but you have a few minutes basically to achieve that, because the nodes accept the old feerates before they totally switch over to the newly announced feerates and you’re just not going to use a channel you don’t know about. So, it’s not that bad if you don’t know about a channel for a couple of minutes. So, maybe in that sense, it would be more compatible with the trade-offs that Erlay is making.

So, Sergi had been working a bunch on the adoption of the Erlay style transaction propagation in Bitcoin Core, but in Bitcoin Core, the transaction propagation also limits how quickly blocks can be propagated. So, when transactions are missing, more nodes need to ask for the missing transactions in order to reconstruct the blocks, and that introduces additional round trips. But the most recent version that I read was proposing that for every transaction you receive, you flood it to three peers, two or three peers, and then the rest of it is reconciled with the minisketch approach that Erlay uses, where you just compare what you would be announcing to each other and then find the differences, and only ask for the ones that you’re missing. And so, I’m just thinking, what you described might be more compatible with that because you have a little more time for the announcements to propagate. You still need to flood them out in order to make the differences small between the comparisons of the announcements, because minisketch is only efficient if the difference is small.

But maybe, well, on Bitcoin nodes, you might have 125 connections, so you don’t want to propagate the same transaction information, even if it’s just a header 125 times on every single connection. I don’t know. How many connections do LN nodes make actually?

Jonathan Harvey-Buschel: Yeah, the default right now is basically five to ten P2P connections, but that’s not really counting your channel counterparties. So, with most implementations, you’re also going to send and receive gossip messages with your channel counterparties, but not everyone has five or ten of those. The other thing worth bringing up here is right now, each implementation, they don’t flood any messages immediately. They normally build up a batch of messages and then flood every 60 seconds. So, this introduces some natural delay that we already have, which means if we switch to a minisketch-based approach or some mixed flooding and minisketch, we don’t necessarily need to aim for a propagation delay that’s much lower than what we have right now. I think the real issue is just making sure that everyone eventually gets a message, not necessarily just making it fast.

Mark Erhardt: Yeah, but the delay is mostly to reduce the overall bandwidth, I think, right? So, if you did Erlay, where you minimize the amount of things that get announced to each other by just finding the differences between what you would announce to each other, you might actually be able to announce more often in the same bandwidth. So, it might actually allow announcements to propagate faster without using more bandwidth in LN.

Jonathan Harvey-Buschel: Yeah. I mean, this is something I need to look at in simulation or some sort of modeling, but there’s the same consideration of maybe I want to keep the minisketch timer relatively long, but I want to reconcile with my peers in some staggered ordering, so that if one peer has a message I don’t have, I have time to reconcile with them and include it in my set so that for the next four peers, I’ll be able to spread that message to them. Or maybe I decide to flood it and that reduces the differences. It’s sort of the number of expected differences is something you need to dig into to actually compute. This is what I’d expect with how many messages we see right now. I think right now it’s like 300 messages a second, or something. There’s a fair amount of traffic. And we could say, if the network grows in this way, this is how we expect that to change. And the parameters we pick now are still going to be fine, at least for a while. I just need to dig into that more.

Mike Schmidt: Awesome. JHB, anything else as we wrap up this item? Any call to action for our listeners that could help out, or dig in for more information?

Jonathan Harvey-Buschel: Yeah, I’d say definitely, I think I’d like to have some sort of private kind of closed beta API up soon for node runners, or other people currently participating in the network to use, to see, like, are my messages getting widely propagated, or what does the timing look like for my specific set of messages that I’m producing? So, if there’s features that you think would be very useful to you in some sort of API like that, definitely let me know. Should be reachable via Twitter DMs or Delving, I think, has DMs as well. That’s probably better, honestly. And otherwise, I mean if you’re some of the people listening to this that are collecting their own data, definitely chime in on that thread. So, I know there are a lot of companies that run infrastructure that probably have their own kind of internal metrics and their own observations of this. If there’s some issues that you see with your own infrastructure, definitely let me know and I can see what I see on my side. Maybe that’s something other people are having. I guess, yeah, just feel free to DM me with any sort of requests or just comments of like, “Hey, this issue always pops up for me. Do you have any ideas?” things like that.

Mike Schmidt: Awesome. Thanks for your time, Jonathan. Thanks for joining us today. You’re free to stay, but you’re also free to drop. Cheers. This would normally be our monthly segment where we talk about a PR Review Club, but there have not been Bitcoin Core PR Review Clubs for the last few weeks and months. And so, if you’re curious why we haven’t been covering that, that’s why. Which means we move right into Releases and Notable code and documentation changes, authored by our friend and co-host here, Gustavo, who will help walk us through them.

BDK wallet 3.0.0-rc.1

Gustavo Flores Echaiz: Thank you, Mike. Thank you, Murch. That was an interesting conversation. Let’s dive into the releases. So, this week, we simply have a BDK wallet 3.0.0-rc.1. So, this is a major version of BDK that introduces a few takeaway features. The first one is a persistence in how a UTXO is locked, and basically a new table inside the SQL database to track UTXO lock status. And what does it mean to lock a UTXO? It means that I could reserve a UTXO to be used in a future transaction and my wallet wouldn’t ever try to take that UTXO into another transaction, right? So, I can reserve it for future use. And this would previously not persist through restarts. However, this state now lives in the database, which allows it to persist across restarts.

Another major update of this release is the structured wallet events. So, basically, when you had a wallet event, you couldn’t receive specific callbacks related to the change of the status of a transaction, for example, when a transaction was newly seen in the mempool, replaced, dropped from the mempool, then confirmed in a block. This release introduces wallet events that let you know about the change of status of a specific transaction. And then also, there’s also other features such as the addition of NetworkKind, which is basically an easy structure that allows you to detect whether you’re using testnet or mainnet, so this can be used by other parts of the code. And finally, just additional support for new wallet formats, specifically for the Caravan project, which has been covered in a previous Bitcoin Optech Newsletter, exactly Newsletter #77, which is a multisignature open-source wallet tool; and just a special migration utility for SQLite database migrations with previous versions.

So, this is the first RC out here for testing and we should expect, in the next few weeks, the official release to come out.

Bitcoin Core #26988

So, we continue with the notable code and documentation changes. This week, we have two on Bitcoin Core. The first one, this CLI command called -addrinfo, or address info, that used to return a subset of the full set of known peer or node addresses, will now return the full set of known addresses instead of the subset that was filtered for quality and recency. So, how does it achieve that? It replaces the RPC that was used behind the command. It used to use getnodeaddresses and now it uses getaddrmaninfo, which is a newer version that will basically return the whole set instead of a subset. So, now, you’re obtaining all the data you would like from this endpoint. Also important to note that if someone is running a different version of bitcoin-cli than his Bitcoin node, this would be incompatible with bitcoind versions that are earlier than v26, because the underlying RPC was added in v26. But this only affects users that have complex setups where they use a different version for the bitcoin-cli than for bitcoind. If you’re using the same version altogether, you wouldn’t have this incompatibility issue or risk. Any addition here? No? Perfect.

Bitcoin Core #34692

So, the next one, Bitcoin Core #34692. Here, there’s an increase of the default values used in the setting dbcache that was set on to 450 MiB. it’s now increased to 1 GiB, specifically on 64-bit systems that have at least 4 GiB of RAM. Else, it falls back to the previous setting of 450 MiB. So, this change only affects bitcoind. If you’re using the kernel library that we’ve covered in previous newsletters, then you retain the previous default value of 450 MiB. Also important to note that a larger dbcache is useful specifically at the moment of IBD (Initial Block Download) and for the performance in that process.

LDK #4304

So, the next one, we have two on LDK. The first one is a refactor of how HTLCs (Hash Time Locked Contracts) are forwarded, specifically for trampoline routing. So, here, there’s an update in how LDK forwards HTLCs to now support multiple incoming and outgoing HTLCs per forward. So, basically, the way it was working before is that LDK’s code assumed that when an HTLC came out, one in, one out. So, every time an HTLC resolved, it would only apply to an HTLC that came in, an HTLC that went out. However, when you’re doing trampoline forwarding, the sender might be sending you multiple HTLCs split using MPPs (Multipath Payments). And once you’re the trampoline node and you’re sending it to the receiver, you might also use MPPs to get to your target. So, how can an LDK node that acts as a trampoline routing node forward multiple HTLCs and act basically as a MPP endpoint on both sides? So, the structure is rebuilt to accumulate multiple incoming HTLC parts, find a route to the next hop to the receiver, and splits the forward across multiple outgoing HTLCs as well.

So, there’s a new variant called TrampolineForward that tracks all the HTLC states related to a TrampolineForward. Also, there’s a claim and failure handling added, and also a trampoline-specific channel monitor recovery is also implemented. So, for example, if the node restarts in the middle of the forward, it would need to reconstruct the state of all incoming and outgoing HTLCs. So, a specific channel monitor recovery, specific to trampoline forwards, is implemented for that.

LDK #4416

Next one, LDK #4416. Here, there’s an extension of the splice protocol that occurs when both splice peers try to initiate a splice at the same time. So, when that happens, there’s the quiescence protocol that basically would determine which one would be selected as the splice initiator. Previously, if two nodes would try to initiate a splice at the same time, one would win and that would be the one to open the splice; and the one that would lose would simply be the acceptor and not be able to commit any funds. So, what this PR does is that it enables the acceptor, the one that lost the tie break, to contribute funds as well in the same splice transaction. So, it effectively adds support for dual funding on splice transactions. So, because the acceptor had prepared to be the initiator, the main work done in this PR is the adjustment of the fee he pays, right? Because in the splice, the initiator covers the fees of those common transaction fields. So, a lot of the work of this PR was adjusting that the one who became the acceptor, the one who lost the tiebreak, his fees will be adjusted from the initiator rate, which was going to cover the common transaction fields, to the acceptor rate which only covers the fields that are only specific to himself.

So, now, the splice_channel API also accepts a new parameter to target a max_feerate. Because, for example, when you’re the acceptor, the initiator would lead with the feerate. So, now that there’s dual funding on splices, as the acceptor, you would want to be able to target the max feerate that you would be willing to pay as the acceptor that also contributes funds to a splice transaction.

LDN #10089

So, the next one is LND #10089. Here, we advance in the implementation of BOLT12 support for LND by officially adding onion messaging forwarding support. In Newsletter #377, we covered that there was some message types and some RPC endpoints that were added that were definitely the structure required to add onion messaging forward support. And now, in this PR LND #10089, we’re finally at the moment where all of these message types and RPCs are used to implement official onion message forwarding support. So, there’s also a flag that can allow to disable this feature, called –protocol.no-onion-messages, and a wire type called OnionMessagePayload will decode the onion inner’s payload. And there’s also a per-peer actor that handles decryption and forwarding decisions.

So, I looked specifically at the epic or the issue that tracks BOLT12 support. And this addition, this merged PR, basically completes, or at least is the last one before the last to complete the stage one of implementing forwarding onion messaging. The next two stages are about pathfinding for onion messages, and the final stage is offer creation and invoice request handling. So, quite exciting to see LND move forward on this support. Murch, Mike, any thoughts at this point? No? Thank you.

Libsecp256k1 #1777

The next one comes from libsecp256k1 #1777. So, here, a new API endpoint is added that allows external applications to supply a custom SHA256 compression function at runtime. So, the situation here is that when you’re using libsec, which is a binary that comes built-in within Bitcoin Core, you used to have no way to let libsecp know about the CPU that the computer was using, and to target a specific hardware-accelerated version of the library that would run these computations. So, now this endpoint allows Bitcoin Core or other software to basically let libsecp256 know at runtime to know the CPU that is being used, and to also parse the hardware acceleration algorithm that would be used to do these computations faster. Why couldn’t you just do this at compile time? It’s because at compile time, you don’t know the user’s CPU, if the user’s CPU supports the hardware instructions. So, Bitcoin Core already has solved this and can detect whether the CPU supports the hardware instructions at runtime, and now is able to let libsecp know about it, and also to parse the hardware acceleration algorithm. So, very cool.

Mark Erhardt: Yeah, so this has become much more common in the last few years, that CPUs have architectural support for secp. And obviously, it’s way faster if your CPU can directly run it in the hardware. And so, my understanding here is that just it allows the secp library to leverage the hardware gains. And so, for example, especially on low-powered devices, some of which – I think maybe our listeners should correct me if I’m wrong on this – but I seem to remember that Raspberry Pi got hardware support for SHA256 in the newer versions, and there, that would make a huge difference because all the calculations are what the bottleneck is in IBD for Pis.

Gustavo Flores Echaiz: Makes sense. Yeah, I think that’s my understanding too. Thank you, Murch, for adding that.

BIPs #2047

So, we’re almost done, but we move forward with BIPs #2047, which publishes BIP392, which is the BIP proposal for defining the descriptive format for silent payment wallets, which would allow for wallet software to have specific instructions on how to handle the scanning and the spending of silent payment outputs, and also for interoperability between wallets. So, the way silent payments works in general is that it has both a scan key and a spend key, right? So, a scanned private key allows you to see which silent payment address is linked to which specific P2TR outputs, as specified in and BIP352. However, the spend key either is public or is private. So, BIP392 introduces two types of expression. One is a one key expression argument that takes a single bech32m key can have two different forks. The first one is called spscan, which encodes both the scan private key and the spend public key. So, this allows you to fully watch a silent payment wallet but not to spend from it. The second expression is called spspend, and this one is a full spending wallet which has both the scan private key and the spend private key as well.

There’s also a two-argument form of the silent payment descriptor, which separates the keys instead of encoding them together. And the first key is always the private scan key as the first expression, and the second argument is a separate spend key, which can be either public, it can be either private, but also it has support for MuSig2 aggregate keys. So, your spend public key or private key can also be specifically a MuSig aggregate key. Anything to add here, Murch?

Mark Erhardt: Yeah, maybe just higher level. The descriptor format is a way of describing patterns of output scripts. So, with BIP392, we formalize how you could export and import and backup silent payments keypairs and transfer them between wallets. So, I don’t know, if you’ve been following BIPs, you’ve probably seen that there’s a lot of descriptor BIPs. The whole 380s, and now the 390s too, are all about output script descriptors. This is just an improvement in how we do wallet backups and wallet import format. And yeah, descriptors are now also available for silent payments. And hopefully silent payments adoption continues to grow because it’s awesome.

Mike Schmidt: I’ll also just plug Newsletter #387 and also Podcast #387, where we talked about this idea when it came out originally, and also had Craig Raw on to talk about it. So, if folks are curious, listen back for those.

BOLTs #1316

Gustavo Flores Echaiz: Thank you, Murch Mike. Great additions here. So, we move forward with the two final PRs of this week. So, both are additions or improvements to the BOLT specification. The first one, BOLTs #1316, clarifies that when an offer_amount is present in a BOLT12 offer, it must be greater than zero. The writer must set the value greater to zero, but if it was set to zero, then the reader must not respond to those offers. Also test vectors are included. So, this was just a clarification that was missed initially, because you can omit the offer_amount, but if you include it, it must be a non-zero value, it must be greater than zero.

BOLTs #1312

The next one is BOLTs #1312. This comes as a follow-up from a fix we covered in LDK, Newsletter #390, which applies specifically to the invalid bech32 padding of BOLT12 offers. So, in this PR, BOLTs #1312, a test vector is added with an example of a BOLT12 offer that has invalid bech32 padding, and clarifies that such offers must be rejected according to the BIP173 rules. So, basically what happens here is that a specific bech32 encoding comes out and works in 5-bit groups. But the data encoded is often in 8-bit groups. So, it means that it supersedes the number of bits of the data encoded and you add some padding bits. But the rules say that the padding bits must be at most 4 bits, and those bits must be all zeros. So, if the padding bits are non-zeros or exceeds 4 bits, then the encoding is invalid and must be rejected.

So, this was discovered through differential fuzzing, and it was revealed that LDK and CLN were accepting invalid padding offers, while other implementations were correctly rejecting them. So, this adds this vector at the specification level to ensure that the BOLT specification has the right semantic or clarification around it, so implementations can then base themselves properly on the specification. This was the last PR and this completes the section and the newsletter. Thank you.

Mike Schmidt: Awesome. Thanks, Gustavo. We also want to thank JHB for joining us earlier, for Murch for co-hosting, and for you all for listening. We’ll hear you next week. Cheers.

Bitcoin Optech Newsletter #396

2026-03-13T00:00:00+00:00

This week’s newsletter describes a collision-resistant hash function using Bitcoin Script and summarizes continued discussion of Lightning Network traffic analysis. Also included are our regular sections with announcements of new releases and release candidates and descriptions of notable changes to popular Bitcoin infrastructure software.

News

● Collision-resistant hash function for Bitcoin Script: Robin Linus posted to Delving Bitcoin about Binohash, a new collision-resistant hash function using Bitcoin Script. In the paper he shared, Linus states that Binohash allows for limited transaction introspection without requiring new consensus changes. In turn, this enables protocols like BitVM bridges with covenant-like functionalities for trustless introspection, without the need to rely on trusted oracles.

The proposed hash function indirectly derives a transaction digest following a two-step process:
- Pin transaction fields: Transaction fields are bound by requiring a spender to solve multiple signature puzzles, each demanding W1 bits of work, making unauthorized modification computationally expensive.
- Derive the hash: The hash is computed by leveraging the behavior of FindAndDelete in legacy OP_CHECKMULTISIG. A nonce pool is initialized with n signatures. A spender produces a subset with t signatures, which are removed from the pool using FindAndDelete, and then computes a sighash of the remaining signatures. The process is iterated until a sighash produces a puzzle signature matching requirements. The resulting digest, the Binohash, will be composed of the t indices of the winning subset.
The output digest has three properties relevant to Bitcoin applications: it can be extracted and verified entirely within Bitcoin Script; it provides approximately 84 bits of collision resistance; and it is Lamport-signable, allowing it to be committed to inside a BitVM program. Together these properties mean developers can construct protocols that reason about transaction data on-chain today, using only existing script primitives.
● Continued discussion of Gossip Observer traffic analysis tool: In November, Jonathan Harvey-Buschel announced Gossip Observer, a tool for collecting LN gossip traffic and computing metrics to evaluate replacing message flooding with a set-reconciliation-based protocol.

Since then, Rusty Russell and others joined the discussion on how best to transmit sketches. Russell suggested encoding improvements for efficiency, including skipping the GETDATA round-trip by using the block number suffix as the set key for a message, avoiding an unnecessary request/response exchange when the receiver can already infer the relevant block context.

In response, Harvey-Buschel updated his version of Gossip Observer that is running and continuing to collect data. He posted analysis of average daily messages, a model of detected communities, and propagation delays.

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.

● BDK wallet 3.0.0-rc.1 is a release candidate for a new major version of this library for building wallet applications. Major changes include UTXO locking that persists across restarts, structured wallet events returned on chain updates, and adoption of NetworkKind throughout the API to distinguish mainnet from testnet. The release also adds Caravan (see Newsletter #77) wallet format import/export and a migration utility for SQLite databases from before version 1.0.

Notable code and documentation changes

● Bitcoin Core #26988 updates the -addrinfo CLI command (see Newsletter #146) to now return the full set of known addresses, instead of a subset filtered for quality and recency. Internally, the getaddrmaninfo RPC (see Newsletter #275) is used instead of the getnodeaddresses RPC (see Newsletter #14). The returned count now matches the unfiltered set used to select outbound peers.
● Bitcoin Core #34692 increases the default dbcache from 450 MiB to 1 GiB on 64-bit systems with at least 4 GiB of RAM, falling back to 450 MiB otherwise. This change only affects bitcoind; the kernel library retains 450 MiB as its default.
● LDK #4304 refactors HTLC forwarding to support multiple incoming and outgoing HTLCs per forward, laying the groundwork for trampoline routing. Unlike regular forwarding, a trampoline node can act as an MPP endpoint on both sides: it accumulates incoming HTLC parts, finds routes to the next hop, and splits the forward across multiple outgoing HTLCs. A new HTLCSource::TrampolineForward variant tracks all HTLCs for a trampoline forward. Claims and failures are handled properly, and channel monitor recovery is extended to reconstruct the trampoline forward state upon restart.
● LDK #4416 enables an acceptor to contribute funds when both peers attempt to initiate a splice simultaneously, effectively adding support for dual funding on splices. When both sides initiate, quiescence tie-breaking selects one as the initiator. Previously, only the initiator could add funds, and the acceptor had to wait for a subsequent splice to add their own. Since the acceptor had prepared to be the initiator, their fee is adjusted from the initiator rate (which covers common transaction fields) to the acceptor rate. The splice_channel API now also accepts a max_feerate parameter to target a maximum feerate.
● LND #10089 adds onion message forwarding support, building on the message types and RPCs from Newsletter #377. It introduces an OnionMessagePayload wire type to decode the onion’s inner payload, and a per-peer actor that handles decryption and forwarding decisions. The feature can be disabled using the --protocol.no-onion-messages flag. This is part of LND’s roadmap toward BOLT12 offers support.
● Libsecp256k1 #1777 adds a new secp256k1_context_set_sha256_compression() API, which allows applications to supply a custom SHA256 compression function at runtime. This API allows environments such as Bitcoin Core, which already detect CPU features at startup, to route libsecp256k1’s hashing through hardware-accelerated SHA256 without recompiling the library.
● BIPs #2047 publishes BIP392, which defines a descriptor format for silent payment wallets. The new sp() descriptor instructs wallet software on how to scan for and spend silent payment outputs, which are P2TR outputs as specified in BIP352. A one key expression argument form takes a single bech32m key: spscan which encodes the scan private key and the spend public key for watch-only, or spspend which encodes both scan and spend private keys. A two-argument form sp(KEY,KEY) takes a private scan key as first expression and a separate spend key expression, either public or private with support for MuSig2 aggregate keys via BIP390. See Newsletter #387 for the initial mailing list discussion.
● BOLTs #1316 clarifies that offer_amount in BOLT12 offers must be greater than zero when present. Writers must set the offer_amount to a value greater than zero, and readers must not respond to offers where the amount is zero. Test vectors for invalid zero-amount offers are added.
● BOLTs #1312 adds a test vector for BOLT12 offers with invalid bech32 padding, clarifying that such offers must be rejected according to BIP173 rules. This issue was discovered through differential fuzzing across Lightning implementations, which revealed that CLN and LDK accepted offers with invalid padding while Eclair and Lightning-KMP correctly rejected them. See Newsletter #390 for LDK’s fix.

Bitcoin Optech Newsletter #395 Recap Podcast

2026-03-10T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Jon McAlpine, Antoine Poinsot, Mike Casey, and Ethan Heilman to discuss Newsletter #395.

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

Download audio

News

● A standard for stateless VTXO verification (1:31)
● Draft BIP for expanded `nVersion` nonce space for miners (1:23:45)

Changing consensus

● Extensions to standard tooling for TEMPLATEHASH-CSFS-IK support (13:52)
● Hourglass V2 update (25:40)
● Algorithm agility for Bitcoin (51:15)
● The limitations of cryptographic agility in Bitcoin (1:05:15)

Releases and release candidates

● Bitcoin Core 28.4rc1 (1:36:53)

Notable code and documentation changes

● Bitcoin Core #33616 (1:38:30)
● Bitcoin Core #34616 (1:42:23)
● Eclair #3256 (1:46:20)
● Eclair #3258 (1:48:34)
● Eclair #3255 (1:50:14)
● LDK #4402 (1:52:27)
● LND #10604 (1:53:56)
● BIPs #1699 (1:55:34)
● BIPs #2106 (1:57:30)
● BIPs #2068 (2:01:28)
● BOLTs #1301 (2:04:54)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #395 Recap. Today, we’re going to be talking about a few News items, including verifying VTXOs across different Ark implementations; there is a draft BIP for expanding miner-usable nonce space in the block header; and then, we have our monthly segment on Changing consensus that has a handful of quantum-related items, and also some tooling for OP_TEMPLATEHASH. This week, Murch, Gustavo and I are joined by a few guests. I’ll have them introduce themselves briefly. Jon.

Jon McAlpine: Hi, my name is Jon and I’m working on V-PACK, which is a tool for independently verifying VTXOs on Bitcoin layer 2.

Mike Schmidt: Antoine.

Antoine Poinsot: Hey, my name is Antoine, I work on Bitcoin stuff and Bitcoin Core at Chaincode Labs.

Mike Schmidt: Mike.

Mike Casey: Mike Casey I work over with the Anduro team over at MARA, and we work on quantum-related issues primarily these days.

Mike Schmidt: And Ethan.

Ethan Heilman: Hi, I’m Ethan, I’m one of the co-authors of BIP360, and I’ve been taking a look at how Bitcoin can survive breaks in its signature algorithms, including quantum attacks, but also classical attacks.

A standard for stateless VTXO verification

Mike Schmidt: Thank you all for your time and thanks for joining us. We’re going to jump in with the News. First item, “A standard for stateless VTXO verification”. Jon, you posted to Delving Bitcoin about new V-PACK that you just mentioned, a stateless VTXO verification standard. Maybe there’s a few different questions we can unwrap for the audience to make sure they’re up to speed. How about, remind us what a VTXO is, what is verifying a VTXO, what is the stateless verification of VTXO, and then why do we need a standard for this?

Jon McAlpine: Sure, yeah. Okay, so starting with what is the VTXO, that’s probably the most important. VTXO stands for Virtual Unspent Transaction Output. And it’s kind of the atomic unit of ownership for the Ark layer 2 protocol. So, one of the things that’s, I think, really helpful and nice about Ark is that the VTXO maps very closely to a UTXO, just like on layer 1 Bitcoin, and it’s even right there in the name. But there’s one important distinction, maybe more, but there’s one that I’m going to talk about today, which is that on layer 1 Bitcoin, to kind of have full sovereignty and access to your funds, you only need a private key or a seed, something like that, and you can access your funds. In Ark, with VTXOs, if a user wants to unilaterally exit, which is to say kind of claim their funds on layer 1 without cooperation of the Ark Service Provider (ASP), they actually need two parts. So, I call this kind of a half-key problem. You need the private keys and you need a map to your specific VTXO, because your VTXO lives in a leaf in a taproot tree. And to get to that leaf, you actually need to kind of construct the tree from the root, which lives on layer 1 as a layer 1 transaction, up each layer of the tree until you get to your specific leaf containing your VTXO.

So, for unilateral exits, you cannot just have your private key, you also need this kind of map. And so, that’s what V-PACK aims to do, is to store this map in a kind of highly optimized file that can give users sort of an independent backup, and also kind of verify that there’s kind of two pillars of security with VTXOs. One is that you have the map to your funds and you have the ability to store your funds, and that’s what V-PACK does currently. It’s work in progress. So, the second pillar is not quite implemented yet, but that’s to go through that tree and verify that there are no other spending possibilities, no other kind of back doors where an ASP, or someone else, could sweep those funds or take those funds for themselves.

Okay, and so then moving on, the stateless aspect is that this is meant to be deterministic. So, if you have the anchor transaction on layer 1 Bitcoin and you have the full taproot tree, you can construct those two pillars of security to be sure that you have access to your funds and no one else does. I want to be clear as well, there are two main implementations of Ark currently. Ark labs are building Arkade and Second are building Bark. And with both of these implementations, you already can have all of this information. They freely provide this data, those are open-source projects. I want to shout out those teams, they’ve been very helpful. And this isn’t to say that they don’t give you everything you need, they do. But V-PACK is aiming to be kind of an independent, neutral standard so that even as Ark implementations are diverging in their focus, or innovating and bringing new features to layer 2, the security and the fundamental sovereignty and ownership of the VTXO hopefully can kind of converge on an open standard, so that users maintain their sovereignty over their funds and their ability to independently audit that sovereignty and potentially claim those funds on their own as well.

Mike Schmidt: I think we covered all of the pieces of my original question, and you also touched on one of the, I don’t know if, I guess it’s maybe not an objection, but one of the concerns raised. I think it was Stephen Roose talking about the path exclusivity, and I think you mentioned that that’s something that you’ll be working on next, which is, okay, you can ensure that your unilateral exit is in there, but what about any other shenanigans that may have been put in there? And so, that’s in progress, correct?

Jon McAlpine: Yes, that’s right. I’ve actually recently applied for a grant from OpenSats to continue this work. I’m still building it on my own. But yeah, the current next step is, like you said, verifying that no one else can claim those funds. Looking further down the line and longer term, if covenants become a thing, this makes things a little easier for V-PACK, and I would say for Ark in general. But the need to still be able to independently verify is still there. And so, I think this kind of tool is useful and important now and moving forward.

Mike Schmidt: Now, I know there’s a website with a live tool. Is it vtxopack.org; do I have that right?

Jon McAlpine: Yes, that’s right. Yeah, so I’d eventually like this to be kind of a suite of tools. The V-PACK library is intended to be no standard and potentially usable on hardware wallets or other kinds of constrained devices. But I’d also like to add some tools where users can broadcast these unilateral exit transactions, or these series of transactions, if needed. Currently, that vtxopack.org site allows users to verify their specific path. But I plan on continuing to work on that to show the full tree once I have the path exclusivity part of the security model, and also add an ability for users to, if they need to, import their V-PACK and broadcast the series of transactions to claim their funds on layer 1. And I think also it’s just very helpful to kind of be able to visualize. I think a lot of users understand the UTXO model well. And the VTXO model, I think, is not too difficult once you wrap your head around it. But for me, at least visualizing the tree and the idea of a path to your funds is helpful. And so, I hope the site can do that as well.

Mike Schmidt: Great. What’s the feedback been from the different teams? You mentioned you appreciate that they were open source and they were engaging with you. Are they on board with developing such a standard, or is there a competing standard or idea?

Jon McAlpine: Yeah, right now the feedback has been positive. I think another benefit of V-PACK is that it acts as kind of a second pair of eyes. So, right now, both teams are kind of on their own, they’re writing the code for the server. So, they’re writing the code that generates and creates these VTXOs, and they’re also writing the code that kind of consumes those VTXOs. And so, there’s maybe an increased possibility where if there’s an incorrect assumption, that assumption could be baked into the server side and the consumption side. And V-PACK hopes to be another set of eyes to run kind of like a cleanroom math on these taproot trees and things. So, I think the project is also meant to be helpful for the teams, in that they’d have a second set of eyes, and I think they’ve kind of recognized that. As far as a competing standard there, there isn’t right now. The thing to keep in mind is that Ark in general is very new, so they’re changing very quickly. And so, the VTXOs that they are creating are changing and are not set in stone. And so, the idea of a VTXO standard, we’re not to that point yet, I think. But deciding on kind of a minimum viable standard to verify VTXOs, I think that’s what I’m trying to get at, and I think there’s been some positive momentum toward that.

Mike Schmidt: Well, those are my questions. I’m not sure if Murch, Gustavo or others have any follow-up.

Mark Erhardt: I think I didn’t fully appreciate that you were completely independent from the Ark teams before you explained this. So, that’s pretty awesome, because there’s a lot of complexity in how these trees of transactions work and what assumptions all are baked in there. So, having a third set of eyes is pretty nice. I was wondering, so there are a lot of covenant proposals floating around and I think that the Ark teams are especially interested in TXHASH and CSFS (CHECKSIGFROMSTACK), maybe CTV (CHECKTEMPLATEVERIFY) or TEMPLATEHASH. Have you been looking into how that changes your implementation, if any of them might get adopted at some point?

Jon McAlpine: A little bit. Not in the specifics of each particular possible implementation, but more broadly, I’d say with covenants, there’s less ambiguity about where funds can be spent. And so, currently, going back to the two pillars of security, that second pillar of path exclusivity. Right now, we will need to store in V-PACK additional signatures and more data to prove that there are no hidden back doors to your funds. Once we have covenants at a high level, and we can more easily verify that the funds can only be spent to your address, we still need to kind of traverse the entire taproot tree to verify that those funds aren’t double-spent in another way, but we don’t need to store as much data, because signatures that are not trying to spend those funds to your address I don’t think will need to be stored. So, I’ve kind of started looking in that direction a little bit, but haven’t gone very deep on what it means specifically.

Mark Erhardt: Yeah, thanks for your work.

Mike Schmidt: Jon, any parting words for the audience, any calls to action before we wrap up this News item?

Jon McAlpine: No, I just want to say thank you again to the Ark Labs and Second teams. They’ve really been very helpful and I hope to continue the good work.

Extensions to standard tooling for TEMPLATEHASH-CSFS-IK support

Mike Schmidt: Jon, thanks for your time, we appreciate it. We’re going to move out of order a bit and go to the Changing Consensus segment, and we’ll start with the first item there titled, “Extensions to standard tooling for TEMPLATEHASH”. Antoine, you posted to the Bitcoin-Dev mailing list about your preliminary work, working on TEMPLATEHASH and the surrounding opcodes that bundle in that proposal, specifically tooling around miniscript and PSBTs. Maybe just really briefly for the audience, maybe you can recap OP_TEMPLATEHASH, and how that bundle can achieve additional things in Bitcoin.

Antoine Poinsot: Sure. So, TEMPLATEHASH is a primitive that allows you, in a taproot script, to commit to the very specific transaction to spend an output. For people familiar with CTV, it’s a taproot-only version of CTV, which allows us to leverage the modern features of taproot, such as address reusing the signature hash that is already cached for signatures, which really simplifies, by and large, the implementations in the consensus code, and also allows to push the hash on the stack instead of having to verify semantics that were necessary in CTV, because it was using the OP_NOP upgrade hooks instead of the more modern OP_SUCCESS upgrade hooks in tapscript. So, that’s what TEMPLATEHASH is. And the whole bundle is very similar to the CTV plus CSFS proposal from last year, except that it’s using TEMPLATEHASH instead. And it’s arguing that it’s a good first stopping point for a feature soft fork, because feature soft forks have been discussed for the past six years without finding real consensus around what features do we really want to enable, and what new applications do we want to enable, and what are we wary of enabling? And there is bias expressivity levels.

The first one that is a good balance, in our opinion, with Greg Sanders and Steven Roose, is this bundle, which improves existing proven ways of scaling Bitcoin, such as Lightning, improving all sorts of payment channels, and also new promising ways of scaling Bitcoin, such as Ark. So, that’s the tl;dr of the bundle.

Mike Schmidt: Awesome. And so, I don’t have the newsletter handy, but we covered your initial publication of the idea around TEMPLATEHASH and the software bundle. Users can search for that on their own, and I think we had you on to talk about it. But now, I guess, as this proposal moves forward, one in the community might expect things like what we’re talking about today, which is integrate this with some of the tooling and see how that works, right? And maybe you can talk a little bit about challenges or ease of integrating TEMPLATEHASH into miniscript and PSBTs.

Antoine Poinsot: Yes, so the goal is, I guess, twofold. First of all, it was interesting to me to just go through the process of, let’s say we had enabled these opcodes, and now we need to use them in various protocols and applications using Bitcoin, then we would have to modify the standard toolings that we have to work with Bitcoin transactions and scripts. And so, the tooling that we have that is standard is PSBTs to work with transactions, and miniscript to reason about Bitcoin Scripts. So, I was trying to think through what could make sense to integrate into miniscript, because you want to first reason about the script and then you think through what do you need in the PSBT, what new fields do you need in the PSBT to satisfy the scripts. So, you want to think more at the capability level rather than the specific opcode primitives when you’re thinking about new miniscript fragments, which is essentially new miniscript operations. And the capabilities that are introduced in the soft forks are committing to very specific next transactions, re-bindable signatures, which is the basis on which a lot of the payment channels improvements I discussed earlier are based on, and arbitrary message signatures.

So, there is an existing type system for miniscripts, where all fragments, all operations in miniscript have some defined properties that are encoded into types. And then, when you want to combine them, you assert that the various operations are compatible using those properties by leveraging the types. And so, there was some work around the type system with thought for the existing operations. And these new operations have some properties that do not neatly fit in the model, so I had to extend some of the type properties. I don’t think discussing the very specific details of the modifications to the type would be necessary here. If you want the details, the auditors can look up the mailing list post.

But essentially, I think the takeaway is with some small modification, it fits in fairly nicely. And also, I learned something about, for instance, the order of operation for the CSFS opcode, which is it turns out that all the operations that was chosen by the BIP authors actually conflicts with how miniscript reasons about the general operations. I don’t think it’s necessarily a big conflict. I also discussed it with one of the authors of BIP348, CSFS, and I think we agree that if we didn’t want the additional OP_SWAP that was necessary to work around the order of operation in CSFS, we might as well just change the type system of miniscript. At the end of the day, my exploration was just an exploration. I didn’t want to introduce a whole new type into miniscript. But if we were to activate those opcodes, it might be necessary and it’s fine, and CSFS does not need to be changed. So, I think it’s some amount of validation on the design of those opcodes.

Mark Erhardt: Sorry, you said that there would be a lot of OP_SWAPs required if you just fit an OP_CSFS into miniscript. I assume that that is because you either want to modify the message that is being checked with the CSFS, or you want to modify a key, or sometimes maybe the signature, well, tweaking something into it, or whatever. So, in our writeup, we say that there’s not an obvious order in which OP_SWAP would be used less often. How would fixing the type system get around this issue?

Antoine Poinsot: Actually, changing the order of operations would fix the issue for the miniscript integration. It might conflict with other use cases that required this order of operations, and it turns out that I was not aware, but the author of the BIP pointed out to me that this specific order was chosen based on some empirical work he had done. So, one thing needs one order, another needs the other order, and it turns out that my thing can just be adapted to work around it. So, I think it’s better to adapt miniscript if needs be. And with regard to your other question of how to adapt it, the issue with the order is that in miniscript, there is a type, which is K for keys, which can be any general expression. And it can be really anything that checks a multisignature and is a threshold of another set of conditions. And at the end, it just spits out a public key. Then, it will still be a type K, and it will be supported in my generalistic fragment for verifying arbitrary messages.

An alternative to design the fragments to check the arbitrary messages could have been to hard-code the public key inside the fragment. In this case, we do not need the OP_SWAP. This is because the type of miniscript depends on where it takes its arguments from. It takes its arguments from the top of the stack. And because the public key needs to be the first argument to a CSFS, and then there’s the message, if you have the message and then the generalistic argument that precedes it, you cannot give argument to the generalistic message. So, you need to have the message first, take the generalistic operation, let it be fed its arguments, and then you swap the result, because the result is always a single element. The way of fixing it is to instead, instruct the defragment to take its inputs from one below the top of the stack. And we already have one such type that does it, which is W, and it just does not exist for the key type. It only exists for the basic type, which is something like “Check a signature”. That’s a basic type, because it always returns 0 or 1 on the stack. And we have a W that does the equivalent of this, but takes its input from one below the top of the stack, and we could just have the equivalent for the key type as well, if we wanted to.

Mark Erhardt: So, basically, the order in which the elements are read would be changed so that CSFS would always take the public key from the second element from the top rather than the top, even while there is still a top element. Anyone else have comments on this topic?

Mike Schmidt: I had another question for Antoine, but maybe if he comes back, we can integrate them. But maybe in the meantime, we can move forward.

Hourglass V2 update

Mark Erhardt: Okay, so Hourglass V2, I think that’s up next.

Mike Schmidt: Yeah, we’ll move on to Hourglass V2. Mike, thanks for joining us. You posted an update to the Hourglass protocol on the Bitcoin-Dev mailing list. I don’t think we’ve discussed Hourglass on this show before. So, maybe it would make sense to talk about the motivation, and maybe just a brief explanation of what Hourglass V1 was; and then, that will make a little bit more sense about V2.

Mike Casey: Sure, thanks for having me. Well, the motivation is basically what to do with the P2PK coins, which are the earliest mined coins before we switched over fully to the P2PKH, which of course is a hashed variant of that output type, which does provide it some protection from quantum attackers, because it is much, much harder to reverse a hash than it is with a cryptographically-relevant quantum computer using Shor’s algorithm to reverse a public key. And the public key is in fact what is posted on the P2PK transactions on the blockchain. It’s particularly onerous for this set because these are the first coins that were mined on the network, which include presumably all of Satoshi’s coins. Your guess is as good as mine as to how many of that set are Satoshi’s coins, but the total set is pretty well known. It’s about 1.7 million BTC in total are part of this set. And most of them are pretty much generally regarded as lost. They were mined at a point in time where Bitcoin effectively had no price, had no value. And it is assumed that most of them were just thrown away as they were just an experiment. But that may or may not be the case. They are found from time to time. And of course, Satoshi may or may not still be out there and maybe still has his keys. So, nobody knows.

There are two camps on what to do, or historically there’ve been two camps on what to do with these coins. One is probably Bitcoin purist, is to do nothing. You know, not your keys, not your coins. If somebody has the ability, they have the private key, they should be able to spend the coins. That’s the assurance of Bitcoin. The other camp say, well, this could be very, very dramatic on the price of bitcoin and the security budget of bitcoin because of that. If somebody were to get it, it would cause havoc. And it was already assumed, under most people who joined into Bitcoin later, they operated on the assumption that was told by everybody who orange-pilled them, “Well, those coins are gone. They’ll never be spent. Satoshi said, ‘Consider those a donation to the rest of bitcoin’s value’”. So, they’ve operated under that assumption and to say, “Well, these could come roaring back to life in the hands of new owners”, then it could be very deleterious and it would allow them to effectively steal the coins.

It’s interesting, because both sides are kind of a bit of a violation of the promise of Bitcoin. Because the promise of Bitcoin is (a), you will always be able to spend your coins if you have the keys. There will be no restrictions, you cannot be censored. That’s part of the promise. And the other part of the promise is, technologically, cryptographically, it’s safe. Nobody can steal your coins unless you reveal your private key. So, those two things are at a conflict, and then we don’t know what to do as a group. And I personally find the thought of confiscation kind of abhorrent, which would be freezing or burning these coins and saying they cannot be used after a certain date. But a lot of people feel very differently, and they feel that we should do it. But the fact is, if we are to do anything with these coins, other than liquidation, which is the current status quo, if we do nothing, then if quantum computers ever do become a thing, then they will be stolen. And the scary part about that is, we did the math. These things could be stolen in a matter of three hours if you pre-cracked all of the keys and crammed every single block full of these transactions. You could get all 1.7 million bitcoin somewhere liquid within three hours, which that could be disruptive.

Yeah, so the original hourglass proposal, it was the simplest thing. We talked about it a lot, Hunter and I, and we went back and forth on a bunch of things. We decided we had to keep it exceedingly simple. And the simplest thing to do was just restrict it to one output per block. This was not our idea, by the way. I forget the gentleman’s name. He’s in the draft as an acknowledgement, but he mentioned it to Hunter in Denver as, “Well, why don’t you just restrict the P2PK spends to one per block?” And I started thinking about that, and I was like, “But that’s amazing”. Because if you restrict it, you’re not confiscating, you’re restricting. So, somebody who has one of these coins, or one of these P2PK outputs, they can still spend it. It’s just inconvenient because you can’t spend a whole bunch of them at once, you can only spend one per block. And so, it creates kind of a secondary fee market based on that; but one that in the absence of a quantum attack, I would not expect to be heavily leveraged, because these coins have been sitting dormant for nearly as long as Bitcoin has been around. So, you wouldn’t imagine there would be much competition at any one time to start moving these keys all of a sudden.

Also, most importantly, this would be a flag-day activation soft fork out in front. There would be plenty of notice for anybody before activated to be able to move their coins ahead of time before any restrictions put in place. So, the idea would be, much like any of the confiscation proposals, to let people know, “Hey, on this date, this is going into place. So, if you move anything you have in this set to some other form of output, there will be no restriction. You can freely use them. However, if you leave them there beyond this date, then there will be this restriction put in place that will make them harder to move”. But you still can move them, that is the key. It is not a total confiscation because you can move them, there are just restrictions in place to which the speed you can move them.

So, the original proposal was one per block. And we did the math. Roughly eight months for the 1.7 million bitcoin would be the maximum somebody could move all of those coins. So, you go from three hours to roughly eight months. But a lot of people that we talked to when we socialize this, especially in the confiscation camp, they said, “That’s not enough time. You could still lead to a mass liquidation event, because of panic in the market because these things are flying off”. And that’s a lot of bitcoin to change hands in a brief amount of time. I mean, I don’t necessarily 100% agree with that perspective, but I am sensitive to it, right, if we’re trying to appease people. Well, okay, so we revisited it. We actually initially had a much wider scope, because we wanted to try to apply Hourglass to not only the P2PK coins, but also the reused set, the reused addresses, addresses that have been spent from prior. We looked into it. There’s no way conceivably to do that, because the only way you could do that is to track every address that has ever been sent from, through the history and growing history. This is an enormous amount compared to the UTXO set, and will grow forever, and there is no trimming it. So, it’s just not something you can consider.

But as part of that original proposal, one of the other things we were looking into, and we discussed it with Peter Todd, you can actually put in a further restriction on it, so it’s not only one output; you put in another restriction mandating that in any excess of a certain amount, we chose 1 bitcoin, 1 BTC as the amount, anything in excess of that amount as an outflow from a transaction with a P2PK input must contain that amount minus 1 as an input back to the original sending address. So, what that means is you can take bitcoin out of it, and there’s no use about reusing address, don’t even worry about it, because the public key is already posted, it’s already exposed. So, you change nothing by having multiple spends on this. Yes, Murch?

Mark Erhardt: Let me jump in there for a moment. I don’t think that’s true. Because now you’re making 50 payments and if you’re paying to 50 different outputs, you’re tying together all of these 50 other outputs. So, you’re creating a set of outputs that belong together that is vastly bigger than a single one. And so, there is a privacy concern due to the address reuse because it ties together all of the recipient addresses. Even if you only do that one operation, a P2PK input, and sending the rest back to the same output script, all of the outputs are being tied together. So, it creates a huge tree of future transactions that are associated.

Mike Casey: Well, yes, I mean, it is somewhat deleterious from a privacy perspective if you do not use the same path for all of the transactions going out. It’s not perfectly analogous to it, but it doesn’t really bloat anything, right? It’s just privacy trade-offs, correct?

Mark Erhardt: Yeah, it’s just privacy. But when you say it doesn’t bloat anything, well, you go from a single input that’s 114 bytes and 1 output to, well, 50 inputs and 49 P2PK outputs that weren’t necessarily – so, yeah, you increase the block space you need by about 600 times.

Mike Casey: That is correct, it does, but it is temporal. So, the total block space is still the same, it’s the same amount per block, because it’s pushing it out into the future.

Mark Erhardt: But to spend your 50 bitcoin, let’s say you start with 50 bitcoin and one P2PK output. You now need 50 transactions to chip off 1 bitcoin each time. And every time, you also need this additional change output that goes back to the prior. So, it’s not quite, but 50 times more block space to spend your coin.

Mike Casey: That is correct. But it’s spread out over 50 blocks. So, you have 50 times as much block space to use as a percentage of, versus 1. So, it’s actually very close to the same size on a per-block basis. But you’re right; in total, it does use 50 times as much. But it’s not at one set point in time, 1 block.

Mike Schmidt: Mike, how do the fees work here?

Mike Casey: Okay, very, very, very good question. So, I mean, it would create another fee market, because you would have a separate fee market for this, opposed to regular fees. So, if somebody did want to move these, if nobody else was moving them and it was open, you would submit, you know, it depends on your time preference, of course, right? So, in the absence of a quantum attacker, I think it’s a safe assumption that most of these holders who have been holding on to them since 2010 probably have a fairly low time preference. And if that changes, then the value has increased such that 1 BTC is worth quite a bit more than it was back then. So, let me just first, the 1 BTC restriction, did I go over that? So, yeah, so the amount is 1 BTC.

So, yeah, once you get back to the 1 BTC restriction, I would just like to touch on this briefly. That level, it is arbitrary, but it’s a good Schelling point. And aside from that, if you backtest it, how long would it take you to move that in the absence of any other fee competition? That means you could move one of these P2PK outputs, which are typically 50 BTC, you could move almost three in a day. It would take you about a third of a day to get through all 50 of those, with 144 blocks in a day, easy to do the math. So, yeah, so that’s the bandwidth that we’re talking about here. And of course, if you’re talking about fees, it’s a function of how much demand on one side, and supply. So, we’ve restricted the supply for these. You cannot move them. Under an Hourglass, it’s coded. Yes?

Mark Erhardt: Well, to be fair, this would be announced way ahead of time, and assuming that people who have a ton of money in Bitcoin are even superficially paying attention to what’s going on in Bitcoin, they would hopefully hear about this restriction being discussed and planned. And if they have the keys, they would just move their P2PK outputs before the restriction even applies. So, we’re talking presumably, unless people have been really laying low and not paying attention at all, we’re talking only about UTXOs of people that weren’t paying attention or that have been misappropriated by people with quantum computers.

Mike Casey: Correct, and that’s an excellent point, Murch. It’s not like we’re just going to impose this overnight, and then everybody’s funds are stuck and they now have to compete. The goal is to do it with a sufficiently advanced warning that everybody who wants to move their keys and has access to them can do that. And what’s really weird is we talk about timeframes and scales. We don’t really know what the timeframe or scale would be until that that event has happened. Now, imagine if Satoshi was among that population, just decided to move all of his keys, which let’s say is somewhere between 600K and 1.2 million, and just decides to move all those in advance. Well, that would drastically change the assumptions. So, I mean, which is fine, that’s why you go through the exercise. And the reason I like Hourglass so much better than a confiscation is in a confiscation scenario, you have now potentially forced Satoshi’s hand. They, he, she, whatever, Satoshi has to move those coins or lose them forever, per the protocol, if a confiscation’s enacted. But if Hourglass is put in place, that doesn’t really exist, right? So, Satoshi’s temporally restricted, but – yes, Murch?

Mark Erhardt: Well, you already mentioned that it would take 38 years to move all of the coins, and you’re talking about 1.7 million. If the Patoshi pattern actually is correct, and if Satoshi still has the keys, then 1.2 million of those coins roughly are Satoshi’s. So, that’s temporarily limited to 25 years to move their coins. No, I think Satoshi, if they still have their coins and this limit gets consensus, they would move their coins in advance. It would be very dumb to rely on being able to do it over 25 years.

Mike Casey: Correct. Well, I would assume so too, but it all depends on how much Satoshi values his privacy, right? Because there could be other coins that Satoshi has, far more than you or I or anybody, that are not part of the Patoshi pattern, that he mined independently that are not tied to him. So, I don’t know enough about Satoshi to say what he would or wouldn’t do. But with this, he would have the option, if he wanted to maintain his anonymity and not move his coins, to hide in the set of Hourglass-restricted, whenever he wanted to draw from the pile of coins that he holds and still maintain his relative anonymity, which is something great. Yes, Mike?

Mike Schmidt: Yeah, Ethan, I want to bring Ethan in, he had his hand up and he’s been patient.

Ethan Heilman: I just thought of something while you were talking and maybe you said it and I missed it, but I was curious, do you limit the amount of fees that can be paid to a miner?

Mike Casey: Yeah, well, that’s an interesting part of it. The total that is capped out, yes, the fees are limited, and that’s a very good point. The fees are limited to – I don’t know where I said this in the proposal. I don’t think it matters for this version. It mattered in the other version, where it was 50x. But in this version, it doesn’t actually matter what the fees are, because you’re forced to pay the 49, or whatever, the remainder, n-1, back to the address. But in the original version of Hourglass, it was a cap; you can spend no more than half of it on fees to the miners. Because otherwise, yes, you’re correct, you could just bribe a miner to offload the set, and then you could actually pay them to take the coin, and then make it all in fee, and then do a back channel to yourself of a payment. Then, you’re kind of avoiding the cap altogether. But in the Hourglass V2 version, I don’t think that’s applicable, because you have the forced output back to the original address.

Mark Erhardt: Right, you can’t extract more than 1 bitcoin from the set, because n-1 has to go back to the original output script. So, paying more than 1 bitcoin fees would be possible, but you would be burning money from other inputs in addition to burning all that you can extract from the P2PK output. So, it doesn’t make sense to pay more than 1 bitcoin. In fact, it doesn’t make sense to pay the whole bitcoin. So, it would be something less than that.

Ethan Heilman: There’s an aspect to this that may solve a different problem, which is that it seems like if it’s not Satoshi moving them, like it’s someone that’s broken ECDSA that’s moving them, if this break is well known, then the miners are likely the people who would exploit this break, because if a miner could steal the coins, they would not mine a block in which stolen coins were being moved, because it’s not incentivized for them to move it, because they could steal it in another block, so they would drop that and steal it themselves. And this is one of the things that’s always worried me about quantum, not just the price, but these sorts of attacks. And I think this does a really good job of turning stolen coins into a block reward.

Mike Casey: Well, yeah, that’s the knock-on effect, which isn’t actually the intended purpose of it. But if you game it out, it really ends up effectively as a subsidy. Because if you have more than one quantum attacker, and remember, keep in mind, if Satoshi doesn’t move his coins, if nobody appreciably does, the span of Hourglass V2, because it’s 1 bitcoin per block, actually goes out over 32 years. So, it would be a 1 BTC you could pull out of this for 32 straight years, which is a multiple of how long Bitcoin has existed. But yes, over that span of time, you would have to assume if you have one quantum attacker, then pretty shortly you will have a second quantum attacker of equal capability. And when you have at least two, they have to bid against one another in order to reclaim those coins. And since we have such a limited amount of throughput, they have to start bidding more and more for the block space for this specific type of coin from the miner, meaning more and more of that restricted throughput is going to be paid out to the miner in fees, and it’s not any one specific miner, it’s going to be whoever wins the block, right?

So, what that ends up being is a de facto emission of reuse of whatever coins that were in here, not intentional, just that’s the way that it works out, and you end up with, instead of having this quantum-attacker risk to Bitcoin, you now have quantum attackers subsidizing Bitcoin by insuring the security budget for a long amount of time.

Ethan Heilman: Yeah, the risk of a fork catastrophe, where miners don’t build on each other’s blocks because they all want to steal the coins.

Mike Casey: Well, that was the first thing.

Ethan Heilman: But if the coins are still there, if it’s a subsidy, then you address that. I don’t know, that’s one of the things that I worry a lot about, and I do like the thinking about the protocol there.

Mark Erhardt: Okay. So, the interesting thing here would be that usually, if there’s a humongous fee, it would incentivize remining the prior block because you want to collect the fee instead. But because if there are multiple quantum attackers that are putting transactions in every block to chip off that 1 bitcoin from an existing output script, they would be presumably roughly bidding the same fee on every block. So, you would have the same incentive to move forward versus remining the prior block. So, the concern doesn’t really apply here.

Mike Casey: Exactly.

Mike Schmidt: Mike, anything else we should know? We kind of went pretty deep on there, but maybe there’s perhaps also more.

Mike Casey: No, it’s pretty wide and varied with the game theoretical knock-on effects, but at its core, it’s a very simple process. The one thing I would also say is the biggest complaint I’ve got, other than hardcores who say, “We cannot touch this”, the biggest complaint I’ve got is just that it’s arbitrary at 1 BTC. But I think it’s a great Schelling point, it serves a good purpose for clear communication of the concept. And if you do the math for any gameable actual scenario, it works out to a good value. So, I don’t see any other reason to change it, and just keep it simple. And my hope with this is that I don’t see us getting consensus for a confiscation fork without having a hard fork, which I don’t want to happen, if we can avoid it. So, this is put forth as something that maybe we can all agree is a decent compromise between the two camps of confiscation and liquidation. So, that’s my hope.

Mark Erhardt: Hopefully, one of the last few questions, but what have you been thinking about the deployment timeline? The draft that I read doesn’t have a deployment timeline or even a recommendation of how long out to schedule this deactivation of this rule. What are your thoughts on this so far?

Mike Casey: I mean, open question, I would say without a doubt, a minimum of six months to give people enough time to be able to move their funds. But possibly longer. And I’m open to opinions on that. But I mean, it would be a standard. You would do a BIP9 flag day, “Well, this is when we intend”, and it’s n number of blocks from when it becomes approved, right? That’s how I envision it. But again, I’m open to suggestion on timing, but yeah.

Mike Schmidt: Sorry, a BIP9 flag day? So, you mean something like speedy trial? Because usually BIP9 is activation when the signaling is high enough.

Mike Casey: Yeah, with an offset. So, everybody would activate or signal activation, but that’s just the lock-in for it, and it doesn’t actually access until the set determined period after it actually ratifies. Yeah, that’s what I would suggest. But as to the length of time, that’s up for debate. Quantum is still viewed by many to be very, very, very far out, but advancements are made all the time. So, the sooner we can come to agreement on when we should do something, the sooner we can act.

Mark Erhardt: Yeah, thank you.

Mike Casey: Thank you.

Mike Schmidt: Thanks for joining us, Mike. You’re welcome to hang on or you’re free to drop. A couple more quantum items here. These two are somewhat related to each other. And there was a thought to put them potentially together as one item, but we split them off.

Algorithm agility for Bitcoin

The first one titled, “Algorithm agility for Bitcoin”. And we have Ethan, who wrote to Bitcoin-Dev mailing list talking about cryptographic, specifically, algorithm agility for Bitcoin. Ethan, what are you getting at here? And I know we just talked about quantum, but you have ideas here about how this is potentially advantageous, even regardless of quantum. So, maybe you want to talk about this cryptographic algorithm agility.

Ethan Heilman: Thanks. This is really motivated by the question of how Bitcoin can be safely used over long time horizons. So, a human lifespan, let’s say 75 years. Someone buys bitcoin when they’re 20, they put it in a safe somewhere, the estate planning is handling it when they’re 90. Would those coins still be safe over a 90-year period or over a 75-year period? So, the idea is to think through, given the history of cryptography and the fact that cryptographic algorithms weaken with age, how someone could put their coins down somewhere, and those coins, they don’t touch them, and 75 years, they take the coins out and the coins are still good. And I think this is a really important question for Bitcoin, because if people are using bitcoin as a savings account or to put wealth in, thinking on these long time horizons is actually really important to both communicate the value of bitcoin and for bitcoin to still have that value.

Part of this is motivated by quantum, as quantum is the current big threat to the digital signatures used in Bitcoin. But it’s also motivated by the fact that almost every single cryptographic algorithm we’ve had has weakened with time. And so, there may be classical attacks on the elliptic curve cryptography use. I want to be really specific in the cryptography I’m talking about. I believe that for most likely cryptographic attacks, Bitcoin can survive the hash functions being broken. If someone breaks the collision resistance of SHA256, that’s actually a pretty easy fix. The miners are incentivized to go along with the fix, and you just have additional data next to the chain that uses a new hash function for everything, and the old chain; and you soft fork this in so that the new consensus change is just, “Reject blocks that don’t have this additional data”, similar to how segwit works.

So, I’m not very concerned with breaks in SHA256, because I think that the recovery story is actually pretty good there. What I’m concerned with is the signature algorithms, because if, say, ECDSA or EC-schnorr were to be broken, how do you prove that you own an output? It’s almost entirely through EC-schnorr. And if that’s broken, it becomes extremely difficult to authenticate; or basically, the ownership of Bitcoin outputs is now no longer cryptographic. And I say I own it and someone else says they own it and we can both provide signatures, how do you tell who owns it? And that seems like that’s the soul of Bitcoin, like that’s really the value that Bitcoin provides. And if that was broken, that would be really, really bad for Bitcoin. There might be some ways to survive this with proof of seed phrase, but it would be a very, very hairy situation to deal with.

So, what I am proposing is a way of having a redundant signature scheme, such that you put your coins on a seed phrase, you bury it in a coffee can in your backyard, not suggesting anyone do this for their seed phrase, it’s a bad idea, but for the scenario, maybe you put in a safety deposit box, and there are multiple signature algorithms to spend it. And so, you use schnorr like you do every day, but then schnorr gets broken, you don’t move the coins, 50 years go by, someone looks at it and is like, “Oh, schnorr’s totally broken”. But you can also spend these coins with another signature algorithm. And because you can spend those coins with another signature algorithm, the coins can be then safely moved to an output that is secure and doesn’t use EC-schnorr.

The really important thing to understand about how this works is that it uses the tapleaf tree, where you can have multiple scripts that are all in a tree, in a taproot output. And so, it’s not that you have to spend with a new algorithm and the old algorithm. It’s actually an ‘or’. You could spend with schnorr, or you could spend with, like, imagine Fancy Algorithm, right? You could spend with either one. So, if you’re just spending these as normal, you’re not incurring any cost. But because they’re at the bottom of this merkle tree in a taproot output, as long as you haven’t revealed the public key for schnorr, no one can spend it even if schnorr is broken. This does require BIP360 or something similar to BIP360, because if you could break schnorr, you could actually just spend through the keyspend path in taproot. But assuming that either BIP360 is out there, and by BIP360 I mean P2MR (pay to merkle root), which is basically P2TR, but with the keyspend path cut off, or the keyspend path has been disabled in taproot, which is actually really similar to BIP360, if either of those are true and we have an additional signature algorithm, you could employ this. If the current signature algorithm is broken, you could use the new signature algorithm to then move everyone over to a new output. Those that don’t move over will still be protected. And using this, we can rotate the signature algorithms that are used in Bitcoin as they’re broken.

If you want to get really long-term about this, be long-termist about this, imagine Bitcoin for 200 years. I think that it’s hard to think about things on this timescale, but I do think it’s a valuable mental exercise. We’ll probably have multiple signature breaks over that time. So, we need a mechanism to move from one signature to another that doesn’t get us in the situation that we currently are with, like, P2PK outputs, where it’s like, do we confiscate them, do we not confiscate them? So, the main idea with algorithm agility is, what can we learn from where we are now so that we can make these transitions to new signature algorithms smooth and safe? And also, if someone just buries an HD seed or buries a secret somewhere or sticks it in a safety deposit box, in 75 years when their estate takes over, they don’t have a security problem, they can move those coins safely.

Mike Schmidt: Ethan, it sounds like the idea is that there basically would always be two. Is that the preference; two, not more than two, not less than two, two? And so, when one gets bad, then the combination would be the second one, plus a third one potentially would be then the standard moving forward, or maybe talk a little bit about how that might work.

Ethan Heilman: Yeah. You would always want at least two, so that if one’s broken, you can have one, like a transition, a migration public key, and a migration algorithm. The way that I’ve been thinking about it is that the secondary one, the migration one, for the 75-year use case, you really want that one to be secure. You don’t want there to be two breaks, because then the person that buried their HD seed in their yard is in trouble when they dig it up in 75 years. So, you want a cryptography for the migration key that probably will be the same over time. And then, you have the sort of new, everyday signature algorithm, that occasionally gets replaced when it weakens with a new everyday signature algorithm. And we do have some signature algorithms that are very inefficient but are thought to be extremely secure that would make good backup algorithms, specifically hash-based cryptography.

You could use SPHINCS for this, or you could use SHRINCS for this, which is like a stateful version of SPHINCS, which is significantly more efficient than SPHINCS, and also has the property that you can treat a SHRINCS public key as either a SHRINCS public key or a SPHINCS public key. Now that I’m saying these words out loud, it’s a bit of a tongue-twister. And so, the nice thing about that is that almost works as like a third backup. Like, you have two signature algorithms, SHRINCS and schnorr. Schnorr gets broken, maybe it’s quantum, maybe an AI discovers some new elliptic curve approach that breaks it. And you go to use SHRINCS, and SHRINCS is almost definitely going to be secure. But let’s say there’s some discovery that somehow it’s not secure. Now, using your SHRINCS public key, you can fall back to a SPHINCS signature. So, I guess SPHINCS is the backup and then SHRINCS as the everyday algorithm.

Mike Schmidt: Yeah, that example makes sense. And I know you’re not necessarily proposing this exact scenario, but I think it’s helpful for folks to wrap their heads around it. So, we have schnorr now and we can do fancy things. But people are worried about that breaking, so maybe they would use something dumb, like a hash-based, right, as like their panic button that they push. And then, maybe the fancy signature that comes around is something more like lattice-based, where my understanding is that maybe we get some of the interesting benefits of the crypto that we enjoy now. And then, I guess that would be sort of an example of how this could play out over the next few signature schemes? I know you’re not proposing this, but I’m just trying to wrap my head around it practically.

Ethan Heilman: Yeah, I think that’s exactly it. We don’t want to lock Bitcoin into SPHINCS and then have to give up a whole bunch of things, like signature aggregation. And I know there’s ways to do signature aggregation with SPHINCS, but it’s messy. You really would want something that’s like a drop-in replacement for schnorr, but we’re not there yet. And so, it’s like you have two castle walls, and you have the outside castle wall that people come through all the time, it’s very useful. And then, you have the last castle wall where everything’s gone wrong. There’s one gate in it, it’s a real pain to get in there, but if you’re at the last wall, you’re really happy it’s there. And if the outside castle wall gets breached at some point, it’s cool. You can build a new one out there with all the nice features that you want. But you’ll always have that final wall to fall back to if everything goes wrong. And I really think we need that final wall if we’re going to think of Bitcoin as not like a 30-year project, but as a 100-year project, or even longer.

Mike Schmidt: Mike?

Mike Casey: Yeah, thanks. Yeah, I totally agree with everything you’ve been saying. I just wanted to point out something as well, that P2MR offers as a structure. If you have multiple algorithms there, you also have the ability to have a leaf that requires two different algorithms or some sort of hybrid of that, which the advantage it gives you there is we’re, in some cases, dealing with novel cryptography here. And there’s a chance it could be quantum-vulnerable or even classical-vulnerable, whatever we’re injecting into the system. So, if you have a leaf that allows you to rely on both a new crypto scheme and, say, schnorr, it gives you at least the resistance to any of those other traditional attacks that schnorr does, if it requires both. And since schnorr is such a light algorithm, it doesn’t really add much extra to the weight of it versus some of these PQC (post-quantum cryptography) schemes. So, that’s just another little avenue of this. But yeah, I followed Ethan’s post. It was great, phenomenal.

The limitations of cryptographic agility in Bitcoin

Mike Schmidt: Ethan, maybe this is a good segue and you can help us, because we don’t have Pieter here. And I know Pieter wrote a different post, but it was in the similar vein of this algorithm agility. And so, do you feel comfortable summarizing what you think his – can you steelman his stance?

Ethan Heilman: So, I saw his post. his post is called, “The limitations of cryptographic agility in Bitcoin”. And I was like, “Oh, I’m going to disagree with this”. And I think that I largely agree with it. I kind of see it as kind of in the same direction that I was trying to go with, with algorithm agility. And I’m looking at it now. I think his main point was that we don’t want a fragmentation of cryptographic algorithms, which is something I really agree with. And my attempt to steelman his post, which I’ll just give you my own views, because it’s pretty much the same as Pieter’s on this; if we just had people adding their own signature algorithms to Bitcoin and being like, “Well, I want Fancy Algorithm 1”, and someone else is like, “I want Fancy Algorithm 2”, and they can’t agree, so we add both, this would be bad for security and it would be bad for user experience and it would be bad for wallet developers, because do the wallets support all of these? Is this a privacy leak? The wallets are probably not going to support a bunch of different signatures, and people adding their own signatures to Bitcoin means that people will likely get it wrong. Or you go to dig up the HD seed in the backyard after 75 years and then you can’t figure out how to spend it because it’s some cobbled-together algorithm that grandpa thought was cool 75 years ago.

So, I think that we have to be very exact in this, that adding signature algorithms to Bitcoin should be taken very seriously and very carefully, and that we should make sure we understand why we’re adding it. We shouldn’t just add it to make people happy. We should add it because it solves a real security problem, we’ve heavily tested and looked at this algorithm. And when we go to wallet devs and be like, “Listen, you’ve got to build this. There is a real desire from users for it”, so that the wallet devs feel like they’re not wasting their time and that we haven’t come to them, like, five times last year and been like, “You’ve got to add a new signature algorithm”. So, I really agree with almost everything that was said in there.

Mike Schmidt: Well, it seems that Pieter just takes it one step further. You both agree that maybe everyone shouldn’t be rolling their own schemes using things like OP_CAT, or something, and trying to come up with their own way to secure things. And obviously, there’s the ecosystem tax that that puts on wallet developers, etc. But I think Pieter seems to be taking it one step further and saying like, “Even if there’s two, everyone’s going to want the other people to use the one, right? There’s going to be camps and they’re going to want to force people on their scheme”. Am I understanding his perspective right?

Ethan Heilman: I think so. I think every time there is a discussion of like, “Should we add a new signature scheme to Bitcoin?” there’s going to be a lot of debate around that. I personally don’t see that as a bad thing. And I don’t think that we should solve the debate by just letting everyone have the scheme that they want. I think the community has to make hard choices. And I think if the community can’t make hard choices on this on a timescale long enough, and we only have one signature scheme on a timescale long enough, that signature scheme will be broken. So, I think there’s actually a strong forcing function for the community to make these hard choices. But I think it has to be a hard choice. It can’t be, “Oh, we’ll just let any signature scheme in”.

Mike Schmidt: Is it a hard enough choice that it’s only moving from one signature scheme to the next single-signature scheme? I guess, that’s where I see the delta, is you’re saying it should be hard. But I think from what I’m reading from Pieter, he thinks that having more than one is the issue. If you add one, you turn off the old one, right? That’s where I’m seeing the delta.

Ethan Heilman: Yeah, I think that’s my point of disagreement with Pieter. Although I feel like he says that he’s not arguing that Bitcoin should turn off the old one, he just thinks that that’s likely.

Mike Schmidt: Fair. Yeah, he’s not saying that; he’s saying people will say that, I guess, yeah.

Ethan Heilman: Yeah. My personal view on both how this will work and how this should work is that at least with scripts that use ECDSA or schnorr, I think we should still allow those opcodes to be used, and that we shouldn’t just turn them off, even if they’re insecure; similar to how we don’t turn off SHA1, even though SHA1 has collisions in it. I do think that we want at least two secure signatures at any one time, where one of them is thought, “This will not be broken on a 100-year timescale”, and one of them is thought, “This is a really useful signature”, but it’s more like schnorr, where it might work for 30 to 40 years before being broken. I just made those numbers up, I should be clear. No one really knows how long schnorr will last, but elliptic curve cryptography is currently being phased out, given its age. And so, we don’t really know, but I should be careful what I say there. We don’t actually know when schnorr will be broken. There’s the threat of quantum computers, there’s also the threat of classical attacks and new mathematics. But I think that most cryptographers would imagine that SPHINCS would last significantly longer than schnorr. And so, I would advocate for two signatures so that Bitcoin can last long term.

My perspective here is actually motivated by something I used to say. I used to say, “If elliptic curves gets broken, Bitcoin’s doomed, so we shouldn’t think about that”. And I said that for years. And then, one day I thought about it and I felt bad about myself having said that. And I was like, “I should turn that around. What can we do to ensure that Bitcoin survives if elliptic curves get broken?” And so, informed by that perspective, I think we need at least two signature algorithms.

Mark Erhardt: It’s been a while since I read that thread, but my understanding was that Pieter was just basically expressing, when people have doubts about cryptographic assumptions and therefore push for one or another signature scheme, the problem is that they’re not going to say, “Oh, if you want to trust that, that’s fine, but I really would like this other scheme to be used”. But rather, you get into a situation where the people that have strong feelings about the cryptographic assumptions are going to want everyone to have the same cryptographic assumptions as them. And I think he was mostly opening up the debate about what social dynamics would exist when there are multiple cryptographic assumption sets among the population of Bitcoin users, and how that could be rectified. I guess even if you say, “Well, let’s just combine both signature schemes and require that both are relied upon”, then you’re still saying, “Well, I want everyone to use my cryptographic assumptions, that we need the security of both these cryptographic schemes”.

So, I don’t know if that’s the whole point Pieter was making. It seemed pretty complicated, but I think the main point is if there are different sets of cryptographic assumptions, you’re not choosing and picking when you introduce all the signature schemes, but you force all of the cryptographic assumptions on everyone, because if some people secure their coins with Fancy-sig Algorithm, then everybody is trusting that their coins are secured by Fancy-sig Algorithm. And vice versa, if people don’t want to move over because they don’t trust Fancy-sig yet, everyone has to trust that the old algorithm continues to be secure, because so much of the supply is secured by that, right? So, I think that’s the point he was trying to make.

Mike Schmidt: All right.

Ethan Heilman: Yeah, I mean that makes a lot of sense. And I think that Bitcoin as a whole should have a set of cryptographic assumptions that we all agree on. And where I want to move us to is a set of cryptographic assumptions where we have a backup algorithm where, if everything goes wrong, we can fall back to that. And then, we have an algorithm that is convenient and everyone can use. There is this whole risk that we are in currently because we don’t have that, where basically what Hourglass is trying to solve, which is like, there’s this enormous risk that if you don’t turn off the older algorithm and someone continues to use the old algorithm, if it’s like one person, like I could do some really, really bad signature scheme in Bitcoin today using like SHA1 or something, and no one should trust that. I can do that, but I’m not a risk to Bitcoin because if I do that with a tenth of a bitcoin, who cares, right? But it’s when you have large groups of holders that don’t agree on cryptographic assumptions, you do have this very dangerous situation. And I think we need standards and to work with wallet developers so that as we transition to Fancy-sig, or whatever new signature we want, that we don’t end up with two camps, that we always have one camp. And I think there’s an enormous amount of work here that I don’t want to pretend doesn’t exist. But I see Bitcoin being around after we’re all gone as something that is important and valuable.

Mark Erhardt: Right. And I think this is whole debate is a meta comment on the quantum fears right now, because there is this set of people that have been arguing very loudly that Bitcoin should move to new cryptography faster rather than slower, because of the perceived risk of cryptographically-relevant quantum computers. And this is basically exactly the scenario, where people are now trying maybe to push for lattice-based signature schemes that have had a lot less money secured by them in the past, and maybe it seems like dangerous new cryptographic assumptions to some people. Whereas others feel, “Oh, not having quantum safe signature schemes is the bigger risk”. And we get this social dynamic now where these different camps are pushing for their own interpretation of the work.

Ethan Heilman: One thing we talked a lot about with BIP360 is sort of a worst case. And we designed BIP360 to handle the worst case, where imagine that the quantum threat becomes very real. Like, no one’s stole funds yet, but it’s seeming more and more likely that it’s getting there.

Mark Erhardt: Like, they actually factored 21?

Ethan Heilman: Exactly. We got to 21, maybe they even factored a larger number. You know, we’re not in the current situation where there’s disagreement about it being threat, it’s really a threat. An enormous amount of work gets put in and we move to, like, a lattice signature scheme. And then we’re like, “Oh, thank God we moved here. The quantum computers can now break things, but everything’s good”. And then, just as quantum computers become practical and breaking Bitcoin public keys, someone discovers a classical attack on the lattice scheme. And it’s like, “Oh, that is the absolute worst case, because now we have to move to a new scheme”, and all trust has been lost. Like you said, this scheme was good, and then it turns out not to be, at the worst possible time. And so, a lot of this algorithm agility stuff is motivated by discussions that we had with BIP360, where it’s like, how do we pick the backup algorithm that we’re 100% sure of that that won’t happen to, so that we can do this transition without that worst case happening? And I think that some of the, “Just move to lattice like yesterday, bro”, is like, we have to be careful. It’s not just that there are quantum risks. There are also risks of moving too quickly, and there are risks of moving too slowly, and we’ve got to manage those two risks and not view one risk as not there.

Mark Erhardt: And the third one being it becomes unusable due to block space. I mean, if we just go with a hash-based complicated scheme like SPHINCS or SPHINCS+ or whatever, and suddenly public keys are 3,000 bytes and signatures are 8,000 bytes. And, I guess we could have another expense extension block and then everybody puts spam there. That’s the third dimension, like how much block space are we willing to trade off? It’s a big pile of trade-offs.

Ethan Heilman: Yeah. I mean, I think with SPHINCS, you would be in trouble. You really only want to use this as a last wall. The really cool stuff with SHRINCS, although it hasn’t been looked at as much as SPHINCS, is that because it’s stateful, it has like 380-byte signatures and 32-byte pubkeys. So, you could probably use it, it wouldn’t be that bad. But my ideal is that we get SPHINCS or SHRINCS as the final wall, and then a SQISign becomes performant, and now we have 100-byte quantum-proof signatures that we can do all sorts of fancy stuff with. We’re not there yet. But I do want to give things time. I want to get us to the point that we have the final wall, but then also give the community time to improve the performance and shrink the size of post-quantum signatures. Mike, you had your hand up for forever.

Mike Casey: Yeah, thank you. This is actually going back to Pieter’s point on the externalities of somebody else using a weaker cryptographic scheme and being compromised and losing their keys, and that affects you negatively. I just would like to point out a shameless plug here. It’s not totally trustless, but facilities exist like MARA’s Slipstream, which would allow you to submit your transaction privately. And unless the transaction’s orphaned, as long as MARA doesn’t steal your key, then it’s not at any risk of attack until it’s mined. So, there is a world with the use of private mempools that it can be broken, but still, we can migrate over to something secure by using private mempools in that manner.

Mark Erhardt: Well, that’s a terrible crutch, though. We’re replacing cryptographic security with, “Trust me, bro”.

Mike Casey: Better than nothing! But yes, point taken.

Mike Schmidt: Well, it was a great series of conversations, but I think in the interest of time, we should probably move on with the rest of the newsletter. Ethan, you’re welcome to hang on and chat a little more with us if you’d like. But if you have other things to do, we understand, and you’re free to drop as we move through the rest of the newsletter.

Ethan Heilman: Thanks so much.

Draft BIP for expanded nVersion nonce space for miners

Mike Schmidt: We’re going to move back to the News section, and we’re going to talk about the item titled, “Draft BIP for expanded nVersion nonce space for miners”. This is a Bitcoin-Dev mailing list post from Matt Corallo, proposing to increase the miner usable nonce in nVersion from 16 bits, which I believe BIP320 designated, to 24 bits. We have Antoine back and also Murch to help out with this. And maybe I’ll punt it to Antoine. Antoine, this nVersion field was originally used as an integer for versioning blocks, correct? And then, after v2, those bits were then shifted to be used by BIP9 for signaling, and then some of those bits were carved out with BIP320, and now Matt is proposing to carve out more of those bits. What are the miners doing with these bits that we need to start carving out more and more for them? And is that timeline that I roughly outlined correct?

Antoine Poinsot: I think it’s roughly correct. I think the minimum version is actually 3 or 4. I need to go check that real quick.

Mike Schmidt: Murch is saying 4. Stack Exchange answer right there.

Antoine Poinsot: Boom, nice! Okay, so it’s actually 4. So, it means that, well, there’s a number of values that cannot be used anymore. It was transitioned to signal for voice-concurrent deployments for soft forks. There are 29 bits available in the version field, provided that we respect the existing constraints, for deployments. However, well, first of all, it’s a lot more than we appear to need. We don’t have a lot of soft forks happening in parallel. What we must say also is you can have one soft fork; as long as it starts before the other one is completely done and removed, they can’t use the same bit number. So, even if they don’t happen exactly at the same time, we still need a few of these bits. Nonetheless, it seems to me, and that’s my personal opinion, that as Bitcoin matures, consensus changes are becoming less and less frequent, and so it’s fine to have less bits available for concurrent deployments.

So, coming back to our discussions back when we discussed the BIP54 and locktime, the way ASICs work is that they can only mine the header of a block, and they have a controller on top of the ASIC that is feeding new jobs. And the controller is grinding, for instance, the extraNonce, which is in the scriptSig of the coinbase transaction, re-computing the merkle root and feeding a new header in the ASIC. And the ASIC rolls the nNonce in the header and rolls some of the bits in the version field, and then needs a fresh job. With only 16 bits in the version field, that with the 32 bits of nonce, that’s 48 bits of free work for an ASIC, which is going to be exhausted after 280 TH (terahash), I think, if I remember correctly the figure.

Mark Erhardt: That is correct, I also calculated that.

Antoine Poinsot: And that’s less than what many miners nowadays can do in a second, which means that it’s starting to put pressure on controllers to feed jobs to the ASIC for more than every second. And so, the natural tendency of this is that your controller is starting to become a miner as well, because it needs to grind the extraNonce and needs to recompute the merkle root, which is a lot more hashing than is required to just grind the headers, and then send the fresh jobs. And currently, controllers can be very cheap boards, they don’t need to be computationally expensive. And it would be really annoying to have ASICs do these operations themselves, or have the controller become essentially an ASIC itself. However, miners have another field that is loosely enforced by consensus but with some flexibility, and that’s the timestamp. And so, it turns out that some commercial real miners some of the links in the proposal point to – what’s the name of these small miners that individually run the pleb miner stuff?

Mike Schmidt: The Bitaxe?

Antoine Poinsot: The Bitaxe, yeah. So, it was a discussion on the Bitaxe, but it actually points to some of Intel’s really beefy miners that started rolling the timestamp fields. So, there are ASIC designers out there that are not involved in the Bitcoin community that have started grinding timestamps. And it’s not ideal, because obviously we have consensus restrictions on timestamps, but it would be better if miners didn’t start skewing the time of blocks; especially as we have free, well, let’s say unused space in the version field that would better serve this purpose than the timestamp field. So, this proposal from Matt Corallo is to standardize the use of version bits that miners could be doing anyway. It’s in no way prevented by consensus, but as a norm, we only allowed 16 bits to be used in the version bits, and so miners started using the timestamp instead. And so, Matt was like, “We should tell them to use the version bits instead, rather than skew the timestamps”.

Mark Erhardt: Right, let me try to give a bigger overview again. So, miners need entropy in the blocks in order to go through tons of candidates in order to find one that hashes to a very low number, which makes a valid block. So, Satoshi included the nonce field there, which only had 4 bytes and 4 bytes is I think enough for 4 billion candidates. And you can do that on a laptop these days. So, at some point, we allowed using 16 bits of the version. Well, first we redefined 29 bits to be used for BIP9 version flags for soft fork development. But then, we realized that we would never have 29 soft forks in concurrent or parallel deployment closely together, and we don’t need 29 bits for that. So, we use these 16 bytes since BIP320 to have extra nonce space, extra entropy, where miners could now go up to 280 TH per second without touching the timestamp. And now, it would be instead 24 bits of the nVersion, which leaves us only 5 signaling bits for soft fork activation. But that would bring us up to 72 PH (petahashes) per second per block candidate, where I think that’s pretty far away from what individual ASICs are still doing, because the whole network is only up to, was it 1 YH (yottahash) now? And so, that’s like a 140th of the entire network right now. That’s not something individual ASICs can do. So, now we would be able to maybe have a clock on ASICs that is actually accurate and it goes through block candidates with the timestamp set to the actual time.

I think so far, ASICs don’t actually manage their own timestamps because for the most part, they just work with whatever the job provided, because most blocks are some range of seconds off from the actual time, just lagging behind somewhere between 10 and 30 seconds, just how long the ASICs were noodling on the jobs they had. But now, if we declared the timestamp to be hopefully mostly accurate, ASICs could just switch over the timestamps once per second and continue noodling on the same job until they get a new job, by using the 24 bits from the version. And the 32 bits from the nNonce would give them 56 bits, which is 72 PH per second, and the ASICs would never run out of work.

Mike Schmidt: So, did we do it? Did we cover it?

Mark Erhardt: I mean, so far there’s been one reply on the mailing list, from Antoine. And there is now a BIP draft, which I haven’t read yet. It’s on my to-do list. So, yeah, between the three of us, we have the whole conversation here, if Matt were here! But it makes sense. I’m a little worried, there’s so many soft fork proposals right now. We haven’t had many signaling in parallel, but if all of these people were saying, “Well, why are we not signaling for our current soft fork proposals?” we might actually run out of the 5 signaling bits. But in that case, we could also come up with smarter schemes where we use a combination of bits or reinterpret how the bits are used, or whatever. But anyway, this seems at least worth talking about. I haven’t seen any pushback on it yet.

Mike Schmidt: Antoine, anything else from your perspective?

Antoine Poinsot: No, I wish we could have more feedback from other people, but it seems to be well received. At least my implementation on Bitcoin Core has received some reviews. That’s good.

Mike Schmidt: Excellent. Well, thanks for hanging on and jumping back on, Antoine.

Mark Erhardt: I also notice we should probably put BIP320 at least. It’s in draft. It should probably be deployed.

Mike Schmidt: All right. Go ahead Antoine.

Antoine Poinsot: BIP320 is not enforced by Bitcoin Core though. Bitcoin Core would still warn about these bits. So, BIP320 said that you shouldn’t warn about them, and the implementation was closed because of reasons.

Mark Erhardt: So, do we currently warn all the time about unknown soft forks being deployed? I thought someone turned that off, but okay.

Antoine Poinsot: Yeah, in the GUI, because there was spurious warnings in the GUI, but I’m pretty sure you would still have the warnings on the getblockchaininfo warnings list and in getnetworkinfo list as well.

Mark Erhardt: Interesting, okay.

Mike Schmidt: Well, that wraps up News and Changing consensus. We can move to Releases and Notable code changes. We have Gustavo, thankfully, back with us this week, so Murch and I don’t butcher these too bad. Hey, Gustavo.

Bitcoin Core 28.4rc1

Gustavo Flores Echaiz: Hey, thank you, Mike. Thank you, Murch. That was a great discussion. Now let’s get ahead with the Release and Notable code and documentation changes section. So, on the Releases this week, we have the same as last week, Bitcoin Core v28.4, the first RC for this series. You can check out the RC for additional feedback to the maintainers. And this is a bug fix or a maintenance release, so it contains the wallet migration fixes that were added in v30.2 and were backtracked to v29 and also now v28. It also removes a DNS seed that was reviewed and considered unreliable. An RCv2 is expected over the next few days. There’s already some GitHub activity signaling that a second RC for this version will come soon. Any thoughts here? Perfect. Oh, yes, Murch, please.

Mark Erhardt: Not on 28.4, but I just thought it would be a good point to mention that v31 is in the making. Feature freeze happened a little while ago. The branch off point is coming up very soon and we’re expecting Bitcoin Core v31 in April.

Bitcoin Core #33616

Gustavo Flores Echaiz: That’s awesome. Thank you, Murch, for adding that. So, now we move forward with the Notable code and documentation changes. We have about 12, 13 different PRs this week. So, the first two are from Bitcoin Core. The first one, #33616. Here, there’s a check that is now skipped when a block reorganization happens and confirmed transactions re-enter the mempool. So, this is specifically about ephemeral dust or ephemeral transactions that get spent in the same block they get added, and are usually broadcasted as 1p1c (one-parent-one-child) packages. However, when they’re brought back into the mempool after a block reorganization, every transaction is brought back individually rather than as a package. So, when this check existed before this PR, it would see that the transaction, that the parent wouldn’t be spent in the same block, because it would only see the transaction individually, and it would reject it by relay policy.

So, what this PR does is simply remove that check so that these transactions can come back into the mempool after a block reorganization without getting rejected. Yes, Murch?

Mark Erhardt: Remove the check only in the context of a reorganization. So, this is when you have the chain tip A that is at a height 100 and then chain tip B finds a block. There was a block B also at height 100 and now there is a block 101 on chain tip B. Your node would now remove block 100 on the A chain tip and then add block 100 on the B chain tip and block 101 on the B chain tip. And in that brief step between removing block 100 A and adding block 100 B, all transactions are pushed back into the mempool from block 100 A, because they’re unconfirmed again, right? And in this situation, we would throw away the creation of the ephemeral dust, because the ephemeral dust spend check (CheckEphemeralSpends) would be applied here, even though the transactions are not seen as a package, but individually. So, only during the reorg, this check is not.

Gustavo Flores Echaiz: That’s exactly right. Thank you, Murch, for adding that extra explanation on the process. And this is just about transactions such as 1p1c. But if a miner was receiving transactions out of band and skipping relay policy, this could apply to other types of transactions, right? The PR author gives an example of a chain of ephemeral dust, that spend each other in the same block. So, that’s an extreme scenario that is not common on the relay policies and the relay settings of Bitcoin Core, but technically possible if a miner added a non-standard set of transactions to his block.

Also important to note that there’s another check called pre-check ephemeral transaction. That check is kept when a reorg happens, because what this check does is to check if a transaction has dust and non-zero fees. So, if it had fees and it would pay for itself and it would be a dust transaction, it wouldn’t be a standard transaction. Only dust and non-zero fee transactions are accepted, because those are the parents in the 1p1c package relay. So, just to say that this other check is kept in place, only the check we talked about previously is removed in the reorg scenario.

Bitcoin Core #34616

We move forward with Bitcoin Core #34616. Here, a more accurate cost model is added to the spanning-forest cluster linearization (SFL) algorithm. So, in Newsletter #386, a new algorithm was added designed to handle difficult clusters more efficiently. The problem was that this was implemented with a naive version of calculating the cost. The first problem was that it would only track one type of internal operation, when there’s about 15 different types of internal operations occurring when handling these clusters through this algorithm. So, a lot of CPU time was unaccounted for. So, that’s the first major thing that’s happening here. It’s accounting for the CPU time that’s spent across all operations on this algorithm.

The second aspect of it, it’s that to find exactly the CPU time spent for exactly this algorithm and this process, it would be naive to simply look at how one machine does it. Instead, the PR author ran a benchmark across 13 diverse types of machines and averaged it across those machines, linearized more than 385,000 clusters, thousands of times. So, now that’s how he obtains the acceptable cost threshold, is by weaning out all of these different benchmarks. Yes, Murch?

Mark Erhardt: I wanted to take a step back and look at it from a little further away. So, what we’re talking about here is the algorithm that is used to linearize the clusters for cluster mempool. So, as you probably have heard if you follow this show regularly, cluster mempool is coming with Bitcoin Core v31. And the algorithm that it uses to sort the clusters or to find the best order of these clusters is the newly introduced SFL algorithm. And previously, there was a naive way of estimating how much CPU time it would take to work through a cluster. And so, assuming that there’s many big clusters, we would want to prioritize or estimate how long clusters would take to optimally order, and stop prematurely before the clusters are ordered fully, if some clusters take too long and it takes too much CPU resources. So, there is this cost function here that measures or estimates how much CPU time has been spent on ordering a cluster. And to allocate the CPU time more appropriately, the CPU time estimation was improved by making it more granular and testing it against many different machines.

What you should take away from it at a high level here is there’s a very fancy, cool algorithm that does the optimization of the cluster order efficiently. And now, it will also more accurately estimate how much CPU time was spent on every cluster to prioritize clusters. But you’ll never notice any of this. Hopefully your computer is generally way sufficiently powerful, and all of that happens in the background and your clusters are all just sorted perfectly.

Eclair #3256

Gustavo Flores Echaiz: Thank you Murch for taking a step back and giving a full picture of what’s happening here. So, we move forward with three PRs from Eclair, the first two, #3256 and #3258, are very related, at least in the motivation of why they were done. So, the first one, #3256, a new event is emitted or added, called ChannelFundingCreated. This is emitted when a funding or splice transaction is signed and is now ready to be published, either by you or by your peer. And the motivation behind this event, as much as for the next one, is so that you can basically react to the creation of this channel that you had. For example, if you didn’t fund the channel and it was simply funded by your peer, you could now see the inputs that he used to fund this channel or to add additional funds to when splicing. And this would allow you to react immediately if, for example, you found out that the inputs that are being used for this channel are considered blacklisted inputs; you could immediately react by closing the channel. So, that’s the example that the PR author gives for why this event would be useful, but there could also be other use cases. It’s just an additional event that is added in the transaction flow.

I want to point out that in Newsletter #388, we covered other channel lifecycle events or work that was done. There used to be a channel-opened event that was removed in that PR and that Newsletter #388; and two events, channel-confirmed and channel-ready for payments were added. So, now as a follow-up, in this newsletter we’re covering right now, #395, the new event, ChannelFundingCreated is emitted that could be useful for allowing someone to react as soon as a transaction will be published, to see if the inputs used are adequate to you. Any thoughts here? Perfect.

Eclair #3258

So, the next one, #3258, like I said, is very related. This is different. This applies to dual-funding channels, where you’re committing inputs as well as your peer is committing inputs as well. And there’s a new function that’s added, called ValidateInteractiveTxPlugin, that enables you to plug an external software, with say a plugin, that would inspect the inputs and outputs of your remote peer. So, for example, you could see that your remote peer is inserting inputs that you don’t wish to be associated with, then this trait or this function would allow you an external software, like a plugin, to simply reject or validate this before proceeding to sign it. So, compared to the previous PR which I mentioned, that was specifically about remote peer funding all the inputs and it was ready to be broadcasted and was already signed, here both peers are committing inputs and this is before signing, you have the chance to reject or accept your remote peer’s inputs and outputs. Specifically, if you were to implement this in, let’s say an LSP model, where you’re looking at filtering your users and the inputs of your users, this would be very handy for that use case specifically. And this applies for both dual-funded channel openings as well as splices.

Eclair #3255

So, the last one from Eclair, #3255, this is a bug fix that was introduced in the previous newsletter we covered, where in Newsletter #394, we covered that you would be able as an Eclair node to simply automatically select the channel type you want to open with your peer by preferring the best channel type. So, for example, if both peers support anchor channels, or in the future if both peers support simple taproot channels, then a channel would be opening preferring those types of channels. However, a bug was introduced in that PR where the specific feature, called scid_alias, that should be reserved for private channels, was being automatically used for public channels, which is not compliant with the BOLT specification. So, in this newsletter, the PR #3255 fixes this so that the feature scid_alias is never picked when using public channels, and only is reserved for private channels to be spec-compliant.

What is scid; what does this mean? It allows a node that sits behind a private or unannounced channel to basically conceal its identity, because its funding transaction, the funding transaction for the private channel, was never propagated to the gossip network. So, this node sitting behind a private channel can use the scid_alias feature to create invoices that will route through the node that is publicly announced and that will end up with him. So, this is a feature only possible with unannounced channels which, is why the PR fixes it so it doesn’t ever apply to public channels.

LDK #4402

We move forward with LDK #4402. Here, there’s another bug fix, where in a specific scenario where you are receiving a payment but you’re also a trampoline node, previously the HTLC (Hash Time Locked Contract) claim timer would use the external onion payload value rather than the internal HTLC CTLV (CHECKLOCKTIMEVERIFY) expiry value. And in most cases when you’re receiving a payment, this is fine, the two values should be the same. However, because in this case the receiver is also a trampoline node, the trampoline node has basically added an extra CLTV delta on the outer onion, because in most cases it is simply routing a payment; but in this specific case, it is receiving the payment so there is a difference between those two values. And the fix is introduced so that in this specific case, LDK will target the internal value, the HTLC CLTV expiry, rather than the onion payload external value that should be looked up when the trampoline node is actually routing the payment to someone else.

LND #10604

The last one from the Lightning implementations is LND #10604. So, this has been a work that has been done over many multiple weeks now and is brought together with this PR. But many other PRs were part of the same project. So, here, an SQL backend, that could be either SQLite or Postgres, is implemented for LND’s outgoing payments database. This is reworked from LND’s existing bbolt key-value (KV) store or database. So, this has been a long objective of LND, moving away from its previous database scheme that was that was part of the Go ecosystem from which LND is built. And now, LND is transitioning to backends that are more standard, that are SQL-based. So, you can find multiple PRs within the release notes of this one that talk about the specific things that were done to bring it all together.

So, I want to also add that this is a known criticism or feedback to the LND implementation for years already. So, for example, in Newsletter #169, support for Postgres was added; and Newsletter #237, support for SQLite was added. So, this PR brings it together for specifically LND’s outgoing payments database.

BIPs #1699

Perfect, so now we’re entering the BIPs section, so I’m sure, Murch, you’re going to have a lot of things to add here. So, we can start with the first one, where the tapscript opcode, OP_PAIRCOMMIT, basically one that resembles OP_CAT but avoids enabling recursive covenants, here two elements of the stack can be combined basically, and their SHA256 hash can be added to the stack, which allows for similar multi-commitment functionality to OP_CAT, like I said. And also, this is part of the LNHANCE soft fork proposal alongside CTV, CSFS, and INTERNALKEY. This was initially proposed in Newsletter #330, but please, Murch, if you have some extra thoughts to add here, I think listeners would appreciate it.

Mark Erhardt: Yeah, so moonsettler had proposed this almost one and a half years ago, and I’m glad that this is for a relatively simple proposal that this is wrapped. So, that was published just recently. If you’re interested in LNHANCE or OP_TEMPLATEHASH or OP_CAT, I think this one is an easy and interesting read that you might want to take a look at. I think that it is pretty mature as a proposal, but it hasn’t gotten a ton of commentary. If you’re into the whole covenant stuff, maybe give it a read and leave some feedback.

BIPs #2106

Gustavo Flores Echaiz: Thank you, Murch. Next one is BIPs PR #2106, where the proposal for silent payments, BIP352, is updated to introduce a per-group recipient limit of 2,323 for mitigating worst-case adversarial transactions. So, in Newsletter #392 and the podcast that came with it, we covered a proposal to limit the number of per-group silent payment recipients, and we brought in the author of the Bitcoin-Dev mailing list post, Sebastien Falbesoner, to explain his discovery and his proposed mitigation for a theoretical attack on silent payment recipients. So now, initially, the amount that was proposed or the value that was proposed was 1,000, and now actually what is merged in the BIP proposal increases it to 2,323. The goal is to match the maximum number of P2TR outputs that can fit in a standard size 100 kvB (kilo-vBytes) transaction. And the reason why the 1,000 was not chosen is because it would allow to fingerprint silent payment transactions, because it was extremely precise. However, pushing it to the upwards limit makes it less easy to fingerprint. Murch, any comments?

Mark Erhardt: I just wanted to point out, this is specifically only limiting the count of outputs that can be sent to the same recipient. So, when you scan for silent payments, your node will check whether there’s a first payment to your key. And if a recipient is paid to multiple times, because the output script is composed of the recipient keypair and the input keys, it would have the same output script for several payments, right? So, when there are multiple payments that go to the same recipient, there’s a counter that gets incremented in order to create multiple different output scripts. So, the vulnerability here is that if you pay a recipient multiple times, they might need to scan all of the outputs again. So, if you have 2,323 outputs, they might find in the last one they scanned that they got paid. And now, they check again all other 2,322 outputs, whether they’ll get paid again. And maybe the last one they scan, they get paid. So, it introduces a quadratic cost to the scanning. And if you made a whole block of silent payment payments to a single recipient, you could have them scanning multiple minutes.

On the other hand, this attack is pretty theoretical because it requires you to pay the same person every time. Now, you could have a lot of zero-sats payments and then one juicy last payment, and they would continue scanning through all of them, and then the last one you send to yourself. So, you could waste someone’s time, but you’re still paying for all that block space. So, overall, this is probably not something we will see in the wild. But yeah, there was a long discussion in the past few weeks about what the appropriate limit is. And now, it’s basically just limited to the maximum number of P2TR outputs that you could have in a standard transaction, so there’s no additional fingerprint by introducing this limit.

BIPs #2068

Gustavo Flores Echaiz: Thank you, Murch, very insightful to give all that context. So, now, the final BIPs PR is #2068, which publishes BIP128, also called Timelock-Recovery Storage Format. So, here, a standard format is proposed for specifically timelock-recovery plans. So, the way it works is that it consists of two presigned transactions that would enable to recover funds if an owner loses access to their wallet or, for example, inheritance use cases. So, the first transaction that is pre-signed is an alert transaction that would consolidate all the wallet UTXOs into a single address part of that wallet. And then, the second transaction would be the recovery transaction, but it would be timelocked with a specific relative time lock. It could be configured between 2 to 388 days. And the reason why there’s the specific second recovery transaction that is timelocked is because the other transaction could be broadcasted prematurely and out of protocol. So, the timelock gives the initial owner the chance to spend the output that was created with the first alert transaction, back into his wallet to invalidate the recovery. So, there’s a failsafe for the owner to block the recovery flow by simply moving the funds somewhere else as he wishes. Yes, Murch?

Mark Erhardt: Or actually, just any single input to the second transaction. So, the second transaction is supposed to sweep the entire wallet’s funds to the second wallet, to the backup wallet. And of course, if you spend any single input of that, you invalidate the second scheduled transaction. I think the scenario the authors have in mind is you might have a less secure, maybe mobile wallet, and this is basically infrastructure that would eventually sweep all the funds in your mobile wallet to your backup wallet or more secure wallet in case you lose your mobile phone. Of course, If you have a backup anyway, then hopefully you wouldn’t be in the position to need to rely on this. Anyway, this is also a proposal that has gotten so far not a whole ton of commentary. I think there is a project or a company that is trying to implement this as a service. So, there’s interest in implementing this already. But if you find it interesting, you could find the mailing list post and reply there for leaving some feedback.

Gustavo Flores Echaiz: Yes, thank you, Murch. And yeah, I want to add that there’s a reference implementation that is added as a plugin on specifically Electrum Wallet that is cited in the specification of BIP128.

BOLTs #1301

So, the final PR covered this week is BOLTs #1301. Here, the specification is updated to recommend a higher dust limit threshold value for HTLCs in anchor channels. So, the HTLCs of modern anchor channels have zero fees, and they have to be higher than the dust limit. But the initial specification didn’t account that a second transaction would be needed to spend them, because they pay zero fees. So, the dust limit should actually apply to the combined weight of both transactions. And here, only the second transaction that would spend those HTLCs wasn’t accounted for when determining the dust threshold of these HTLCs. So, there’s not a specific value that is set in the specification, it’s simply noted that there should be a consideration for these subsequent transactions that spend these zero-fee HTLCs, when setting the dust limit value threshold for these HTLCs.

Mark Erhardt: And it’s probably good that there is not a specific limit set, because at least recently, the minimum feerate that we see confirmed in blocks has gone down almost a factor 10. And therefore, while you have to account for the second transaction, the overall fees that are acceptable are much lower. I should point out, however, that at least in Bitcoin Core, the dust amounts have not been adapted. The dust amounts are still based on 3 sats/vB (satoshis per vByte) in Bitcoin Core, so the dust limits of what Bitcoin Core considers a dust output are still the same.

Gustavo Flores Echaiz: Thank you, Murch. Yeah, this specification update also mentions the Bitcoin Core standard values, so it’s specified that they have to be higher than the standard values of Bitcoin Core. And this completes this section and the whole newsletter. Thank you, Murch. Mike?

Mike Schmidt: Awesome. Thanks, Gustavo. Well, that was everything from #395. We want to thank our guests for today, Jon, Antoine, Mike, and Ethan for joining us this week. Thank you to my co-hosts, Gustavo and Murch, and for you all for listening. We’ll hear you next week. Cheers.

Gustavo Flores Echaiz: Cheers.

Mark Erhardt: Cheers.