Bitcoin Optech

Bitcoin Optech Newsletter #404

2026-05-08T00:00:00+00:00

This week’s newsletter describes possible solutions to node fingerprinting and links to discussion of using public fraud proofs to improve incentives around just-in-time channels. Also included are our regular sections describing notable changes to popular Bitcoin infrastructure software.

News

● Possible solutions to node fingerprinting: Naiyoma posted to Delving Bitcoin about possible solutions to the node fingerprinting issue that uses the addr message timestamp to identify the same node on multiple networks (see Newsletter #360).

Since the last update, researchers were able to gather more insights on the problem and identify new factors to consider. One of the key insights was related to the AddrMan, the code structure managing the addresses. AddrMan considers addresses as stale in case their timestamp is older than 30 days, usually due to a peer being offline. Thus, there are two important factors that a possible mitigation needs to take into account: refreshing old timestamps to newer ones may cause old addresses to be continuously gossiped and making them older may cause them to stop being gossiped prematurely. These considerations led to discarding some previously considered solutions and provide new ones:
1. Simple fuzzing: Apply random distortion to the address timestamp in a range of [-5, +5] days. However, the distortion may average out over time.
2. Fixed timestamps across networks: When responding to a request, the real timestamp is preserved for the specific network, while on the others the timestamps are set to a randomized value in the past. However, old addresses might remain in circulation longer than necessary.
3. Fuzzing - Addresses only older: Make addresses only older, never newer, by applying a random distortion in the range [1, 10] days. However, addresses may reach the 30-days threshold too quickly.
4. Fuzzing - Aging-biased timestamp noise: Apply a random distortion in the range [-1, +5] days, so as to make addresses mainly older, with only a small chance of becoming newer. However, old addresses might remain in circulation longer than necessary.
5. Hybrid approach: The final option is to combine two of the previous approaches together.
Naiyoma asked for feedback on her work to other developers interested, and shared her PR in which she is testing solution 2.
● Public fraud proof for just-in-time channels: Thomas Voegtlin posted to Delving Bitcoin about a new proposal for improving the game theory behind just-in-time (JIT) channels by using public fraud proofs to demonstrate that an LSP is misbehaving.

Alice negotiates a JIT channel opening with an LSP, Bob. When Alice needs to receive sats from Carol, she creates a preimage. Carol sends an HTLC to Bob. Alice discloses the preimage to Bob, expecting the LSP to broadcast the channel funding transaction. What happens if Bob claims the HTLC without opening the channel with Alice?

Voegtlin proposes to use the chain as a public arbitration layer. Alice should publish the preimage using an OP_RETURN, so that disclosure can be verified by anyone and dated to a certain block height. On his side, Bob creates a UTXO commitment valid up to a number of blocks n. If he spends the same UTXOs in a transaction different from the one he committed to, does not broadcast the funding transaction, or tries to double-spend it, he would create a fraud proof, damaging his reputation as an LSP without requiring other clients to trust Alice.

Voegtlin provided the full paper containing the in-depth explanation, and invited other developers to provide feedback on the proposal.

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 #33796 adds btck_check_transaction() to the libbitcoinkernel C API (see Newsletter #380) for running context-free, consensus-level checks on a transaction’s structure. This includes rejecting empty input or output lists, invalid coinbase scriptSig lengths, duplicate inputs, null prevouts in non-coinbase transactions, and output values outside the valid money range, without requiring chainstate, the UTXO set, or script verification.
● Bitcoin Core #21283 implements BIP370 PSBTv2 support, while maintaining backwards compatibility with PSBTv0. PSBTv2 stores transaction construction data, such as version, locktime, inputs, outputs, and transaction modifiability, directly in PSBT fields, instead of requiring a complete unsigned transaction.
● BIPs #2150 adds BIP451, a specification for a Dust UTXO Disposal Protocol, which defines a standard for wallets to safely dispose of unwanted dust UTXOs by spending them to a single zero-value OP_RETURN output, with the entire input value paid as transaction fees. The protocol includes privacy-preserving construction rules, such as per-address disposal of confirmed dust UTXOs, and ALL|ANYONECANPAY signatures that allow unrelated dust-disposal transactions found in the mempool to be batched through RBF.
● Eclair #3144 updates simple taproot channels to use the official feature bit and enables them by default, without support yet for announcing those channels. Test vectors are added to align with the BOLTs specification and LND’s implementation (see Newsletter #401).
● Eclair #2887 adds support for the official splicing protocol merged into the BOLTs specification (see Newsletter #398), while maintaining backwards compatibility with Eclair’s earlier experimental splicing implementation.
● LDK #4592 starts checking if a node has sufficient reserves before opening new zero-fee commitment (0FC) channels by counting them as anchor channels. Previously, LDK’s reserve check only counted channels that used the older anchors_zero_fee_htlc_tx feature, allowing a node to open more 0FC channels than its wallet could safely fee bump during simultaneous force closes.
● LND #9153 adds a source_pub_key field to the Route proto message to construct and deserialize routes from the perspective of a node other than the local node. If no source is provided, LND continues to use the local node as before.
● Rust Bitcoin #5835 adds a constructor for V1MessageHeader that computes the four-byte payload checksum used in Bitcoin’s P2P message header. This simplifies constructing network messages by allowing callers to build the header for a serialized payload and command before sending the message over the network.
● BOLTs #995 adds an extension BOLT for simple taproot channels, assigning feature bits 80/81. The specification defines a minimal taproot-based channel type that uses a P2TR funding output with MuSig2 key aggregation, taproot commitment and HTLC scripts, and new TLV fields for exchanging MuSig2 partial signatures and nonces during channel opening, commitment updates, cooperative closes, and reconnection. The nonce fields in revoke_and_ack and channel_reestablish are keyed by funding txid to support multiple active commitment transactions, such as during splicing. The extension intentionally excludes gossip changes, so announced taproot channels remain future work.
● BOLTs #1228 specifies zero-fee commitment (0FC) channels and assigns feature bits 40/41. For this channel type, feerate_per_kw is set to 0, commitment and HTLC transactions use v3 transaction relay (TRUC), and mining fees are provided by child transactions using CPFP. Commitment transactions include a shared pay-to-anchor (P2A) output funded from trimmed outputs and rounded-down millisatoshis, capped at 240 sats, allowing the parent commitment transaction to pay no direct fee in most cases. The specification also limits the maximum number of HTLCs to 114 for this channel type due to TRUC’s 10 kvB transaction size limit.
● BOLTs #1327 updates the RBF feerate bump rule to ensure compliance with BIP125 replacement rules at low feerates. Instead of applying only the existing 25/24 feerate multiplier, the specification now requires the replacement feerate to increase by the larger of two values: the multiplier or an additional 25 sat/kw. This matches the behavior of LDK covered in Newsletter #400.

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

Bitcoin Optech Newsletter #403 Recap Podcast

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

Gustavo Flores Echaiz and Brandon Black are joined by Olaoluwa Osuntokun to discuss Newsletter #403.

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

Download audio

News

● Binary fuse filters as an alternative to BIP158's GCS (19:05)

Changing consensus

● Post-quantum HD wallets with fallback SPHINCS keys (31:07)
● Discussion of a post-quantum output type (34:42)
● Proposal to embed post-quantum keys in tapscript without consensus changes (38:03)
● BIP54 demonstration of slow blocks on signet (43:28)
● Post-quantum BIP86 recovery using zk-STARK proofs of BIP32 seeds (1:05)

Releases and release candidates

● Core Lightning 26.04.1 (48:16)
● BTCPay Server 2.3.8 (50:15)
● BTCPay Server 2.3.9 (51:52)

Notable code and documentation changes

● Bitcoin Core #33671 (52:39)
● Bitcoin Core #34885 (58:01)
● Bitcoin Core #33920 (59:57)
● Bitcoin Core #34911 (1:02:00)
● BIPs #1548 (1:04:47)
● HWI #831 (1:08:17)
● BDK #2188 (1:09:11)
● BDK #2115 (1:10:14)

Transcription

transcription coming soon

Bitcoin Optech Newsletter #403

2026-05-01T00:00:00+00:00

This week’s newsletter describes research around using binary fuse filters as an alternative to the GCS used in compact block filters. 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

● Binary fuse filters as an alternative to BIP158’s GCS: Csaba Purszki posted to Delving Bitcoin his research on finding a better alternative to Golomb-Rice Coded Sets (GCS) used for compact block filters as defined in BIP158.

According to Purszki, a suitable alternative can be found in binary fuse filters, a family of probabilistic data structures for approximate set membership, and specifically the 16-bit variant, called Fuse16. The main characteristic of this type of algorithm is the ability to give O(1) query time (for reference, GCS gives O(N)), which reduces the CPU power required to query the filters. Moreover, these filters guarantee zero false negatives, with a rate of false positives equal to 1/2^k, with k being the number of bits.

Purszki provided the preliminary results of his research, which compare the current GCS performance against binary fuse filters. Tests were performed on 10 different wallet use cases (from 24 scripts up to 480), running filters on 50,000 mainnet blocks, on two different CPUs, a desktop x86_64, and an ARM. Binary fuse filters were able to obtain a 6x-45x speedup on ARM, according to the different wallet use cases, and 9x-80x on desktop at the cost of a slight increase in bandwidth, 0%-3%. For a full write up on the methodology and full results, the reader can refer to Purszki’s website.

Kyoto developer Robert Netzke commented on the differences in false positive rates with respect to GCS and possible failures that could occur in the algorithm.

Changing consensus

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

● Post-quantum HD wallets with fallback SPHINCS keys: In a post on the Bitcoin-Dev mailing list, Conduition described a design for post-quantum BIP32 congruent hierarchical deterministic wallets with fallback SPHINCS keys. The design replaces the child key derivation functions of BIP32 to generate SPHINCS keys alongside secp256k1 keys. Due to the lack of an algebraic relationship within SPHINCS keys, non-hardened child keys share the same SPHINCS keys as their parents and siblings. This requires wallets to insert a nonce (or the secp256k1 key) into scripts spent using the SPHINCS key to retain privacy equivalent to BIP32 wallets. A benefit of this design choice is that the expensive full SPHINCS key derivation can be deferred to the first non-hardened derivation step and then cached for all non-hardened keys below that step. This wallet design is intended to be combined with BIP360 P2MR outputs and a future OP_CHECKSPHINCS (or similar) to enable migration to quantum-resistant wallets. Conduition suggests that such a wallet structure might also be combined with future lower-cost post-quantum signature algorithms with SPHINCS providing a dependable fallback in case they are proven insecure.
● Discussion of a post-quantum output type: Antoine Poinsot wrote to the Bitcoin-Dev mailing list defending a plain post-quantum output type (as opposed to a P2TR-like output type which allows quantum-vulnerable key spending to be disabled by a later soft fork). The crux of the argument is that the decision of whether or when it makes sense to disable quantum-vulnerable spends should be separated from enabling users to migrate to post-quantum cryptography at their discretion. In the subsequent conversation, the participants agreed on both adding post-quantum signing to tapscript and adding a plain post-quantum output type. Several open questions remain, including whether and to what degree to incentivize migration and when / whether to disable quantum-vulnerable signatures.
● Proposal to embed post-quantum keys in tapscript without consensus changes: Daniel Buchner sent a proposal to the Bitcoin-Dev mailing list which describes a potential path to enabling flexible post-quantum wallet designs without fully describing the signature validation parameters. Because BIP342 signature checking opcodes treat all non-32-byte keys as unknown key types which are valid with any non-empty signature, other key lengths (in this case with an initial tag byte) can be used in scripts today as long as either the scripts are kept secret or they also require a secure BIP340 signature in addition to the unknown key or keys. If Buchner’s proposal were to be standardized, wallets could start building scripts with various post-quantum key types now while continuing to spend using quantum-vulnerable keys until such time as a soft fork enables secure spending with the post-quantum keys. Like many quantum migration proposals, this proposal only retains security in the face of a quantum adversary if key reuse is strictly prevented. Buchner is seeking feedback on the proposal.
● BIP54 demonstration of slow blocks on signet: On Delving Bitcoin, Antoine Poinsot wrote about a demonstration of the types of slow-to-validate blocks that BIP54 (consensus cleanup) prevents. Repeated three times over the course of a day, batches of slow-to-validate blocks were signed on the most popular Bitcoin signet and then reorged away to enable testing of propagation and validation behavior of these blocks without forever slowing signet initial block download. Many around the world watched the slow blocks hit their nodes and logged the validation and propagation behavior. As expected, the slow-to-validate blocks propagated much more slowly through the network and required significantly more time to be fully validated on individual nodes compared to typical blocks. It should be noted that these demonstration blocks were far from the worst case that is prevented by BIP54.
● Post-quantum BIP86 recovery using zk-STARK proofs of BIP32 seeds: Olaoluwa Osuntokun (roasbeef) posted on the Bitcoin-Dev mailing list his project to demonstrate zk-STARK recovery of quantum-vulnerable coins secured by keys derived using BIP32. This possible mechanism for coin recovery in the event that secp256k1 is disabled in the face of a cryptographically relevant quantum computer has long been discussed, but never fully demonstrated. Osuntokun produced a fully working implementation of the required prover and verifier and provided benchmarks showing that recovery using this method is, at least, possible. The original implementation was intentionally not optimized and several developers offered optimizations that make the recovery less costly both to prove and to verify.

Releases and release candidates

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

● Core Lightning 26.04.1 is a maintenance release that includes gossip protocol fixes, as well as build system fixes for environments that experienced problems immediately after the major release.
● BTCPay Server 2.3.8 is a minor release of this self-hosted payment solution that includes subscription and point-of-sale updates, LUD21 LNURL-pay support, an additional API surface for managing subscription offerings, and other fixes and improvements.
● BTCPay Server 2.3.9 is a maintenance release that addresses server recovery after a plugin crash and fixes an xpub parsing issue that was introduced in v2.3.8.

Notable code and documentation changes

● Bitcoin Core #33671 adds a nonmempool field to the getbalances RPC (see Newsletter #46) for wallet UTXOs spent by transactions that are neither confirmed nor in the node’s mempool, such as unbroadcasted, non-standard, evicted, or transactions that are part of too-long mempool chains. Previously, balance buckets could omit value tied to those in-flight spends even though the wallet still recorded the transactions, so getbalances did not fully reflect how the wallet was accounting for those coins. The PR counts that value in the usual mine buckets where it belongs and applies an offset via nonmempool so the fields sum to the wallet’s overall balance while making the mempool mismatch explicit.
● Bitcoin Core #34885 adds btck_block_tree_entry_get_ancestor() to the libbitcoinkernel C API (see Newsletter #380) for retrieving the ancestor of a block at a specified height on its chain branch. Instead of walking backward one block at a time with repeated calls to btck_block_tree_entry_get_previous(), callers constructing block locators from a stale or forked tip can directly request ancestors at the needed heights.
● Bitcoin Core #33920 adds an exportasmap RPC that exports the node’s ASMap data embedded at build time (see Newsletter #394) to a file. This allows users to inspect, validate, and analyze the data using tools such as contrib/asmap-tool.py.
● Bitcoin Core #34911 removes deprecated RBF-related boolean fields from several mempool RPC responses unless they are explicitly requested using the deprecatedrpc configuration option. The getmempoolinfo RPC no longer returns the fullrbf field by default, as full-RBF behavior has been the default since Bitcoin Core 28.0 and the mempoolfullrbf option was removed in Bitcoin Core 29.0. The getrawmempool, getmempoolentry, getmempoolancestors, and getmempooldescendants RPCs no longer return the deprecated bip125-replaceable field described in BIP125 by default.
● BIPs #1548 adds BIP391, a specification for Binary Output Descriptors (BOD), an efficient container format for output script descriptors based on PSBT-style key-value maps. This BIP has a closed status and lists BIP393 as a proposed replacement, noting that BIP391 was withdrawn after BIP393 proposed an alternative method for handling wallet metadata such as descriptor annotations (see Newsletter #400).
● HWI #831 adds support for the Ledger Nano Gen5 hardware signing device.
● BDK #2188 starts verifying that a transaction returned by an Electrum server matches the requested txid before caching or using it. Previously, a server could respond to a fetch_tx() request with any transaction data and a different txid, and BDK would accept it.
● BDK #2115 adds previous-block-hash awareness to CheckPoint by extending the ToBlockHash trait with an optional prev_blockhash() method. This allows BDK to verify that adjacent checkpoints connect when their payloads contain previous-block-hash information, such as in block headers. This also prevents merge_chains() from treating a conflicting height-0 checkpoint as a normal reorg and replacing it. Now, if two checkpoint chains disagree on genesis, the merge fails. See Newsletters #372 and #390 for previous work on CheckPoint.

Bitcoin Optech Newsletter #402 Recap Podcast

2026-04-28T00:00:00+00:00

Mark “Murch” Erhardt and Gustavo Flores Echaiz are joined by Toby Sharp to discuss Newsletter #402.

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

Download audio

News

● Hornet Node's declarative executable specification of Bitcoin consensus rules (1:02)
● Onion message jamming in the Lightning Network (23:22)

Selected Q&A from Bitcoin Stack Exchange

● Why did BIP342 replace CHECKMULTISIG with a new opcode, instead of just removing FindAndDelete from it? (40:53)
● Does SIGHASH_ANYPREVOUT commit to the tapleaf hash or the full taproot merkle path? (43:28)
● What does the BIP86 tweak guarantee in a MuSig2 Lightning channel, beyond address format? (45:23)

Releases and release candidates

● Bitcoin Core 31.0 (47:10)
● Core Lightning 26.04 (54:26)
● LND 0.21.0-beta.rc1 (56:29)

Notable code and documentation changes

● Bitcoin Core #33477 (57:55)
● Bitcoin Core #35006 (1:02:26)
● BIPs #1895 (1:04:31)
● BIPs #2142 (1:12:47)
● LDK #4555 (1:15:03)
● LND #10713 (1:16:23)
● LND #10754 (1:18:02)

Transcription

Mark Erhardt: Good morning. This is the Bitcoin Optech Newsletter Recap for Newsletter #402. As you can hear, I’m not Mike Schmidt. This is Murch. Today, we’re talking about a newsletter that describes an update to the Hornet Node project; we’re talking about onion messages on the LN and how they might be jammed and what could be done about it; we are talking about the Bitcoin Stack Exchange regular section; we have three Release candidates and releases to dive into; and then a bunch of Notable changes to the software. We’re going to start out today with Toby Sharp, if you want to introduce yourself.

Toby Sharp: Hi, I’m Toby and I’m a professional software developer who’s also working on a personal project called Hornet Node.

Hornet Node’s declarative executable specification of Bitcoin consensus rules

Mark Erhardt: Thanks for joining us. So, Toby, you wrote to the mailing list and on Delving about your Hornet Node project. And one of the things next to your Hornet Node implementation, that has very impressive speed in IBD (Initial Block Download) that we’ve reported on previously, and we had you on before, you are producing a specification of the Bitcoin protocol. And your update now described that you had created a set of 34 rules that completely describe block validation, from what I understand. So, you caveated that with, it is only the non-script block validation. I assume that has something to do with transactions, but maybe you could explain that better to us.

Toby Sharp: Yeah, sure. So, the background on Hornet Node is that it’s a project whose goal is to produce a formal specification for Bitcoin consensus rules, something that Bitcoin has not had previously. And so, although Hornet Node is capable of doing some of the client tasks already, it’s not really intended to be a competitor for Bitcoin Core, for example. The main goal is this specification. And so, that’s quite a big project, which in the end would enable formal verification of clients meeting that specification. But right now, I’ve just got a milestone along the way, which is these 34 semantic rules. Now block validation, blocks are broadcast to the network and then a client node has to decide whether a block it receives is valid or not. If it’s valid, it gets added to the blockchain; and if it’s not, it gets rejected. So, it really comes down to a binary decision on that block as to whether it’s valid or invalid. And there are many, many different logical steps that are made to decide that validity. So, what I’ve done in Hornet Node is very carefully reverse-engineered that logic into a set of 34 semantic rules. Each rule is separate semantically and declaratively. And I’ve built that into a draft specification that I’m sharing with the community.

You mentioned about script rules. So, there are sort of different levels of rule or different levels of logic that have to be applied. Some rules are applied to the headers, some rules are applied to the transactions, some rules are functions of the script language, etc. And so, these 34 rules have slightly different contexts. And one of the rules at the moment is just that basically the script has to be valid. Now, that’s like a meta category in itself, so it requires in the future another specification or another set of rules which more accurately or more fully describe what it means for a script to be correctly unlocking. So, the other 33 rules are not script-related. So, what I meant by this non-script rule is basically that these are the high-level rules that have to be true, and then there will need to be like a double-click, a drill-down for the script logic specifically.

Mark Erhardt: Right. So, basically you just black boxed the whole script validation, how transactions actually work under the hood and just say the transactions are valid as a whole rule for itself. And then, that might be another 100 rules or so later, hopefully not more. So, okay. We’re looking at block validation rules, so that would include something like the difficulty statement is accurate, the block commits to the prior block hash, the block is not larger than the allowed block weight limit, that sort of thing, I assume?

Toby Sharp: Exactly. And so, I’ve sort of carefully separated these into one semantic invariant per rule. And each of those semantic invariants also has an English specification statement. For example, a pre-segwit block must not contain any witness data, or each transaction must contain at least one input. And so, now I have both a declarative specification of those rules in English and also have an implementation, one pure function per rule that enforces that rule.

Mark Erhardt: So, you said that it could be used later to formally verify whether Bitcoin implementations meet all the rules. So, would it make it easier to develop nodes that are fully compatible rule by rule, bug by bug? One of the reasons why people have been saying for the last decade that making a specification for the Bitcoin protocol would be very difficult is that there might still be unintended behaviors in how Bitcoin Core parses transactions or blocks, and finding those might be difficult and might be a place where we would get a consensus failure as we had, for example, with some other node implementations a couple of years ago in a small aspect of how native segwit transactions with, I think it was somewhere around the witness count or something.

Toby Sharp: Well, yes, and there was one with the Berkeley DB stuff.

Mark Erhardt: Oh yeah, 2013, March 2013 bug. We have a whole BIP about that, BIP50.

Toby Sharp: Right, and I also wrote about it in the Hornet Node paper. Basically, the whole thesis of the project is to say, yeah, this is an issue, but I think the conclusion in the past has been wrong. I don’t think it’s the correct conclusion to say, therefore we must never change the code and keep one codebase forever. I don’t think that scales. I think the more correct conclusion would be, therefore we have to carefully and systematically document all the logical changes. Because it’s not magic, it’s not unknowable, it’s not intractable, it’s just a little bit complex and difficult, and that’s not the same thing at all. So, it’s perfectly possible to decide what all the logic is that’s being executed. And so, my approach is that the correct thing is to do that, even though it’s difficult, and specify it clearly and explicitly, rather than leave any such behaviors lurking as implicit, unknown, undocumented aspects of consensus. Because if you don’t do that, then you stay permanently in the structure where consensus-critical code has to never be changed, refactored, improved, touched; you don’t get client diversity; and you don’t know if you’ve introduced a bug in a future version. I just don’t think that’s scalable for something which really is trying to be a protocol.

Mark Erhardt: Right. So, basically it allows another level of testing and cross-checking of consensus code implementations, which might have some interesting synergies with projects like the Bitcoin kernel, or also inform other node implementations, like your Hornet Node, Libbitcoin, btcd, knots, other node implementations. I saw on the mailing list that you had a bit of a conversation with Eric Voskuil. Could you summarize what you took away from that?

Toby Sharp: Yeah, so Eric is the lead developer of Libbitcoin, which is another consensus library and a node implementation which has been around for many years, and takes different approach in validation to Bitcoin Core, both with the UTXOs and also with the structure of validation, parallelism, and so on. And Eric pointed out that some of the work that Hornet Node has done independently is very closely related to what Libbitcoin’s done in the past, which is sort of separation of the consensus logic into individual rules rather than just kind of weaved throughout the codebase. And so, that was very interesting to learn about. And also, we’ve taken the conversation offline now, so Eric continued to email me kindly and set out some more of his thoughts about particularly the different dependencies of different rules. Like, some rules depend only on the transactions in that block, some rules depend on previous headers, some rules depend on previous transactions in the chain. So, we have an ongoing conversation about how these different dependency connections have implications for concurrency and how best to organize this draft semantic spec in order to really make sure that that concurrency is easily preserved.

Mark Erhardt: Cool. I’m glad to hear that you’ve found collaborators, at least to some degree, who knows. What is the long-term plan for your specification? Are you looking to publish it as a paper, as a BIP?, I think that that might be a good protocol BIP eventually, for example, or not protocol, specification BIP, sorry.

Toby Sharp: Right. Yeah, so on the collaboration, it’s been very encouraging. I haven’t had a huge number of responses, but I’ve had responses from several key people, which is encouraging, Eric being one of them, of course. And I also had a conversation this week with Sebastian, who’s leading the kernel project for Bitcoin Core. And I was encouraged to hear that the Hornet work is already proving to be somewhat of an inspiration for their work on that project, which I find very encouraging. So, good interest so far. It would be nice to hear more from other developers who either are interested in Bitcoin consensus or who have experience with Bitcoin consensus, firstly on whether they think these semantic rules are accurate, representative, helpful. One could easily dismiss this as, for example, “Well, it’s just a set of rules. It’s likely just a set of ideas or rules. It doesn’t really change the code, therefore it’s not really doing anything”. But I think actually it is an important step towards something bigger. And it’s good to actually know that there’s a set of rules for consensus and what they are. I don’t think it’s been clearly written and articulated in a straightforward way before, so I think there’s some value here.

So, you asked about what would the next step be. So, I wrote a paper after some of the work that I’d done on Hornet Node back in September. I’m not sure whether this latest milestone warrants another paper. It might warrant an update essay, but also people don’t really read papers like that. So, maybe you mentioned a BIP. Can you talk to me a little bit about how that might work? Or what do you think an interesting step would be for this?

Mark Erhardt: Well, I’m thinking that one of the gripes people have had with the Bitcoin protocol is that it had been de facto specified by just Bitcoin Core being so broadly adopted. And therefore, whatever Bitcoin Core did was the Bitcoin protocol. But for other implementations that are trying to interact with Bitcoin Core, and even for different versions between Bitcoin Core, it would be very interesting to clearly specify what the intended behavior is, as you said, to be able to argue or reason about it, to even apply changes where we can and want to, and just to have a clearly defined set or framework against which we’re arguing. So, if this project continues to work out the way it seems to be working, and we’d eventually get a full set of rules that includes transaction behavior, and so forth, I could imagine that it becomes the official specification of the Bitcoin protocol. Because basically, if it fully describes the behavior, we would be able to also adapt Bitcoin Core to a specification. So, in that case, it should.

I mean, there’s a lot of work there if you want to go that way. And obviously, I can’t speak for anyone else but myself, but that sort of seems to be the underlying potential direction there. And in that case, it would make sense if it were published somewhere where the Bitcoin community sees it and can co-own it with you. And the BIPs repository usually has been something that helps towards that. But before you get there, it might be easier to keep it in your own repository, so you’re not dependent on BIP editors, or someone else, to process your updates to it.

Toby Sharp: So, I’ve made the code open-source now and public, so that’s in my repo on GitHub, and people are welcome to go have a look. It’s a work in progress, it’s not a finished work, but people are welcome to go and have a look, especially at the consensus validation or the UTXO engine, if people are interested in that. And then, I think I’ve got at least two more major pieces of work to do before probably I would be considering writing a BIP. The first of those is the script validation rules. As I mentioned earlier, this is like a drill-down of one of the rules that just says, “The unlocking script has to unlock the transaction”, whatever that means, okay. So, that’s like a black box of logic in itself. And I’ve started work on this, but there’s a lot to do. I’m trying to find a similar way of breaking down the rules into a very manageable set of semantic rules, but there’s a lot of work in that.

The second part that I want to do is I’ve started work on a domain-specific language, a pure functional, very mathematical language, which I’m designing specifically for the Bitcoin consensus specification. And the idea here is that ultimately, what is working at the moment in Hornet as declarative C++ would become a pure declarative DSL specification. That would be more exact than the English and more pure than the C++, and that’s sort of the intended final goal, because then that can interface with theorem provers and formal analysis as well. So, in the end, I would expect the whole specification, including the script logic, to be specified in this pure DSL. And that’s where I want to get to in the end. The DSL could then be interpreted or compiled to produce a runtime binary.

Mark Erhardt: Yeah, that sounds cool. So, one of the things that this reminds me of is that there has been a lot of discussion in the past few years about other languages that could be used to define Bitcoin transaction behavior. There is, of course, high-level approaches that compile down to existing script variants, which is something like miniscript. But there are also efforts to come up with entire new languages like Simplicity and AJ’s thing, for which the name eludes me right now. But I was just wondering, have you looked at those? I mean, it’s slightly different to define a new language, but maybe it’s also interesting in the sense of Simplicity being a formally verified script language for Bitcoin transactions. I was wondering whether there’s any parallels here.

Toby Sharp: Yeah, that’s a very good question. I think I need to engage more with that work and understand more about how the simplicity stuff works. How that could fit into a Hornet DSL or whether it could expand into something that specifies the wider block rules. So, that’s on my to-do stack right now. But I’d be very interested in conversations with anyone who knows more about that or who has engineering experience or opinions on how that could be done.

Mark Erhardt: Yeah, I think we had an update recently, where we learned that Simplicity had now been deployed on the Liquid Network. So, it’s a production-ready project now. The project by AJ, which I think that’s, I don’t remember, I think it’s not on Inquisition yet either, so it’s more theoretical yet. There have been some other approaches, so those might be some people that have opinions on this. AJ, Russell O’Connor, people that have been doing a lot of script and consensus and Bitcoin Core, the usual suspects, you know.

Toby Sharp: Okay, yeah, that’ll be some interesting future conversations to have. Thanks for the recommendation.

Mark Erhardt: Sure. So, I guess we covered pretty well on your steps towards a full specification so far. I think we’ve had a call to action. People, if you’re working on similar things or would like to chat with Toby, I believe his email address is on his website. And we’ve written about his website a few times already. So, you should be able to find out if you google, “Hornet Node”. Did you have any other things to share before you drop?

Toby Sharp: If you want to read the English specification rules that’s in draft I’ve published, that’s at hornetnode.org/spec.html. And yeah, I look forward to receiving any emails from interested parties.

Mark Erhardt: Thank you very much for your time, and I hope you have a nice day.

Toby Sharp: Thank you both. Have a great day.

Onion message jamming in the Lightning Network

Mark Erhardt: All right, we’re continuing with the second News item. This week, we’re talking about, “Onion message jamming in the Lightning Network”, when Erick Cestari posted to Delving Bitcoin about onion messages being another jamming vector similar to HTLCs (Hash Time Locked Contracts). And the dynamic here is slightly different in the sense that when we send HTLCs, obviously we do so to facilitate payments. So, (a) they can only go to peers that have channels with us, (b) they’re naturally limited because you’ll only send HTLCs when you want to make payments and they’re limited by the channel balances, and so forth. With onion messages, we have a slightly different problem, that they can be sent across any P2P connection in the LN. So, if you weren’t aware, Lightning nodes make peer connections with many different Lightning nodes, not just the ones that they have channels with, or at least several others beyond the ones that they have channels with. And they can use those connections to send onion messages. So, the onion message is encoded similarly to the other payment messages where it is in layers, like one onion wrapped by another onion wrapped by another onion. And they would find a route through the network and send these onion packages in order to deliver a message rather than a payment.

So, the problem here is that BOLT4 does not specify a limit on the message size, and it doesn’t clearly indicate how messages should be limited. And that would enable, therefore, an attacker to just flood the network with lots of onion messages. So, nodes have been implementing a variety of approaches to mitigate unlimited flooding. But these in turn cause issues now, because if someone floods their peers with messages, they might start rate-limiting, or using other mitigations, and then other legit messages wouldn’t be able to make it through either. So, this email goes into a review of the current available mitigation ideas for jamming of onion messages, and it details five ideas. So, one is upfront fees. I’m going to package that with another one called bandwidth metered payments. Both of these only work between nodes that have channels. So, instead of being able to send onion messages to any peer, you would only be able to route them along the channel network, which is a subset of the P2P connection network. So, that might cause slightly longer routes, it would create additional P2P overhead because now you have to bundle every message with a bunch of payments to each hub along the way. And so, either with the upfront fees you would pay along the way as the onion gets unwrapped, there’s a payment to each hop; or with the bandwidth meter payment, I think you’re doing an AMP payment and it just pays everyone in advance of the message, and the message will only be forwarded if the payment arrived.

There is the idea to either limit the hops so you could only message peers up to three hops away, or that the limits are based on how much channel balances your node has in sort of a proof-of-stake kind of way. If you have a lot of money in the LN, you’re allowed to send more messages. The concerns there are that a small limit of hops would reduce privacy and make it more visible or easier to guess where a message came from. And the making it based on how much channel balances a node has would of course favor larger nodes. Alternatively, there was a sub idea here to make it a proof-of-work (PoW) puzzle that is exponentially more difficult the more hops it has. But that seems odd if we’re packaging messages into an onion that is supposed to hide how many more hops there are, if you then can just read off the difficulty statement and see how many hops it has under the hood in order to continue all the way. But maybe I’m missing something. I didn’t dive too deeply. Unfortunately, we were unable to have a guest on for this topic. So, I’m just doing my best here to sort of walk you through what I gleaned off reading here.

The last idea is to have a backpropagation-based rate limiting. And the idea there is if you get a lot of messages from a connection that your limit is hit, you would reply at some point with the drop message reply, which is indicating that you will only accept half as many messages from that peer for the time being. So, when your limit is hit, you halve your limit. If you get a drop message signal from a peer, you would then propagate it back to the last node that sent you a message. So, in this proposal from ‘22, this you wouldn’t actually track for every single message where it came from and then apply the drop message in that direction, but rather you would remember who sent you the last message. And then just if there’s a large flood of messages coming to your node, statistically, you would be likely to send it to the right direction because if most messages are coming from one source, then that’s probably where the drop message will go. And then, for that peer that received the message, from there it would go on to the next peer and along the line of wherever the spammer is, most likely the drop message would halve the limits. And this limit would then be lifted after some time, maybe 30 seconds, if the limit isn’t hit again within those 30 seconds. If it’s hit again, it would continue to just halve the limits and eventually shut down the spam source completely.

The issue with this one is, of course, either someone could just send a false dropped message signal, and then it would propagate through the network and punish nodes that didn’t actually misbehave. Or statistically, you are hitting the right one, but you would occasionally hit the wrong one. If you got ten messages from one peer and then one more message from another peer to exceed the ten-per-second message limit, you might punish that 11th message that was the only message sent by another peer.

So, the context here is that the email is calling to action. The developers that are interested in this topic should please join the conversation. The author is concerned that currently, the LN is open to DoS vector or, well, either this flood attack or it preventing legit messages being sent by flooding. So, yeah, this is trying to start a discussion to explore the ideas further so that there might be a standard or spec how this could be mitigated in general. Gustavo, do you have any comments?

Gustavo Flores Echaiz: Yes, certainly. So, I think it’s important to note that LND is currently in the final works of enabling onion messages and BOLT12 offers. And when that occurs, which is very soon, it will now mean that all four major implementations have fully implemented onion messages and BOLT12 offers, which means that now is the perfect time to talk about this, right? Because it could be that very soon, this actually becomes more relevant, and where its usage becomes standardized, it becomes too late to address this issue. So, I want to also add that the post on Delving by Erick mentions that LND hasn’t yet implemented the rate limiting. However, in this newsletter, we cover that LND has now implemented rate limiting as well. So, all four implementations proceed in the same rate-limiting manner when it comes to onion messages.

I also read the conversation and many seem to think that the backpropagation-based rate limiting proposal by Bastien from the Eclair team seems to be the one with the least trade-offs. I wonder maybe if that’s going to be the route that’s going to be taken. It seems to also be the one with the least technical lift to implement. But do you think there’s any trade-offs related to that method that maybe were not properly mentioned here, maybe a privacy trade-off?

Mark Erhardt: I don’t see how there would be a privacy trade-off here. What do you mean?

Gustavo Flores Echaiz: So, from what I understand here, you’re able to identify the sender that basically pierced through the rate limit. Is that a correct assessment?

Mark Erhardt: I briefly looked at Bastien’s email from 2022 and the way he was proposing it was to not track, for every message, the sender of the message and then to assign the punishment according to the source of the message that exceeded the limit, but rather that it would just assign the punishment to the last peer that sent an onion message to your node. And so, this could of course lead to the wrong peer, not the source of the flood, to be punished. But it would also just be a temporary limiting of the throughput. So, when you start with a limit of ten messages per second for a peer that you have channels with, or one message per second for a peer that you don’t have a channel with, it would just go to five messages per second for a channel peer and one message every two seconds for another peer, and would only last for 30 seconds, at least according to that email.

So, I guess you could sort of see which route is limited further now by when your message gets dropped, but basically you would have to flood the network in order to see where channels get limited more. But then, I’m not sure if you could actually learn something interesting, because as the sender, you pick the route in the first place, so you know where it was headed. So, I’m not sure I follow your privacy concern.

Gustavo Flores Echaiz: No, I think you’re right. So, it’s mostly the trade-off here is the false positive, right? You could be punishing the wrong sender. But there’s also a note in the end that says, “A malicious node could also send fake onion_message_drop signals to artificially halve peers’ rate limits and suppress legitimate forwarding without actual congestion”. So, this is also possible, right? I guess these are the two trade-offs of this method.

Mark Erhardt: Yeah, I was just thinking about that. I guess whenever you receive this drop message signal, you would probably have some sort of heuristic on your end where you say, “I’ve only seen a single onion message in the last ten seconds. So, clearly I’m a false positive. I guess I’m rate limited for the next few seconds, but I’m not going to propagate this”. Yeah, I’m not sure if that would actually be easy to exploit. It seems like a few common-sense heuristics could at least make it not propagate through the network.

Gustavo Flores Echaiz: Makes sense. I also saw that one of these solutions was trying to reproduce the same PoW commitment from, yeah, so it’s the one from Bashiri and Khabbazian, the, “Hop Limit + Proof-of-Stake Based on Channel Balances”. So, if I understand correctly, here there’s, well, there’s either setting a hard cap on the maximum sender of hops, for example, three hops, which would have a trade-off; but also, there’s proposal of having the sender solve a PoW puzzle. This is similar to the mitigation that the TOR network implemented I believe last year or two years ago, when they got in a very similar situation where they were facing a DDoS attack in the network, right? So, is my understanding correct there?

Mark Erhardt: I didn’t look too deeply into that. The way I understood it was that the sender was going to have to solve the entire PoW and then include a PoW in each level of the onion, each layer of the onion. But that would certainly slow down a DoS attack. That would make it also very difficult for embedded chips, like say VLS, where you have the Virtual Lightning Signer that is actually talking to a hardware device, that might not be capable of actually doing PoW. So, you might limit some of the existing hardware from participating in BOLT12, which seems like a downside. And I must admit, I haven’t looked too much into it, but if you make the PoW puzzle scale by the number of hops, it would make it harder or easier to guess how many hops there are. But if you don’t scale it by the number of hops, you might make it too cheap to still flood the network. So, maybe it should be more of a PoW marketplace where you choose how much PoW you send, and when you have multiple messages waiting, you only send them in the order of highest PoW at the rate limit, and if your queue gets too big, you start dropping them. Or maybe there are more solutions there. I haven’t deeply thought about this. This is just a shot from the hip.

Gustavo Flores Echaiz: Thank you, Murch.

Mark Erhardt: All right. I guess we haven’t really formally talked about it, but I assume I’m doing Bitcoin Stack Exchange, right?

Gustavo Flores Echaiz: Yeah, I assume that too.

Mark Erhardt: Good, great, we’re in agreement. All right. We have three questions from Bitcoin Stack Exchange this month. I’m afraid it turns out that question and answer platforms are a lot less popular in the day and age of LLMs that just generate answers. So, I think that the people that used to answer them are still around, there’s just a lot fewer questions that are interesting being asked. So, if that’s your sort of jam, do ask some more questions on Bitcoin Stack Exchange. And this concludes the rant by a Bitcoin Stack Exchange moderator.

Why did BIP342 replace CHECKMULTISIG with a new opcode, instead of just removing FindAndDelete from it?

So, our first question was, “Why did BIP342 replace CHECKMULTISIG with a new opcode, instead of just removing FindAndDelete from it?” So, if you’ve looked into P2TR deeply, or not so deeply, you might be aware that in script leaves you’re not allowed to use OP_CHECKMULTISIG. It is simply not available in script leaves, at least in v0 script leaves that use tapscript. Instead, it was replaced with OP_CHECKSIGADD, which allows you to increment a counter of signatures that were valid. And the underlying design decision there is P2TR and schnorr signatures is deliberately designed to enable batch validation, which means that you can take all of the signatures across a transaction, or even all of the signatures across a block, and validate them against all of the corresponding public keys in one swoop. And this speeds up the validation of signatures drastically. So, in order to be able to do batch validation, you have to know in advance which signature pairs with which public key. And with OP_CHECKMULTISIG, you do not know that.

With OP_CHECKMULTISIG, you get a number of 2 signatures, and then you get 3 public keys, or whatever n and m are, obviously; in this example, they are 2 and 3. But then you have to see, “Does the signature fit the first public key? Oh, that failed. Maybe the first signature fits the second public key, or maybe the two signatures are for public key 1 and 3, right?” So, you don’t know in advance which public key and which signatures are paired, and therefore you cannot use batch validation with OP_CHECKMULTISIG. However, with OP_CHECKSIGADD, we require that either there’s a valid signature or there’s an empty dummy element in front of the OP_CHECKSIGADD or OP_CHECKSIG. And therefore, we can batch validate because we know which signatures we expect to be valid and what public key to pair them with. So, that’s why MULTISIG works differently in tapscript. Any questions or comments so far?

Does SIGHASH_ANYPREVOUT commit to the tapleaf hash or the full taproot merkle path?

I continue with the second question, “Does SIGHASH_ANYPREVOUT commit to the tapleaf hash or the full taproot merkle path?” This question was looking into the BIP118 covenant proposal SIGHASH_ANYPREVOUT, which was the original proposal for re-bindable signatures to enable LN-Symmetry. Per the current write-up of BIP118, the SIGHASH_ANYPREVOUT sighash code requires that the input commits to the tapleaf hash, but not the full merkle path. And there is currently a discussion ongoing, I haven’t looked too deeply into it, but I assume it is because if the same leaf were to appear twice in a tree, if there were a signature for one leaf, the transaction could be malleated to point at the other leaf instead with the same signature, if someone is aware of the tree having that.

I would also like to point out that BIP118 has been in draft since 2017, and there have been multiple other proposals since then that do similar things, most lately, the OP_TEMPLATEHASH re-bindable signature package that just got assigned a BIP number earlier this year. So, it’s still under discussion, it’s still draft, it’s not proposed or complete and therefore proposed for adoption yet. But I guess it’s a good question to ask what it actually commits to and to make it commit to the right things.

What does the BIP86 tweak guarantee in a MuSig2 Lightning channel, beyond address format?

For the final question of the Bitcoin Stack Exchange segment, we are looking at, “What does the BIP86 tweak guarantee in a MuSig2 Lightning channel, beyond address format?” And there are a few comments on this question, which I think clarified what the asker wanted to know. And it seems to me that the actual question boils down to MuSig2 actually itself guarantees that every signer, every participant in the aggregated signature, for their partial signature must apply the tweak in order to go from the internal public key to the external public key. And therefore, MuSig2 itself already guarantees that there can’t be a hidden path. And yeah, so basically the tweak is more of a property of – or I should say BIP86 and MuSig2 are a little unrelated in this regard. But the interesting takeaway is that MuSig2 already prevents the rogue key attack, which it was specifically designed to do, and therefore the concern raised by the question doesn’t apply.

All right. We’re going from here to the Releases and release candidates section, and I believe Gustavo will take over here.

Gustavo Flores Echaiz: Yes, thank you much. So, now we move forward with the Release and release candidates. So, this week we have two releases that have been long-awaited for the past few weeks.

Bitcoin Core 31.0

So, the first one is Bitcoin Core version 31, which is the latest major version release. So, if listeners want to learn more about all the changes that happened here, I would point out to the Newsletter and the episode #400, where we invited a guest, part of the Bitcoin Core PR Review Club segment, to go through all the testing guide and talk about all the major pieces here. But in general, Bitcoin Core 31 includes the implementation of the cluster mempool redesign, which has been a proposal and something in the works for years, to change how the internal mempool of a Bitcoin Core node basically handles all unconfirmed transactions, specifically in complex scenarios where there’s multiple clusters with dozens of descendants, and it creates a sort of complex logic. So, cluster mempool is a redesign to better order and linearize unconfirmed transactions.

The next important feature of Bitcoin Core 31 that I personally really like, and that we covered more in detail in Newsletter #388 and its accompanying episode, was the new -privatebroadcast option, which creates a short-lived connection to broadcast a transaction either through a TOR or I2P short-lived connection. So, basically a node that includes this -privatebroadcast option when using the sendrawtransaction RPC, it will open a short-term, short-lived connection, it will broadcast the transaction to that connection to protect the privacy of the transaction originator, and then it will close that connection and come back to its regular identity. So, that’s another big important feature.

Something else that has been in the work for years and has now been added into the Bitcoin Core binary is the asmap, or autonomous systems map, data that is optionally embedded into the binary for eclipse attack protection. So, in previous versions, you could always bring your own data for this. However, now it can be optionally embedded into the binary, if you build a binary with it. And then, there’s also many other changes, such as the increase of the default -dbcache setting to 1 GB, or 1,024 MiB, on systems with at least – you’ve got a correction to make there, Murch?

Mark Erhardt: So, yeah, sorry, short x course. Usually kilo, mega, giga, and so forth refer to a 1000x increase, right? Of course, we’re interested in multiples of binary in computer science. So, in computer science, we actually use 1024, which is 2^10. And this has been butchered over decades forever, where, for example, if you buy hard drives, they will list it in MB and then overstate sort of the capacity, if you think in the actual 24 multiples. So, the proper term, if there’s a little ‘i’ in the center, is to replace the last two letters of the prefix with B. So, it’s kibibytes (KiB), mebibytes (MiB), gibibytes (GiB), and so forth. And that indicates the 1,024x instead of the 1,000x.

Gustavo Flores Echaiz: Right. MiB, right, that was the correct name in this instance. Yeah, so the increase of the default -dbcache setting is now 1,024 MiB instead of, well, I think it doubled on systems with at least 4,096 MiB of RAM. And there’s many other updates, obviously, included in this release, so we invite listeners to check out the release notes for further details. Like I said, there’s multiple features, and there’s dozens of contributors that are credited in this release. Anything to add here, Murch?

Mark Erhardt: I believe it was 450 MB before. So, if you didn’t change any settings on your Bitcoin Core client when you started it, it would use a -dbcache of 450 MiB. And so, this refers to the cache that keeps the UTXOs. So, when we run a Bitcoin node, whenever we process a block, we would add all of the newly created transaction outputs to this cache. And otherwise, when we process any transactions, we would load from disk the UTXOs corresponding to inputs, and put them into our cache. And then, of course, when they get spent, we would write that back. So, the cache is tracking basically the UTXOs that your node currently needs to process blocks and transactions. And during IBD, because nodes do not request unconfirmed transactions during IBD, because obviously they can’t validate them without being at the chain tip, so the RAM set aside for mempool data structure is used additionally as -dbcache during that time. Any mempool RAM that isn’t used by default, that’s 300 MB – MiB, I should be precise, right, especially after correcting you!

So, by default, the mempool data structure is limited to 300 MiB and when that is not used, such as during IBD, that is used as additional -dbcache. So, by default, if you hadn’t changed anything so far, you were probably using 750 MiB as -dbcache during IBD. Now, you will be using 1,324. This is just in light of computers having a lot more RAM now, especially on non-32-bit systems. And all this change only applies to systems where at least 4 GiB of RAM were detected.

Core Lightning 26.04

Gustavo Flores Echaiz: Thank you, Murch. Next release is Core Lightning 26.04, which also follows three RCs and has now shipped. I want to add that 26.04.1 was shipped very shortly after we published this newsletter, with a hotfix release addressing build and protocol correctness issues found shortly after the v26.04 release. So, if you still haven’t upgraded to this version, make sure to install the one with the hotfix. This release mostly focuses on splicing. So, following the merging of the splicing proposal into the BOLTs repository, Core Lightning (CLN) has now enabled splicing by default. It adds two new commands, splicein and spliceout, including a cross-splice mode, that within a spliceout, targets a second splice as the destination of a spliceout. So, it’s a spliceout for one channel but splicein for another. And there’s also many other features included in this release, such as the redesign of the bkpr-report, which is a sort of database inside that tracks income summaries, and other improvements and plugins, such as askrene, which are used for pathfinding, so parallel pathfinding and bug fixes.

So, you can see there on the release note multiple other features related to this, or you could also listen to the episode #398 and read the newsletter where we invited Dusty from the CLN team to talk about all the splicing-related changes now in CLN, but also the splicing proposal that was merged into the BOLTs repository.

LND 0.21.0-beta.rc1

So, the next and the final item in this segment is LND 0.21.0-beta.rc1. So, one key takeaway from this is the migration of what is called the payment store database. It migrates from using its traditional key-value (KV) format to native SQL. So, if you have been using LND with the –db.use-native-sql flag, which means you’ve been using SQLite or PostgreSQL backends for your LND node and other parts of your node, well, just be aware that you should note that this version migrates the payment store to also native SQL. However, you can optionally opt out of that. And, well, this release has multiple items related to it that I don’t think we’re going to go into much detail here, probably wait until it gets out of RC for that. But you can find that into the release notes. I guess the main new feature is the basic support for onion message forwarding, which we were talking about earlier in this episode and which I’ll cover as well later in this episode with an item in the Code changes section. So, that completes the Release section and I will continue with the Notable code and documentation changes section.

Bitcoin Core #33477

So, the first item is a very interesting one, called Bitcoin Core #33477. This one updates how the RPC command dumptxoutset works. So, what is all that? First, let’s give a little background. So, if you want to build a historical UTXO set dump so that you can create a snapshot of your UTXO set for the assumeUTXO protocol, so another node can use assume UTXO with your snapshot and basically sync to the chain tip faster, and then validate in the background all the previous blocks before the snapshot height, well, you use the RPC command dumptxoutset, which will dump the snapshot and that can then be used by other nodes. You could use it with the rollback mode, which what it does is that it goes at a previous height. It will roll back your chain, go to a previous height, and then create the snapshot from a previous height. So, if, let’s say, you’re synced to the block 900,000, but you want to create a snapshot to the block 800,000, you would invalidate 100,000 blocks, and you would go back to height 800,000, and that’s when you would produce the UTXO set dump for an assumeUTXO snapshot.

So, what this PR does, it changes how that rollback mode works. Instead of rolling back the main chainstate, invalidating a bunch of logs, suspending network activity, and then coming back to the chain tip after producing that snapshot, instead Bitcoin Core will create a temporary UTXO database, it will rollback that UTXO database to the requested height and write the snapshot from that temporary database. So, this enables you to keep being in sync with the network, you don’t have to suspend network activity, and it also removes a risk related to fork-related interference. So, in the previous mode, if you would rollback and something would change at the chain tip, for example, a reorg would happen, then there would be some fork-related interference with your rollback. So, all of that is removed. However, the temporary disk space is a trade-off, and also the process becomes slower. So, there is a little performance trade-off, but in general it’s a big improvement, because you no longer need to suspend network activity.

Just going to finish here that there’s an option called in_memory that keeps the temporary UTXO database entirely in RAM memory. So, if you have enough RAM memory, you could use that to enable faster rollbacks. And also, it’s recommended to use no RPC timeout with the bitcoin-cli, because it can take several minutes. And I believe the default for the timeout is about five minutes. So, if you don’t precise that, then you could timeout before it completes the job. Yes, Murch?

Mark Erhardt: Yeah, doing this sort of stuff was a huge pain in the neck before, because you actually basically had to suspend using your node to roll it back to a historic state in order to create the txoutset. I remember when we used to make images of nodes in BitGo, we would stop it at certain heights in order to have a snapshot at a specific height from which we can recover, and so forth. So, having a way where you can just virtually roll it back in memory seems like a huge step up.

Bitcoin Core #35006

Gustavo Flores Echaiz: Certainly, definitely one of the biggest items of this week. The next one is also from the Bitcoin Core repository. It’s the PR #35006. So, here, an option is added to the bitcoin-cli to program, called -rpcid, which allows you to set a custom string to your JSON-RPC requests instead of the default hard-coded value of 1. So, this allows requests and responses to be correlated if, let’s say, multiple clients are making concurrent calls and are using the same backend server-side instance. This identifier is also included in the debug log. So, now, I believe that Bitcoin Core is moving towards an architecture where multiple different instances could call the same – yeah, sorry, it’s c-l-i, not ‘cli’. It’s an old habit! So, yeah, bitcoin.cli. So, this new option allows requests and responses to be correlated when multiple clients use the same Bitcoin instance, called through different bitcoin-cli programs.

Mark Erhardt: Sorry, I just felt that the watchers might be reacting to me reacting to you, so I wanted to make it clear to you why I was doing that, but you’re aware of it, of course. Yeah, ‘cli’ sounds funny to me. Usually, the way I’ve always heard it, it’s c-l-i for Command Line Interface, right?

BIPs #1895

Gustavo Flores Echaiz: Yeah, it’s an old habit from learning it in French. So, the next, we did a little change this week. We moved forward the items from the BIPS repository, because it’s more related to Bitcoin infrastructure, and we have LN items at the end. So, the two items from the BIPs repository this week, the first one, #1895, publishes BIP361, which is an abstract proposal for post-quantum migration and legacy signature sunset. So, when this draft was merged, when this PR was merged, there was an initial version that has now changed since then. The initial version had three phases, and now the latest one has two phases. So, I wrote my item not based on this, on the merged PR, but instead the latest phase or the latest draft when I wrote this item. So, in the current draft, there’s only two phases. First of all, I want to say that this proposal assumes that a post-quantum signature scheme has been deployed and implemented in Bitcoin and is also standardized.

So, the first phase means that the nodes or clients would be prohibited from sending funds to quantum-vulnerable addresses. So, all the current signature schemes that currently exist in Bitcoin, if this proposal was to be implemented, once a separate post-quantum signature scheme would be standardized and deployed, phase A would prohibit sending funds to legacy addresses, which are all of today’s addresses, to accelerate the adoption of post-quantum address types. Yes, Murch?

Mark Erhardt: Not just to accelerate the adoption, but also to prevent more funds becoming long-range attack vulnerable, right? So, just a small clarification here. The concern with quantum, of course, is that with elliptic curve cryptography, such as ECDSA, and the use of secp, the private key can be calculated from a public key should a cryptographically-relevant quantum computer arrive. And the concern here is that for every output for which the public key that is used to authorize the payment is public, attackers with a quantum computer would have essentially any amount of time to calculate the private key and then spend the funds. So, the first step would be to move funds to output types that are not vulnerable to long-range attacks and/or to output types that internally can have post-quantum schemes.

So, the way I understand it, this would also potentially apply to BIP360, which proposes a new output type that has a hash in its construction that hides the public key in the first instance when it is only paid to, only reveals it upon spending. But it could have a script tree under the hood which could have both legacy spending leaves and post-quantum spending leaves. So, let me also say maybe, when I announced the publication of BIP361 after publishing it, obviously it’s not my BIP also to be clear, a lot of people were confused between the role of BIP editors and BIP authors. So, BIP authors write BIPs; BIP editors read them, review them, and when ready, publish them, as editors do. So, this is not my BIP. This is a BIP by Jameson Lopp and colleagues. First clarification.

Second clarification, BIPs are proposals to the Bitcoin ecosystem by their authors. So, when a BIP is published, it doesn’t mean that it has broad support among the Bitcoin developer scene or that it is already adopted or that it is scheduled to be merged into Bitcoin Core, or anything of that sort. It is a way of presenting an idea in a comprehensive fashion in a central place where everybody knows where to find it, from the authors to the Bitcoin community. Now, as these proposals progress over time and get more mature, they become more co-owned by the Bitcoin community as they get more adopted. But especially in the draft stage, they’re basically just a more thorough write-up of a concrete idea that someone wants to discuss with the ecosystem. So, everybody that’s already all up in arms and predicting that this is the end of Bitcoin, please understand that this is a proposal that has been put forth to discussion, not a decided final thing or anything like that.

So, this one specifically is based on both (a) activating itself, and then (b) previously a post-quantum signature scheme being available. So, this would follow perhaps both the introduction of a new opcode that allows OP_CHECKSIG with a post-quantum signature scheme. First, that signature scheme has to be invented and specified. Then, an output, the opcode has to be deployed to script. Presumably that would be tapscript if we go via BIP360 with the P2MR outputs. And then, this BIP would be deployed. And after three years after it’s deployed, it would start restricting sending to legacy outputs. And then, I think after another two years, it would start restricting sending from legacy outputs, and require post-quantum-resistant proof that the owner is making that payment. And there be dragons there still. It’s not entirely clear yet how such a post-quantum proof could be created. This would, of course, especially not be possible for lost coins.

One of the most controversial aspects of this would be that people feel freezing lost coins is unacceptable. Often people say, “Let quantum computer developers take it”. And I always wonder why Bitcoin needs to sponsor quantum computers. Quantum computers don’t do anything for Bitcoin. It’s not like mining or anything, where we actually have a benefit from funding miners. Quantum computers don’t make Bitcoin better. So, it’s not clear to me why we, as Bitcoin, would need to support quantum computer development with a huge bounty that is currently about a third of all existing Bitcoins.

Gustavo Flores Echaiz: Thank you, Murch, for that extra context. So, yes, this proposal is particularly very abstract and it has changed already since it was merged. So, we expect more changes to happen and it should be taken with a grain of salt that this is anything sort of close to being materially final, right? So, this remains in draft mode and in a very abstract mode as well.

BIPs #2142

The next one is the PR BIPs #2142, which updates the specification of BIP352, where silent payments are proposed. So, here, a new test vector is added for an edge case where basically the running sum of some input keys hits zero after two inputs, but the final sum over all inputs is non-zero. So, a naïve implementation could see how two input keys hit zero and then assume that this fails, however later see that the final sum actually ends up in non-zero. So, this catches implementations that reject early instead of summing all inputs first. Yes, Murch?

Mark Erhardt: So, this would specifically happen if two keys were constructed to cancel each other out. So, basically one is minus the other. And I think that this was specifically added to BIP352 because a couple of silent payments implementations were found to not correctly check for this. So, if you have implemented silent payments, and I think this only applies to a handful of people here, please do check that your implementation passes these latest test vectors. And yeah, I keep being excited that silent payments is making progress, but I’m very much hoping that it soon – I think it’s still in draft mode. It should probably move to complete soon and then – oh no, sorry, it is complete. But probably, it should be moving to final soon, because there’s already multiple projects that use it in production on mainnet. And hopefully eventually, that will also include Bitcoin Core.

LDK #4555

Gustavo Flores Echaiz: Thank you, Murch. So, now we pass on to the final part of this section, where we talk about changes in LN implementations. So, the first one is LDK #4555, which fixes how forwarding nodes enforce max_cltv_expiry for blinded payment paths. So, what was happening here is that a blinded path that had expired was still getting routed into the first hop and was failing deeper inside. Instead, it should have been rejected at the introduction node. But instead, it passed and got forwarded into the blinded segment, only to fail somewhere deeper down. So, now, LDK makes sure to compare against the inbound CLTV expiry as intended, instead of against the hop’s outgoing CLTV value, so it knows if a blinded path has already expired, and it will not just try to reach its end to then fail later; it will just simply fail and kill the payment at the introduction node. So, this is a proper implementation to how to resolve payments faster and not get caught up into a blinded path that has already expired only to fail later.

LND #10713

So, the next one is related to a topic we discussed at the beginning. So, LND #10713 adds per-peer and global token-bucket rate limits for incoming onion messages. So, as we had described at the beginning, there’s a potential onion message jamming attack in the LN. First, if you don’t implement rate limits, you could just get spammed by onion messages. But then, the rate limits themselves also create a vulnerability, where an attacker could make you reach your global token-bucket rate limit and you would be dropping other important onion messages that are directed to you. So, anyways, we’ll see where that discussion goes, but this item is about LND implementing what other implementations have implemented, which are weight limits for incoming onion messages. So, if you want to learn more about LND’s recently added onion message support, we covered that in Newsletter #396 and its accompanying podcast episode. And also, in Newsletter #370, we talk about similar methods that LND implemented for gossip messages. So, this kind of mirrors the work that was done and covered in Newsletter #370, but adapts it for onion messages instead of gossip messages.

LND #10754

And the final item of this week is also in the repository of LND, PR #10754, where it’s just a small correction, where LND will not forward an onion message when the chosen next hop is the same peer that delivered the onion message. So, it will of course avoid an immediate bounce because it’s forwarding an onion message that was sent by the same peer where the destination is.

Mark Erhardt: That one’s kind of funny to me. So, why would anyone ever want to send a message that bounces from Alice to Bob to Charlie and back to Bob? But when Bob forwards it to Charlie, Bob wouldn’t even know that he’s the next target again, because it’s wrapped in an onion that only Charlie will unpack. So, the message would just disappear at Charlie’s. So, I guess that would be maybe interesting as a way to create such flooding messages, if you want to hit a specific node. But yeah, I don’t think there’s ever a good reason to actually have a bounce-back where two hops are directly next to each other. So, just funny, funny that that was an issue, but also obvious how you might miss that as an optimization of something that you can clearly drop.

Gustavo Flores Echaiz: Exactly. Well, that completes this week’s episode.

Mark Erhardt: Yeah. Thank you very much for Toby Sharp to join us to talk about Hornet Node. Thank you to Gustavo. It was a fun episode. We will hear you again next week without me.

Gustavo Flores Echaiz: Thank you.

Bitcoin Optech Newsletter #402

2026-04-24T00:00:00+00:00

This week’s newsletter describes Hornet Node’s work on a declarative executable specification of consensus rules and summarizes a discussion about onion message jamming in the Lightning Network. Also included are our regular sections with selected questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

News

● Hornet Node’s declarative executable specification of Bitcoin consensus rules: Toby Sharp posted to Delving Bitcoin and the Bitcoin-Dev mailing list an update on the Hornet node project. Sharp had previously described a new node implementation Hornet that reduced initial block download times from 167 minutes down to 15 minutes. In this update, he reports completing a declarative specification of non-script block validation rules, consisting of 34 semantic invariants composed using a simple algebra.

Sharp also outlines future work, including extending the specification to script validation, and discusses potential comparisons with other implementations such as libbitcoin in response to feedback from Eric Voskuil.
● Onion message jamming in the Lightning Network: Erick Cestari posted to Delving Bitcoin about the onion message jamming problem affecting the Lightning Network. BOLT4 acknowledges onion messages to be unreliable, recommending to apply rate limiting techniques. According to Cestari, these techniques are what makes message jamming possible. Attackers may spin up malicious nodes and flood the network with spam messages triggering rate limits of peers, forcing them to drop legitimate messages. Moreover, BOLT4 does not enforce a maximum message length, allowing attackers to maximize the reach of a single message.

Cestari reviewed several mitigations to onion message jamming and provided a comprehensive overview of the techniques he deemed more suitable:
- ● Upfront fees: This technique was first proposed by Carla Kirk-Cohen in BOLTs #1052 as a solution for channel jamming, but can be easily extended. Nodes would advertise a per-message flat fee, to be included in the onion payload and deducted at each hop. In case the fee is not paid, the message would be just dropped by the node. This method presents some limitations, such as being able to only forward messages to channel peers and increased p2p overhead.
- ● Hop limit and proof-of-stake based on channel balances: This technique was proposed by Bashiri and Khabbazian at the University of Alberta and has two different components:
  - Leashing hop count: Either setting a hard-cap on the maximum number of hops that a message could do (e.g. 3 hops), or having the sender solve a proof-of-work puzzle, whose difficulty increases exponentially with the number of hops.
  - Proof-of-stake forwarding rule: Each node sets per-peer rate limits according to the peer’s aggregate channel balance, granting well-funded nodes more forwarding power.
  The trade-offs of this approach are related to centralization pressure, due to larger nodes being at an advantage, while the 3-hops hard-cap could reduce anonymity set.
- ● Bandwidth metered payment: Proposed by Olaoluwa Osuntokun, this technique is similar in scope as upfront fees, but adds per-session state and settles through AMP payments. A sender would first send the AMP payment, dropping fees at each intermediate step and delivering an ID for the session. The sender would then include the ID in the onion message. Known limitations of the approach are related to the ability to only forward messages to channel peers and the possibility to link all the messages belonging to the same session.
- ● Backpropagation-based rate limiting: This approach, proposed by Bastien Teinturier, uses a backpressure mechanism that is statistically able to trace back spam to its source. When the per-peer rate limiting is hit, the node sends a drop message back to the sender, which in turn relays it to the last peer that forwarded the original message halving its rate limit. While the correct sender is statistically identified, the wrong peer could be penalized. Moreover, an attacker could fake the drop message, lowering rate limits of honest nodes.
Finally, Cestari invited LN developers to join the discussion, stating that a window is still available to mitigate the issue before prolonged DDoS attacks hit the network, as happened to Tor recently.

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.

● Why did BIP342 replace CHECKMULTISIG with a new opcode, instead of just removing FindAndDelete from it? Pieter Wuille explains that the replacement of OP_CHECKMULTISIG with OP_CHECKSIGADD in tapscript was necessary to enable batch verification of schnorr signatures (see Newsletter #46) in a potential future protocol change.
● Does SIGHASH_ANYPREVOUT commit to the tapleaf hash or the full taproot merkle path? Antoine Poinsot confirms that SIGHASH_ANYPREVOUT signatures currently commit only to the tapleaf hash, not the full merkle path in the taproot tree. However, this design is under discussion as one BIP co-author has suggested committing to the full merkle path instead.
● What does the BIP86 tweak guarantee in a MuSig2 Lightning channel, beyond address format? Ava Chow points out that the tweak prevents the use of hidden script paths because MuSig2’s signing protocol requires all participants to apply the same BIP86 tweak for signature aggregation to succeed. If one party attempts to use a different tweak, such as one derived from a hidden script tree, their partial signature won’t aggregate into a valid final 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.0 is the latest major version release of the network’s predominant full node implementation. The release notes describe several significant improvements, including the implementation of the cluster mempool design, a new -privatebroadcast option for sendrawtransaction (see Newsletter #388), asmap data optionally embedded into the binary for eclipse attack protection, and an increase in the default -dbcache to 1024 MiB on systems with at least 4096 MiB of RAM, among many other updates.
● Core Lightning 26.04 is a major release of this popular LN node implementation. It enables splicing by default, adds new splicein and spliceout commands including a cross-splice mode that targets a second channel as the destination of a splice-out, redesigns bkpr-report for income summaries, adds parallel pathfinding and multiple bug fixes in askrene, adds a fronting_nodes option on the offer RPC and a payment-fronting-node config, and removes support for the legacy onion format. See the release notes for additional details.
● LND 0.21.0-beta.rc1 is the first release candidate for the next major version of this popular LN node. Users running nodes with the --db.use-native-sql flag against an SQLite or PostgreSQL backend should note that this version migrates the payment store from the key-value (KV) format to native SQL, with an opt-out via --db.skip-native-sql-migration. See the release notes.

Notable code and documentation changes

● Bitcoin Core #33477 updates how the dumptxoutset RPC’s rollback mode (see Newsletter #72) builds historical UTXO set dumps used for assumeUTXO snapshots. Instead of rolling back the main chainstate by invalidating blocks, Bitcoin Core creates a temporary UTXO database, rolls it back to the requested height, and writes the snapshot from the temporary database. This preserves the main chainstate, eliminating the need to suspend network activity and the risk of fork-related interference with the rollback, at the cost of additional temporary disk space and slower dumps. A new in_memory option keeps the temporary UTXO database entirely in RAM, enabling faster rollbacks but requiring over 10 GB of free memory on mainnet. For deep rollbacks, it is recommended to use no RPC timeout (bitcoin-cli -rpcclienttimeout=0) as it may take several minutes.
● Bitcoin Core #35006 adds a -rpcid option to bitcoin-cli to set a custom string as the JSON-RPC request id instead of the default hardcoded value of 1. This allows requests and responses to be correlated when multiple clients make concurrent calls. The identifier is also included in the server-side RPC debug log.
● BIPs #1895 publishes BIP361, an abstract proposal for post-quantum migration and legacy signature sunset. Assuming a separate post-quantum (PQ) signature scheme is standardized and deployed, it outlines a phased migration away from ECDSA/schnorr signature schemes. The current version of the proposal is divided into two phases. Phase A prohibits sending funds to quantum-vulnerable addresses, thereby accelerating the adoption of PQ address types. Phase B restricts ECDSA/schnorr spending and includes a quantum-safe rescue protocol to prevent theft of quantum-vulnerable UTXOs.
● BIPs #2142 updates BIP352, the silent payments BIP proposal, by adding a send/receive test vector for an edge case where the running sum of input keys hits zero after two inputs but the final sum over all inputs is non-zero. This catches implementations that reject early during incremental summation instead of summing all inputs first.
● LDK #4555 fixes how forwarding nodes enforce max_cltv_expiry for blinded payment paths. The field is meant to ensure an expired blinded route is rejected at the introduction hop rather than being forwarded through the blinded segment and failing closer to the receiver. Previously, LDK compared the constraint against the hop’s outgoing CLTV value; it now checks the inbound CLTV expiry as intended.
● LND #10713 adds per-peer and global token-bucket rate limits for incoming onion messages, dropping excess traffic at ingress before it reaches the onion handler. This hardens LND’s recently added onion message forwarding support (see Newsletter #396) against high-volume abuse from fast peers. The per-peer and global split mirrors LND’s earlier gossip bandwidth limits (see Newsletter #370).
● LND #10754 stops forwarding an onion message when the chosen next hop is the same peer that delivered it, avoiding an immediate bounce on the same connection.

Bitcoin Optech Newsletter #401 Recap Podcast

2026-04-21T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Remix7531 and Luis Schwab to discuss Newsletter #401.

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

Download audio

News

● Discussion of using nested MuSig2 in the Lightning Network (34:05)
● Formal verification of secp256k1 modular scalar multiplication (01:10)

Changes to services and client software

● Coldcard 6.5.0 adds MuSig2 and miniscript (40:56)
● Frigate 1.4.0 released (41:46)
● Bitcoin Backbone updates (47:10)
● Utreexod 0.5 released (16:18)
● Floresta 0.9.0 released (19:41)

Releases and release candidates

● Bitcoin Core 31.0rc4 (48:01)
● Core Lightning 26.04rc3 (49:00)

Notable code and documentation changes

● Bitcoin Core #34401 (50:01)
● Bitcoin Core #35032 (51:51)
● Core Lightning #9021 (55:33)
● Core Lightning #9046 (56:53)
● LDK #4515 (58:25)
● LDK #4558 (59:51)
● LND #9985 (1:01:53)
● BTCPay Server #7250 (1:04:07)
● BIPs #2089 (1:07:28)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #401 Recap. Today, we’re going to talk about nested MuSig2 in Lightning, or potentially using nested MuSig2 in Lightning; we’re also going to talk about formal verification, this time in secp in the modular scalar multiplication; and we have, I think, five entries in our Changes to services and client software and then we have our weekly segments on Releases, release candidates and Notable code and documentation changes. This week, Murch, Gustavo and I are joined by a couple of guests and we’ll have them introduce themselves. Remix, you want to say hi and talk about what you’re working on?

Remix7531: Hi, I’m Remix, and I’m working with formal methods on cryptography.

Mike Schmidt: Awesome. Luis?

Luis Schwab: Hey, I’m Luis, I’m a grantee from Bitcoin Dev Kit, and I’m currently working on wallet integrations with utreexo.

Formal verification of secp256k1 modular scalar multiplication

Mike Schmidt: Excellent. We’re going to go a little bit out of order since we have our guests on. We will jump to the second news item titled, “Formal verification of secp256k1 modular scalar multiplication”. Remix, you posted to the Bitcoin-Dev mailing list about a project that you have apparently been working on for some time, to formally verify parts of secp’s implementation. Maybe to start off, how would you articulate for listeners what it means for something to be formally verified?

Remix7531: Yes, so what it means to formally verify is basically, you write a mathematical specification of what a program should do and then you write a proof that the code that you’re verifying matches the proof, so that it actually computes what the proof says. And then, you use a proof assistant to mechanically check every step of the proof. So, you don’t have a teacher or professor checking your proof, but the computer is actually doing that part.

Mike Schmidt: Okay. I think it makes sense. Maybe you can walk us through the example, and maybe not an example, but the project that you’ve worked on here in terms of C, and maybe that’ll help. Maybe you can mention some of the tooling and how it works so we can connect that explanation to something more tangible.

Remix7531: Yeah, so what I’ve been working on since the beginning of the year is a proof of concept that it’s part of my OpenSats grant. I am evaluating different toolchains to do this formal verification. So, formal verification is not a new concept, it has been done by different people over the years. And so, basically, I’m looking at the codebase of secp and evaluating which tools I can use for doing that. And the first toolchain I used was the Verified Software Toolchain (VST). It’s arguably the most well-studied or most used, oldest toolchain for doing this kind of work on C. It was originally developed at Princeton, and I now think it’s continued to be worked on at the University of Chicago. And basically, what you can do with it is you have a program that converts your C code into an abstract syntax tree that you can then reason about inside a proof assistant. And because all that is quite a bit of work, I started with a single function of a signature generation verification, and that is this modular scalar multiplication.

All that function really does is it multiplies a with b, and then does mod n. So, it’s a small function, it has about 300 lines of code, and the proof to check this function is along 6,000 lines of proof code. But what you get from that is a guarantee that for any input, not just specific unit tests of tests you’re doing with fuzzing, for any possible input, which is 2^512, it will always give you the correct result and it will not have like a memory leak or an integer overflow, or any other kind of undefined behavior. Does that explain it a little?

Mike Schmidt: Yeah, I think that that makes sense. I’m curious, you mentioned some of the types of errors or behavior that would be avoided by formally verifying. What is that list; maybe the top items, or if there’s a smaller list, the list in entirety?

Remix7531: Yeah, so in general, it is the memory safety, then any kind of integer overflows or division by zero. Yeah, that’s basically the main things. And the motivation for this is also because when you look at crypto code, the cryptographers are very well at designing new algorithms and primitives, so they go through rounds of review, they may be going through standardization, but the actual bugs in crypto code are implementation errors, and this is what we are preventing with this.

Mike Schmidt: I see. On the Brink Engineering call, we had on Russell O’Connor, who did some formal verification of safegcd in libsecp, and he walked through some of his tools and approaches to that. I’m not sure if you’re familiar with his work and if you built on that work, or is this like a different stack that you’re using or a different approach?

Remix7531: No, I am not 100% sure but I think he also used the VST. He also acquired a license to use some parts that are not free, so I’m pretty sure it’s the same stack.

Mike Schmidt: Okay, yeah, interesting. Maybe listeners would be curious about the level of effort that went into this, because I think folks hear these benefits and just, I think, initially would say, “Yeah, let’s do it all. Have all the codebases formally verified”. So, maybe you can articulate what you can and cannot formally verify, and also some indication of how much work went into this.

Remix7531: Yeah, that is a usual answer to that. Like, “Yeah, let’s just verify everything”. And that’s where you have to stop them. In theory, you can formally verify any code, any C code, but it takes some tremendous work. So, for the VST, a general rule that I’ve seen in other works and papers is that for a single line of C code, you have 20 lines of proof code. And what does proof code mean? It’s basically steps that you take, as they call tactics, that are used to convince the proof assistant that you’re basically the teacher, the checker, that what you’re actually doing is correct. And in terms of time, this is the first time I used the VST. I’ve used other proof assistants for other projects before, but it took me about, I would say, two to three months to get used to Rocq and the VST, and then five weeks to do this scalar multiplication.

Mark Erhardt: So, now that you know how to do it, obviously you would be way faster for doing it for another one, right?

Remix7531: Of course, yeah. And there is more advanced, so to say, tactics, like steps convincing the proof assistant that I haven’t really touched or understood. So, there is room for not just being better at it myself, but also using more advanced tools as well. But this 20-to-1 rule is kind of general.

Mark Erhardt: Right, so how does that proof code factor into it? Is the proof code reflective of the work that the software stack then has to plow through, or do you write it manually, the proof code?

Remix7531: Yeah, so the proof code you write manually, and maybe we can talk about writing it with an AI later. But yeah, you write the proof code and it’s an interactive process. So, you have your current goal and state accepted by the proof assistant, and then you basically give them a tactic to form that rule or the goal or the current state and you try to bring them together. The state should, at end, be the same as the goal. Sometimes you run in the wrong direction doing your proof. Maybe business people are familiar with doing informal proofs with pen and paper in undergraduate studies or something. Sometimes you go in the wrong direction and you have to start over. It’s basically very similar to doing pen-and-paper proofs.

Mark Erhardt: Okay, cool. So, what’s your overall project? You now did a formal proof for a single function, from what I understand, right?

Remix7531: Yeah.

Mark Erhardt: Is the idea to have a full formal verification of the libsecp library, or is this generally secp and can be used by any implementer of it, or how does it work?

Remix7531: Yeah, so the overall goal, I think I also wrote it in the blog post, is that of course you want to have a fully verified secp library. But right now, I’m still in the exploration phase, looking at different proof assistants. This was the first one. And of course, there’s other tools that might have better automation or other workflows. And once I know which tool to use, then of course the goal is to have an end-to-end verified libsecp code.

Mike Schmidt: I know in some cases, testing requires some refactoring to get things sort of appropriately modularized for the testing. Is that the same case here with formal verification? And if so, I’ve heard that secp is pretty modular, and so you can just jump in and start, you know, picking off functions? Or does there need to be work at the secp layer to architect it for this sort of work?

Remix7531: Yes, so there’s two things that the VST does not support. And it’s first returning a struct from a function that is used in libsecp. And the second one is assignment of struct. So, you have to assign every field of a struct manually. That is a refactor you definitely have to do. And on the other side, which I also did for this project, is the original code used macros very heavily for the computation of, let’s say, some results. And I had to convert these to inline functions. So, instead of macros, you have, in C, inline functions. Because otherwise, you can’t really use a divide-and-conquer strategy. So, you try to prove a single helper function. Let’s say it just adds two numbers, and then you have another one that multiplies two numbers, and then you kind of get to have a modular proof. And if you would have to have macros, it would have the entire big function and have to do the proof all at once. And it has to be seen if turning macros into an inline function has any performance implications, but I think with the modern compilers, it shouldn’t really be a problem.

Mike Schmidt: Have you been following along, Remix, with some of the discussion on the mailing list this past week about Hornet Node and the attempts there to do formal verification on Bitcoin consensus rules?

Remix7531: I’ve read the mails but I haven’t really looked into the Hornet Node yet. So, I understand that they implement a domain-specific language for C++, but I don’t think they’re doing actual formal verification of the consensus code. I think the project is more about formalizing the actual rules at this point, but I don’t know.

Mark Erhardt: Yeah, that was my understanding too. Toby Sharp was on a while back and was talking about trying to, as a byproduct or as one of the two products he’s trying to develop while creating Hornet Node, he wants to try to formally specify the Bitcoin protocol. So, I think that’s related, but not quite exactly the same. He has also been implementing a lot of the cryptography around it, from what I understand. He was implementing ECDSA signing and things like that. So, maybe he would be an interesting conversation partner in this regard.

Remix7531: Yeah. As for the consensus code, it’s all written in C++, and formal verification of C++ is a very difficult thing. I think many people tried and failed, and so I don’t know if that is possible with current tooling.

Mike Schmidt: If there’s listeners that are curious about this sort of work and the details, obviously there’s the post that you have up on remix7531.com that they can go to. What other resources would you point people to who might be curious about tinkering with this sort of thing? Are there, like, onboarding to formal verification resources out there, or just check out your posts?

Remix7531: Yes, there’s a very great book series. It’s named Software Foundations. It has multiple volumes and you can use it to learn how to use Rocq, the proof assistant I’m using, and it’s interactive. So, you shouldn’t really read it as a PDF or in the browser, you should be opening it in your editor, and then you can read along and do the examples or the exercises. And it’s a really great way to learn about formal verification. And if you’re interested in my work, you can go on my website, and I’m a very big fan of just writing somebody an email and, yeah, that’s how you can get in touch with me.

Mike Schmidt: Okay, excellent. Well, that’s probably a good spot to wrap up, Murch, unless you had any follow-up questions. Okay. Well, Remix, thank you for your time. Thank you for your work on this and for joining us to explain it today.

Utreexod 0.5 released

We will move down now to the last two items in the Changes to services and client software monthly segment. First one is Utreexod 0.5 being released. Luis, I know you touch a bit of both this as well as Floresta, and I was hoping if we had you on for one, you could help us with the other. Utreexod 0.5, do you want to talk a little bit about why that is an important release and what’s in there?

Luis Schwab: Yeah, so utreexo is basically, we are trying to compress the UTXO set in a way that fits into lightweight devices like phones or a router, whatever. Currently with Bitcoin Core or anything that uses the UTXO set, we can’t really do that because the UTXO set size is huge, and we need to do a lot of lookups on the LevelDB to validate stuff. So, that pretty much puts phones and anything lightweight out of the question. So, Tadge came up with utreexo back in 2019. It introduces two new types of nodes. The first one is a bridge, which pretty much for each new block, it creates a merkle proof for the block and creates a forest of merkle trees to model the whole UTXO set. So, each UTXO is a leaf on that tree. And then we also have CSNs, which are Compact State Nodes, which rely on proofs generated by the bridge. So, let’s say you mine a new block, the bridge will receive that. It’s going to add the UTXOs for the block on the tree and remove the UTXOs that were spent. And then, when a CSN receives a block, it doesn’t have a UTXO set. So, we can’t really validate the block without extra information. So, it asks for utreexo proofs from the bridge, which are just merkle inclusion proofs, so they can verify that those UTXOs that are being spent are actually in the UTXO set.

So, with these new batch releases, we are mainnet-compatible. There’s three BIPs for utreexo, which are BIPs #181, #182, and #183, using the P2P implementation that’s defined there. We also introduced SwiftSync. So, we have a huge problem that when a CSN is doing IBD (Initial Block Download), it needs to ask for a proof for each block, right? Those proofs represent almost 70% overhead. So, it’s a lot of data for you to download. So, with SwiftSync, you can cut that a lot, because we only need proofs from the height SwiftSync ends. And so, we cut back on a lot of data.

Floresta 0.9.0 released

And for Floresta, we recently swapped the old libsecp consensus for kernel, which is a lot better maintained and more performant. And we are doing a lot of work to get that production-ready.

Mike Schmidt: Maybe you can comment a little bit, you mentioned bridge nodes, you mentioned the compact state nodes; we have utreexod, we have Floresta. Which of those projects implements which of those types of nodes? And maybe you can just kind of connect the architecture that you outlined with these bridge and compact state nodes to these two pieces of software. Do they both implement both, or maybe explain that a little bit?

Luis Schwab: Yeah, so utreexod is a fork of btcd with utreexo support implemented. And Floresta is made from scratch. So, it’s a composable set of libraries that you can use to build nodes. We have like the main production node, which is florestad, which is built on top of those set of crates, but other people can use those crates to build nodes that fit their own application. So, you can embed a node inside a wallet, you can put it in a device, whatever you want. I’ve managed to compile Floresta to run on my router, so I have a node in my router. That’s just one of the possibilities of this.

Mike Schmidt: And if I’m running a bridge node, am I running utreexod, florestad, or I can run either, I can compose my own with the modular Floresta libraries, or how does that work?

Luis Schwab: No, so the only implementation of a bridge you have today is utreexod, and Floresta is an implementation of the CSN. But there’s nothing stopping you from making a bridge with Floresta. It’s just not a focus right now.

Mark Erhardt: Okay, just to recap. So, the main idea with utreexo is that we usually don’t want to trust other nodes for the validity of data. We just take the data from them and then verify everything ourselves on our nodes. And with utreexo, we prove that the data is correct and therefore we can just provide the proofs, or receive the proofs, validate the proofs, and then update our UTXO set representation, which is just a miniscule forest of merkle trees, to prove that a UTXO exists, and then with the updates, whether it got spent. And so, we’re talking about two pieces of software here that we have both updates for in the newsletter. One is utreexod, which I think is the more comprehensive implementation so far, that implements a so-called bridge node. The bridge node sort of does the legacy validation but then provides proofs. And Floresta is currently only a CSN that can process proofs and then update the representation, the forest of merkle trees of the UTXO set on its end. And that one is running in your router, right?

Luis Schwab: Yeah, that’s not exactly. So, the bridge keeps a forest of merkle trees representing each UTXO, and Floresta only keeps the roots of those trees. So, let’s say Floresta receives a block. It validates all the scripts, all the transactions, like any of our other nodes. We use the same consensus engine as Bitcoin Core. But it cannot verify that those UTXOs are indeed present in the UTXO set. So, it asks for a proof to the bridge, like, “Prove to me that these UTXOs are in the UTXO set”. So, with that inclusion proof, I can verify that the root hash is the same that I had.

Mark Erhardt: Right. That’s basically a merkle branch to one specific root in the forest. And because you have the roots of the merkle trees, you can now look at the right root attached to the merkle branch. And if that proof that was provided, all the hashing steps compute, then obviously the UTXO must be present in the tree.

Luis Schwab: Exactly. And the other point about wallet privacy data, this is one of the biggest points of this, because pretty much any wallet today just hits an API, like Explorer or Electrum, or whatever. With Explorer, we don’t have any guarantees about the data. Electrum can provide some inclusion proofs as well, but you’re still not verifying anything. And what’s huge about this is you can embed this into any application. So, let’s say you have a mobile wallet. You can have a node running there, it’s going to receive every block, it’s going to validate every block and let you be absolutely sure of the validity of the information.

Mark Erhardt: Right. Usually, thin clients can be lied to by omission. So, the server or other node that they’re getting data from can just tell them, “No, there’s nothing interesting for you here”, while there is maybe a UTXO or transaction that is relevant to the thin client. This is not possible in the utreexo model, because you can actually prove the existence of every UTXO. And you can actually also prove that something was spent by showing, if I remember – I read the BIP such a long while back, like half a year ago – if I remember correctly, all of the trees are sorted. And therefore, if you show the leaf that would be to the left of the one that you’re looking for and the leaf to the right of the one you’re looking for, and obviously the leaf for that UTXO is not present, you can even prove that a UTXO no longer exists with this model.

Luis Schwab: Yeah, and without mentioning the privacy concerns. Because when you’re using Stratum or Electrum, you’re hitting an API endpoint, you’re telling, “This is my address, and this is my IP”. With utreexo and Floresta, you remove that out of the equation completely, because you just act like a normal Bitcoin node on the network. There’s no honeypot indexing servers or anything like that.

Mark Erhardt: Right. And then, every transaction you process has to be translated by a bridge node, which then adds the merkle proofs for the UTXOs to the forest of merkle trees that we have the roots of. And therefore, basically you trade off compute and bandwidth for less data storage and more privacy.

Luis Schwab: Yes. And it’s super light, like takes 200 MB of RAM. We don’t keep any blocks, so we validate a block and throw it away. So, pretty much no storage as well. Also implements compact block filters, so we can do full scans backwards. So, it’s a pretty complete piece of software.

Mark Erhardt: Yeah, that sounds pretty awesome. Now, just to be clear, you said earlier, the bandwidth overhead for blocks is roughly 70%. So, while you’re catching up your node for a full archive node, you basically download 1.7 times as much data as the whole blockchain. How much do you download with the CSN? You must process the proofs in some way, I assume. Do you download all of that too?

Luis Schwab: So, you can choose to either download every block since genesis and validate them, then you’re going to have a huge bandwidth usage. But we can also do something called assumeutreexo, which is kind of like assumeUTXO, where you can export a height, a set of roots. You can start at some height and you can skip IBD. So, that’s the default on the binary. Every release, we make a new checkpoint and it’s going to automatically jump to that height. You can also sync from genesis. It’s going to take like just as much as Bitcoin Core takes. And you can also do something called backfill. So, you skip IBD and then you validate blocks backwards in the background. So, the node is up and running very fast.

Mark Erhardt: Cool, very nice. How closely do you work with the BIP authors? I’ve been hoping to get an update on the BIPs. They’ve been open for quite a while. They read very well in the last iteration already, but it seems like the software is coming out before the BIPs here.

Luis Schwab: Yeah. I work with them very closely. There’s still a lot of architectural decisions to be made, so we don’t want to drop anything too fast, you know, make it right.

Mike Schmidt: I think we covered both of those pieces of software pretty well. Luis, any calls to action for listeners in terms of testing, using, contributing, feedback, anything like that?

Luis Schwab: At the moment, I’d say run a bridge.

Mike Schmidt: How many people are running bridges these days and how do you quantify that being like a bottleneck?

Luis Schwab: I mean, right now, not a lot of people. I think not a lot of people know about this. There’s not really that much of a bottleneck right now, because we don’t have a lot of users, but it will be interesting to have more people running bridges so we can decentralize this kind of node running.

Mark Erhardt: That brings me to a follow-up question. I don’t know if you already stated that, but can the CSNs forward the proofs for blocks, or do the proofs always have to come from bridge nodes? So, would it be enough to have like a handful of bridge nodes and then the proofs propagate around the CSNs? Or do you actually need to have sort of a one-to-one relationship from every CSN to bridge nodes?

Luis Schwab: That’s in the plan, but not currently. We still need to implement proof-caching on the CSNs. But yeah, in the future, we only need like a few bridges for it to work. Because the idea is, I don’t know, like a CSN wants to broadcast a transaction, it’s going to cache the proof for its UTXOs, and then it attaches that to the transaction when it wants to broadcast, so nobody needs to ask a bridge for those proofs. But that’s not implemented yet.

Mark Erhardt: Maybe my antagonistic mindset is going a little too far, but how concerned would you be about the network splitting at the points of the bridges? If there’s only a handful of bridges, and I don’t know, maybe a weird transaction causes them to fail, wouldn’t that split off the entire utreexo subset of nodes? Have you guys been discussing that?

Luis Schwab: No, that doesn’t work, because CSNs can also talk to normal Bitcoin Core nodes. Like, most of the blocks will be fetched from normal Bitcoin Core peers. You only need the bridges for the proofs.

Mark Erhardt: But a CSN without the proofs cannot update the forest of merkle trees, right, because they don’t actually have the UTXOs, so they can’t construct the update? So, does it help them to get the legacy format blocks? Maybe I’m missing something here.

Luis Schwab: Yeah. In a sense they will be stuck, but there will not be a chain split.

Mark Erhardt: Oh, okay. So, you’re saying they would be aware that a new block has come and they are aware that they haven’t received the content of the block yet. And therefore, it would be hard to trick them, or they would sort of be able to at least realize that they should pause and wait – okay, I see.

Luis Schwab: They’re just going to work on the [inaudible] proofs. They’re not going to split to another chain, or anything like that.

Mark Erhardt: Right, okay. Thank you.

Mike Schmidt: Luis, thanks for joining us. We appreciate your time. We appreciate your work on this novel light client work and you’re free to drop, we understand if you have other things to do.

Luis Schwab: All right. Thank you guys.

Discussion of using nested MuSig2 in the Lightning Network

Mike Schmidt: Cheers. We’re going to jump back up to the News section. We have our first item, “Discussion of using nested MuSig2 in the Lightning Network”. This was a post by ZmnSCPxj, and if you are a listener of the show or reader of the newsletter, you know that his proposals can get somewhat technical. Unfortunately, he wasn’t able to join us today, so Murch and I are going to try to give an overview of it, and maybe we can touch base with him at some point in the future on this, when we have him on for other discussions. But he posted to Delving Bitcoin, “Towards a K-of-N Lightning Network node”. And in it, he sort of poses this question, “Can we make a multisig self-custodial wallet with Lightning Network integration?” He puts forth the use case of someone who owns bitcoin and maybe wants to use it to generate routing fees on the LN, but somebody who owns bitcoin doesn’t really want to give away their bitcoin for someone to operate that. And so, he comes up with this idea, “Hey, can we make signing on the LN K-of-N so that the owner can have some keys”, maybe there’s some other operator that’s doing the routing or some such thing, or even if they’re just doing it themselves, they can not have it all in one key. And so, he’s building on this idea of nested MuSig2, which I think was a paper from a couple of months ago. He touches on FROST as well to be able to achieve this.

But he brings up in this post that there is part of the BOLT specification that might need to change in order to enable this. And this is part of the LN spec that has to do with the shachain, which is how revocation keys are handled. And maybe, Murch, you can bail me out with this, but that needs to be modified to be optional. So, I think there’s an optimization there, so you don’t need to hold all the past revocation keys. And that optimization is sort of incompatible with this k-of-n signature scheme that he’s proposing. So, he’s proposing to make that piece of the spec optional so that maybe there could be these sorts of channels in the future. There’s more work to be done, but that’s what I took away from the post.

Mark Erhardt: Okay, maybe a couple comments first. The idea here is to make one of the two sides in the channel k-of-n. The channel in principle is already 2-of-2, but then one of the two out of the 2-of-2 would be a k-of-n under the hood. And from reading this post, or rather the news item here, my understanding is that the way that the state progression in the channel is managed usually, you get a new sort of step in a chain of secrets that depends on the previous. And for some reason, this is difficult to do when you don’t have a single key but multiple involved keys, because it’s derived from key material. So, if the key material is distributed, I think you can’t have this shachain, and that’s where that is coming from, is my understanding here.

So, the problem basically seems to be if you have a 2-of-3 onchain wallet on the other end, you can’t easily just plug the construction into the Lightning channel on that side, because other things in how the Lightning channel is managed depend on there being a single key and being able to derive information from the private key material.

Mike Schmidt: Yeah, so a bunch of different pieces of technology. So, there’s part of the LN spec here; we’re talking about MuSig2; he mentions in order to get the k-of-n features, we’re talking about FROST. So, there’s a lot of big-picture moving pieces here. For folks who are curious about the details, obviously jump into the Delving Bitcoin post, because I’m sure we did not fully do this idea justice, and so you all can explore maybe on your own some of the details. Murch, anything else you’d like to say about this item?

Mark Erhardt: Sorry, I wanted to add a little more. So, generally, I think ZmnSCPxj has been writing about several of these ideas before. So, he has written about channel factories before. He had another proposal that proposed a sort of Lightning channel battery that was shared between multiple large entities and was essentially a single, much more slowly-updating shared channel between many parties. So, the idea was that these large holders might have channels crisscrossing between each other, but then they would have one big UTXO that they have shared control of that uses a different scheme than Lightning, that they could reassign the payout from in order to rebalance their network of channels among each other on a maybe once-per-day basis. So, this at least contextually fits with the other proposals that ZmnSCPxj has been thinking about. I think that all of these would still benefit from ideas like TEMPLATEHASH or ANYPREVOUT (APO) as a predecessor to achieve LN-Symmetry and/or other covenant proposals that would make them much more interactive or more powerful.

I think ZmnSCPxj’s background idea in this context is that he thinks it’s unlikely for such a covenant proposal to be adopted, and therefore comes up with constructions that can work under the current existing consensus rules. But they tend to be a little more complicated, involved, and highly interactive in order to work around the non-existence of these covenant proposals.

Coldcard 6.5.0 adds MuSig2 and miniscript

Mike Schmidt: Back down to our monthly segment, we have Coldcard 6.5.0. And this release has a few different things that we noted. One is the ability to sign MuSig2 UTXOs. There is also a feature around signed message, BIP322, for proof of reserves for miniscript and MuSig2 UTXOs. There’s also new support for miniscript and mini tapscript; taproot spending, signing, multisig; tapscript up to 8 leaves. BIP129, which is the Bitcoin Secure Multisig Setup (BSMS) is also added in terms of support. And so, it feels like a larger-than-normal Coldcard release and some good Bitcoin tech in there.

Frigate 1.4.0 released

Frigate 1.4.0 released. We covered Frigate in a previous newsletter, that was #389, and we’ve had Craig Raw on as well. But Frigate is essentially an Electrum server, which is basically a backend for silent payment scanning. And we talked with him a little bit about GPUs and some of the performance that I think he squeezed out of that. I don’t remember if we talked with him or if we talked about it, but we covered that in the show previously. But with 1.4.0, it sounds like Frigate is now using this UltrafastSecp256k1 library in addition to the GPU computation. And I think it’s like 14 times faster using that library. So, I’m unsure the details of those optimizations. I’ve seen this library talked about in Delving, but I didn’t dive into it, until this is the first time I’ve seen someone using it. So, that’s interesting. Murch, did you get a chance to look at this?

Mark Erhardt: A little bit. So, I saw some discussion about this library, and I sort of want to comment on the trade-offs here. Basically, this is a reimplementation of libsecp with a ton of LLM-assisted improvements and speedups, and so forth. So, I would say that from a level of review, it would obviously be much less trusted than libsecp, which is extremely well vetted and has a lot of people looking at it. This is an almost completely new library that has some, I don’t know, tens of thousands of lines of code that were output by a single developer with assistance of, well, according to himself, I think, with the assistance of LLMs. So, the goal of this one is to be very, very fast. And so, the trade-off, I think, that is attractive here is when you’re only doing validation work and not, for example, signing transactions and sending funds, this library could be very interesting in order to do the validation more quickly, which is what Frigate is using it here for. And in that case, maybe you’re a little less worried about bugs or correctness or unvetted code, because you’re only validating and you’re reading data, not creating data. So, maybe in this context, this is a good fit.

I’ve also seen that Toby Sharp, the Hornet Node developer, was interested in seeing how quickly Hornet Node would perform if it used UltrafastSecp256k1 instead of libsecp. So, yeah, this is, on the one hand, a very interesting and useful effort to have such a fast library. But on the other hand, it’s probably not something that will get adopted quickly on the wallet side of libsecp usage, where people might be much more interested in it taking its time, but being secure, and not having side channels, having constant time implementations, and so forth.

Mike Schmidt: Yeah, I know some of the Delving posts around this library were seeking feedback, and I think one of the pieces of feedback was, “Hey, this is tens of thousands of lines of cryptographic type code, and it’s going to be hard to get feedback on a huge chunk of that”. Like you mentioned, maybe there’s a use case for something that’s faster and isn’t necessarily the wallet itself, and so maybe this thing will evolve over time and get more eyeballs on it due to its usage.

Mark Erhardt: I think one of the interesting things might be if you have a highly vetted piece of software like libsecp, you might be able to do some cross-implementation fuzzing that verifies that the results of another implementation matches exactly. So, I don’t know, maybe the implementer could look into some fuzz comparison throwing the same fuzz inputs against libsecp and UltrafastSecp256k1, and seeing that it matches in results all across.

Mike Schmidt: Yeah, I wonder if bitcoinfuzz, which I think is differential fuzzing, could do something like that. I’m not sure if they’re fuzzing libsecp currently. But yeah, interesting idea to piggyback on the correctness of one and use the speed of the other. Cool.

Bitcoin Backbone updates

And our last piece of software in the monthly segment was Bitcoin Backbone updates. There were two posts to the Bitcoin-Dev mailing list about updates to Bitcoin Backbone. This is a piece of software we covered a few months ago that is building a node on top of Bitcoin Kernel. And the developer posted to the mailing list about two updates. One was around compact block support, another one around multiprocess improvements, and a little bit of under-the-hood work. But I thought it was interesting. Obviously, there’s Kernel involved here, we’re talking about compact block support, and yeah, I think it’s an interesting proof of concept, interesting prototype that people might want to poke at.

We can jump to the Releases and release candidates and can bring in Gustavo who’s authored this, as well as the Notable code segment.

Bitcoin Core 31.0rc4

Mark Erhardt: Bitcoin Core version 31 has been released on Sunday, I think, the 19th. So, we’ll probably be reporting more deeply on the content of the 31 release next week. And then, Gustavo seems to be back and we’ll do Core Lightning.

Core Lightning 26.04rc3

Gustavo Flores Echaiz: Yeah, thank you, Murch. Sorry for the technical issues. So, yeah, so this week we have two releases which are two RCs from Bitcoin Core 31 and Core Lightning 26.04. Both of these have now been released fully, so in the next newsletter we’ll cover their full release. I just want to point out, if someone’s interested in more details around the Bitcoin Core 31 and specifically the testing guide for the RC, we did dig into that in the podcast related to Newsletter #397; and Core Lightning 26.04 was at its third RC when we wrote this past newsletter, but we first covered it in the Newsletter and the Episode #398. So, we do go into more detail in those episodes, but we’ll have more news for people on the next newsletter and the next episode when we cover the full versions, not just the RCs.

I just want to say that the Core Lightning (CLN) release was very much focused on splicing. So, now that splicing has been merged in the BOLTs repository, CLN has made many upgrades around its implementation, one which we’ll cover in the Notable code and documentation changes section. Awesome.

Bitcoin Core #34401

So, we move forward with that section. This week, we have two items for Bitcoin Core. The first one, #34401, is the extension in the libbitcoinkernel API that we’ve covered multiple times, specifically in Newsletters #380 and #390. So, the support for obtaining block headers through that API interface, which was added in Newsletter #390, is now extended by adding a method that serializes a block header into its standard byte encoding. So, initially, after Newsletter #390, you could have used this block header support, but you weren’t able to obtain it in a serialized format into its standard byte encoding. So, you would need external serialization code if your external program wanted to store, transmit, or compare a serialized header. Now, this is no longer required, and you can just use this method to leverage that. And why would someone want to do that? The practical example is that once you serialize the header through the API, you could feed those bytes to hash the header to obtain the blockhash. So, you don’t need an external program that leverages the libbitcoinkernel API to have separate serialization code; it can just simply use this API through its new method to get the standard byte encoding of a block header and use it for computing a blockhash, for example.

Bitcoin Core #35032

The next item, #35032, here there’s work being done on a feature that was introduced in Newsletter #388 called the privatebroadcast option, which allows users to broadcast transactions through short-lived Tor or I2P connections, or through the Tor proxy to IPv4 or IPv6 peers. The goal here is for Bitcoin Core to open a short-term connection, broadcast a transaction, and then close that short-term connection. However, the issue was that potentially, when using the private broadcast through those short-lived connections, some peer addresses learned could then be added to Bitcoin Core’s peer address manager. So, what this new item does is that it basically ensures that it will never store a network address learned when using the privatebroadcast option, it will never store it in the address manager, so that this feature not only hardens the privacy of this feature, but now all the information learned through these short-lived connections is isolated from the rest of your normal usage.

Mark Erhardt: That was one of the things that I was curious about. So, if we only do a version handshake, send our single transaction ping and pong and then disconnect, I think what we’re not doing is asking for addresses from that peer. And I was sort of wondering, from my understanding, that we shouldn’t be usually getting any addresses from that peer in that period of time. It would sort of be an unexpected behavior of the counterparty, the peer that we’re connecting to, that they send us any addresses. Or it might be referring to if this node were in our unknown table and we connect and we find a peer there, we would add it to the tried table so that it would be an update of the specific peer that we actually connected to that gets updated. But I even just went over the PRs. I couldn’t really see where we should ever expect to learn addresses. So, if you know what I’m missing there, please fill us in. Otherwise, maybe our listeners can tell us on Twitter, or somewhere.

Gustavo Flores Echaiz: Yeah, to be fully honest, I reached that blocker too, so it wasn’t clear to me either. At first, I thought it was the new short-lived identity that you gain would be added in the address manager, but then the PR description basically makes you think that it’s about peer addresses that are learned through that connection. So, yeah, I would then say that if someone’s listening and knows the answer, that’d be great because, yeah, it’s not super-clear exactly. It probably is just a fail-safe to make sure that it would never happen, even if it’s just not normal behavior. At least, from the description and the discussion in the PR, it seems to just be a preventive measure that doesn’t necessarily happen in a regular flow. But yeah, if someone knows the answer, we’d love to learn more about that.

Core Lightning #9021

Moving forward with CLN, two new items are from CLN this week. The first one is the enabling of splicing by default by removing it from the experimental status. So, when I was covering earlier the Release section, I mentioned a few changes around splicing. So, splicing is now considered fully default and production-ready on CLN. And if you want to learn more about the merging of the splicing protocol into the BOLT specification, or the work that CLN splicing implementation did at the same time that the splicing protocol was merged in the BOLT specification, Newsletter #398 and the accompanying podcast episode, we invited Dusty from the CLN team to basically tell us about both the work done in the splicing protocol LN specification and on CLN that was fully attached to it. So, that episode has more details around that. But for now, we can say that CLN, probably in preparation for this 26.04 release, now considers splicing a default feature and a production-ready feature.

Core Lightning #9046

Next, Core Lightning #9046. Here, there was some interoperability issue between the keysend implementation between CLN and LDK, where LDK was expecting a final_cltv_expiry value, or the CLTV expiry delta, for the last hop to be 42 when receiving a keysend payment. CLN, however, was sending a 22 value when sending a keysend payment. What would happen is that LDK would simply refuse to receive a keysend payment sent from a CLN sender, because CLN uses simply a different value than LDK. And this value is the safety margin for the recipient on the last hop. So, if something were to fail, it would still have enough time to claim the HTLC (Hash Time Locked Contract) onchain if the upstream counterparty became unresponsive and an onchain resolution was needed. So, LDK was basically just telling CLN, “This is not enough time for me as a receiver to handle this edge case”. So, now CLN raises this value so it matches LDK’s, and now keysend payments are fully interoperable between these two implementations.

LDK #4515

The next two are from the LDK repository. So, a pattern in this newsletter is that there are multiple features that have switched from experimental status to production feature status. That was the case for splicing in CLN, and is now also the case for zero-fee commitment channels on LDK. So, the feature bit is promoted from the experimental to the production feature bit. We covered in Newsletter #371 LDK’s initial implementation of zero-fee commitment channels, which replaced the two anchor outputs from regular anchor channels with one shared P2A output that has a zero-fee value, because we cannot predict the onchain fees required in advance. So, this makes it more flexible and modular for future fee conditions. So, LDK is the first implementation to not only implement the zero-fee commitment channels feature, but also to promote it to a production feature bit. However, when other implementations would be ready to move to that production feature bit, they could be interoperable with LDK.

LDK #4558

The next one on LDK, #4558. Here, something called a receiver-side timeout that is present in multipath payments (MPPs) is now extended to also cover keysend payments. So, basically, when you send an MPP, if one of the multiple parts fails to reach the destination, the receiver can have a timeout where it will fail back all the different HTLC parts back to the sender after it has reached a timeout, so that it can avoid having HTLC slots tied up and consumed. However, this wasn’t properly implemented in keysend payments, so an LDK node that would receive a keysend payment that used the MPP method, if one of the multiple parts was stuck, then the sender would have to wait until the final CLTV expiry for those HTLC slots to be freed up again. So, now the receiver-side timeout, which was already present in other forms of transactions that use MPPs but not keysend payments, is now extended to cover keysend. So, now a receiver can always fail back those HTLCs and free up HTLC slots, instead of having to wait for a longer period until the CLTV expiry timeout.

LND #9985

So, the next one, LND #9985, is also, like I said, part of the similar pattern where things are getting promoted to production feature bits. So, in this case, it’s simple taproot channels, which are promoted to the production feature bits with a distinct commitment type called SIMPLE_TAPROOT_FINAL. So, there is an optimization around the tapscripts that are used for these types of channels, which will now use OP_CHECKSIGVERIFY instead of a mix of OP_CHECKSIG and OP_DROP. There’s also another improvement, something called map-based nonce handling, that are keyed to the funding transaction IDs. So, basically, as we’ve discussed in previous episodes and newsletters, the simple taproot channels that are funded through a MuSig2 wallet, they have to change nonces every time they sign off a different funding transaction. There’s more interchange in the nonces being used on MuSig2 channels. So, every nonce has to be properly mapped to a different funding txid as groundwork for future splicing.

So, this promotion to production doesn’t just come with a new feature bit, it also comes with an optimization on the tapscript that is being used; but also, just properly better mapping between the nonce handling and the funding txid as groundwork for future splicing. So, we can probably expect splicing on simple taproot channels to be follow-up work in LND from this. But yeah, this basically is the third promotion to production feature in this newsletter: splicing in CLN; zero-fee commitment channels in LDK; and now, simple taproot channels in LND.

BTCPay Server #7250

The next one is an addition in BTCPay Server, PR #7250, where LUD-21, LUD being the LNURL spec, so support for LUD-21 is added, which basically means an unauthenticated endpoint, or an endpoint that doesn’t require authentication, named verify, that allows an external service to verify whether a BOLT11 invoice created via LNURL-pay has been settled. So, as a sender, I have the preimage after I’ve sent a payment, and I can verify that I sent a payment. However, if I’m, let’s say, a website that is feeding a BOLT11 invoice on behalf of a receiver, I might not have full confirmation that the payment was settled. I’m not the sender, so I don’t get the preimage. So, this endpoint allows an external service to get a confirmation from a Lightning node behind a BTCPay Server instance, that a BOLT11 invoice created via LNURL-pay has properly been settled, even if I’m not the sender or the receiver, I’m just an external service working or providing invoices on behalf of the receiver.

Mark Erhardt: This one’s interesting because some of the very early websites that used Lightning payments, I think there was a demo of a forum-like construction or blogging website called htlc.me very early on, 2017, 2018; and what they did was basically just, when the person that was trying to read the article had paid the invoice, they would show the proof of payment, the preimage that they received back from settling the payment, and then forward that to the browser, and the user would be able to see the content. Of course, that meant that now, also the website could basically prove that it had paid the invoice because it also had the preimage. And with this new approach, you sort of get a different way. You now trust the server to say, “Yeah, this has been paid and you can serve the content”, without having to forward the preimage and giving the proof out of hand that you paid the invoice. Although, of course, most of the time it just matters whether something was paid or not, not that you can prove that you were the one that paid it. So, an interesting addition here.

Gustavo Flores Echaiz: Yeah, certainly. I haven’t seen it being implemented in other instances. I think BTCPay Server must be one of the first to implement such a feature. So, yeah, definitely interesting.

BIPs #2089

So, the next and the final item is the PR #2089 in the BIPs repository, which publishes BIP376, which defines new per-input fields on PSBTv2 to carry BIP352 tweak data needed to sign and spend silent payment outputs. So, this complements BIP375, which we had covered previously, I believe, in Newsletter #337, that basically allowed or specified how to create silent payment outputs using PSBTs. So, BIP376 is a natural follow-up and the completion to be able not only to create silent payment outputs using PSBTs, but also to be able to sign for them and spend them using PSBTs as well. Murch?

Mark Erhardt: Yeah, so PSBTs, or Partially Signed Bitcoin Transactions, are always employed when you either have multiple devices involved in creating a transaction or even multiple senders participating in creation of a transaction. So, we already had a specification for how to facilitate a multi-user transaction that pays to silent payments, which is BIP375. And now, we also have a specification for how to implement spending silent payment inputs, right? So, obviously you need a bunch of data about the previous transaction in order to be able to construct a silent payments input. And then, to have the silent payments input exist next to other inputs requires some additional information. Yeah, this has been coming for a while; finally out there. If you’re a wallet developer that is working on payjoin and wants to support silent payments, I think now that sort of stuff is ready. So, maybe take a look.

Gustavo Flores Echaiz: And there’s been so many different BIPs related to silent payments, right? The first one, BIP352, which defines silent payments. But then, BIP375, that basically defines how to send silent payments or create outputs, is preceded by BIP374, which defines how to create the discrete log equivalency proofs that are required for that. But then, there’s also BIP392, which describes the descriptor format, and now we have BIP376, which defines how to sign and spend those outputs. Would that be the complete full picture, or is anything else needed to implement silent payments?

Mark Erhardt: I think it’s pretty much the complete picture, especially if we have additional software, like Frigate, that can allow light clients to more easily catch up with the silent payments information. There are also, I think, four or five silent payments implementations already in production use. So, I assume that they are not PSBT-compatible yet, and I haven’t really got full information right here what exactly they all support and whether they can, for example, do multi-user transactions or anything like that in general, just not for silent payments. But I think that should be all of the necessary parts to sort of get silent payments in, multi-user transaction silent payment support for thin clients. And basically, just I’m still excited to see it also come out in Bitcoin Core. Hopefully, that’s going to be something that happens this year or next year. But anyway, yeah, I think this is all, from the top of my head.

Also, maybe the sending to silent payment outputs is the more complicated part. So, BIP375 needed the proofs to make sure that the other signers participated honestly, otherwise you could basically accidentally create, or intentionally create, outputs that burn funds instead of being spendable. The using of inputs is not as complicated, because only the party that owns the silent payments input has to do special work there. When you send to it, all of the inputs are involved in the creation of the output. So, there, you need participation of all the input contributors.

Gustavo Flores Echaiz: Thank you, Murch. Yes, and that completes the newsletter.

Mike Schmidt: Thanks, Gustavo and Murch. And we also want to thank Luis for joining us earlier, as well as Remix, and for you all for listening. Thanks for your time. Cheers.

Bitcoin Optech Newsletter #401

2026-04-17T00:00:00+00:00

This week’s newsletter describes an idea for nested MuSig2 Lightning nodes and summarizes a project formally verifying secp256k1’s modular scalar multiplication. Also included are our regular sections describing recent changes to services and client software, announcing new releases and release candidates, and summarizing notable changes to popular Bitcoin infrastructure software.

News

● Discussion of using nested MuSig2 in the Lightning Network: ZmnSCPxj posted to Delving Bitcoin about the idea to create k-of-n multisignature Lightning nodes by leveraging nested MuSig2 as discussed in a recent paper.

According to ZmnSCPxj, the need for a k-of-n signature scheme in Lightning derives from large holders wanting to provide their liquidity to the network in exchange for fees. Those large holders may need strong guarantees on the safety of their funds, which a single key may not grant. Instead, a k-of-n scheme would provide the required security as long as less than k keys are compromised.

As of today, the BOLTs specifications do not allow for a secure way to implement a k-of-n multisig scheme, with the main obstacle being the revocation key. According to the BOLTs, the revocation key is created using a shachain, which, due to its characteristics, is not suitable for use with k-of-n multisig schemes.

ZmnSCPxj proposes a modification to the BOLTs specifications to make it optional for nodes to perform shachain validation of revocation keys from channel parties by signaling a new pair of feature bits, named no_more_shachains, in both globalfeatures and localfeatures. An odd bit would signal that the node will not perform shachain validation on the counterparty, while still providing shachain-valid revocation keys to keep compatibility with legacy nodes. An even bit would signal that the node will neither validate nor provide shachain-valid revocation keys. The former bit would be used by gateway nodes, as ZmnSCPxj defines them, which would connect the rest of the network to the k-of-n nodes, those featuring the even bit.

Finally, ZmnSCPxj emphasizes how this proposal would present a major trade-off, namely the storage requirements for revocation keys. In fact, nodes would be required to store individual revocation keys instead of the compact shachain representation, effectively tripling the on-disk space needed.
● Formal verification of secp256k1 modular scalar multiplication: Remix7531 posted to the Bitcoin-Dev mailing list about formally verifying secp256k1’s modular scalar multiplication. The project demonstrates that formal verification of a subset of bitcoin-core/secp256k1 is practical.

In the secp256k1-scalar-fv-test codebase, Remix7531 takes real C code from the library and proves it correct with respect to a formal mathematical specification using Rocq and the Verified Software Toolchain (VST). Formalization with Rocq can prove the absence of memory errors, correctness against a specification, and termination.

He plans to port the existing scalar multiplication proof to RefinedC, which would give a direct comparison of both frameworks on the same verified code. Also, on the verification side, the next target is Pippenger’s algorithm for multi-scalar multiplication, which is used for batch verification of signatures.

Changes to services and client software

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

● Coldcard 6.5.0 adds MuSig2 and miniscript: Coldcard 6.5.0 adds MuSig2 signing support, BIP322 proof of reserve capabilities, and additional miniscript and taproot features including tapscript support for up to eight leaves.
● Frigate 1.4.0 released: Frigate v1.4.0, an experimental Electrum server for silent payments scanning (see Newsletter #389), now uses the UltrafastSecp256k1 library in conjunction with modern GPU computation to reduce scanning time for a few months of blocks from an hour to half a second.
● Bitcoin Backbone updates: Bitcoin Backbone released multiple updates adding BIP152 compact block support, transaction and address management improvements, and multiprocess interface groundwork (see Newsletter #368). The announcement also proposes Bitcoin Kernel API extensions for standalone header verification and transaction validation.
● Utreexod 0.5 released: Utreexod v0.5 introduces IBD using SwiftSync which uses cryptographic aggregation to eliminate the need for downloading and verifying accumulator inclusion proofs during IBD, and eliminates the extra data downloaded by Compact State Nodes during IBD from 1.4 TB to ~200 GB, with further reductions possible through proof caching.
● Floresta 0.9.0 released: Floresta v0.9.0 aligns its P2P networking with the BIP183 for UTXO proof exchange, and replaces libbitcoinconsensus with Bitcoin Kernel for approximately 15x faster script validation, among other changes.

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.0rc4 is a release candidate for the next major version of the predominant full node implementation. A testing guide is available.
● Core Lightning 26.04rc3 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.

Notable code and documentation changes

● Bitcoin Core #34401 extends the btck_BlockHeader support added to the libbitcoinkernel C API (see Newsletters #380 and #390) by adding a method to serialize a block header into its standard byte encoding. This allows external programs using the C API to store, transmit, or compare serialized headers without needing separate serialization code.
● Bitcoin Core #35032 stops storing network addresses learned when using the privatebroadcast option (see Newsletter #388) with the sendrawtransaction RPC in addrman, Bitcoin Core’s peer address manager. The privatebroadcast option allows users to broadcast transactions through short-lived Tor or I2P connections, or through the Tor proxy to IPv4/IPv6 peers.
● Core Lightning #9021 enables splicing by default by removing it from experimental status, following the merge of the splicing protocol into the BOLTs specification (see Newsletter #398).
● Core Lightning #9046 increases the assumed final_cltv_expiry (the CLTV expiry delta for the last hop) for keysend payments from 22 to 42 blocks to match LDK’s value, restoring interoperability.
● LDK #4515 switches zero-fee commitment channels (see Newsletter #371) from the experimental feature bit to the production feature bit. Zero-fee commitment channels replace the two anchor outputs with one shared Pay-to-Anchor (P2A) output, capped at a value of 240 sats.
● LDK #4558 applies the existing receiver-side timeout for incomplete multipath payments to keysend payments. Previously, incomplete keysend MPPs could remain pending until CLTV expiry, tying up HTLC slots instead of failing back after the normal timeout period.
● LND #9985 adds end-to-end support for production simple taproot channels with a distinct commitment type (SIMPLE_TAPROOT_FINAL) and production feature bits 80/81. Production uses optimized tapscripts that prefer OP_CHECKSIGVERIFY over OP_CHECKSIG+OP_DROP, and adds map-based nonce handling on revoke_and_ack keyed by funding txid as groundwork for future splicing.
● BTCPay Server #7250 adds LUD-21 support by introducing an optional unauthenticated endpoint named verify that allows external services to verify whether a BOLT11 invoice created via LNURL-pay has been settled.
● BIPs #2089 publishes BIP376, which defines new PSBTv2 per-input fields to carry the BIP352 tweak data needed to sign and spend silent payment outputs, plus an optional spend-key BIP32 derivation field compatible with BIP352’s 33-byte spend keys. This complements BIP375, which specifies how to create silent payment outputs using PSBTs (see Newsletter #337).

Bitcoin Optech Newsletter #400 Recap Podcast

2026-04-14T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Julian Moik to discuss Newsletter #400.

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.

Bitcoin Core PR Review Club

● Testing Bitcoin Core 31.0 Release Candidates (29:00)

Notable code and documentation changes

● Bitcoin Core #33908 (31:56)
● Eclair #3283 (37:06)
● LDK #4529 (38:12)
● LDK #4494 (39:55)
● LND #10666 (45:31)
● BIPs #2099 (46:40)
● BIPs #2118 (1:15)
● BIPs #2134 (51:08)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #400 Recap. A little bit of a numerical milestone for us; 400 of these over the last eight years. And so, welcome to the Recap. We’re happy about that milestone and today we’re going to be talking about, we have a Bitcoin Core PR Review Club. Finally, those are back after a few months hiatus, talking about the Bitcoin Core 31.0 RC testing. We have our Notable code and documentation changes, including a GSR-related BIPs merge that we’re going to get into right off the bat here. This week, Murch, Gustavo and I are joined by Julian. Julian, you want to introduce yourself for people?

Julian Moik: Sure. Hi, everyone, thank you for inviting me. Yeah, I’m Julian, I’ve been working on script restoration with Rusty Russell for about the last year. And we finally managed to publish two of the draft BIPs, which are often referred to as script restoration or GSR, Great Script Restoration. And yeah, happy to be here.

BIPs #2118

Mike Schmidt: Awesome. Well, we’ll jump right into that item. For listeners, we’re jumping down to BIPs #2118, covering BIP440 and BIP441 being formally published in the Bitcoin Improvement Proposal repository. We covered these last week briefly when Rusty Russell announced them. That was in #399. These are two, I believe, of potentially four BIPs that could be rolled into GSR, and maybe Julian can walk us through these two and what isn’t included in these two as well, and maybe as an easy lead-in question, GSR, Great Script Restoration, Grand Script Renaissance, what are we going with here, Julian?

Julian Moik: I usually just like to refer to script restoration.

Mike Schmidt: Okay, script restoration.

Julian Moik: I think that’s pretty clear, but it’s nice to have these fancy names on it.

Mike Schmidt: All right, so what’s in BIP440 and BIP441 for script restoration?

Julian Moik: Yeah, I can give a quick rundown of the first BIP, which is now labeled BIP440. It describes a computational budget for a Bitcoin Scripting language. And so, it takes this existing sigops budget, that just limits the amount of signature verifications that you can put into a block, and it generalizes that concept so that it applies also to other operations. So, not only are signature verifications computationally expensive, but another good example that I like to give is also hashing functions. They can also be slow, and currently there is no explicit limit on that. So, you could argue even that for the current state of script, it would make sense to extend that sigops budget into a budget that also includes hash functions. It’s currently not really an issue that there is not this hashing budget, because we have a block size limit, we have quite strict stack limits, which just prevent construction of blocks that would be too slow to validate. But still, we only have those size limits, and you could imagine that in the future, we might have opcodes that are more computationally dense than we have now. In this case, we might need other limitations besides the block size alone.

The varops budget, it really tries to establish a framework for computational cost, and it can be seen as a foundation for future upgrades, like adding new opcodes, which then need that computational restriction. That would bring me to the second BIP.

Mike Schmidt: Maybe a quick question. Could the varops budget apply just even if you didn’t have 441 or any changes to script; that’s something that could be applied in consensus?

Julian Moik: Yeah, you could potentially restrict the current state of script. I guess it’s a little bit complicated with legacy script and then you have, well, really in GSR, we introduce a new tapscript version and we don’t even touch the original leaf version. So, we try to not change it at all. And I don’t think it’s really useful to have that with our GSR. It’s like a prerequisite of restoring scripts.

Mark Erhardt: I believe, having read it a few times, but obviously not being an author, I believe that it is backwards compatible in the sense that per the varops pricing, all the existing prices are limited by the varops budget, either to the same extent or more leniently. So, I think that in conjunction with the existing limits that also exist for the new introduced stuff, it is not a change at all for the existing scripts.

Julian Moik: It was initially Rusty’s idea that we define the hashing costs such that basically, existing functionality is unchanged. But we had to increase that cost based on benchmarking results. And so, now this might not be true anymore. So, you could probably find a case that would exceed the varops budget if you just use hashing.

Mark Erhardt: Oh, so it is more restrictive than the existing budget in some cases?

Julian Moik: It’s only the sigops budget currently. So, yeah, definitely.

Mark Erhardt: Right. So, sorry, in tapscript v2, which we will get to in a moment, the old things that were possible in tapscript v1, some of those might not be possible under the new rules because the varops is more restrictive than previous. So then, answering Mike’s question, it would be possible to introduce it. It only really makes sense in conjunction with BIP441, but it’s a soft fork and backwards compatible in the sense that it’s just more restrictive.

Julian Moik: Yes, exactly. But you would actually have to really try to hit the limit. The limit is quite high. But if you really try it, you could craft a script that would fail.

Mike Schmidt: Okay, so maybe we can move to BIP441 and what would be in there; and then, what would be in there that would necessitate a varops budget?

Julian Moik: Yeah, there are several changes included and they all have that aim of making script more expressive. So, this is really the idea here. We want scripts to have those basic building blocks which are general and not super-specific to any use case. And I think this is a big contrast to most other proposals, that we just want to provide primitives and not be so specific about it. And yeah, for once what is included is the restoration part. So, we have those 15 opcodes that were disabled in a very early version of Bitcoin in 2011 by Satoshi still. And the concern back then was that you could basically use some operations, like left shift, to create very large stack elements. And there were no limits in place, so you could just overflow the memory of nodes quite easily, making that node crash and really making the complete network crash just with a single transaction that would cause a stack overflow. And yeah, this led to this disablement of all 15 of these opcodes. And now, the script interpreter still has this code branch where it checks, okay, are we currently evaluating any of those 15 opcodes? And if so, we throw that script error, the opcode is disabled. And I always thought it was kind of weird to have that section in the code. It just hasn’t been touched for, like, 15 years now.

These opcodes, you can categorize them into three distinct categories. So, the first one would be splicing. So, if you take a stack element, you would like to maybe just take a part of it. You take an element, maybe you just want the first 4 bytes of that. So, you could do that with OP_LEFT, for example. You could do the same on the right side. Also, you have concatenation, which is probably the most famous of the opcodes. It just concatenates the top two elements. Then the next section is bitwise logic. So, also very fundamental operations, just AND, OR, XOR, and bitwise inversion of an stack element. And the last section is arithmetic, which basically boils down to multiplication and division. So, these are all things we cannot do right now in script. And yeah, this is really the big change, I would say.

There are some other changes. One is the number type. Currently, we use a signed 32-bit integer. So, you have positive values and negative values. And the BIP proposes an unsigned bignum integer. So, this is like an arbitrary length number which can grow arbitrarily large, basically. And the reason for that is, maybe for the sign first, the reason is you don’t really have negative values in Bitcoin. So, the negative part, to my knowledge at least, was mostly like wasted space. And we would also like to just represent larger numbers. Because of the 32-bit integer, you cannot even go up to the maximum number of coins. So, you have this new number type, and then it also loosens some kind of arbitrary script limits. So, you have the stack size, so the maximum number of stack elements that you can push. This one is loosened, and also the maximum size of the individual stack elements. So, this currently sitting at 520 bytes. So, just removing some of these arbitrary restrictions and, yeah, they all just aim to make scripts a more expressive language.

Mike Schmidt: Those restrictions you mentioned, that’s different than what was around in 2010. So, that’s unrelated to the change that Satoshi made back then. But all of these opcodes, these are the exact same set of opcodes that were disabled in 2010, or is there some that don’t overlap?

Julian Moik: Those are exactly those 15. And yes, you could potentially argue that maybe we don’t need all of these 15, maybe we want something slightly different. The thing is, basically you have these opcodes already in the codebase and they have their opcode number, and you would just have to re-enable them. You would not have to use a no-op, or however you want to add new opcodes, it’s a little bit more complicated for operations that haven’t been in there. So, yeah, this is just the idea. But you could totally argue that maybe we don’t need an LSHIFT, for example, because you can do that with multiplication already.

Mark Erhardt: So, to be clear, the reasons why Satoshi stated that opcodes were disabled back then were the concern of DoS. So, all of these limits that are being introduced with the varops budget and this loosening of other limits is very much in line with this. Basically, I think there was one bug discovered in one of these 15 opcodes in how it was implemented back then in the codebase. And basically, Satoshi presumably felt that he didn’t have a lot of time to react, and just disabled a bigger number of opcodes at the same time that could either have vulnerabilities or could have a DoS vector potential. And what I perceive this proposal now to do is explore to a much bigger extent what exactly the DoS vector surface is, what limits are necessary, what sort of computational footprint is acceptable, and gives a framework to re-enable the previously existing opcodes in a way that would be computationally safe in the Bitcoin Stack.

Julian Moik: Yeah, that’s a really good summary.

Mark Erhardt: And because re-enabling disabled opcodes would be a hard fork, introducing a new version of tapscript, that is previously completely undefined and therefore everything is allowed, allows you to have a bigger set of opcodes by restricting it from anything goes to just tapscript v2.

Julian Moik: Right, yeah, this is how I understand these leaf versions. They are really designed to have future upgrades made with relative ease. I think there can be up to 50 of those leaf versions. It really doesn’t touch the rest of the scripting language. So, if you don’t feel good about those changes, you could say, “Okay, I’ll just use the original tapscript for my transactions”. Yeah, so potentially we could have many iterations of the language like that.

Mike Schmidt: I know a lot of people were excited when Rusty presented, I think it was at BTC++ in Austin, about this idea. And so, there was a lot of energy from the folks who like to build. And I’m wondering, have people been tinkering at all yet? Obviously, we’re just at the sort of draft BIP stage, so things are early, but I’m wondering if that energy manifested itself into prototypes and things like that, using script restoration?

Julian Moik: I mean, one thing that everyone knows about, I guess, is OP_CAT, which has been like, I mean, the builders have been building with OP_CAT, like, I think it’s really crazy what you can do with OP_CAT. It’s very unintuitive and quite surprising. And this is really one of the main enablers. If you only had OP_CAT, you could already build like a ZK verifier, you could build a vault, you could even do some introspection. And yeah, having the whole set of opcodes, it just makes that a bit more convenient. But so far, I mean I have been actually working on the Splunk verifier. So, I looked, there is from Starknet, there’s like a prototype for verifying a proof. And they just use OP_CAT because OP_CAT is a thing that people maybe hope to activate alone. I tried to figure out what if we also had multiplication and the mod operator, and this improves the efficiency of that verifier by quite a bit. It would be one example of a use case, like having the multiplication of numbers is very useful.

Mark Erhardt: So, very concretely, OP_CAT is proposed in BIP347 to be enabled in tapscript with the leaf version 0xc0. This is basically independent, because if you use tapscript version 0xc0, which is the currently defined tapscript, then if it were added there, you could do OP_CAT in that. And here, the proposal is to introduce a whole new version of tapscript. So, if the leaf version of a script leaf in the script tree were defined as, I think, did you say 2c, right? Then it would 0xc0 and 0xc2, not 2c. So, if you used the second tapscript version, then you get all of the new 15 opcodes, you get the varops budget and so forth. If you use the first version of tapscript, if OP_CAT were enabled via BIP347, it would be added there.

Mike Schmidt: Julian, I have a question referencing back to some previous coverage that Optech had, based on some posts that Rusty had to the mailing list. This was Newsletter #374, which was October last year. Along with the varops and the restoration of previously disabled script, there was, at least articulated in the same email, OP_TX as a third BIP, and then new opcodes for tapscript v2, which was the final BIP that was part of the post that Rusty put up, which I think would include things like INTERNALKEY, MULTI, SEGMENT. What is the status of those? Is the idea to work on those next, or to put forth these two together and address those other two later?

Julian Moik: Yeah, I must say I haven’t worked on those at all. So, yeah, you really need Rusty for those two. But I think introspection is super-useful, just the idea of it. And I mean, there are now a lot of proposals. It’s again, this question, do you want a specific operation, like CTV (OP_CHECKTEMPLATEVERIFY), or do you want this super-powerful, generic, general OP_TX, which they are really complete opposites. And yeah, I think we have to think about really, do we want a general language or do we want these super-specific operations, which are potentially safer and less powerful? But then, if you add, for example, CTV, you have that in Bitcoin and you struggle again if you at some point want to have something more general. So, this is why I and why Rusty like this more general approach. It just enables builders to build. And then over time, we might figure out if we see onchain, for example, if we see a lot of vaults being built with OP_CAT and blocks are full of vaults, we know we might want to have a dedicated opcode for that, which is more efficient than having this CAT construction. And it should make it easier to come to a consensus with having this general approach, I believe.

Mark Erhardt: So, sorry, I feel like there were two things I heard here. One is you prefer the more general approach, but then OP_TX sounds like a very, very specific and small and narrow approach. thing you can commit to another transaction. So, with the general approach, you were talking about being able to do many different things with OP_CAT. But you also mentioned that introspection is super-useful, which is extremely difficult by OP_CAT. So, I think that the OP_TX use case is essentially also covered by other proposals like OP_ TXHASH, BIP346. Then, OP_CCV probably, the CHECKCONTRACTVERIFY, could probably achieve something similar. And there is both CTV, which is BIP119, and OP_TEMPLATEHASH now with BIP446. And packages around that, like LNHANCE and taproot-native (re)bindable transactions. So, I think we actually have a lot of options and we should just pick one if we’re going to do introspection. And, yeah, if we get OP_CAT and that allows us to sort of demonstrate that there is demand for it, because people even do it with the super-complicated and convoluted OP_CAT approach, that might inform which one we pick. But do you have a preference if you’ve been thinking about covenants so far?

Julian Moik: Honestly, I’m not super-deep into the latest proposals there. I mean, initially, I was a fan of CTV, but I more and more like these more general versions, like TXHASH, or even Rusty’s approach, which doesn’t even hash the values.

Mark Erhardt: Oh, maybe I misunderstand what OP_TX does then. I thought that it just commits to a txid, but what is the idea of OP_TX then?

Julian Moik: So, as I said, I haven’t been working on that. I think I have read the draft paper once. But as I understand it, it is like a more general approach to OP_TXHASH. Is that not the case?

Mark Erhardt: I guess then we’ll have to leave that for another episode. I don’t know better than you either.

Julian Moik: Yeah, sorry.

Mike Schmidt: Julian or Murch, is there anything else that we should cover on this item before we wrap up?

Mark Erhardt: Well, maybe a general call to action here. We’ve been getting a little more BIPs. I feel that might be induced demand to some degree, because BIPs have been getting processed a little more quickly and people are writing more BIPs again because, well, they don’t just sit there anymore. But it would be really nice if there were more people from the community taking a look at drafts or open PRs. A lot of them have only been getting BIP editor review before they move from being opened as PRs to the repository to being published. I’m sure people also look at them once they’re published, but so far very little of the review or reading has led to comments or additional remarks on them. So, please feel free. You don’t have to be a BIP editor to read BIP drafts or PRs. You can just look at them, leave your comments. We have something like 50 open PRs right now again. And about probably ten of those or so are proposing to create a new BIP.

Mike Schmidt: I’ll emphasize one thing that Murch said there to sum it up for listeners. You do not have to be a BIP editor and have that title in order to comment or review BIPs in the BIPs repository. I guess maybe an analogy is Bitcoin Core, you don’t have to be a maintainer to review a PR. In fact, most of the review comes from folks who aren’t maintainers. But perhaps there’s some stigma in the BIPs repository that review maybe often and should come from the BIP editors as opposed to general audience. So, if you’re curious about these sorts of things, poke in, see what you’re interested in, and leave feedback. Murch, maybe just quickly, what types of things are valuable for people to look at? They don’t necessarily need to evaluate the internals of the proposal, right? There’s general things that can be reviewed as well, which would be helpful, right?

Mark Erhardt: I mean, if you even just say, “I didn’t understand this part”, or, “The motivation seems unclear”, or I mean, it’s not very helpful to say you’re against something because that’s not the point. The point is to make them clearer or more accurate or more comprehensive. So, if you notice there’s a part that should be defined but isn’t mentioned, or if something is hard to understand, or maybe there could be a table demonstrating the listed values here, or something like that, that is useful feedback. Saying, “I don’t like your proposal”, is not. So, please keep it technical and constructive. And I don’t know if you see typos or stuff like that, that should be fixed before it gets published. That’s also useful, of course.

Mike Schmidt: Julian, anything else for listeners before we wrap up?

Julian Moik: Yeah, I was just thinking, as someone who has spent quite some time on these BIPs, it’s always a good feeling to have some kind of engagement or have someone being interested in your work. So, I mean, even if you just kind of look at the BIP and maybe you have a bunch of questions, yeah, it’s always a good feeling to have someone showing interest. And yeah, so I agree, it would be great to have more conversation and more review in the repository.

Mark Erhardt: One more question for you, Julian. So, having worked on the restoration of script and proposing to activate this new tapscript version, what are some of the things that you’re excited to see people build with this?

Julian Moik: Yeah. So, I like to refer back to that we don’t even really know what people might want to build. If you have a general purpose programming language, you have no idea what people are creating with that. And I guess this is also part of the dislike about these forward-thinking proposals, that it might allow things that we don’t want to have on Bitcoin. But eventually I have this hope or I believe that if we would give builders all the tools, they would build good tools, they would build tools that would help with Bitcoin, and they would probably also build things that you would not like to see. But in the end, the idea is really that you have a fee market, you have limited block space, and I would think that the useful applications, which scale payments, scale ownership, potentially improve privacy, that those use cases would win out through the fee market, right? Because in the end, Bitcoin is designed to be money and this is really the point. And I would hope that if you have these primitives, you could build things like a rollup on that, which improves scaling and just makes better decentralized money.

Mike Schmidt: Excellent. Good way to wrap up, Julian. You’re welcome to hang on, but we understand if you have things to do and you’re free to drop.

Julian Moik: Sure. Thank you.

Testing Bitcoin Core 31.0 Release Candidates

Mike Schmidt: We’re going to jump back up to our monthly segment on a Bitcoin Core PR Review Club. This one is titled, “Testing Bitcoin Core 31.0 Release Candidates”. And it’s a little bit different than following a specific PR, since this one is more of a group testing effort. This was the testing guide that we covered previously in #397 that svanstaa came on and talked to us about creating the guide and how he went about that, and also the different components in there, which include testing around cluster mempool and the RPCs and cluster limits. We talked about cluster limits in #382. Private broadcast and testing that, I think we covered private broadcast in #388. The getblock RPC with the new coinbase_tx field, that was in #394. And then, we also talked about -dbcache size in #396, ASMap data by default in #394, and the REST API endpoint, we talked about that in #386.

Mark Erhardt: And so, we’re on RC4 for Bitcoin Core v31. That means the original roadmap was aiming for tentative date of April 10th to attack v31. We are on RC4; that was tagged a few days ago. As far as I’m aware, there are no open issues. So, this might be the version that gets released and we’re on the verge of having v31 come out. Obviously, if you still want to test or take a look at the feature, the testing guide might still be interesting as a sort of guided tour around the new features. But if you’re just ready to jump in, you’ll probably be able to do so in a few days. I mean, you can always just run the master branch from the repository, but then the actual release will be there soon.

Mike Schmidt: Yeah, the testing guide in addition to the release notes draft would have good ideas of what to test and obviously, like Murch said, what is actually in there, if you’re going to be looking to upgrade to 31. Anything else on this Review Club, Murch? Great. We’re going to bounce to the Notable code and documentation changes. We didn’t have any News and we didn’t have any Releases to cover this week. We did touch on the one BIPs PR, but for the other PR we have, Gustavo authored this segment this week. What’s going on, Gustavo, this week in Notable code?

Bitcoin Core #33908

Gustavo Flores Echaiz: Thank you, Mike and Murch. Yes, so this week, we have the first one which is on Bitcoin Core #33908, which is a new endpoint or addition that is added to the libbitcoinkernel API in C programming language. So, this API is something that we’ve been recurrently talking about for the past few newsletters. This one adds a new function called btck_check_block_context_free, which basically the name tells you that it’s for validating candidate blocks with context-free checks and also per-transaction checks that do not depend on chainstate, the block index, or the UTXO set. So, what are these context-free checks and these per-transaction checks that don’t depend on the chainstate and these other data fields?

So, for example, block level context-free check can be just simply looking at the block size and the weight limits, or it can also be looking at the presence of a coinbase transaction, or witness commitment checks that verifies the witness reserve value size. So, those are like the main block level context-free checks. But also, this PR ads optionally, can also enable callers to verify the proof-of-work and also the merkle root, right? So, actually, this function is just a layer on top of an internal function in Bitcoin Core called checkBlock, which is different from another function called ContextualCheckBlock, right? So, you can tell by the name why the checkBlock one is contextless. So, a sub-function of checkBlock, excuse me, is checkBlockHeader, which checks that the blockhash meets the difficulty target declared in the header. And the merkle root verification is also just re-computing the merkle tree from the block transaction and checking against the header’s hash merkle root field. So, those are the optional things you can also add that callers can enable in this function.

Per-transaction checks that are context-free, well, you would have, for example, making sure that inputs and outputs are not empty, once again transaction size and weight limit, or other things like that. So, coinbase scriptSig length bound, for example, something we’ve talked about in the past. So, yeah, so this is just a new function part of this API that exposes the libbitcoinkernel. So, an interesting addition, just a follow-up. Probably in the next few weeks, we’ll see more additions to this API. Yes, Murch?

Mark Erhardt: Yeah. As some of the things that require context, for example, in the blockHeader, you commit to the previous block, so you can only check that if you know the previous block. To know whether your transactions actually have the funds that they create for the outputs, you need to know about the UTXOs, so you need context. But there are a number of things that you can check directly just from receiving the block. And the idea there is that if you have only the block, you can do a bunch of checks already that, for example, mean the block was produced with a proof of work. And that is already a very high bar to meet. It would be very expensive for someone to lie to you and to give you a chunk of data that passes the proof-of-work check, but is not actually valid. So, that can maybe, in some regards, inspire confidence, but to have a full check of whether a block is consensus valid, you need the context of the UTXO set, the previous blocks, and so forth.

Mike Schmidt: Murch, question for you. When we see btck, like this btck_check_block_context_free, we just read that as Bitcoin kernel, the btck part?

Mark Erhardt: I don’t know, but sounds plausible.

Mike Schmidt: Okay, I’ve been seeing it pop up, so I was curious. Okay, back to you, Gustavo.

Gustavo Flores Echaiz: Thank you, Murch and Mike. Yeah, so that’s exactly right. And this is very much used by, like, mining pool template validation for Stratum v2 template validation. So, yeah, like Murch said, it’s not a full coverage, but it’s a minimum verification around the mining template you created or received specifically, and can be leveraged for Stratum v2 pools verify miner-constructed blocks.

Eclair #3283

So, the next item is from the Eclair repository, PR #3283. Here, a new field is added to three similar endpoints, called findroute, findroutetonode, and findroutebetweennodes. So, a new field is added, called fee, that in msats, this field provides the total forwarding fee for the route. So, before this fee existed, a caller would have to manually calculate the fee per hop and then sum all that up to get the total fee of the route. So, this makes it simpler for callers to just get the fee filled from these endpoints, and not have to manually construct the fee that would require them to go backwards and go per hop, calculate the fee and then sum it all up.

LDK #4529

So, the next one is LDK #4529. This is one of the two LDK PRs we’re covering this week. The first one enables operators to set different limits for announced or unannounced channels when configuring the total value of inbound HTLCs (Hash Time Locked Contracts) in flight. So, what this means is that before this PR, you could set a limit for the total value of inbound HTLCs in flight, but there wouldn’t be a difference between the announced and the unannounced, or also called private channels. So, now this value, or the setting, is split across two different settings, that one is for the announced channels and the other one is for the private channels. And what is the total value of inbound HTLCs in flight? This just means that, for example, when you cap it at 25%, which is the default for the private channels, then at most there will be 25% of the channel’s capacity that is currently in flight, so that has either not succeeded or failed. So, the HTLCs are in flight and haven’t yet completed. So, you’re always reserving channel capacity and you’re not at risk of getting all of your channel capacity stuck in an HTLC.

So, the defaults for this are 25% for announced channels and 100% for unannounced channels, but this is all very configurable, so a user could change that to any desired value.

LDK #4494

The next one, LDK #4494. Here, the internal logic around RBF for fee bumping transactions is updated. So, in the past few weeks, we’ve covered LDK’s RBF implementation specifically for splicing. So now, it was found that LDK would fail to comply, at the same time, with the BIP125 replacement rules, and the also the rules specified in BOLT2. So now, the update of the logic makes it that LDK will always use whichever is larger, either the BOLT2 rule, which is that the feerate has to be multiplied by 25/24, which is about a 4% increase; so, it’s either that 4.17% increase, that’s what the LN spec says that the fee bump has to respect. The BIP125 rule simply says that the absolute fee has to be higher, so you could simply increase by 1 sat. But at very low feerates there’s a potential for one to be better to use than the other.

So now, LDK simply compares both rules and applies whichever is larger to ensure that it always complies with the LN spec rules and the BIP125 rules. And also, this PR opened a new discussion on the BOLTs repository to ensure that we always comply with BIP125, that the spec instructs implementations to always make sure that they not only comply with the BOLT2 specification around fee bumping, but also the BIP125 rules around the RBF.

Mark Erhardt: That is so odd to me. BIP125 is still implemented by some Bitcoin Core derivatives, but Bitcoin Core implement it anymore. And then, why 25/24, a 4% increase in fees when an additional 25 sat per kiloweightunit (sat/kW) is 0.1 sats per vbyte (sat/vB)? So, that is the new default of Bitcoin Core for the incremental relay TX feerate. So, it sounds like they’re actually implementing Bitcoin Core’s current new default feerate. But where does this 25/24 come from? And the other thing, yeah, it also assumes that the transaction is the same size as before, which I think is a problem here, because you do have to increase the absolute fee too, which usually happens when you increase the feerate if the transactions are the same size. But if your transaction gets smaller, increasing the feerate doesn’t necessarily mean that you beat the prior absolute fee.

So, this update confuses me and I shall just state that I’m confused by it, but I will probably not dig into it. But if anyone working on this is interested, we can talk!

Gustavo Flores Echaiz: Yeah, so I just took a look at the new PR that was opened in the BOLTs repository, and I can see that this has been a requirement in BOLT2 specifically. For example, it says, “The sender MUST set feerate greater than or equal to 25/24 times the feerate of the previously constructed transaction, rounded down”, right? So, this has been a requirement on BOLT2 for probably a while already, and there was maybe a hypothetical scenario where this would conflict with the BIP125 rule, and this is why this was implemented in LDK; probably very hypothetical, because from what I understand, LN funding transactions are quite large, so this might not even be a problem often in reality.

Mark Erhardt: I mean, very specifically the 25/24 does not increase the feerate enough, if the prior feerate was less than 24 sats/vB before the recent subset summer. So now, it would be at 2.4 sats/vB, below of which this increase is not enough. And in all of those cases, increasing by 25 sats/kW is the minimum amount that you have to bump for Bitcoin Core nodes to accept the replacement. So, it’s just confusing to me that you now use whichever is larger instead of just the latter, because the latter is always the right value. Anyway, we’re getting too much into the weeds here. Let’s carry on.

LND #10666

Gustavo Flores Echaiz: Thank you, Murch. Yes, so the next one is from LND. So, LND #10666 adds a new RPC called DeleteForwardingHistory and an equivalent command on the lncli tool. This enables operators to selectively delete forwarding events older than a chosen cutoff timestamp. So, you basically call this with a specific timestamp and it will delete all the forwarding events before that. So, what’s interesting about this is that you can now delete historical forwarding records without having to take your node offline or resetting your database. So, this was not possible before this PR. And there’s also a minimum age guard of one hour that prevents you from deleting or removing data that is just way too recent. So, you’re unable to delete with this function data that is over the past hour, but anything before that, you can easily delete with this new command.

BIPs #2099

Next one, now we get into the BIPs. So, we have BIPs, the PR BIPs #2099, which publishes BIP393, which specifies an optional annotation syntax for output script descriptors. So, a common problem is that through the descriptors, or I guess a limitation of the descriptor protocol is not being able to specify recovery hints, such as for example, the birth date of a wallet. So, wallets would implement this outside of this descriptor protocol. So, this adds it directly into it. Yes, Murch?

Mark Erhardt: Yeah, so the descriptors are very specifically designed to express a set of output scripts, right? And in Bitcoin Core, where this proposal comes from, the descriptors are used to basically refer to a set of output scripts that define part of a wallet. So, if you, for example, have output scripts for P2PKH and for P2TR, you would have at least two descriptors that define those sets of output scripts. So, in that context, they do not have that meta information, because the wallet format of Bitcoin Core already stores this meta information in other ways. Where BIP393 comes from here is that this project sees descriptors as an interesting way of they would like to use descriptors in their wallet backups. But in the context of wallet backups, you have additional information that is relevant. And very specifically, knowing when a descriptor was created allows you to only scan the blockchain from that point on. As we’ve discussed with Craig Raw when he was on, who is the author of BIP393, especially for silent payments, the scanning is so expensive that this is a huge speed-up to be able to know exactly from what height to scan.

So, in the context of using output descriptors as an element of wallet backups, it is interesting to have this meta information. And if I recall correctly, BIP393 adds exactly three kinds of metadata. Was it the height and – well, I shouldn’t have even started that if I don’t remember!

Mike Schmidt: Block height, gap limit, max label.

Mark Erhardt: Wonderful, thank you. So, max label only applies in the context of selling payments. The gap limit, of course, is a hint for wallets, describing sort of how many addresses they tend to give out between payments in average, or in the extreme. And if you have a higher gap limit, you would generate more addresses or output scripts in advance before scanning, and fill up the bucket more quickly while you’re scanning, which would potentially allow you to find the history of your wallet more easily, but also mean that if the gap limit is too high, create way too many output scripts. And that is an expensive operation on devices with little compute, and would probably be a little harder to scan. So, you kind of want a semi-accurate gap limit. In case of doubt, just 10x it or something.

Gustavo Flores Echaiz: Makes total sense. Thank you, Murch, for adding that. And listeners who want to learn more about this, the Newsletter #294 and its accompanying podcast episode, Craig Raw was invited to talk about this more in detail.

So, the next one, we just covered it at the beginning of the episode, which was the merging of the PRs BIPs #2118, which merges BIP440 and 441. So, you can listen to the beginning of the episode to hear Julian tell us more about that in detail.

BIPs #2134

And finally, the last one, which is not so huge newsworthy, but we kind of had a light week, so we still included it, is BIPs #2134, which updates the BIP352 specification around silent payments to warn wallet developers not to let policy filtering affect whether scanning continues after a match is found, right? So, if you completely ignore, for example, dust, or you apply policy filtering when scanning for a wallet, you will, for example, skip dust outputs and consider that no match was found at that height. And then, your wallet stop limit or stopgap will simply arrive faster and you will miss later outputs from the same sender. Yes, Murch?

Mark Erhardt: Here, this is especially in the context of silent payments. You can theoretically, it doesn’t really make sense to do this, but theoretically you could be paid multiple times in a single silent payment transaction. And the way the silent payments construction works is because the output script depends on the inputs in that same transaction, if you were paying the same recipient multiple times in a transaction, all of the outputs would have the same output script. And obviously, the whole point of silent payments is to have a reusable payment instruction that does not reuse output scripts. So, when you pay the same recipient multiple times, you increment a counter in the generation of the output scripts, so the output scripts actually look unrelated. And because the recipient doesn’t know which of the outputs paid the recipient, when a silent payments recipient or a silent payments user scans P2TR outputs, they have to scan every single P2TR output on the transaction to see whether their first output exists. And then, they can check if a second output exists and they have to scan all outputs again. And if a second one exists, you have to check, does a third one exist?

The warning here very specifically is if you ignore, for example, dust outputs and stop scanning because you didn’t check whether a dust output was for you, you might overlook a second output that has a larger amount that is derived from a higher index and the incremented counter. And that would be a mistake. So, you have to actually check all the outputs, even if they’re dusty or something, to see whether one of the other outputs pays you and you can only stop once you do not find an output that pays you at that index.

Gustavo Flores Echaiz: Understood, that makes a lot of sense and I guess it just amplifies the fact how expensive it is to scan for silent payment outputs. Thank you, Murch.

Mark Erhardt: Yeah, we’ve been reporting on this, the accompanying debate around this point, with like, how many payments to the same recipient should be allowed in a silent payments output? How many outputs should be allowed in general in a silent payments transaction? And so the developers and researchers that work on silent payments have been spending quite a bit of time thinking on that edge case. And this is sort of another follow-up just to clarify very specifically to implementers of silent payments that they do not overlook any outputs that might pay their recipients and their users.

Gustavo Flores Echaiz: Right, even in a scenario that doesn’t make that much sense, but awesome. Thank you, Murch. That completes this section and completes the whole newsletter.

Mike Schmidt: We want to thank Julian for joining us and hanging on today. I thank my co-hosts, Murch and Gustavo, and you all for listening. We’ll hear you next week. Cheers.

Mark Erhardt: Cheers.

Julian Moik: Thank you, guys. Cheers.

Gustavo Flores Echaiz: Thank you.

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

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

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

Mike Schmidt: Welcome everyone to Optech Recap #399. Today, we’re going to be talking about a wallet fingerprinting series of risks that have been brought up around payjoin and privacy; we also have a draft BIP around wallet backup metadata formats; we’re going to talk, in our Changing consensus monthly segment, about Isogeny approach to post-quantum cryptography; we have the SHRIMPS post-quantum signature construction that we’re going to talk about; and we have great or grand restoration BIPs that are getting their numbers as well. This week, Murch, Gustavo and I are joined by four guests. We’ll have them introduce themselves briefly and then we’ll jump into the newsletter. Armin?

Armin Sabouri: Hello, Armin here. I’ve been in the Bitcoin space, specifically self-custody, for a little bit over half a decade. My focus right now is on Bitcoin privacy, where I contribute to the Payjoin Dev Kit (PDK) and just think about privacy in general.

Mike Schmidt: Thank you. Pyth?

Pyth: Hi, guys, I’m Pyth, I’m working at Wizardsardine, mainly on Liana Wallet.

Mike Schmidt: Conduition?

Conduition: Hi, I’m Conduition, I’m a freelance cryptographic engineer and open-source researcher. Recently, my focus has been on various forms of post-quantum cryptography, namely hash-based and Isogeny-based.

Mike Schmidt: And Jonas.

Jonas Nick: Hey, everyone, I’m Director of Research at Blockstream. We work on programming languages for blockchains, like Simplicity, and we work on cryptography for Bitcoin, focusing as well on classic cryptography that is not secure against quantum computers, and cryptography that is secure against quantum computers.

SHRIMPS: 2.5 KB post-quantum signatures across multiple stateful devices

Mike Schmidt: And that’s what we’ll pick up. So, if you’re listening, we’re going to actually jump to the Changing consensus segment, a little bit out of order in deference to our guests. We’re going to jump to, “SHRIMPS: 2.5 kB post-quantum signatures across multiple stateful devices”, which was from Jonas’s post to Delving Bitcoin. We had Jonas on in #391 to talk about SPHINCS+ SHRINCS, and now we have him back again to talk about SHRIMPS. So, Jonas, how does this constellation of things fit together, and then we can get into some details on SHRIMPS?

Jonas Nick: Yeah, so SHRIMPS is a hash-based signature scheme, just like SHRINCS and SLH-DSA and SPHINCS, if people have heard about that. The advantage is that it’s smaller than at least standard SPHINCS+ and the standardized SLH-DSA scheme. How does it achieve that? It assumes a wallet that is stateful, and this is something that is shared with SHRINCS. Now, SHRINCS is more efficient than SHRIMPS, and that’s why SHRIMPS is best understood when first talking about SHRINCS. So, just to remind everyone what SHRINCS is, SHRINCS is a very efficient hash-based signature scheme, where the signatures are about 350 bytes in certain situations. So, the way this works is we are exploiting the fact that in Bitcoin, we usually only do a few signatures for every public key. This is different to most other applications for signatures, where we publish a public key and then we make arbitrary many signatures. In Bitcoin, we don’t try to reuse addresses, and therefore we only make few signatures per public key. And that allows SHRINCS to make these very small signatures.

As I said, this requires the wallet to be stateful, so essentially what the wallet needs to do, it needs to remember an integer for every public key that it generated, and this integer just represents how often did the device, the signer, sign with this for this public key. So, it’s just an incrementing integer. If that is wrong, then the security of the system breaks down. So, this is a very big assumption. And if the state is lost, then SHRINCS is set up in a way where the signer can use a fallback signature scheme that is then rather large. Depending on the parameters, it would be between 4 kB and 8 kB, seems to be the most realistic. So, SHRINCS works then this way, like lifecycle of a device, signing device. I’m always imagining signing devices because hardware wallets, they have the most credible way of storing state. So, the signing device generates a key, a seed, and then it can store the state, it gets asked to sign something, then it updates the state, etc. The user has a seed, device breaks down, user imports seed into new device, and then the new device knows, “Okay, I have been initialized with the seed, so I don’t know the state. So, I’m going to use the fallback”, and the fallback is expensive.

Now, what SHRIMPS improves on is this fallback method, where you can say SHRIMPS either reduces the size of the signature or it reduces the amount or the probability that this full fallback would even be used. So, how does this fit together? On the primary device, where you generated the key, you produce very compact signatures, 350 bytes. Now, if this device breaks down or you import it into a different signing device, you produce 2,500-byte signatures. And if everything is breaking down, or whatever, you still have a fallback method where you produce 8,000-byte signatures.

So, SHRIMPS is really this improvement. Perhaps we have to use this worst fallback method, 8000 bytes; much more rarely we can use 2.5 kB signatures. This works by first assuming stateful devices, primary device and backup device, all backup devices; second, we only create few signatures per public key; and third, we only import a seed into a fresh signing device relatively rarely, or at least we can bound it. So, for the numbers I propose in the post, I would say 1,000. Like normal consumer wallets, probably you will never exceed 1,000 fresh devices with your seed during the lifetime of your wallet.

Mark Erhardt: So, how does that work? Do you have sort of a part of the seed that is device-based; or every time it’s imported, it also reads out some key from the signing device, and that allows it to produce different signatures for the same public keys; or what are you doing there?

Jonas Nick: Okay, so the way this works is first, it’s all based on SPHINCS+ and SPHINCS+ is a stateless signature scheme. And SPHINCS+ has this property that it sort of has this parameter that represents the maximum number of signatures you can produce with the public key. By default, or at least the standardized SLH-DSA that is 264, enormous, you will not reach that. If you reduce it to, let’s say, 210, 1,000, then the signature becomes much smaller, 2.5 kB. So, what do we do then in SHRIMPS? So, you could imagine that your public key just consists of two components that are arranged in a merkle tree. So, you have a public key with a compact SPHINCS+ instance, the one that only allows 210 signatures, and one that is like your fallback method, 264 signatures. And the hash of these two public keys concatenate together is your overall public key for SHRIMPS. And I’m excluding SHRINCS right now for the moment.

All right, so you have these two ways now of signing the compact and the fallback. Now, whenever you initialize a new device, the new device will just, for the first signature it produces, it will use the compact instance, and it produces a signature. If it’s being asked to produce a second signature for the same public key, it will use the fallback method. So, the first signature is very efficient, second signature is very inefficient. And on the compact path, we have a budget of 210, 1,000 signatures. So, every device that I initialize, that means I can have 1,000 devices that I initialize with that seed, each one signing exactly once with that compact path, and that then the fallback.

Mark Erhardt: So, basically you remember as state how many devices you’ve initialized? Are you, are you basically telling the device, “Oh, you are the second device with this key”?

Jonas Nick: No, you don’t need to, because SPHINCS+ is a stateless signature scheme, so you don’t need to. You only bound the number of times that you initialize a device with the seed. You don’t need to remember or know the state, the number of times you’ve initialized the device. Each device will just produce one signature with a compact path. So, at most, if at most 1,000 devices are initialized, at most 1,000 signatures will be produced with the compact path. And that means that this entire scheme remains secure.

Mark Erhardt: Right, a single signature is a little adventurous. If you, for example, use too low of a feerate and you want to RBF, suddenly you’re not only increasing the feerate, but also increasing your signature size to an enormous 8 kB, right? So, would it be a way to make like three signature to a device, or something?

Jonas Nick: Right, so if we say, okay, we have 1,000 devices at max that we’re going to initialize and each of the devices is allowed to do 16 signatures with a compact path, let’s say, then we use a compact SPHINCS+ instance with 24 times 210 signatures, so 214 allowed signatures. And that, according to the numbers that I provide in the post, still results, I think, in a signature that is about 3 kB. So, still much less than the SLH 8 kB.

Mark Erhardt: I saw that Conduition wanted to chime in, sorry.

Conduition: I just wanted to mention that the maximum number of signatures on a SPHINCS key is actually a more flexible number than Jonas is making it out to be. It’s more so a ceiling beyond which, once you go there, there be dragons. It’s not so much an instant death, the floor is lava limit. As soon as you cross that, you’re not instantly exposing your keypair, you’re more so making your keypair gradually less secure as you overuse it. And actually, in Jonas’s post, I think he goes through some examples of how that signature security degrades overuse.

Jonas Nick: Yeah, I think that’s a good point. So, for example, with the parameters that I provide for 1,000 devices, if you accidentally initialize 2,000 devices or each device somehow signs twice instead of once, you still have exactly the same security. So, there is some budget there. It goes down relatively slowly, but it sort of depends very much on the parameters. And this is not the case with SHRINCS. So, with the SHRINCS signatures, if you reuse the state and mess up the state, you’d be really in trouble.

Mike Schmidt: Jonas, in the case of managing state, it seems like the implication here is if my primary device is lost, that integer that you mentioned that represents state is assumed to be lost as well, and then you go to the fallback path, is that right?

Jonas Nick: Yeah.

Mike Schmidt: And if that is right, can’t I just replicate that state in some way on a new device; say if I knew that I am done with this signing device and I’m intentionally stopping here, pull out the integer, move it to a new device, and continue on?

Jonas Nick: So, this stateless assumption, I think, is a big change to the philosophy that we have previously applied to Bitcoin cryptographic design, where we try to be very careful about misuse resistance, making it very hard for users to accidentally do anything wrong, use the cryptographic APIs incorrectly. And with these stateful designs, we can’t really do that anymore. And that’s why when I try to explain these things, I try to explain them in a way where they would be the most secure against user error. What you’re describing is certainly possible and there are many variants of it. But that always assumes that the user does something correctly. For example, let’s say they put the state on an SD card and they insert this SD card into the new hardware wallet, and then they delete the SD card, or whatever. That is fine. But they shouldn’t make a copy of it, for example, before inserting it into the new device and it getting deleted. So, there are a lot of ways to perhaps improve on this, where you make some additional assumptions on correct behavior of the user. But that’s kind of more difficult to analyze, but certainly possible.

Mike Schmidt: Conduition or Murch, any additional feedback? Murch has given thumbs up.

Conduition: I could say, I really like the idea of adding a stateful option. For the wallets that want to use it, the savings in terms of compactness are huge compared to SPHINCS, which is stateless. And it’s an engineering hurdle. Absolutely, it’s a big problem. But for the wallets that want to do it and that want to take on the challenge, it could provide a very good option in the doomsday scenario, where we do need to use stateful, or where we need to use any hash-based signature algorithm as an everyday transaction signing tool. Having that option, I think, is a good thing.

Mike Schmidt: Jonas, how’s feedback been so far?

Jonas Nick: Yeah, I’m surprisingly positive on these stateful signature schemes, because I think they can be fragile and I don’t like them, because I have spent a lot of time trying to prevent user error as much as possible. But maybe this is an interesting point in this trade-off space. If you say, okay, there’s a doomsday scenario, then everyone using SLH-DSA, these enormous signatures, is a systemic risk for Bitcoin, because then the transactions per second, everyone uses them, goes down to 0.3 transactions per second, right? So, very, very small systemic risk to Bitcoin, I would say. Whereas if we use a stateful signature scheme, that sort of goes away. We can still get like 4 transactions per second, a little bit higher than that, but now we have this localized risk. So, it moves the systemic risk to a more localized risk. I think people will probably mess this up because there is some probability and there are enough Bitcoin users that someone will mess it up, but at least the whole Bitcoin Network won’t be messed up.

Mark Erhardt: I guess I have another follow-up question, and it sort of maybe pounds the same path that I’ve previously explored, so stop me if it’s getting repetitive. But I’m kind of confused by the choice of parameters. I’d say it would be much more interesting to be able to do a few signatures per device versus I don’t really see the point of being able to import your backup 1,000 times. Surely, you would want to import a backup a few times, but it’s probably more on the order of 5 to 10 times, even the most crazy setups, unless you’re keeping your backup offline and importing it every time you create a transaction. But then, you’d have hopefully different output scripts for those transactions and that problem wouldn’t apply. I just feel like it should be rather the other way around, allow maybe 15 or 20 signatures per import, and then only have 5 to 10 imports. So, I was just wondering whether you could expound on how you arrived at the parameters, or whether we can tickle this a little more to come up with smaller signatures?

Jonas Nick: Yeah, so let’s say we say, okay, the number of device initialization we allow is 32, right, much smaller. And then what? As the choosers of these parameters, like whatever, in Bitcoin consensus or in the wallet, I guess that’s up to debate how to exactly include it into the Bitcoin protocol, let’s say we fix it to 32. But what happens if the user somehow imports it more often, right? So, really, this number needs to be a maximum, because if the user imports it more often, then the security will go down gradually. So, we will need to find an upper bound that is a real upper bound and that no one with very high likelihood will exceed. And sure, you can tweak the parameters. But to me, when I started writing this post, it was just, 1,000 sounds large, it’s not debatable, right? Whereas if I had picked 32, then people would say, “Oh, 32, that sounds very, very scary”.

Mike Schmidt: What is the difference in size, I guess, would be maybe the follow-up question, if you did 32 versus 1,000?

Jonas Nick: So, the difference in size is not enormous. It would still be probably just over 2 kB.

Mark Erhardt: Maybe 20% or so less, but okay. Conduition, you wanted to say something?

Conduition: I just wanted to note that the parameters of the protocol are very flexible. It’s even debatable whether we could include flexible parameterization in consensus, so that individual wallets would have the ability to determine their parameter sets. But then you get into questions of fungibility, because different wallets would then have different fingerprints. I think choosing an upper limit that works for most people is the better option here, since we’re using this mostly as a fallback anyway. Ideally, nobody ever has to use this. Ideally, we come up with a better signature algorithm that has the same compactness as schnorr, but that’s a best-case scenario. So, we want to plan for the worst.

Jonas Nick: Yeah, the fungibility issue, I fully agree.

Mike Schmidt: Well, it seems like we’ve done this one pretty good. Anything that you’d leave for listeners, Jonas, other than reading your post?

Jonas Nick: Not right now. I mean, on these stateless schemes in general, I’d be interested to hear feedback from wallet developers, if they think this is actually a worthwhile direction. So, that would be one kind of feedback that I’d be interested in. And the other feedback would be, I think what has not really been explored that much in the Bitcoin space is post-quantum hash-based signatures, for example, and layer 2s. Because if signatures get larger, and they will get larger, even with SHRINCS, then there would be a higher incentive to use L2s and more importance placed on using L2s. So, I’d be interested in what L2 devs think about these various post-quantum options that are on the table.

Mike Schmidt: Conduition, one more comment? I just had a response to Nick. Jonas, you said you were interested in hearing about what wallets and their developers think about stateful and statelessness. I can’t name names publicly, but I can tell you that I have been speaking to some wallet developers and they are very interested in the stateful option. So, you should take that as a positive, I think.

Jonas Nick: Okay, that’s good to hear.

Compact Isogeny PQC can replace HD wallets, key-tweaking, silent payments

Mike Schmidt: Well, we’ll stay on the topic of quantum, because we’re going to talk about another Changing consensus item here, “Compact isogeny, post-quantum, and then also in the context of HD wallets, key tweaking, and silent payments”. So, we’ve talked about hash-based signatures sort of losing some of these nice features potentially, although I know there’s research into replicating some of these potentially. But Conduition, you posted to Delving about isogeny-based cryptography, IBC, and that I think is a something that’s new, at least on this show, in terms of our discussion on the newsletter previously. Why don’t you give us an overview, knowing the context of folks hearing about hash-based and maybe a touch of lattice, how does isogeny fit into this?

Conduition: Absolutely. I was researching hash-based signatures for a few months late last year and I started looking into lattices shortly after that, as I was curious about more compact and flexible schemes. I always found the same pattern with lattice-based schemes, which was if you want to add structure, you need to compromise on compactness. So, lattice-based public keys contain a matrix of polynomials, and in order to generate that matrix, which is very large, you typically include a seed in the public key, and that seed is basically just a salt that you use to generate that full matrix. And in order to add structure, by which I mean adding enough mathematical flexibility to derive child keys, to re-randomize, to aggregate signatures, that kind of stuff, you need to include that full matrix most of the time, and that makes the public key way larger. And there are shortcuts around it. there have been lots of papers published on it, but it’s really not an avoidable compromise. And you also have to compromise on security.

So, after I realized that, I started looking into alternatives. And the first one that came to mind, when I looked up the different relative sizes of signature schemes, was IBC. So, if I’m going to draw analogs between classical and IBC, let’s just tl;dr it. So, an isogeny is a function that maps points on one curve to points on another curve, but preserves the structure between the two curves. Now, we all know what elliptic curves are more or less, but there are a specific subclass of elliptic curves, and that specific subclass has a bunch of nice cryptographic properties; these subclasses, called supersingular elliptic curves. And the properties of these curves, I’ll shorten a lot of research here, but basically they make for very nice public keys. If you start from a given supersingular elliptic curve, which is called the base curve, also known as E0, you can create isogenies from E0 to other supersingular elliptic curves. And those isogenies become secret keys and the elliptic curves that those isogenies map to, which is called the co-domain of the isogeny, those are your public keys.

Now, the really cool property of this construction for me that I noticed, when reading the SQIsign NIST document, was you can create isogenies from any elliptic curve very easily. And because of another mathematical result, you can actually create a new isogeny between curves that you derive from a starting curve. So, let’s say you start at E0 and you have an isogeny to E1. If you create a new isogeny from E1 to E2, well now you have a path from E0 all the way through E1 to E2 and you can actually find a shorter path between E0 and E2. And that effectively looks a lot like BIP32. Think about it. If you have a public key, E1, and you can create a random isogeny from E1 to a new one, E2, that looks like a new public key. You don’t need to know any secret information to do that. Now, if you do know the secret information, which is the isogeny, from E0 to E1, now you can work out a new piece of equivalent secret information for E2. So, it kind of updates the secret relation, you might say, in cryptographic terms, between E0 and E1 to a new relation between E0 and E2. And this is formally called key re-randomization, and this is the property that I was really interested in and which I didn’t see anybody else noticing its applicability to Bitcoin.

So, that post that I made was really calling to attention that, “Hey, this is an interesting subject that we should all be interested in, because it gives us all the properties that we want in a post-quantum cryptosystem”, well, maybe not all of them, but certainly a good deal of them.

Mark Erhardt: So, this key re-randomization is PQ safe? Is that what you’re saying?

Conduition: Yes. There is no information that you reveal by generating a new isogeny from a given curve. Anybody can do it and it doesn’t compromise anything with the secret key, because it doesn’t affect the base assumption of isogeny cryptography. By the way, that base assumption is called the Supersingular Isogeny Path Problem. It’s essentially a challenge, where given two supersingular curves, try to find an isogeny between them. Turns out to be very hard. And generating new isogenies from a starting curve doesn’t give you any advantage if you’re trying to connect to two fixed curves. You can create new isogenies but you don’t know where you’re going to land.

Mark Erhardt: So, basically you would have the order of the curves predetermined, that would be sort of the equivalent of the index on the key derivation, and then the owner of the private key would be able to create the isogenies and would be able to find the re-derivations or the key re-randomizations of those isogenies to step through the process; whereas it sounds like the public key would enable people to find the public key on the new curve. So, you essentially get both an xpub sort of behavior and an xpriv sort of behavior. Would this also allow tweaking and signature aggregation?

Conduition: I’m just going to step back for a second to correct there. The curves themselves are actually the public keys. The points on the curve are not used for security purposes. They’re only used to communicate information about isogenies and curves. Now, the order of the curve is actually a constant fixed by the scheme, because every supersingular elliptic curve actually has the same number of points, interestingly. Now, as for your other question, yes, it allows for key tweaking. In fact, it’s almost perfectly analogous to taproot and key tweaking done in Taproot. The only distinction is what you use to re-randomize a given curve. So, the way that re-randomization would work is very similar to the way that taproot or BIP32 works. You essentially just take a hash of the public key, which is an elliptic curve, along with a salt. And that salt can be played with to be whatever you want it to be, depending on context. In the case of taproot, that salt is a merkle root; in the case of BIP32, it’s a chain code and an index; in the case of silent payments, the salt is a shared secret derived through ECDH. But we don’t have ECDH anymore in the context of post-quantum, so it’s not clear what that secret should be in the post-quantum context.

Mike Schmidt: Armin?

Armin Sabouri: Yeah. I saw in your post, your blog, that every isogeny also has a dual isogeny, essentially the reverse mapping. If this is true, isn’t this a problem, if one of your root or leaf isogenies gets leaked that you can then derive the root isogeny?

Conduition: Well, first of all, any isogeny from your public key curve is supposed to be publicly derivable only if you have the salt. And in the case of BIP32, for example, the salt is actually a secret key. So, unless you already know the parent’s secret key, you can’t walk back using duals, for instance. It is indeed a problem if the salt is a public value. And this follows the same semantics as BIP32’s unhardened derivation works today. If you know a secret key and a parent xpub, you can walk back to get the parent xpriv. And it’s functionally the same with this post-quantum isogeny-based idea.

Armin Sabouri: Got it. That makes sense. Thank you.

Mike Schmidt: Conduition, in your research, are there other folks doing similar research for blockchains, for lack of a better word? Obviously there’s some literature on these isogenies, but I’m wondering if people have gone down this path with regards to something like Bitcoin.

Conduition: That’s a great question. I honestly don’t see it yet. I certainly think I’m the first one to notice its applicability to BIP32 and re-randomization. I would not be surprised if some altcoin has tried to integrate isogenies before, but if they have, I don’t know about it.

Mike Schmidt: I don’t know if you’ve touched on it already, but what do the numbers look like, you know, signing, verification, sizes, these sorts of things?

Conduition: Oh yes, I love talking about numbers. So, for compactness, keys are about 65 bytes, public keys are 65 bytes, secret keys are a bit larger. Signatures are, for SQIsign, 148 bytes. For PRISM, which is a competitor alternative newer than SQIsign, signatures are slightly larger. I think it was around 160, 170 bytes, but those can be compressed a little more at the cost of some speed. For performance, signing now takes, I think, on the order of like 5 to 10 milliseconds on an average CPU, and verification takes around 1 or 2 milliseconds.

Mike Schmidt: It sounds impressive from those metrics.

Mark Erhardt: Where’s the dirt? Give us the dirt!

Conduition: The dirt is the verification speed, honestly. 1 millisecond is actually not that great in the grand scheme of things. It’s about 50 times slower than module lattice, otherwise known as Dilithium, and about the same amount slower than schnorr. So, it’s much slower in the overall zoo of post-quantum signatures. That number is being worked on a lot and it’s the primary metric that most researchers seem to be optimizing for now. Given they already have a giant leap forward in compactness, they’re now trying to get it competitive on terms of verification speed. Now, there’s been a bunch of new research since 2022, with the rediscovery of a theorem called Kőnig’s lemma, that has been to massively improve signing performance, but verification speed wasn’t affected that much. So, that’s, I think, now the dimension that they’re trying to meet.

Mark Erhardt: Yeah, I mean, signing performance is not quite as important as verification. Everybody has to verify; only one person has to sign. So, it being 50 times slower would, of course, be a bit of a problem. Although, of course, with the signatures also being 2.5 times bigger, there would be a few fewer signatures per block, probably. So, overall, that would significantly slow down block validation of full blocks. My understanding is that isogeny is more new cryptography still, lots of new cryptographic assumptions. Could you maybe touch on how this compares to the assumptions we are currently making in Bitcoin?

Conduition: Oh, yes, absolutely. Now, the fundamental assumption of IBC, I already defined it a little earlier. Given two curves, find an isogeny between them, specifically supersingular curves, because of the security properties of how curves are connected on what’s called the supersingular isogeny graph. That assumption is actually equivalent to another well-studied assumption, called the endomorphism ring problem, which is given a supersingular curve, find this mathematically-related object called an endomorphism ring. And those two are actually so equivalent that in SQIsign, the endomorphism ring is the secret key, because you use it to create signatures. The isogeny between E0 and your public key can be used to derive the endomorphism ring and vice versa.

Now, the cool part about the assumptions of isogeny cryptography is they actually rely on a lot of math that already has been studied. So, elliptic curves are in use in Bitcoin today all the time, constantly, and we use all the same math that IBC uses, but it’s just a different set of assumptions. So, it’s still a very well-studied field, it’s just a set of new hard problems that we rely on. These are still well-studied. They’re not as well-studied as the ECDLP, but there’s no denying that they are still new assumptions. Now, those aren’t actually so worrying to me as other assumptions that specific schemes have to make. A key example here was SIDH. SIDH relied on the Supersingular Isogeny Path Problem, but it also relied on this assumption that the torsion points, which are like pieces of data attached to the public key, that those torsion points didn’t leak information. And that turned out to be very wrong, which they proved in 2022 with the Castryck and Decru’s attack on SIDH.

Now, that is the same genre of attack that I would be most worried about with schemes like SQIsign and PRISM. If you would allow me a moment to elaborate here, I want to show you the distinction between these two and why their security proofs are actually almost like invertedly related. They’re like complementary, so that SQIsign relies on prime degree isogenies being easy to simulate. In the signatures for SQIsign, they include these prime degree isogenies, which are essentially just, you know, what a degree of a polynomial is. Think of it the same thing for an isogeny. It’s the measurement of complexity in the isogeny. And in the signatures of SQIsign, you include a prime degree isogeny, and in the security proof, you have to simulate that somehow. But it’s not exactly obvious how to do that, and it turns out to be such a hard problem to simulate prime degree isogenies that Andrea Basso and a bunch of others, like de Feo and so on, came up with a new scheme based on that assumption, that producing prime degree isogeny seems hard. It’s called PRISM. I alluded to it earlier.

So, as a result, you now have two schemes where depending on whether this problem is actually hard or not, one scheme or the other can be proven secure, but not necessarily both. So, it seems good to assume that either SQIsign or PRISM are secure, but it seems not easy to prove both.

Mike Schmidt: I was just going to ask, Where are isogenies used currently? What are the current applications of this in industry or otherwise?

Conduition: I haven’t spoken with anyone who’s using them in industry yet. They seem still well in the realm of research, and I think that’s mostly because they haven’t been standardized by NIST.

Mark Erhardt: Well, maybe we need to get some standardization by the Bitcoin Institute of Standards, the BIST! But no, I mean this sounds super-promising in the sense of the blockspace use, the tentative compatibility with a lot of the features that we have been using in wallets. The speed sounds a little concerning. I imagine that blocks full of these signatures would significantly slow down IBD (Initial Block Download) and, well, somehow we’ve been talking about that already a lot in the last year. So, yeah, go ahead.

Conduition: I have one idea for how to optimize for that. So, it’s a kind of a blunt answer, but what about STARKs, right? If you have a block that’s full of very difficult-to-validate signatures, one person can produce a zero-knowledge proof that these signatures are all correct without validating any of the other consensus rules, by the way, it’s just signature validation here that we’re worried about. You could actually do this over all blocks, and this would significantly speed up IBD, although producing that proof would be very onerous.

Mark Erhardt: Right, so that would sort of give nodes that are trying to catch up to the blockchain a way out or a way to speed it up. But one of the big problems about block validation needing to be fast is, of course, that it limits how quickly other miners can start working on the block. So, once the block comes in, if it’s way slower to validate, that might in itself be a problem already.

Conduition: Absolutely. I think in order to assuage the risks associated with a higher verification time, we should really be looking at ways to amortize that cost. And right now, there’s no effective batch verification for SQIsign, or at least nobody has looked into it as far as I’m aware. I haven’t read any papers about it, there’s nothing akin to CISA. This is all open research that I think would be well in need of funding and research by the Bitcoin community, since they are primitives we often rely upon and would really desire in a post-quantum scheme.

Mike Schmidt: Well, Conduition, thank you for joining us today. I’ll plug very quickly that if you liked this discussion with Jonas Nick and Conduition and myself, we will be joined by Taj on the open-source stage in Vegas and talking about signature schemes. I will be asking similarly naïve questions to these smart people, who will give answers for us all to understand hopefully a bit better about the different pieces of post-quantum crypto that they’re working on. So, Conduition, thanks again for joining us.

Conduition: Thank you very much, Mike. It’s been a pleasure.

Wallet fingerprinting risks for payjoin privacy

Mike Schmidt: Cheers. We’re going to bounce back up to the news section. We’re going to talk about wallet fingerprinting risks for payjoin. And we have Armin on, who posted to Delving Bitcoin about how differences between the different payjoin implementations can allow it to be possible that there’s some fingerprinting going on of the transactions. And I’ll let him get into the different categories of fingerprinting. But Armin, how would you frame your research; why did you start looking at this; and then we can get into what you found?

Armin Sabouri: Yeah, thank you. This is something that we’ve been thinking about as a team for quite a long time, specifically how differences in wallet policy, bugs even, can be used to partition the inputs of the receiver and the sender and their outputs as well in a payjoin. And so, what this blog does, it just sets up what this attack would look like and then applies it to three transactions that I know are payjoins. And what we attempt to do is exactly that, partition the inputs and then recover the payment amount using some value analysis. But this is kind of like a teaser to a more general attack or a more general heuristic that could be built, that takes into consideration fingerprinting distributions. After all, clusters are meant to be entities with common owners, so it would only make sense that they share the same fingerprints. So, just kind of setting up the groundwork for some future research. I’ve used a lot of jargon and words already. Let me take a step back and just talk a little bit about payjoin and wallet fingerprints, and then maybe we can go through some of the examples.

So, from a privacy preserving point of view, what payjoin attempts to do is to add doubt into the common input heuristic. This is a heuristic that chain analysis uses very frequently and it’s accurate as well. Essentially, what this heuristic says is if there is inputs, the inputs of a transaction belong to the same person. So, if you have a transaction, it’s got five inputs, those belong to Bob. And we would cluster those outputs and put Bob on it. And maybe using some other information, we could find out who Bob is. That’s kind of its own rabbit hole. What payjoin does is it has the sender and the recipient interact, so they can both collaborate and make the transaction together. Concretely, the sender sends the fully signed transaction to the recipient. The recipient contributes their own inputs and maybe outputs the transaction and sends it back, sender signs it, broadcasts it. Now you have a transaction with multiple inputs that belong to different wallets. And now, an analyst would apply a common input heuristic and get false results, false positives. But note that this only works if the transaction is indistinguishable from a unilateral single wallet transaction.

So, the analyst’s job is then to find artifacts of collaboration, is there any behavior that is inconsistent with a single wallet producing this transaction? And there’s been other work that’s done similar things. Simin Ghesmati has a paper that looks at unnecessary inputs, is there any oddities in coin selection that a single wallet just wouldn’t do? Is there like weird inputs added there that are inexplicable? And fingerprints kind of are another tool for a similar job.

So, what are wallet fingerprints? So, wallets construct transactions. And when they do that, they’re making tons of small decisions about what this transaction should look like, how the inputs are sorted, what coins to select, fee estimation, signature encoding. And the whole idea is that these manifest onchain in the transaction themselves, and they can be used to identify the wallet that actually created it. So, I linked some previous work by Ishaana Misra that did this comprehensive study. She looked at a dozen wallets, a bunch of fingerprints. She found which wallets produced what fingerprints and then attempted to attribute onchain transactions to the wallets that created them.

Now, we use wallet fingerprints a little bit differently in this kind of work. For us, it’s not important what wallet actually produced the transaction, but just the fact that there are seemingly two different wallets collaborating. So, to recap, what we do is we detect artifacts of collaboration via wallet fingerprints. We partition the inputs and outputs by sender and recipient, and then you could apply your normal heuristic to those sub-transactions. Last thing I’ll add here is that there is kind of two ways to apply wallet fingerprinting. There is what I call intra-transaction fingerprints, which are fingerprints that are available just in a single transaction. So, think about a transaction with some inputs that have nSequence sent to one number and then other inputs are nSequence sent to another number. A normal wallet wouldn’t really do this. This is consensus-valid, but why would it do that? So, with high probability, we can say, “Hey, there’s something going on here. Maybe two wallets are working together”. Whereas inter-wallet fingerprinting is looking at the adjacent transactions. So, do the outputs of this transaction get spent into a transaction that looks really different from how the other outputs get spent? Is there a fingerprinting there? And same thing for the inputs. How do the previous transactions look like?

So, with those two things in mind, you can kind of apply this framework to payjoins and try to partition the inputs and recover the payment amount on top of some value analysis. And that’s what I’ve done in these examples. I’ll stop there and see if there’s anything you guys want me to elaborate on.

Mark Erhardt: Very good overview. So, actually, when I read our description of your work, I was curious what sort of fingerprints you saw in the input encoding. Are you talking about the sighash flags and signature grinding, or is there something else that might appear there?

Armin Sabouri: That’s a good question. So, yeah, in the two examples that I have that look for –actually, I think all three of them have inconsistencies in their inputs. So, the first example is probably the weakest wallet fingerprinting signal. What you have is two inputs. One of them is grinded with a low-r, the other one is a high-r input. And the only thing you can really say about this transaction is that this wallet doesn’t do low-r grinding. What you would need to do is look at the adjacent transactions to say, “Does one of these inputs come from a cluster with exclusively low-r values and now it’s getting spent in this high-r mix? Okay, that is a signal that this wallet’s now behaving different. Why? Maybe there’s another wallet in the mix”.

The second example is a much more clear signal. There is two P2TR keyspends. One of them has an explicit SIGHASH_ALL byte, the other one omits it. And under taproot’s consensus rules, you can omit it and by default it’s SIGHASH_ALL. There’s really no reason a wallet should include that byte. It’s more of a bug than a policy. I think there was a Stack Overflow exchange question. I was like, “Who is producing these?” I think it’s just people who don’t know about that consensus rule.

Mark Erhardt: Yeah, I mean previously, SIGHASH_ALL had to be stated explicitly. It’s only in P2TR that it is now implicit by default and you don’t have to state it. So, people that didn’t look too carefully at the spec might have missed that they no longer have to state it explicitly. So, yes, this is a bug in the sense that you’re paying for a weight unit that you don’t have to produce, and it’s a fingerprint. So, really nobody should be ever explicitly stating SIGHASH_ALL. We should have probably not allowed stating SIGHASH_ALL because it’s the implicit behavior that would have been maybe better. I don’t know why. Maybe some hardware wallets or signing devices by firmware didn’t have the option not to produce a sighash, and that was a backward-compatibility thing. But generally, it just seems like if you don’t have to state it, we should have not allowed stating it. But again, I’m probably missing some background here.

Armin Sabouri: I would love to know this piece of Bitcoin lore. If anyone knows, comment wherever, just tag me, I want to know what’s up. But in general, optionality leads to reduced anonymity sets is something we just talked about with this post-quantum conversation. So, let’s just reduce optionality where we can.

Mark Erhardt: Funnily enough, it’s exactly the same with the low-r grinding. Everybody should be doing low-r grinding, because it’s like literally a second signature, on average, will give you the low-r signature if the first one doesn’t. And again, it also saves a byte in the witness stack. So, just paying for data you don’t have to pay for.

Armin Sabouri: I mean, this is an interesting point. When it comes to fixing wallet fingerprinting, there’s kind of two schools of thought. It’s like, let’s spec everything. Let’s spec how we sort inputs, BIP69, low-r grinding. But the other school of thought that critiques this is, well, wallets are never realistically all going to behave the same, so why don’t we just randomize everything? Okay, do low-r grinding once in a while, but then just throw a mix in there. Set nLockTime to anti-fee sniping. Maybe don’t do it there. I don’t have a great answer to this. But the only thing I’ll say is that it does feel like there’s a lack of data in this conversation. I feel like wallet developers generally don’t have the data to back up their decisions. I see a lot of GitHub threads where people say, “This will fingerprint us”. But you need to understand what your approximate transactions look like. Fingerprinting is a dynamic problem.

Mark Erhardt: Yeah, actually, I think that for some of the discussed fingerprints, there’s an obvious better way and everybody should do it. And for other fingerprints, going random is the way to go. For example, the order of inputs is very hard to – like, by spec’ing the order of inputs, you’re actually producing a fingerprint, which is hard to hide. And for some applications, you simply cannot fix the order. So, I think in many cases, that is pretty obvious. Maybe we do need to write up a little more about how not to fingerprint wallets. I guess that could be an interesting project.

Armin Sabouri: I forget where I left off. I think I was talking about the examples. Quickly on the last example, so this last one is actually a production payjoin between Cake Wallet and Bull Bitcoin, where Cake Wallet is the sender and Bull Bitcoin is the recipient. The first thing that sticks out in this transaction when you’re looking at it is this nSequence = 0x01, and that’s consensus valid. You can do a BIP68 locktime of one block, no reason not to. But I know this is a payjoin and the thing that was confusing to me is why is Bull Bitcoin matching the nSequence value? This seems odd that both of them would have this relative timelock of one block. It turns out in PDK, we actually match the counterparty’s nSequence. If they send something to me, I’ll just match it and then we avoid the intra-transaction fingerprinting problem. But if you go to this ASCII diagram I have on the blog, you’ll see that this doesn’t help you at all. If you just look at the previous spends, one of the inputs was spent in a transaction that uses the opt-in RBF nSequence value, 0xfffffffd, the other one sticks to 0x01, and that’s pretty clear indication that one input belongs to one wallet, the other one belongs to another, and the same thing for the subsequent transaction.

Mark Erhardt: And in this case, I think that might also actually tell you who initiated, right? Because if you match the initial value, you know which one was the initiator, right? And that tells you who the sender and receiver are.

Armin Sabouri: Yes.

Mark Erhardt: So, this is actually even worse.

Armin Sabouri: Yes, this is correct. Yes, correct. It turns out the nSequence = 0x01 value was kind of a bug. It wasn’t meant to be there. I think they were just trying to opt into RBF.

Mark Erhardt: Also, we don’t have to do that anymore. Since Bitcoin Core v28, we accept replacements for transactions where the original did not opt into RBF. So, all of the signaling nSequence flag stuff could be more homogenous at this point.

Armin Sabouri: Yes, however, one thing to keep in mind is that the very act of RBFing is a fingerprint, if you’re observing the mempool. So, not all wallets actually implement RBFing, let alone opt-in. So, if you’re observing the mempool, you can still do this kind of intersection.

Mark Erhardt: Although that increases the data you have to collect a lot. You can’t get that from the blockchain, right?

Armin Sabouri: Correct, but you just have to observe. So, it depends on what your risk level is. Yeah, go for it, Conduition?

Conduition: I just wanted to ask, to what extent are these problems solvable, like in a high level view?

Armin Sabouri: Yeah, that is a good question. So, there are some bugs, like the nSequence bug, that are trivial to fix, right? So, I mean the whole takeaway from this blog is that you can’t just add payjoin or other privacy, like interactive privacy protocols on top of your wallet, and just expect the magic box to give you privacy. You kind of need to be aware of your counterparty’s fingerprint, and not only for the single transaction, but for the whole subgraph. I don’t have a great answer to your question, like, can we solve this? It kind of goes back to what Murch and I were talking about. It’s like, do we just spec this problem out of existence, or can we just randomize everything? I think we just need to collect more data and just understand how bad the problem is today, like what do the fingerprinting clusters look like? Are we all homogenous? Is there a cluster that really sticks out? Until we have just more data, it’s hard to say.

Mark Erhardt: Yeah, I think there’s an awareness issue here. I think that a lot of wallet developers probably haven’t really looked at it all yet. So, if there were a best practice, maybe a BIP or something that describes, “Hey, here are recommended fingerprint behaviors”, and people over time would migrate to these. A lot of them might just disappear over time. Of course, the problem is that we have no control over how long people continue to use old versions of software. Or if there’s maybe businesses that have their own implementations of things and just don’t care, they might end up sticking out more because they do not migrate to the homogenous defaults, the recommendations. Beyond that, a lot of them could be fairly easily mitigated just by, for example, not setting the RBF flag anymore is the default behavior for people that never supported RBF. And now, the wallets that did update and that continue to update might just stop signaling RBF. Signature grinding makes sense, also is irrelevant with P2TR, because the signature sizes in P2TR are already fixed, and so forth.

So, I think we’re moving slowly towards some of the fingerprints going away, but there is an awareness and a momentum issue, where some people just cannot be arsed to ever stop using the first wallet they downloaded in 2012 and stick out like a sore thumb.

Mike Schmidt: Armin, anything else for listeners, and also next steps after this research, if any?

Armin Sabouri: Yeah, so this blog was really meant to set the stage for a larger-scale attack and survey of the chain. So, what I’m really interested in is how bad the problem is. Like I mentioned before, what does the chain look like in terms of wallet fingerprints? And then, second, if you take the three examples and the kind of attacks I’ve done on them, there’s a more general version of them, which is a different version of multi-input heuristic, one that doesn’t just blindly partition the inputs together, but looks at the clusters of the inputs and their fingerprinting distributions and considers that first. Because right now in the literature, we just look at transactions that look like they’re interactive and just ignore them. So, if you see a coinjoin, which are easily fingerprintable, you just ignore it and go cluster something else. But my argument here is that chain analysis is and can do better. We can look at fingerprints, we can look at other behavior onchain and use that to do smarter partitioning.

Last thing I’ll say is that fingerprints are not really a problem just for collaborative privacy protocols. They affect everyone’s wallets. So, for example, if you have a wallet that produces very distinct transactions, I can infer other things about your wallet and do smarter heuristics. Like, maybe I know your wallet and I know where it places the change. Now I can do a much smarter change classification heuristic. There are so many rabbit holes to go down with wallet fingerprinting, and they’re all fun and interesting. So, if you want to work on this, I’m looking for more people to work on this with me. So, just reach out. And yeah, let’s solve this problem.

Mark Erhardt: Yeah, I was wondering whether you had some input from previous researchers that seem to be located in a similar area of the world.

Armin Sabouri: Yeah, so the tools that I used to do this research were previously a Python version. So, Ishaana built this and I already talked about her report. There’s a link on it in my blog. So, we didn’t work closely together, but I certainly used a lot of her existing tools to do this kind of work.

Mark Erhardt: All right, yeah. Thank you very much, Armin, this is fun. Also, something that I personally find interesting. So, maybe we’ll chat offline sometime.

Armin Sabouri: Cool, thank you very much.

Mike Schmidt: We appreciate your time, Armin. Cheers.

Armin Sabouri: Thanks.

Draft BIP for a wallet backup metadata format

Mike Schmidt: And our last News item from this week, “Draft BIP for a wallet backup metadata format”. Pyth, you posted to the Bitcoin-Dev mailing list about a new proposal. It is in the BIPs repository as #2130. The idea here is coordinating on some sort of a common structure for a wallet backup metadata format. Do you want to walk us through maybe your experiences in this space that led to you wanting to standardize this?

Pyth: Yeah, so this started last year when we decided to implement a backup or export format for Liana. And so, at that time, I started looking to other wallets and how they were doing. So, I was looking at Core and there is not really an export format, you can just copy the database. And Sparrow does the same, you can export the database. And I looked to a few others. Yeah, there is no common interoperable way to pass your metadata from one wallet to another, except just passing the descriptor. But it’s not enough in many cases. So, I do a post on Twitter and I think if you want a developer, and I just share my draft of a spec before implementing in Liana. And I just recently proposed a BIP about this to try to get more feedback and to define also what we have done, because we implemented last year and we’re not yet open.

Mark Erhardt: Yeah, this seems to be a popular topic this year, or in the past few months. We’ve had a BIP proposed for the labels on transactions to export those and import those for wallets; there’s been two backup format proposals; and there’s been a way of adding metadata to descriptors recently proposed. So, this seems to be definitely coming at the right time. There are a bunch of people thinking about this. I was wondering, how much are you working with these other proposals? Have you looked and read them?

Pyth: So, in fact, this BIP was on my to-do list since I implemented in Liana. And a few months ago, Salvatore posted on Delving an encryption scheme for ENCRYPT. At first, a descriptor, but everything in a way that want to be easy to interact with signing device. And because it was something we was talking internally at Wizardsardine for many years, because we want a way for backups of descriptor, but encrypted, because we want to send it by mail or store it online but we want to encrypt it. And so, after Salvatore draft this specification, I started working on and implementation of this, and we get some back and forth. And after, I open a BIP for that. And so, in this BIP, I first author three types of payload we can encrypt. The first one is just a bare descriptor; the second one was just BIP329 labels; and the third one was this specification. And Sjors sheened the PR and told me, “Why you don’t just put any BIP number so we can encrypt anything that is defined by another BIP number in the future?” And so, I have this BIP draft open for many months and I wait to undraft it, to have also this second BIP draft, so I can cross-reference it. So, that’s it.

Mike Schmidt: Murch, I see you’ve commented, you were the first commenter on this draft BIP. Did you have anything you think would be applicable for the audience on this?

Mark Erhardt: I must admit, I was on vacation last week and I did see it come in, but I haven’t fully read it yet. So, I refrain from commenting too heavily right now. I just noticed that there are a bunch of different projects going on right now that seem all topically related. Yeah, so I think that probably the other authors that are currently working on similar schemes will be the best reviewers of this, but I’m looking forward to reading it fully and then maybe making some suggestions myself.

Mike Schmidt: How has feedback been, Pyth?

Pyth: So, the first time I talked about it on Twitter last year, I got a few feedback from two or three wallets that I integrated in, because I just published a repo on GitHub and some open PR, some open issue, and we started talking on it. And I got a few reviews last week, and I think, yeah, people started coming in.

Mike Schmidt: Yeah, Murch mentioned the flurry of similar, I guess, activity. I think we had Craig Raw on to talk about descriptor annotations, I think it was a few weeks ago. And so, yeah, I hope you all can keep your communication lines open with each other and come up with something that is useful for everyone.

Pyth: The proposal of Craig, I think it’s for a different use case, because it’s only attaching few metadata to the descriptor and it’s a backup you do only once when you create your wallet or your descriptor. While the format I offer, it’s more recurrent backup you will do for backup the state of your wallet, because it will include your label, your coin. And if you have a silent payment wallet, you will have all the information around your coin that you need to backup every time you got new coin or you spend coin.

Mark Erhardt: So, I mean, generally the idea to have a standard for how to backup all the information, all the wallet state, it would be very useful there. There are a ton of different wallets. And if this proposal gets adopted broadly, it would of course allow these different wallets to import their backups which, for example, could be very useful when wallets stop being supported or people want to import a backup five or ten years later. If it already used the standard, the standard would probably continue to be supported, and they could just import their backup into a different device or different software. So, the underlying idea of having a standard for how wallets are backed up is very useful. I’m just curious, I haven’t looked at it too deeply yet, but with so many proposals that are sort of adjacent or overlapping, I hope that we can find something that we don’t have 13 standards in the end!

Mike Schmidt: Thanks for joining us and thanks for your work on this and thanks for hanging on to get to this point in the show. We appreciate your time.

Pyth: Thanks for having me.

Varops budget and tapscript leaf 0xc2 (aka Script Restoration) are BIPs 440 and 441

Mike Schmidt: Cheers. Okay, jumping back to the Changing consensus segment, we had one more item that we didn’t cover, that we don’t have a guest for, at least this week, titled, “Varops budget and tapscript leaf (aka ‘Script Restoration’) are BIPs 440 and 441”. Since this was mostly talking about BIP assignments and some references to previous newsletter posts, we didn’t think it was worth trying to rope in Rusty just yet to talk about it. But we do have Murch who I think has some news on each of these or some color commentary.

Mark Erhardt: Yeah, I spent some time reading these. And basically, the main idea is that it reintroduces most of the disabled opcodes. I think it was 2010 or so when Satoshi decided that some of the opcodes were too risky. One of them was actually broken and there was a way for people to spend other people’s coins. So, Satoshi just swept a bunch of opcodes away that either had DOS potential or security vulnerability potential, and they were disabled. And ever since then, some protocol developers, or people that were more excited about complex output scripts, had been griping that they would love to have back all of these opcodes in order to build more complex smart contracts. And smart contract is not a dirty word. It’s simply a Pythian expression for saying that there are conditions that can be evaluated to ensure that spending conditions are met and outputs can be spent in more complex manners. So, very specifically, these proposals introduce a new cost scheme, the varops budget, where they assign a cost for each of the opcodes based on how much data they process. This is a new limit that is backwards-compatible with the sigops limit, and essentially ensures that there is no overt complexity in the validation of these new scripts. And then, of course, it also activates the mentioned opcodes again.

There’s a few arithmetic opcodes there and there are some bitwise operations, and OP_CAT is in there, which has been discussed a lot last year or two years ago. Yeah, I don’t have the list right in front of me. There is, however, also news. This PR was merged this morning, so BIP440 and BIP441 were published this morning. They are now published in draft status to the BIPs repository.

Mike Schmidt: So, Murch, if I have it right, 440 is the budgeting mechanism, the varops that we’ve talked about on previous shows, is that right? And then, 441 is the actual, okay, these opcodes are now valid?

Mark Erhardt: Well, proposal to deploy it. So, this is of course a soft fork. It would use a bunch of the OP_SUCCESS opcodes. Maybe that isn’t clear, but the number of opcodes is of course limited to the bytes that were set aside from when Bitcoin was defined. And the same opcodes that were used originally for these operations are still available, and they’re now OP_SUCCESS in taproot. So, the idea here is to introduce a second version of tapscript. And so, these opcodes would only be available in script leaves in P2TR outputs that use a new version of tapscript in the leaf script. So, it would be injected into P2TR, so to speak. I assume that it would also be compatible with P2MR (pay-to-merkle-root) if BIP360 gets deployed. So, now, of course, the bigger or the surrounding conversation has to be, do we want all these opcodes? Is the varops budget proposal reasonable and satisfies all of our concerns around DoS and computation and validation? And then, you know, it can take a little while to activate a soft fork.

Mike Schmidt: And we’ll leave those questions, I guess, for listeners in the Bitcoin community to evaluate. I guess we’ll talk a little bit more about this as well next week, since that’ll be in the Notable code section.

Mark Erhardt: Yeah, maybe one more mention. Originally Rusty proposed four documents. So, there’s only two of those written and published so far. I am not intimately familiar what the content of the other two would be, but there might be more documents coming that would be part of a deployment that gets proposed. I think one of them was named OP_TX, which is, from what I recall, a similar idea as OP_TXHASH or OP_CTV (CHECKTEMPLATEVERIFY), but slightly different flavor. And I don’t remember what the fourth was.

Mike Schmidt: The fourth was OP_MULTI and OP_SEGMENT.

Mark Erhardt: Okay. I cannot speak on either of those! Anyway, I don’t know how far along this is towards a deployment or anything, but the first two documents that had been proposed in the context of the Great Script Restoration are now published. And I think they, after a first hiccup, I read the BIP441 first and was like, “This is very confusing”. And then I read 440 and I was like, “Oh, I should have read 440 first”! So, I recommend reading them in the order they’re numbered. But other than that, I now consider them very readable. And now, it’s just about what we want to do as a Bitcoin community, which soft forks we should activate, you know, the usual.

I was recently reminded and had totally forgotten about that. We actually have multiple, not just one, but multiple soft fork proposals in flight right now that we are supposedly signaling for. I think we reported on that in Optech. But I had totally forgotten about some of them, because there’s literally no public discussion of them. So, I assume that none of these three activation attempts currently will be successful, simply because there’s not even a public footprint of the discussions about them. Well, one of them has a public footprint, but I don’t think it has broad support. Anyway, it sounds like there might be more soft fork proposals coming. There’s also, of course, a lot of discussion about BIP54 recently and the consensus cleanup. So, yeah, maybe this is a new era of software proposals.

Mike Schmidt: If listeners are curious, those BIPs that Murch mentioned that are part of Script Restoration, we talked about those in Newsletter and Podcast #374, where we dug into Rusty Russell’s proposed summary of four BIPs in various stages of draft at the time. Two of those are now assigned, which is what we just talked about, and then the other two that Murch referenced are also in there. We talked about that in that show. I think we can move on out of the Changing consensus segment, out of the News segment, and onto Releases and release candidates and Notable code and documentation changes with Gustavo.

Bitcoin Core 31.0rc2

Gustavo Flores Echaiz: Thank you, Mike, Murch and everyone. That was a great, interesting conversation. Now we get to the Release section. So, this week we have two RCs, the first one from Bitcoin Core v31. So, this is the second RC of the series. You can find a testing guide that will allow you to test the different components. But the core of the v31 is the release of cluster mempool. So, there’s multiple ways you can test cluster mempool, either through the new RPCs or different scenarios related to high-fee parents with low-fee childs, or similar things like that. Also, the private broadcast, which was also introduced and will be part of the Bitcoin Core v31, is also part of the testing guide and the embedded ASMap. So, an autonomous system numbers map is now embedded in Bitcoin Core, so that is also part of the test guide. So, you can find further information on that link directly on the newsletter.

Mike Schmidt: And we also had Sebastian, who authored the testing guide, we had him on in #397 Recap, and he walked us through that. So, if you’re curious about the testing guide, maybe some things have changed in this latest RC, but I assume most of it’s the same, so check out that podcast as well.

Core Lightning 26.04rc2

Gustavo Flores Echaiz: Thank you, Mike. Yes, that’s right. #397 was when we introduced the first RC. And for the second release, Core Lightning 26.04, this is also its second RC. And its first release candidate was in #398. So, this one is mostly about splicing updates, now that splicing has been merged in the BOLTs repository. Core Lightning (CLN) improved their implementation, but also added new commands related to splice-in and splice-out. So, that is the core of this release, with other bug fixes and additional improvements.

BTCPay Server 2.3.7

Finally, the third release is BTCPay Server v2.3.7. So, this is a minor release. The main issue at hand here is the migration to .NET 10. So, we’ve also linked to a guide that the plugin developers should take a look at on how to migrate from .NET 8 to .NET 10, since .NET 8 is reaching end of support later this year in November 2026. So, worth looking at those that upgrade to that new version of BTCPay Server. It has some additional features and bug fixes as well, but this is the first release that uses .NET 10. So, important to look at that.

Mark Erhardt: Just curious, wouldn’t migrating to a new programming language version be more than a minor release? It strikes me as potentially compatibility-breaking, but anyway, it just jumped out at me that migrating to .NET 10 feels like a potential major version or minor version. Anyway, yeah.

Gustavo Flores Echaiz: Right, that’s a good question. But yeah, this is actually a minor release.

Mark Erhardt: Sorry, actually 2.3.7 would be a patch release, right, .7? And it’s usually major, minor, patch. So, anyway, sorry, please continue!

Gustavo Flores Echaiz: No worries, thank you for that comment. Yes, so those are the three releases of this week. There’s a possibility to expect other RCs for Bitcoin Core and CLN, but for now the testing guides are there. And BTCPay Server, well, this is just a new version for this migration, but with other additional features. For those that are more interested, you can take a look at the release notes in BTCPay Server to find out all the information related to it. Any comments before we move on to the next section? No, perfect.

Bitcoin Core #32297

Okay, so this week, we have about seven new PRs that we present. So, the first two are from Bitcoin Core. The first one, #32297. This is a new option that is being added to the bitcoin-cli command, called -ipcconnect. So, when you use bitcoin-cli with the -ipcconnect command, you’re basically instructing it to connect and control a Bitcoin node instance via inter-process communication (IPC). So, this is something that we’ve covered in multiple newsletters. You can find the link to Newsletter #320 or #369, where we talk about how Bitcoin Core multiprocess separation project has basically built a separate binary for different parts of Bitcoin Core, right? So, you can have the Bitcoin node binary be separate from, let’s say, bitcoin-cli control a bitcoin-node instance that are both separate. And this is done through what’s called IPC over a Unix socket instead of the HTTP protocol, when the binary of Bitcoin Core has to be built with ENABLE_IPC and started with -ipcbind, so that it can be controlled through a separate bitcoin-cli instance, can control it through the IPC connection.

So, this PR not only adds this option, but also makes it the default behavior. So, even if you omit this option, your bitcoin-cli program will still try to connect through IPC and try to find a bitcoin-node instance that has been built, a binary that has been built with ENABLE_IPC, and it will fall back to HTTP if it’s unavailable, right? So, you don’t even need to specify this option. It will look for a bitcoin-node instance that can be connected through IPC. So, just to close on that, that this is part of the multiprocess separation project. This has been a multi-year project that is doing some progress, but still a lot of work remains to be done.

Bitcoin Core #34379

So, the next one is a fix in Bitcoin Core #34379. This is a fix that applies to the gethdkeys RPC, which is an RPC which returns each xpub used by the wallet, and also each xpriv used by the wallet. So, here, the bug is the same bug that we covered in Newsletter #389 for the listdescriptors RPC. So, basically what happens is if in your wallet, not all of the keys have a private key, and you try to obtain all the private keys with that command, it would fail because it would find that some pubkeys didn’t have the matching private key for them. So, similar to the other fix that we presented in #389, now this command will return all the available private keys, even if some of the pubkeys don’t have a private key. So, it won’t fail if there’s a missing private key, it will just return what it has and let you know that it doesn’t have some other ones, right? But however, if you call gethdkeys with the option private=true on a wallet that is strictly watch-only, well then it has to fail, right? So, that behavior is preserved because if it doesn’t have any private key, it has to fail. But if it has some and has some missing, then that is fixed and is now properly returned.

Eclair #3269

So, those are the two additions to Bitcoin Core and now we move forward with the LN implementations. So, on Eclair #3269, there’s a new addition of something called automatic liquidity reclamation from idle channels. So, what happens if you had channels that were absolutely never used, which you could then manually claim back the liquidity? But what if you could have a system that could allow you to automatically claim back liquidity from channels that are not used at all. So, now what occurs is that this component from Eclair, called the PeerScorer, when it detects that it has fallen below 5% of its capacity, it will reduce relay fees down to the minimum gradually, right? So, through multiple iterations, it will reduce fees and try to see if that would change behavior, if that channel gets used more by peers. But if it doesn’t, if the fees reach a minimum and stay there for at least five days and the volume doesn’t pick up, then Eclair will proceed to close that channel, only if it has a redundant channel with that peer. So, it won’t close the channel if it’s the only channel with the peer, but if it’s the second channel with that peer and it’s the least one used. And also, it will always prioritize keeping public channels and closing private channels if it has that choice.

So, after those five days, that’s when Eclair proceeds to close that channel if it’s a redundant channel. And it will only also close it if it has at least 25% of the funds held in the local balance. So, if it’s mostly a channel that you control, that the balance is mostly on your side, or at least over 25%, then you will close it. If it’s a channel where your balance isn’t consumed, so it’s not so much of a risk for you to have that idly, then it will be kept. So, that’s the Eclair update of the week.

LDK #4486

Finally, we have two for LDK and two for LND. So, in LDK, there’s an update to something we have presented in Newsletter #397. So, in #397, we had announced that there was new support for RBFing, so fee bumping, splice funding transaction. Now, there’s a rework in the mechanics of how that works. So, instead of calling the rbf-channel endpoint, that endpoint is now merged into the splice-channel endpoint as a single entry, so that new splices and fee bumping are all done through the same command. It was a bit unnecessary and redundant to have a separate command, because now when you call splice-channel and, let’s say, when you want to RBF a channel, when you want to feed bump it, you simply have to call the splice-channel command and you will receive a FundingTemplate with the prior contribution, which means the transaction will be shown to you so that it’s clear that this was a splice that was already in flight; compared to the situation where you’re trying to create a channel that doesn’t yet exist, you will simply be presented with a FundingTemplate that doesn’t have the prior contribution transaction and the details around the splice that was already in flight.

So, this is just a unification of endpoints to simplify and to facilitate user behavior. But there’s no difference in how it works behind the endpoint. So, you can look at Newsletter #397 if you want additional details on how RBFing a splice works in LDK. Any thoughts here? Nope? All right.

LDK #4428

So, the next one and the final one for LDK, LDK #4428, is the addition of support for opening and accepting channels that have zero channel reserve. So, this has been an open issue on the LDK repository for a couple of years already. And there was a few doubts about how to do this in a safe way. So, we can see that in October 25, 2022, more than about four years ago, someone had requested this and it was started to be unsafe. But now, this implements it in a safe way with a new command as well, a new method, called create_channel_to_trusted_peer_0reserve. So, this is mostly implemented for LSP experiences, where you are a user that is behind or being facilitated by an LSP, and you as a user want to use your full onchain balance in that channel. Because there’s already a sort of trust mechanic or component to the LSP user relationship, the LSP takes the risk of the user having no channel reserve. So, the user has technically more incentive to cheat, less of a penalty if he cheats, because there’s no reserve to put at risk. But because this is an LSP user scenario, or at least this is thought of to be used in those scenarios, then it’s a trust trade-off that the LSP can handle properly.

So, this is enabled for both channels with anchor outputs, and also zero-fee commitment channels, which were added in LDK in a previous PR presented in Newsletter #371. So, that’s the second from the LDK series.

LND #9982, #10650, and #10693

And now we get to LND, which the next item combines three different PRs from LND, #9982, #10650, and #10693. So, these three PRs, what they do is they harden or they improve the MuSig2 nonce handling on the wire for taproot channels. So, what does that mean? It means that when you use a simple taproot channel or simply when you use a MuSig2 transaction, it works very differently from ECDSA in the sense that nonces have to be generated for each transaction, these nonces have to be exchanged, and then the partial signatures can be done, and then there can be an aggregation of the partial signatures. And every time you make a transaction, you must generate, and each peer has to generate a new nonce. If you were to use the same nonce, which is something you should never do, but if you were to do that, then your private key could be sort of extracted. So, it’s very important for new nonces to be generated every time.

So, these three PRs basically build all the proper handling, or at least harden it, for different use cases related to not only funding transactions, but also splicing. And you can see in the next item, we’re going to be talking about RBF. So, this is about building the internal mechanics of how to build simple taproot channels that properly generate new nonces for MuSig2 partial signatures every time.

LND #10063

And then, the next PR, the LND #10063, and the last one from this newsletter, is the extension of the RBF fee bumping cooperative close flow. So, when you’re closing a simple taproot channel in a cooperative fashion and you want to RBF that close transaction, this PR now enables you to do it properly. And it is partially helped by the work that I had just described previously in the previous item, about MuSig nonce handling. So, now, the wire messages required for the RBF transaction of cooperatively closed simple taproot channel, the wire messages now carry specific nonce and partial signature fields related to this type of channel. And also, the closing state machine also uses what some call the just-in-time nonce pattern for MuSig2, because as I described, you need to produce new nonces every time. That is also properly implemented, so you can now RBF a cooperative closed transaction for a simple taproot channel with this PR. And in Newsletter #347, we had covered the introduction of this close flow that was added into LND, but that was for other types of channels. And now, this is brought into simple taproot channels.

I also want to point to Newsletter #393 on the last item, BOLTs #1289. We had announced and we had covered an update to the BOLTs repository of how commitment signatures were retransmitted when nodes would reconnect during a splice or a dual-funding transaction. So, BOLTs #1289 updated that commitment signatures when two nodes would reconnect, when two peers would reconnect. Previously, these commitment signatures would be retransmitted automatically. Now, they’re no longer retransmitted automatically because simple taproot channels indicate that a new nonce has to be generated every time, right? So, you cannot simply just retransmit signatures, you have to make sure that the peer didn’t receive it to retransmit it. So, if you want to learn more about just how nonce generation works for MuSig2 rounds, you can also take a look at that BOLTs update in Newsletter #393. So, it’s a BIP related to these last two items we covered in LND. We’re kind of seeing the implementation versus the spec that had been covered in #393. This is now the full implementation in LND of handling all of that. And that’s the last item and that completes the newsletter. Yes, Mike?

Mike Schmidt: Awesome. I was just going to say, good job, Gustavo. We want to thank our guests for today, Armin, Pyth, Conduition, and Jonas for joining us earlier. Good job on the Notable and Releases, Gustavo, and thanks for co-hosting Murch. And we’ll hear you all next week. Cheers.

Mark Erhardt: Cheers.

Gustavo Flores Echaiz: Thank you.