Bitcoin Optech

Bitcoin Optech Newsletter #394 Recap Podcast

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

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

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

Download audio

News

● Draft BIP for output script descriptor annotations (1:25)

Selected Q&A from Bitcoin Stack Exchange

● Is Bitcoin BIP324 v2 P2P transport distinguishable from random traffic? (35:16)
● What if a miner just broadcasts the header and never gives the block? (39:53)

Releases and release candidates

● Bitcoin Core 28.4rc1 (47:27)
● Rust Bitcoin 0.33.0-beta (47:46)

Notable code and documentation changes

● Bitcoin Core #34568 (48:48)
● Bitcoin Core #34184 (50:37)
● Bitcoin Core #24539 (51:57)
● Bitcoin Core #34329 (53:52)
● Bitcoin Core #28792 (15:35)
● Bitcoin Core #32138 (54:56)
● Bitcoin Core #34512 (56:44)
● Core Lightning #8490 (58:16)
● Eclair #3250 (59:07)
● LDK #4373 (59:55)
● BDK #2081 (1:02:13)

Transcription

transcription coming soon

Bitcoin Optech Newsletter #394

2026-02-27T00:00:00+00:00

This week’s newsletter looks at a proposed BIP for including supplemental information with output script descriptors. Also included are our regular sections summarizing popular questions on the Bitcoin Stack Exchange, announcing new releases and release candidates, and describing recent changes to popular Bitcoin infrastructure software.

News

● Draft BIP for output script descriptor annotations: Craig Raw posted to the Bitcoin-Dev mailing list about a new BIP idea to address feedback that emerged during the discussion around BIP392 (see Newsletter #387). According to Raw, metadata, such as the wallet birthday expressed as a block height, could make silent payment scanning more efficient. However, metadata is not technically needed to determine output scripts, thus it is deemed unsuitable for inclusion in a descriptor.

Raw’s BIP proposes to provide useful metadata in the form of annotations, expressed as key/value pairs, appended directly to the descriptor string using URL-like query delimiters. An annotated descriptor would look like this: SCRIPT?key=value&key=value#CHECKSUM. Notably, characters ?, &, and = are already defined in BIP380, thus the checksum algorithm would not need to be updated.

In the draft BIP, Raw also defines three initial annotation keys specifically to make funds silent payment scanning more efficient:
- Block Height bh: The block height at which a wallet received the first funds;
- Gap Limit gl: The number of unused addresses to derive before stopping;
- Max Label ml: The maximum label index to scan for, for silent payments wallets.
Finally, Raw noted that annotations should not be used in the general wallet backup process, but only for making funds recovery more efficient without altering the scripts produced by the descriptor.

Selected Q&A from Bitcoin Stack Exchange

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

● Is Bitcoin BIP324 v2 P2P transport distinguishable from random traffic? Pieter Wuille points out that BIP324’s v2 encrypted transport protocol supports shaping traffic patterns, although no known software implements that feature, concluding “today’s implementations only defeat protocol signatures that involve patterns in the sent bytes, not in traffic”.
● What if a miner just broadcasts the header and never gives the block? User bigjosh outlines how a miner might behave after receiving a block header on the P2P network but before receiving the block’s contents: by mining an empty block on top of it. Pieter Wuille clarifies that, in practice, many miners actually see new block headers by monitoring the work other mining pools give out to their miners, a technique known as spy mining.

Releases and release candidates

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

● Bitcoin Core 28.4rc1 is a release candidate for a maintenance release of a previous major release series. It primarily contains wallet migration fixes and removal of an unreliable DNS seed.
● Rust Bitcoin 0.33.0-beta is a beta release of this library for working with Bitcoin data structures. This is a large update with over 300 commits that introduces a new bitcoin-consensus-encoding crate, adds P2P network message encoding traits, rejects transactions with duplicate inputs or output sums exceeding MAX_MONEY during decoding, and bumps major versions across all sub-crates.

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 #34568 makes several breaking changes to the Mining IPC interface (see Newsletter #310). Deprecated methods getCoinbaseRawTx(), getCoinbaseCommitment() and getWitnessCommitmentIndex() (see Newsletter #388) are removed, context parameters are added to createNewBlock and checkBlock so they can run on separate threads without blocking the Cap’n Proto event loop, and default option values are declared in the schema. The Init.makeMining version number is bumped so that older clients receive a clear error instead of silently misinterpreting the new schema. The threading change is a prerequisite for the cooldown feature covered next.
● Bitcoin Core #34184 adds an optional cooldown to the createNewBlock() method on the Mining IPC interface. When enabled, the method always waits for Initial Block Download (IBD) to complete and for the tip to catch up before returning a block template. This prevents Stratum v2 clients from being flooded with rapidly outdated templates during startup. A new interrupt() method is also added so IPC clients can cleanly abort a blocking createNewBlock() or waitTipChanged() call.
● Bitcoin Core #24539 adds a new -txospenderindex option that maintains an index of which transaction spent each confirmed output. When enabled, the gettxspendingprevout RPC is extended to return the spendingtxid and blockhash for confirmed transactions, in addition to its existing mempool lookups. Two new optional arguments are also added to the RPC: mempool_only restricts lookups to the mempool even when the index is available, and return_spending_tx returns the full spending transaction. The index does not require -txindex and is incompatible with pruning. This is particularly useful for Lightning and other second-layer protocols that need to track chains of spending transactions.
● Bitcoin Core #34329 adds two new RPCs for managing private transaction broadcasts (see Newsletter #388): getprivatebroadcastinfo returns information about transactions currently in the private broadcast queue, including the chosen peer addresses and when each broadcast was sent, and abortprivatebroadcast cancels the broadcast of a specific transaction and its pending connections.
● Bitcoin Core #28792 completes the embedded ASMap series of PRs by bundling ASMap data directly in the Bitcoin Core binary, so users who enable -asmap no longer need to separately obtain a data file. Removing the build option WITH_EMBEDDED_ASMAP allows excluding the data. ASMap improves eclipse attack resistance by diversifying peer connections across Autonomous Systems (see Newsletters #52 and #290). The feature remains off by default; the user must still specify -asmap to enable it. A new documentation file outlines the process for sourcing the data and including it in a Bitcoin Core release.
● Bitcoin Core #32138 removes the settxfee RPC and -paytxfee startup option, which allowed users to set a static fee rate for all transactions. Both were deprecated in Bitcoin Core 30.0 (see Newsletter #349). Users should instead rely on fee estimation or set a per-transaction fee rate.
● Bitcoin Core #34512 adds a coinbase_tx field to the getblock RPC response at verbosity level 1 and above, containing the coinbase transaction’s version, locktime, sequence, coinbase script, and witness data. Outputs are intentionally excluded to keep the response compact. Previously, accessing coinbase properties required verbosity 2, which decodes every transaction in the block. This is useful for monitoring BIP54 (consensus cleanup) coinbase locktime requirements or identifying mining pools from the coinbase script.
● Core Lightning #8490 adds a new payment-fronting-node configuration option that specifies one or more nodes to always use as entry points for incoming payments. When set, route hints in BOLT11 invoices and blinded path introduction points in BOLT12 offers, invoices, and invoice requests are constructed to use only the specified fronting nodes. Previously, CLN would automatically select from the node’s channel peers, potentially exposing different peers across invoices. The option can be set globally or overridden per offer.
● Eclair #3250 allows the OpenChannelInterceptor to automatically select a channel_type when the local node opens a channel without one explicitly set. Previously, automatic channel creation (e.g., by an LSP opening channels to clients) would fail unless a type was provided. The current default prefers anchor channels, with simple taproot channels expected to take priority in follow-up PRs.
● LDK #4373 adds support for sending multipath payments where the local node pays only a portion of the total invoice amount. A new total_mpp_amount_msat field in RecipientOnionFields allows declaring an MPP total larger than what this node sends, enabling multiple wallets or nodes to collaboratively pay a single invoice by each contributing part of the payment. The receiver collects HTLCs from all contributing nodes and claims the payment once the full amount arrives. BOLT12 support is left for a follow-up.
● BDK #2081 adds spent_txouts() and created_txouts() methods to SpkTxOutIndex and KeychainTxOutIndex that, given a transaction, return which tracked outputs it spent and which new tracked outputs it created. This enables wallets to easily determine the addresses and amounts involved in transactions they care about.

Bitcoin Optech Newsletter #393 Recap Podcast

2026-02-24T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Misha Komarov, Erik De Smedt, and arbedout to discuss Newsletter #393.

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

Download audio

News

● Recent OP_RETURN output statistics (45:54)
● Bitcoin PIPEs v2 (1:33)

Changes to services and client software

● Second releases hArk-based Ark software (20:21)
● Amboss announces RailsX (55:35)
● Nunchuk adds silent payment support (56:11)
● Electrum adds submarine swap features (58:08)
● Sigbash v2 announced (33:56)

Releases and release candidates

● BTCPay Server 2.3.5 (1:00:11)
● LND 0.20.1-beta (1:01:43)

Notable code and documentation changes

● Bitcoin Core #33965 (1:02:55)
● Eclair #3248 (1:05:55)
● Eclair #3246 (1:07:08)
● LDK #4335 (1:08:52)
● LDK #4318 (1:14:32)
● LND #10542 (1:15:55)
● BIPs #1670 (1:17:02)
● BOLTs #1236 (1:27:50)
● BOLTs #1289 (1:29:10)

Transcription

Mike Schmidt: Welcome everyone to Bitcoin Optech Newsletter #393 Recap. Today, we’re going to be talking about some recent OP_RETURN output statistics following Bitcoin Core’s v30 release; we’re going to talk about Bitcoin PIPEs v2, and covenant-like enforcement without consensus changes; and we also have our regular monthly segment covering recent Changes to client software that we find interesting; and we have also our weekly Releases, release candidates, and Notable code and documentation changes. Murch, Gustavo and I are joined this week by three guests. We’ll have them introduce themselves briefly, and then we’ll jump into the newsletter. Misha, who are you? Who are you, what do you do?

Misha Komarov: It’s Bitcoin Pipes, I guess the most relevant thing for today’s conversation.

Mike Schmidt: Excellent, thanks for joining us. Erik?

Erik De Smedt: Hi, I’m Erik, I work at Second. We’re building an implementation of Ark, and I’m going to talk about hArk, which is our new variant of the Ark protocol.

Mike Schmidt: And arbedout?

arbedout: Hey, I’m working on Sigbash, which right now is a zero-knowledge MuSig2 policy signer.

Bitcoin PIPEs v2

Mike Schmidt: Awesome. Well, thank you again for joining us. We’re going to go a little bit out of order. So, if you’re following along at home, we’re just going to have a little deference to our guests, and so bear with us as we jump out of order. But we are going to jump to the News section first. We have Bitcoin PIPEs v2. Misha, you posted to Delving Bitcoin about Bitcoin PIPEs v2, a protocol for enforcing spending conditions without consensus changes, including covenant-like instructions. Maybe, Misha, you can give us a quick overview. What was, or is, Bitcoin PIPEs v1, and then what is v2; and then we can get into some Q&A?

Misha Komarov: Okay. Well, long story short, Bitcoin PIPEs v1 was published October 2024, and it was all about, well, the attempt to enforce post-covenants or like pre-covenants and post-covenants, what’s called pre-covenants and post-covenants, without a soft fork or consensus changes, I mean kind of externally. So, Bitcoin PIPEs v1, we’re focusing on trying to achieve this with functional encryption. Functional encryption is, well, futuristic. Conceptually, it’s how it should be. And it’s kind of the end game. The question was all about, can we make this run faster? Can we make this run in practice? Can we make this run in production? And what, a year, year and a half later, v2 basically is all about that, is all about cutting out pieces here and there, is about switching from functional encryption to witness encryption which, spoiler, turned out to be still enough to enforce, I would say, the most important covenants, like binary covenants and OP_VAULT, or like CSFS (CHECKSIGFROMSTACK), I mean to emulate that effectively. It’s you know still not very cheap to run, but come on, dude, that’s witness encryption! And over the year, this went from, “Oh, it would be cool to run this sometime in the future”, to, “Well, you can run this, you have enough storage”. So, this is what it is. This is what Bitcoin PIPEs v2 is all about.

Mike Schmidt: Maybe, Misha, you can help explain a couple things for us. I think Jeremy Rubin, at some point, tried to explain to me functional encryption. That was the first time I had heard of it. Can you touch on functional encryption and witness encryption a bit for the audience?

Misha Komarov: Yeah, okay. So, both of them are pretty much obfustopia-level cryptographic obfustopia primitives. Functional encryption is effectively a type of encryption scheme which allows you to decrypt and compute certain things as the result over a ciphertext and the input you put through there, only if the input satisfies a certain condition. So, this way, you can define this condition, you can predefine this condition. So, effectively, it’s kind of cryptographically enforcing a certain type of computation if a condition is met. So, it’s a generalization of a public key cryptography, where the key is not just kind of the bytecode, but a circuit or a truth over a certain circuit even more. So, that’s functional encryption.

Witness encryption is a, well, I would say a more lightweight brother of this kind of functional encryption idea. It doesn’t allow you to compute a complicated function over a ciphertext to output something large, like 256 bits, or whatever the amount of bits you want to output as a signature, right? But it allows you to only output yes or no, effectively checking if the condition being executed with a certain decryption algorithm over a ciphertext is true or not; which means we can decrypt either 0, either 1, depending on if a certain ZKP is correct or not; which means, well, turns out that it’s enough to enforce certain covenants. So, that’s what it is.

Mark Erhardt: So, basically you encode some predicates that allow you to encode out-of-band conditions or criteria by which you want to lock up funds. And all of that happens completely transparently or hidden, steganographically basically, in the witness data. So, all of the heavy lifting is out of band. And this works today?

Misha Komarov: It works. Surprisingly, we think we can state that it works, the witness encryption part.

Mark Erhardt: So, you say that you can emulate certain covenants with this. So, I guess, how would the average covenant user know that you’re actually enforcing the right conditions out of band? They can’t really see what’s going on under the hood. How would a person that just wants to use the covenant approach this? Do they just trust you or is there more here?

Misha Komarov: Yeah, absolutely. There is no need, or there is no idea for somebody to trust anybody. We wouldn’t have spent a year otherwise doing the work we’ve done. I’d say, okay, so the idea is that just like, I guess, back in the day, the key mechanism wasn’t changed. Initially, during the setup of a certain covenant, there is a setup procedure for the covenant. And of course, we’ve got to be transparent in here, that there are like one out-of-band assumptions there. So, you’ve got to set up a certain covenant, like you’ve got to generate a private key in like a DKG so nobody would know that key. But of course, the committee or whoever publishes the ciphertext on this key, you can inspect and you can see what kind of circuit is required there for this condition to be satisfied and the key to be unlocked. And it’s obviously also kind of not required, but I would say it’s expected for a committee to at least publish a public key of the keypair they’ve generated, I mean so people could see that once there is a transaction signed by a private key corresponding to that public key, it means somebody has done the computation correctly and there is a transaction and it’s all valid. So, basically, that’s kind of the thing.

Mark Erhardt: Okay, so the ability to sign for the transaction guarantees that the predicate resolved to true, and therefore the conditions that were encoded were met. And so, we trust in the setup procedure to some degree, but other than that, if the setup was done correctly, we’re good.

Misha Komarov: Nothing else can go south there. That’s the whole pitch.

Mark Erhardt: Cool. Okay. Yeah, anyone else got questions? This sounds like something that’s down your alley, arbedout.

arbedout: Okay, this sounds incredibly interesting, and I really like the idea that you don’t have to wait for consensus changes to be able to test this out. I guess my first question is about, because this jumps out when you read the paper, the 383 GB of data that is required. As a user, do I need to fetch that and run a cryptographic operation on it?

Misha Komarov: To be precise, it’s not 338 GB. Right now, at the time of the first release of the Arithmetic Affine Determinant Program (AADP) witness encryption with done, it’s 338 TB, which is too much, obviously, yes. But again, we kind of calm ourselves internally that come on, dude, this is the first witness encryption out there! So, it’s already good enough that we can run something. But we think we know, and there was a little bit of a banter in the chat recently, we think we know how to reduce this to around 100 GB in terms of ciphertext size. Once we prove it’s secure, because we don’t have a formal proof of that reduction in terms of security, we’ll publish that as well. It’s going to be like 100 GB per ciphertext. So, effectively, it becomes similar to what people do with garbled circuits, it becomes pretty close to what people do with garbled circuits. That’s what it is.

In terms of, is a user expected to download the whole thing? I mean, you can, but can you outsource part of that computation somewhere? Yes, that’s the whole thing. You can outsource it to somebody who has enough computation capacity, or you can outsource, I don’t know, a significant part of it to somebody who has enough storage capacity. And I would say again, there is a mention of this in the paper, but we think that as a way to batch a lot of keys into a into a single ciphertext. So, you could generate like several 100 or maybe 1,000, if you wanted more keys inside a single ciphertext, and then decrypt, decrypt, decrypt up to a certain limit. I mean, of course, after a certain limit, it becomes not really secure. But up to a certain limit, you can keep this secure. And this way, you don’t need 100 GB per key, you basically need like 100 GB for a certain amount you have batched inside. So, that’s kind of how it looks right now. But we wanted to be a little bit more conservative and put it out experimental and speculative stuff. I mean, we can talk about it like this, right? But when you put out the paper, you claim something, you’d better claim something which you know works.

So, we know right now that this 338-TB thing is secure, more or less. We weren’t able to crack it. Anybody we consulted with wasn’t able to crack it. We spent significant time trying to crack it. We will be doing public challenges, we will be going around and we will lock some bitcoin behind some ciphertext, behind some key, we will be like, “Okay, well, whoever breaks it gets some bitcoin”. I mean, if you can retrieve the key, absolutely do it. So, that’s just for the sake of making sure that this doesn’t fall apart. But yeah, that’s the situation there right now.

Mike Schmidt: Misha, we covered that you posted in Delving. I believe you or someone else also posted to the Bitcoin-Dev mailing list as well. What’s reception been so far?

Misha Komarov: Well, I mean, Delving Bitcoin, as you might have notice, we haven’t seen anything negative. I mean, there is interest, obviously. There is quite a lot of, I would say, positive reception. Well, not very excited, of course, because when people hear a phrase, “Witness encryption, and you can run that”, everybody gets like, “What?” But in general, we haven’t seen negative feedback. We’ve seen a lot of suspicion and we had to answer a lot of questions. It’s okay, it’s good. We’ve seen a lot of positive results. So, it was like I said, seen positive reactions from, well, specifically from BitVM guys. We are yet to go around a little bit and to try to specify certain opcode proposals, which were specified inside certain BIPs over time, like OP_VAULT. I mean, we know that it will deprecate, right? But if we could do an analogous to an OP_VAULT, I mean, anybody would mind? I don’t think anybody would mind.

So, we’re yet to specify how certain BIPs, which we’re interested in, which are still interesting, over time can be expressed and can be replaced or can be substituted or emulated with PIPEs. We will be trying to go around relevant, certain authors of BIPs, and then we will be trying to be like, “What do you think? I mean, maybe this can work today”. Like, this is one more thing we’re yet to do. There might be something for us also to talk about with, besides BitVM guys, to lightning folks, I mean because there’s always a little bit of a thing liquidity on the receiver side fragmentation, right? So, if you have OP_VAULT, or if you have some kind of vault, you could probably reduce that kind of channel liquidity fragmentation there. That’s a little bit of improvement there. What else is there? Yeah. I mean, we could probably go around some folks who try to do privacy-preserving Bitcoin transactions. That would be interesting. Maybe we could improve Shielded CSV through that somehow. That is a couple of ideas it all comes down to basically, yeah.

Mark Erhardt: You mentioned BitVM a few times. So, my understanding is that BitVM allows you to encode these circuits, and then it’s sort of optimistic in the sense that they publish and if you find a mistake, you can challenge and you have to publish big chunks of data, and then you can take the money. It sounds that your PIPEs are similar in what you can do with them, but the system works rather with the zero-knowledge proof out of band. So, there’s no taking or slashing. Is that roughly correct?

Misha Komarov: It’s pessimistic and single transaction and non-interactive. That’s the whole kind of pitch, yeah.

Mark Erhardt: Okay. Is there other aspects that you would say are important to compare or show the differences?

Misha Komarov: I mean, of course, maybe for now, one of the obvious things for now, maybe the costs of storage are higher than what BitVM folks have right now, right? Of course, there are kinds of nuances about how BitVM constructions in general manage the kind of reorg risks because of probabilistic finality, which it’s much easier for BitVM to handle that, because it’s optimistic, interactive, people are kind of okay-ish with that. On the bright side, like on the upside side, with PIPEs, well, if PIPEs were to be used as a foundation for some kind of bridge, or this kind of stuff like the BitVM people do, this would remove the operator liquidity requirements. It would remove, I think, quite a lot of interactivity. I mean, it would remove the liveness risk, because the whole decryption process is basically not interactive. If the setup is done correctly, then nothing can prevent you from just taking your bitcoin back if something goes south, or whatever. You can call it an escape hatch, if you want to. So, this kind of stuff.

Yeah, I mean, what else is there? And of course, if you want to compare the waiting period in terms of you’ve got to wait for somebody to submit a fraud proof or this kind of stuff, well, there’s nothing like this in here. Once it’s decrypted, it’s decrypted, it’s there, the transaction is done. So, this is the attestation.

Mike Schmidt: Well, I think in those last comments that you made, Misha, I think listeners, depending on what they do in Bitcoin, may have a call to action to either check out the Delving post or reach out to you if there’s something they think is worth emulating or have questions. Anything else you’d have as a call to action for listeners?

Misha Komarov: I mean, we are looking to obviously as much feedback as possible. We are going to be looking for people willing to try to crack this. I mean, it will be open challenges. So, if you’re a cryptographer person, or whatever, don’t hesitate to take a stab or, you know, we will be doing challenges about this. If you have ideas or you have good suggestions on which BIPs also could use help of emulation via PIPEs, I specifically called for that feedback, for those suggestions on Bitcoin-Dev mailing list a couple of days ago, maybe yesterday, whatever.

Mike Schmidt: Great. Well, Misha, thank you for joining us. We appreciate your time and if you have other things to do, you’re free to drop. Cheers. We’re going to jump to the Client and services segment and talk about a couple of items before jumping back up to the news.

Second releases hArk-based Ark software

We’re going to talk about Second releasing a hArk-based Ark software. This is in v0.1.0-beta.6, and we have Erik on who’s going to walk us through, maybe reminding us what Second is working on with Ark; and then, also jump into what is hArk and how does it reduce some of these interactivity requirements we’ve heard so much about.

Erik De Smedt: Okay, cool. So, yeah, at Second we’re building hArk. It’s an Ark implementation and basically, we’re just focused on sending and receiving bitcoin, very straightforward and get user experience very well for users on mobile, their phones, web browsers, not having to run a full node all the time, to run a reliable wallet where you have some good sense of custody. We started building the Ark protocol as it was initially invented. And basically, especially for mobile phones, we ran a little bit into a problem. So, the core concept of Ark is basically, in Ark, you hold vTXOs and your vTXO is a bit like Bitcoin UTXO. The only difference is it’s an output of a transaction that isn’t onchain yet. You just have a chain of transactions, and in the best case, you have a signature in the entire branch in that chain. You can broadcast these transactions and you’re guaranteed that you can get your transaction onchain if you need to. It comes with a little bit of a trick, like this guarantee expires. After some point, the Ark server can basically sweep the coins, which gives the Ark server the liquidity back, which is in the UTXO. And to prevent it, you need to participate in a round. And basically, what you do is you take your old vTXO, you forfeit it, and you will get a new vTXO in return. And that’s basically the idea of participating in a round.

That process works quite well, but for mobile phones especially, it has one big problem. So, basically, the Ark server will host a round and let’s say it will do it at 1.00pm sharp. Everyone who wants to participate in that round needs to be online at 1.00pm sharp. And we noticed, especially for mobile phones, that’s a huge problem. You have some APIs to schedule a phone to wake up or send notifications to the phone that they should wake up, but most of these things are somewhat unreliable because smartphone manufacturers want to preserve battery. And we can say, “Please wake up at 1.00pm”, but if you’re unlucky, it wakes up at 1.00pm and 30 seconds, and your phone has missed a round in the refresh field, or it might not even wake up at all. So, that’s pretty terrible.

Mike Schmidt: And, Erik, what are the consequences if there isn’t a wake-up?

Erik De Smedt: So, basically if you don’t wake up, the phone will not refresh the coin, and basically the old vTXO will expire. And at that point, you get in a situation where both you and the server could basically take the money. But at some point, the server actually has to take the money, because they need their own money back. It’s in the same output. So, basically, you lose custody of your coins, which is very bad. That’s something we want to avoid at any cost. So, what we’ve been trying to do is, how can we make sure that not all the phones need to be online at exactly the same time? And it turned out that the solution is ridiculously obvious. So, in the round protocol, which initially was a little bit convoluted, but basically there are three steps in it. So, the first one is if a round starts as a phone, you go and say, “Hey, I want to participate in a round. I have these vTXOs, I want to get rid of this. Give me a new one basically to sign up”. Then we have the co-sign phase, where basically you sign your branch of transactions. Ark works with pre-signed transactions, it’s some construction thing. And then you have the last phase, which is a forfeit, which is actually what we’re diving in now.

Previously, we used a construct called connectors. It’s kind of weird, but the core idea is that your forfeit transaction will have two inputs. So, one from the vTXO, which is forfeited, and basically that’s the transaction where I say as a client, “I give up my old funds”. But the forfeit also has another input, and that goes back to the new round, which will give me the new vTXO. It’s a little bit confusing. But if you do that, at that point, basically as a client, you’re guaranteed that if you sign the forfeit, it will only be valid if you get a new vTXO in return. And the reason why it used connectors is actually because the server, when it creates the new vTXOs, it needs to create a funding transaction and it needs to put a round of money in. And basically, it also gives the same guarantee for the server, like you don’t need to fund around before you’re sure all the old ones have been forfeited. And for a while, we thought that was super-important and you had to do it like that and hashlocks didn’t work. But actually, that seems to be false. So, what we now did is we basically switched the order.

So, what will happen is the server will first fund around, and you think that sounds dangerous, but we can ignore that for a while. And then, at a later point in time, the server or the clients can come online, sign the forfeits and basically do it whenever they see it fits. And if they come online two hours later, fine, they can sign the forfeits and go through.

Mark Erhardt: Does that work with a similar construction as the connector in the sense that only if you sign away the forfeit, you get your new vTXO?

Erik De Smedt: Basically, we now use hashlocks just like Lightning does it. So, you sign now a forfeit transaction and that forfeit transaction gives the server the coins if it releases a hash in time. So, basically, we now just use the standard hashlocks very much like Lightning works. So, it’s much closer how Lightning works and pretty well understood. And it’s actually also safe for the server, because the fact that you have a vTXO is kind of already a dust prevention for the server, like you can’t sign up without owning a vTXO, so the server has control on how much money it will put in the new round. It’s turned out to be surprisingly simple. Our code became a lot smaller, clearer and easier to understand when developing this.

Mark Erhardt: So, does this change anything about the amount of liquidity that is necessary for each round?

Erik De Smedt: It doesn’t change anything at all. So, the liquidity requirements stay exactly the same. So, protocol-wise, there’s not that much that changes. It also doesn’t really change the trust model, at least not for clients who can stay online. So, if you’re like a server and you can be online at the time of the round, it doesn’t change the trust model, but it allows basically a fix for mobile clients who are not guaranteed to be online. We had the three phases, so the sign-up, which was the first phase, and we had the co-signing phase. If you run a node on a computer, which is always online, you’ll do the co-signing yourself and you will get the best security model. If you’re a mobile client, you can ask others to co-sign for you. So, the co-signers will sign, they’ll forget the key, so you get forward security. It’s just all pre-signed stuff. And that way, the mobile client doesn’t have to be online at the round, it can come online later and sign the forfeit when they want to.

Mike Schmidt: Is the co-signing aspect here sort of a trade-off with this new approach?

Erik De Smedt: Yeah, it’s a trade-off, but it’s fully optional. So, the way it’s implemented, if you don’t want the co-signing, you can still do it self-signed. But if you fail to co-sign, you can say, “Other people are allowed to co-sign for me”. Even as a mobile client, how it’s currently implemented is basically you try to co-sign yourself. If it fails, you fall back on the other methods. Oh, go, Schmidty, sorry.

Mike Schmidt: Oh, yes, sorry. I was going to ask, I’m curious what the other Ark implementations think of this approach. Is this something that everyone’s going to be moving to? Is this something that Second has a strong opinion on and others differ? Maybe just add some color there.

Erik De Smedt: I haven’t gotten much responses there from the other teams. I know we basically were pretty close to launch, but then we came on this idea and it was like, “Hell, no, we’re not going to build it while we have people live on our system”, because you’re like doing open-heart surgery on the protocol. And if you have live users, it will be very hard. So, I think once you have an existing user base – the engineering challenge of switching was already hard. I can only imagine it to be harder if you have to stay backward-compatible for all the other users, because it’s not backward compatible at all. I know other implementations have been looking at different approaches. They call it delegated refreshes, where basically you ask someone else to participate in the round on your behalf. The latest I know, it’s written in blogpost, but not in code, so it’s not implemented yet.

I actually think the hArk model is better, because with the hArk model, it actually comes with a few benefits. So, the first one is if you rely on other co-signers, let’s say if we have ten co-signers, all ten of them can co-sign your vTXO, and you’ll get additional security from all of them. So, that’s definitely a win. It’s not like that you just have the one guy you delegated to do it, which is one thing which is really nice. But also, a bit a downside of the delegated model is basically, for your refresh to succeed, you need a server to be online, like that’s a hard thing because he needs to fund a new round. But you also get, like, if you delegated to a third party, that third party needs to be online to go to the server and say, “Hey, this guy allowed me to participate in the round”; while if you just go to the server, “I want to participate in that round just before expiry”, you require less parties and you can say, “If one of these co-signers is online, it’s good”. So, it also can give you a very robust model where you don’t have to rely on too many other people running services for you, because we see that might become a bit of a reliability bottleneck.

Mike Schmidt: For listeners who want to try this out, we highlighted that it was 0.1.0-beta.6. Is this something that people can download and play with on signet, or how do you recommend people try this out?

Erik De Smedt: I would recommend you to download it, play on signet. If you go to signet.2nd.dev, there’s a demo environment, there’s a faucet where you can request Ark coins, you can make Lightning payments, onchain payments to a dummy store. If you use that, you can use it. We have a CLI, we have barkd with a Rust API. So, on signet, you have quite a lot of things to play with.

Mike Schmidt: Excellent, Erik. Anything else for the audience before we wrap up this item?

Erik De Smedt: No, thanks. Thank you very much.

Sigbash v2 announced

Mike Schmidt: All right, Erik. Thanks for your time. Thanks for joining us. We have a guest for another of our Client and service items. This one was titled in the newsletter, “Sigbash v2 announced”. And we have arbedout here to talk about Sigbash and Sigbash v2, which now uses MuSig, WASM, and ZKPs. Arbedout, we covered Sigbash v1, I don’t know when it was, a couple years ago or whatnot. It seems like you’ve been hard at work at it. It feels like a cool project that I think people should be aware of, so I wanted to get you on to talk about it. Maybe talk about Sigbash and then we can get into v2 as well. What have you been up to?

arbedout: Thanks, I really appreciate that. So, I’ll cover v1 briefly, I guess. V1 was a policy signer that used standard ECDSA, which doesn’t really afford you much opportunities for privacy, just the nature of the beast. It leveraged blinded xpubs, and the idea behind those is that we had the client JavaScript deriving child keys using random paths from a master key that our servers provided. What that means is that users were given keys that the server didn’t know about up until signing time came around. And once signing time comes, of course, the server sees all of your transaction details still, because it’s ECDSA and PSBTs, the key itself as well. Basically, you had privacy up until you actually needed to use the server. Now, that’s a quantum leap ahead of how normal signing works right now, where right off the gate, every member of your ECDSA quorum sees your transaction balance and your entire history and everything from the word go, even if you don’t ask them to sign. But it’s still not great.

So, the past couple of years, I’ve been exploring whether we could improve on that model at all. And what we’ve come up with is v2, which uses, like you said, MuSig2, WASM, taproot, all that good stuff. I’ll talk through the high-level flow of it, and then we can dig into questions. So, you start off by defining a signing policy, and that signing policy can be just about any property of a PSBT, the inputs, the outputs, the amounts, the pubkeys, and it can be as complex as you might like. We take that policy, encode it into a boolean abstract syntax tree. So, all the logic gates you might remember from CS101 AND, OR, XOR, NOT, everything that you might need to express a policy. We take that tree, walk it, and then turn that into a Sparse Merkle Tree, which I know bitcoiners love, take the root node of that Sparse Merkle Tree, and just send that single 32-byte hash to the server. So, for all those transformations, the only thing our server sees is that single hash. It doesn’t know anything else about your policy. And obviously, you can’t really infer anything about the policy itself from that hash.

Next, we create a key entirely in WebAssembly on the client side by fetching a key from our server, generating a new key on the client, aggregating the client side with MuSig2, and storing an encrypted blob on our servers. So, from beginning to end, from when you generate a policy to when you ask to sign a policy, we never see your key, we never see your transaction, we don’t even see the sighash (signature hash) of the message being signed.

Mike Schmidt: Very cool. I’m curious, like, I’ve seen some of the social media discussion, I’ve seen you post about this. Is this a service that is live that you are providing now, this co-signing service?

arbedout: It is live right now. You can go on sigbash.com and start paying your way on the web app right now. You don’t have to download and install anything. That’s the great thing about WebAssembly. Right now, it’s live on signet. If you go looking, you can figure out pretty quickly how to go live on mainnet. Maybe give us a couple of weeks before you do that. We’re still making sure there are no bugs. I have fond memories or not so fond memories of someone on v1 immediately locking up about $5,000 in sats in a key that we had to struggle to help them send. I don’t think we have any bugs this time around, but give us a little bit before you try on mainnet.

Mike Schmidt: And is this open source? Are you providing this as sort of a company and you’re charging for this service, or how does it work in that regard?

arbedout: So, my plan is, and this is still loose, so bear with me, don’t hold me to this, but I think the web app is going to be free as long as I can manage that. It is a company, we are incorporated, but I think for that level of integration, we need an SDK, which is what we’re working on. We’re talking to partners right now at exchanges, at custodians, anyone who is currently handling signing or signing adjacent, whether it’s multisig or watch-only wallets. We’re probably going to be focusing on the SDKs, the commercial enterprise, and the web app will be for all the crazy mountain-men node runners who want to use it.

Mark Erhardt: So, you said that the server doesn’t even see the message that is being signed. Are you referring to the transaction itself at this point with message?

arbedout: Yeah, the transaction.

Mark Erhardt: So, it’s completely blinded to the server; the server is enforcing the policy that you committed to when you created it and signs off on it when the policy is fulfilled, but doesn’t even know which transaction it signed?

arbedout: That’s correct. So, under the hood, what that looks like, remember the server sees that root Sparse Merkle Tree, a hash? What the client in WebAssembly submits, you as a user upload your PSBT, WebAssembly parses that PSBT. Providing that your PSBT matches one of the clauses of the policy that you defined, it will submit a proof bundle consisting of a path leaf with the merkle inclusion proof proving that that path belongs to your original root hash; a zero-knowledge proof proving that you know the inputs that can create that path leaf; and a very small schnorr proof of knowledge, tying it to the sighash, the message being signed. So, end-to-end, you know, okay, this person has a PSBT that must be able to create these inputs, and that PSBT must be tied to a valid transaction.

Mark Erhardt: Sorry, I’m confused. So, you provide a PSBT of the transaction?

arbedout: On your side, and then, from there on, WebAssembly is parsing it and providing, basically proving that you have a PSBT that semantically meets the policy that was originally defined.

Mark Erhardt: Oh, the WebAssembly side sees the PSBT; the server does not see the PSBT?

arbedout: Yeah.

Mark Erhardt: Okay, that’s what I was missing. Okay. I was like, if you’re sharing the PSBT, you still see the transaction, just with extra steps. But yeah, okay. So, only the client side has the PSBT. Okay, cool.

Mike Schmidt: Well, I guess the call to action for listeners is pretty straightforward. Come play with this thing, right? Is there anything else, arbedout, that you want people to know?

arbedout: The nature of Sigbash v2 is that once it launches on prod, it’s set in stone. So, please bang on it and let me know if there are any features we’re missing. Just like Erik said, it’s very difficult to have two different versions of proof bundles, for example. So, if there are conditions that you’re saying that are missing, please let us know. We’ve implemented everything from the basic stuff, like inputs and outputs and pubkeys and amounts, to more complicated stuff, like covenant emulation. But if there’s anything we’re missing, give us a shout.

Mike Schmidt: Awesome, arbedout. Oh, go ahead, Murch.

Mark Erhardt: Yeah, I feel like we’re talking about very much similar ideas a lot lately. So, BitVM, the PIPEs previously, Sigbash. Someone recently asked me to read something in the comments on our tweet that was also sort of encoding functional functions. So, is this just taproot coming to roost; after taproot being out for four years, people have had time to bang on the pot? Or what makes all of you come out with your projects at the same time?

arbedout: Speaking only for myself, I think definitely part of it is just it takes time for tooling to be implemented. A lot of what I built with Sigbash v2 required the upstream libraries to implement MuSig2 support and taproot support. And then, there is obviously a learning curve trying to think about, “Well, what can I do with this? What is now possible?” And then there’s a sort of second level. Once you start seeing that initial trickle of other projects working on things, that you draw inspiration from that and start thinking, “Oh, well, zero knowledge, what can I do with this?” In the case of at least the zero-knowledge side of things, again I’m speaking only for myself, but I sort of can infer this from comments other people have made, there’s a pretty influential paper that was released about two years ago called, Concurrently Secure Schnorr Signatures, where the authors proved that the idea of zero knowledge predicates and how that might work in theory with schnorr sigs. And I remember Jonas Nick tweeting that out, and then a bunch of different projects latching on to that and starting to have discussions, “Well, zero-knowledge covenant-ish type things, what can we do with this?”

I think it sort of is time, but it’s a combination of time passing and then people experimenting, and then other people getting ideas from those experiments. And then it’s just a slow-moving avalanche.

Mark Erhardt: So, it’s just the ideas floating around and then basically infecting each other until something falls out. And there’s like four or five different things that are very similar that have different trade-offs and now, yeah, I guess we’re getting all of them!

arbedout: Yeah, I promise we don’t have some like pseudo covenants dragon’s den slack room that we’re all meeting in to talk about this. It’s all actually organic. It’s interesting, both for PIPEs and I think there’s that other project, BLISK, that announced a couple of weeks ago. They’re very similar orthogonal ideas and you can see none of us have communicated with each other. It’s all after the fact, we’ve been DM’ing like, “Oh, wow, this sounds very interesting. We seem to be on the same wavelength”, but it’s completely organic.

Mark Erhardt: Talking about covenants. So, all of, or not all of you, some of you are basically emulating covenants. And what if we actually introduce some of these opcodes into Bitcoin any decade now?

arbedout: Speaking only for myself, I would love that. I think just from the co-signing point of view, if you’re using a co-signer to emulate covenants, you either didn’t need covenants or you’re making do with something that probably isn’t purpose-suited for you. The difference is the trust model. Covenants, when enforced by consensus, are guarded by the Cyber Hornet crowd. It’s onchain and public, and everyone’s nodes are enforcing it. What we’re doing is offchain, private, and you’re not really trusting the co-signer because the co-signer doesn’t see anything. They can’t be censoring you based on transaction contents that they can’t see, but you are trusting them to be online and to sign things dutifully. It’s a radically different trust model. From my point of view, if covenants were to go live tomorrow, I think we’d start building all sorts of cool new features on top of that, and I’m sure the PIPEs guys would say the same thing as well. As much as I would like to think otherwise, there is no pool of Bitcoin users waiting and hoping, “Oh, I’m going to write Bitcoin Script by hand for my transactions and these opcodes will slide into it”. It’s the builders like us that are actually going to make use of those opcodes.

Mark Erhardt: Thanks for the perspective.

Mike Schmidt: Very cool. Thanks for joining us and hanging on through the first half of the newsletter, arbedout. You’re welcome to drop a few other things to do.

arbedout: Thank you for having me.

Recent OP_RETURN output statistics

Mike Schmidt: Cheers. Jumping back up to the newsletter, we had our first News item, which was titled, “Recent OP_RETURN output statistics”. And we covered AJ Towns’ post to Delving Bitcoin about analysis that he did on OP_RETURN usage since Bitcoin Core v30 was released, which was October 10th, I believe. And he has his analysis, but he also linked to analysis from a couple of other people, orangesurf, and also, Murch. Murch is obviously here and has done some of the analysis hands-on and read both of the other analyses. So, Murch, what should we take away from this? Well, I guess, what was found, and then we can get into takeaways?

Mark Erhardt: So, I think the context of this is people making arguments about the amount of OP_RETURN outputs we’ve been seeing, and maybe also putting that in the context of what would be allowed, given some soft fork proposals activating or not activating. It’s just giving the raw numbers on that. So, AJ has looked at some 20,000 blocks or so, 20,200, I think. And in those blocks, he found 24 million OP_RETURN outputs. And out of those transactions, 24 million transactions with OP_RETURN outputs, 460 either had multiple OP_RETURN outputs or oversized OP_RETURN outputs, where oversized means 84 bytes or more. So, 24.3 million transactions with OP_RETURN outputs, 460 are affected or subject to the new OP_RETURN policy by Bitcoin Core. So, most of these would just be completely unaffected, would not have changed their behavior at all if the policy change in Bitcoin Core v30 hadn’t been made. And maybe also, to make it very clear, 24,360,000 of those transactions minus 400 would also be in reduced data, temporary soft fork chain, because they’re compatible.

So, altogether, AJ found that there were about 474 MB of OP_RETURN data in these 20,200 blocks. And of that, I wrote it out.

Mike Schmidt: Now we have the ‘explicit’ tag on Spotify. Thanks, Murch.

Mark Erhardt: 2 MB. 2 MB of that were oversized or multiple OP_RETURN outputs. So, out of 474, 2 MB were affected, or could have been affected by the mempool policy change for large OP_RETURNs in v30. So, this is a tiny portion. I think anyone still making the argument that OP_RETURN has been used a lot more than it was before, I think it has been minusculely used more. There are a few more transactions, but in volume, I looked at this data myself, I published a dashboard on dune.com that aggregates the OP_RETURN data per week. And the dashboard showed me that there were about, well, a similar amount of transactions and data bytes in OP_RETURN outputs before v30. And especially also, oversized OP_RETURNs have not changed significantly.

So, the facts themselves, they are hard to argue with because they’re facts, but the interpretation that I have is that the OP_RETURN policy did not significantly change the usage pattern of this on the network.

Mike Schmidt: And, Murch, I don’t know if it was your analysis or some other comments that I’ve seen, but there was actually a spike, well not a large spike, but there was a few oversized OP_RETURNs that happened about a year ago before the release, right? Just mostly around, I don’t know, the discussion of large OP_RETURNs, like people playing around with it.

Mark Erhardt: I mean, a bunch of people went around and claimed that oversized OP_RETURNs were hard about a year ago. In April, when the policy was debated whether or not the OP_RETURN mempool policy still has teeth and does something useful, a few people, especially those that were against the change in Bitcoin Core, made the argument that it was essentially impossible to do before. So, I think this spurred a bunch of people that just felt the need to show that it was incorrect to say so, to make a lot of oversized OP_RETURN outputs. So, the biggest spike in the last couple of years actually was April last year, when there were, I think, some 10,000 or so oversized OP_RETURN transactions, just to demonstrate that it was completely possible to do. And yes, so the debate basically provided parallel proof just how loose that policy was already, how little enforcement it got. Yes, only a few miners were including those transactions at that time. But unless you’re urgently trying to get your transaction in, it only takes a few miners to include it to get 100% of those transactions in.

So, I think it succeeded in demonstrating that the policy was not very useful anymore at that time. And especially in the context that the inscription envelope being cheaper for large amounts of data anyway, and being standard and being widely deployed, continuing to enforce the OP_RETURN limit in order to forbid a use case that naturally already was not incentive-compatible, except if people were putting data in payment outputs, which was slightly more expensive, just didn’t make sense. So, I think that our argument that we made as Bitcoin Core developers back then still stands. There is no big economic incentive to use large OP_RETURN outputs because people are going to use the inscription envelope instead. And for people that use payment outputs to stuff data, OP_RETURN being slightly cheaper and now allowing more than the 83 bytes per transaction, actually allows them to use the OP_RETURN output instead of putting data in payment outputs. And I don’t think it’s controversial that putting data into payment outputs is worst kind of data embedding.

So, the inscription data will not move to OP_RETURNs just as predicted, and hopefully some of the payment data will move to OP_RETURNs, where it’s less harmful. So, I don’t know.

Mike Schmidt: In any of these analyses, are you aware of categorization of the small number of OP_RETURNs that do exist, like into buckets other than just truly arbitrary content? Like, obviously I can put, “Mike is the greatest”, piece of content in there and that’s just arbitrary content, but also people try to structure their data and create these protocols. Like, is there anything other than just people putting in arbitrary stuff?

Mark Erhardt: I’m not aware of anyone having done further analysis than just on size so far. But yeah, I think most of them are probably text at this point. We’ve seen, just as AJ found some 400 or so oversized OP_RETURNs, which is not a lot, sure there’s probably a couple of pictures in there too and something else, whatever. But yeah, I’m not aware of anyone actually having done the whole analysis. Orangesurf has published a report for mempool.research. I did briefly skim it. I don’t think it went into this aspect either, but if any of us three, it would be in there.

Amboss announces RailsX

Mike Schmidt: That wraps up the News. We’ll jump back to the Changes to services and client software segment. We have three others that we didn’t touch on. One was Amboss announcing RailsX, and this is a platform built on LN and using taproot assets to support financial services, including things like high-frequency trading or swapping between, let’s say, Lightning bitcoin and a stablecoin, or some such thing that’s on taproot assets. And we link to their post that outlines what they’re looking to build or have built already. So, check that out if you’re interested. Gustavo or Murch, anything?

Nunchuk adds silent payment support

We highlighted some support for silent payments from Nunchuk. So, Nunchuk added support for sending to silent payment addresses. I don’t believe that Nunchuk supports actually creating a wallet that can receive silent payments, but you can send out of your Nunchuk wallet to a silent payment address. So, that’s pretty cool to see that building support for silent payments over time.

Mark Erhardt: Also, maybe sending to silent payments is a little complicated, but it doesn’t require that special scanning, or all you need is to know all of the inputs and the recipient you’re trying to pay, and then you can construct the correct silent payments output. So, sending support is quite achievable by pretty much any wallet. If you want to receive, it gets a little more complicated because you need that special scanning mode, where you construct a shared secret from the input public keys and your own private key and compare that to all P2TR outputs. So, especially on light clients, that is a bit of a heavier lift.

Mike Schmidt: And we dove pretty deep with Craig Raw recently and talked about some of the challenges of scanning. I think last week you guys had Sebastian on also talking about scanning. So, if folks head to the podcast list for Optech, look for the one last week, which would be #392, and then also cruise back for the most recent Craig Raw one, where we talk into some of the challenges with that. It’s definitely not prohibitive for wallets to implement that, but there are some interesting challenges and it’s not quite as easy, as Murch outlined, in terms of sending to a silent payment address.

Electrum adds submarine swap features

Last piece of software we highlighted this month was Electrum adding submarine swap features in Electrum 4.7.0. I think they had some submarine swap features previously, but in 4.7.0, using Electrum you can now pay onchain using your lightning balance. This is the notion of submarine swapping. That’s the feature that we highlighted from this release, but there are many other features and fixes in this Electrum version as well if you’re curious.

Mark Erhardt: Wait a second, so submarine payments, I knew that as having an onchain payment as the last hop, like in a multi-hop HTLC (Hash Time Locked Contract); or vice versa, having an HTLC-based onchain payment first to pay into a Lightning channel. But isn’t paying out of a channel balance to an external address just a splice? Sorry, I’m the terminology nerd here! I think they just implemented splicing even if they call it submarine swaps.

Mike Schmidt: Yeah, they’re calling it Submarine Payments actually in their release notes, and then they also refer to it as, “Supporting reverse swaps to external address”. But yes, functionally similar to what you outlined there.

Mark Erhardt: Sounds like a splice to me, outgoing splice. Anyway. Let’s move on.

Mike Schmidt: We’ll jump to Releases and release candidates and also Notable code and documentation changes. Gustavo authors this every week, which we are very grateful for. So, he is the most informed person on this podcast to also walk us through it. And we’re grateful for that as well. Gustavo, what do we have this week?

BTCPay Server 2.3.5

Gustavo Flores Echaiz: Thank you, Mike and Murch for the intro. Yeah, so on the releases, we have one from BTCPay Server and one from LND. Both are pretty straight forward and pretty light. So, the BTCPay Server v2.3.5 mostly adds support for multi-coin support, so BTCPay Server allows you to use bitcoin, but other altcoins as well. So, support is extended that, for example, you don’t need to use bitcoin if you’re using other UTXO-model coins. Previously, you were forced to sync a Bitcoin node to use other coins that are also based on the UTXO model; now, you’re no longer forced to sync a Bitcoin node for that. Just other things that were added are additional fixes, some user-visible fixes, such as an image that wouldn’t display correctly on mobile. And an important one is payments were getting undetected on LND, when your LND node restarted while your BTCPay Server store was listening for LND for a new payment. Then, on a restart, it would fail to listen to new payments. So, that bug fix was also part of this release.

Finally, some new currency exchange rate providers for some additional currencies, I believe, mostly INR, which is probably Indonesia or India based.

LND 0.20.1-beta

And then the next release is LND v0.20.1. So, we teased, I believe, in two, three newsletters ago, the RC of this release, and now this is the official release. There’s many bug fixes included here. One that I highlighted was a panic recovery from gossip message processing, improvement around reorg protection, and LSP detection heuristics. So, these are things we’ve talked about in previous podcast episodes. But there’s about ten bug fixes included in this. And the heaviest part of the release are the bug fixes and the additional features that I mentioned earlier. That would be it for this part, unless you guys have any notes. No? Awesome.

Bitcoin Core #33965

So, we can proceed with the notable code and documentation changes. So, we have one from Bitcoin Core and a few ones from the LN implementations; and finally, a new BIP, BIP360, and two updates on the BOLT specification. So, let’s start with the Bitcoin Core PR #33965. So, here, a bug is fixed around a concept called -blockreservedweight. So, when a miner constructs a block, he will reserve some weight of the block for the block header and the coinbase transaction. That is what this value sets. So, there’s two ways of setting this value. Most RPC clients will simply set it to the startup config, -blockreservedweight. However, if you’re an IPC caller, particularly a Stratum v2 external client, you will use the mining interface and you will create your own block using another value set, also called block_reserved_weight.

The problem was that if I’m an IPC client and I’m using the second value block_reserved_weight, and I also set a startup config -blockreservedweight, they will enter in conflict, and the startup config option will overwrite silently the other value set. So, here, what is done is that if an IPC caller sets specifically the IPC value, then the startup config value that would previously override it is now ignored for the one that IPC callers specify for that one to take effect. Yes, Murch?

Mark Erhardt: Basically, this is just more special case overrides more general case. And so, the general case is the startup configuration. The node generally uses the startup config. But if you specify something more specific, per the IPC, that should take precedence. And the bug here was that the startup configuration took precedence rather than the mining IPC value. So, both of them can set it, and if a client specifies something specifically on the call that it is making, then obviously that’s more important.

Gustavo Flores Echaiz: That’s exactly right, Murch. Thank you for clarifying that. So, that is fixed. Another part of this PR is also the enforcement of a value called MINIMUM_BLOCK_RESERVED_WEIGHT that would silently clamp a value that was conflicting with this minimum value. And now, instead of silently failing, it will respond with an error message telling you that you cannot set a block reserve weight value that conflicts with the MINIMUM_BLOCK_RESERVED_WEIGHT setting.

Eclair #3248

So, we move forward with Eclair. We have #3248, which is a fairly simple PR, where basically if you have the option as a note to forward a payment through a private channel or a public channel to the same destination, now Eclair will prioritize the private channels when relaying payments, simply because private channels are not publicly viewable. So, if you’re taking a public channel, you’re then sending a channel update to the rest of the network, and the network believes you have less capacity because they’re unable to see that you also have a private channel with similar capacity. So, Eclair now always prioritizes the private channel. But there’s another part of this PR that when two channels have the same visibility, let’s say I have two private channels or two public channels, Eclair now prioritizes the channel with the smaller balance. This allows it to keep channels with bigger balances available for payments that would need more capacity. Any comments here? Perfect.

Eclair #3246

We move forward with Eclair #3246. So, here, many new fields are added to internal events. For example, miningFee field present in an internal event called TransactionPublished is split between localMiningFee and remoteMiningFee. Another computed feerate field is also added to this event. The point here, maybe the details are not as important as to understand why this was done. The goal here is to bring more visibility or auditability into the economic performance of our peers as a node. So, if we’re able to get all details around the fees paid at all levels then we have better visibility into the economic feasibility or economic performance of our different peers. Another important point is an optional purchase liquidity ads field is added to link a transaction to a liquidity purchase. So, if you made a transaction through a liquidity purchase, now a field appears that would link the transaction with that liquidity purchase.

Also, channel lifecycle events now include a field called commitmentFormat to describe the channel type, whether this was an anchor or non-anchor channel type, and eventually other forms of channel types, such as simple taproot channels. So, yeah, all of these fields, the goal is to bring more visibility into the economic performance of your different peers.

LDK #4335

We move forward with two PRs around LDK. The first one, #4335, this is an interesting one. It brings a concept back that was mentioned in Newsletter #188, called phantom node payments. And it applies it for BOLT12 offers. So, what is a phantom node payment? It’s a payment that multiple nodes can claim. In the BOLT11 format, it uses something similar to stateless invoices. Basically, it points to a phantom node, a node that doesn’t exist, but multiple nodes could basically intercept that payment and keep it. Yes, Murch?

Mark Erhardt: Right, basically the idea is if you run a large operation on the LN, you might have multiple nodes running at the same time that are load-balancing, and they have their own channels, and you want to be able to spin out one of them and do an update, or whatever, while still being able to process all of the payments. And in order to do so, you create a pretend node or make up a node that sits as a channel partner behind all of your other nodes. So, let’s say you have three nodes, Alice, Bob and Charlie. They are the actual Lightning nodes that have actual channels to other nodes in the network. And then, you make up a phantom node, Philip, that has a virtual pretend connection, like super-big channel, between Alice and Philip, Bob and Philip and Carol and Philip. And now, every time you get a payment, you make out all of your invoices to Philip, but they could all go through any of the three other nodes to reach Philip. And instead, you collect the payment at the level of Alice, Bob and Carol.

Mike Schmidt: I’ve been thinking about it. You guys tell me if I’m thinking about it the right way. Is this sort of like load-balancing, like everything goes through one, but then it can get routed to one of three behind the scenes? Is that kind of how it works?

Mark Erhardt: No, it always goes to one. And by trying to go to that one, it will have to pass through one of the three. And similar, but not quite the same. And by having these other three nodes that all do their own channels, that all have liquidity floating around, if for example one of the three nodes had all of their capacity on the outbound side and couldn’t receive an inbound payment, if you can’t route through Alice to Philip, you can route through Bob to Philip. Or if Carol is getting a software update and is down for three minutes, you can still route for Alice and Bob. But all of the invoices are created as if Philip were the recipient, and that way you get that flexibility for routing from any of your nodes. Otherwise, if you gave out all of the invoices with Alice, Bob or Carol, if one of them goes down, that node can’t receive, or if the liquidity locks up. I mean, you could still have huge-ass channels between Alice, Bob and Carol in order to make that work most of the time. But if one of them is actually offline, you just can’t receive those payments at that time and all of the payments will fail. So, it’s sort of a trick to be able to get redundancy.

Gustavo Flores Echaiz: So, in this PR, basically this feature is brought for BOLT12 offers. So, as a receiver, I will create a BOLT12 offer with multiple blinded paths, and let’s say I have three different blinded paths and each one would terminate at a different node that I have, right? So, then, technically the payment could be made to any of those nodes once they received any of those nodes’ response to the invoice request, but the resulting invoice after the invoice request can only be paid to the responding node. So, let’s say the phantom payment part only happens at the invoice request level, and then it can only, once there’s an invoice issued, that invoice can only be paid to one specific node.

Mark Erhardt: I just realized something completely unrelated, but if you have a blinded path and the payment fails in the blinded section of that path, you do know what nodes were in that. Do you learn what nodes were in the blinded path by them reporting the issue? We should have a Lightning person on this.

Mike Schmidt: This is when the t-bast bat signal, the bast signal should go up.

Mark Erhardt: The bast signal, wow! Yeah, the t-bast signal. Anyway, if you know the answer, you could just enlighten us on Twitter below this post or something.

Gustavo Flores Echaiz: Maybe through some sort of attributable failures implementation, this could be known, you know, but maybe there’s even limitations to that.

LDK #4318

So, we move forward with LDK #4318. This is a fairly simple one where the max_funding_satoshis field from the ChannelHandshakeLimits is removed. And what does that mean? It basically removes the pre-wumbo or the pre-large channels default channel size limit. So, there was an issue because LDK, at the same time, by default was limiting channels to the pre-wumbo default channel size limit, but at the same time it was advertising support for large channels by default. So, if you were a peer of an LDK node, you might try to open a large channel to an LDK node for them to see that it fails, because LDK advertised support for large channels, but behind the scenes it didn’t really accept them. So, now, this PR basically brings the advertising to be real. Now, LDK by default will accept large channels. Users, however, who want to limit risk and want to avoid large channels can use the manual channel acceptance flow and can configure rejecting channels that are of a larger size than they want.

LND #10542

We move forward of LND #10542. So, this is an interesting one because the graph database layer is basically extended to add support for gossip v1.75, also called gossip v2. This was mentioned in Newsletter #261 and #326, but basically gossip v1.75 is an extension of the gossip protocol to allow for channel announcements of simple taproot channels. So, we know LND has been going down the simple taproot channel direction for a while and this has been work building for a long time. So, now LND can store and retrieve channel announcements on its database. However, this doesn’t mean that LND has completed support for gossip v1.75. It remains disabled at the network level, pending completion of validation and gossiper subsystems. So, additional work is required for LND’s implementation of gossip v1.75 to take fully effect.

BIPs #1670

We move forward with BIPs #1670. This is the publication, or it adds basically BIP360, which specifies Pay-to-Merkle-Root or P2MR, which is a new output type that is very similar to P2TR, the taproot output type, but it removes its keypath spending or keyspending path. The reason why this is done, it’s to be resistant to long exposure attacks by cryptographically relevant quantum computers. So, this is a topic that has been discussed a lot publicly, how to make for taproot or P2TR output types to be resistant to, let’s say, a quantum computer using the Shor’s algorithm. Well, this is the solution for that. However, this is not a new output type that would protect against short-exposure attacks, because when you broadcast your transaction of a P2MR output, you would then sign for that output. And during the time it is unconfirmed, there could be a short-exposure attack theoretically from a quantum computer. So, additional research is being done for other post-quantum signature proposals. I’m guessing, Murch, you might have some comments on this?

Mark Erhardt: Yeah, so BIP360 had been in the works for, I think, over two years. The proposal was previously named differently, too. So, if you don’t recognize P2MR, you might have known it as pay to tapscript hash (P2TSH) or pay to quantum resistant hash (P2QRH) before. It really came together in the past couple of months after it got a complete rewrite. And basically, it is the first concrete proposal for any output type that has any benefit regarding quantum. My understanding is that the authors are looking into combining this with an actual post-quantum secure signature scheme, which we’ve heard a lot about here as well from, for example, Jonas Nick and Mikhail, that were on in the last month or so. Anyway, as Gustavo said, P2MR uses the same tapscript stuff under the hood, just like P2TSH, but because it doesn’t reveal an ECDSA public key onchain, it is not vulnerable to long-exposure attacks. It is still vulnerable to long-exposure attacks if an address is reused, and the post-quantum signature scheme is not available yet. So, the idea would be, presumably, to put a post-quantum signature scheme into an OP_SUCCESS opcode, and then use that directly in tapscript, which is the script variant that we use in P2TR leaf scripts, and then also now in P2MR leaf scripts.

Yeah, the obvious downside of these post-quantum schemes is that all of the so far proposed ones are much, much larger, with public keys being about 3,000 bytes and signatures being somewhere around 8,000 bytes. And if we compare that to the current 32-byte public keys and 64-byte transactions, that’s a two magnitude increase, of course. And, yeah, so we’ll keep monitoring this situation. So far, I’ve not been affronted by any quantum computer on my way to work, but we’ll keep working on this, I guess.

Mike Schmidt: Murch, you mentioned this is a step towards quantum resistance, but in terms of just having P2MR, you mentioned the short range, so I mean, P2SH, for example, would be equally as safe, right, these sorts of things?

Mark Erhardt: That is correct, yes. So, P2WPKH or P2SH would give you the same resistance to quantum attackers right now, as long as you don’t reuse any addresses where you reveal the actual spending conditions only at spending time. And then, the attacker would have to reverse the private key from the public key in the time from the unconfirmed transaction being broadcast and confirmed in the chain. So, given that quantum computers are actually pretty slow, or there’s different variants, but basically just the calculations take on the order of hours. If you make a transaction that goes into a block i n the next hour, you’re just not going to be vulnerable to that, and also not going to be vulnerable to that if we ever get quantum computers that can make calculations that can calculate private keys.

So, far, my understanding is that there are projects that have come up with one physical qubit, and it’s a big question how to get two of them to talk to each other. There are also advances on algorithms for quantum attacks, and the number of qubits that are necessary to make these attacks keeps going down. But if we’re actually still at a phase where these computers can run only in huge facilities that are physically cool to almost absolute zero, where you have to shoot lasers at specific spots on the chips in order to introduce the quantum state, then you have tons of noise reading that out. And we have no clue how to make two of them talk to each other with, as far as I’m aware, the only experiments that have been successful being factoring 15 and 21, when the circuit design already included those numbers as heavily hinted, in order to even factor numbers like that. I’m just not very scared that we’re going to be able to factor 256-bit numbers anytime soon, and especially not in the time between an unconfirmed transaction being broadcast and an unconfirmed transaction being confirmed. So, yeah, I’m still very much in the camp that we have to react to quantum because so many people are worried about quantum, but I’m not worried about quantum computers.

Mike Schmidt: Well, it seems like maybe the Bitcoin community should be worried about quantum in proportion to the output of the quantum side of the equation, right? It’s like you said, Murch, it can’t factor 21, but Bitcoin’s supposed to have a signature scheme deployed, right?

Mark Erhardt: I mean, other systems are upgrading right now. So, NIST has been recommending that all online systems, websites, and online banking, and so forth use post-quantum cryptography by, I think, 2035 or 2030. And of course, for these systems, that’s fairly easy because when we’re streaming hundreds of GB of data just to watch movies, well, GB per hour per user, then sending a few kB to establish an encrypted connection is not a big deal. But in Bitcoin, what we’re doing is we have a highly replicated, very, very small throughput blockchain, and if we have 1 MB or up to 4 MB per 10 minutes, giving them away in chunks of 3,000 to 8,000 bytes for public keys and signatures is going to significantly reduce the throughput. And therefore, for us, the trade-off means that we’re going to reduce our capacity by 100x if we just blindly roll this out today. And meanwhile, with all of the recent interest in the topic again, cryptography is making progress. So, if we wait a couple of years, we might have way more efficient schemes, way smaller schemes, that we’d much rather commit to maintaining for the next five decades, hundred years, whatever.

So, I think being aware, doing the research, putting it into the context of the trade-offs that we are solving for in Bitcoin is currently the right strategy. And saying that we need post-quantum signature schemes yesterday in Bitcoin, and everybody should also start using them right now, is I think just a little too rushed.

Mike Schmidt: Agreed.

Gustavo Flores Echaiz: Thank you Murch, I completely agree with all you said. So, listeners can look up the episodes in Newsletter #344 for the first coverage that we did on this BIP360, when it was called P2QRH, and Newsletter #385, which was a Year-End Newsletter, also has a strong, big section around quantum which includes this when it was called P2TSH.

BOLTs #1236

We move forward with BOLTs #1236. Here, the specification around dual-funding channels is updated to allow either node to send RBF to basically fee bump a channel funding transaction. However, previously, only the channel initiator could do this and now this is extended for both peers to be able to do it. The reason why this is done is because in the PR #1160 that defines channel splicing, this is a proposed part of splicing. So, the goal was to align dual funding with splicing to allow both sides to initiate an RBF. There’s also requirements added that both senders of the RBF initiation must reuse at least one input from a previous attempt, ensuring that the new transaction double-spends prior attempts, right? So, this is a condition around RBF, but it’s more properly specified in this PR to make sure that all details are covered. Any thoughts here?

BOLTs #1289

Finally, BOLTs #1289 changes how the commitment_signed message is retransmitted when nodes reconnect in the interactive transaction protocol, which applies both to dual funding and splicing. So, the reason why the work here is done is because the goal is to avoid unnecessary retransmission, which is especially important for simple taproot channels, when retransmitting the commitment_signed message would require a full MuSig2 signing round due to nonce changes. In other channel types, this is not that concerning. You could just simply retransmit the commitment_signed message. But because we’re now considering for simple taproot channels, we’ve got to consider the work done every time you retransmit the message. So, like I said previously, commitment_signed was always retransmitted when nodes would reconnect, even if the peer had already received it.

So now, instead, the message channel_reestablish includes an explicit field that basically lets a node request for the commitment_signed message if it still needs it. So, in most cases, a node that would come back online would simply tell the other node, “Hey, by the way, I got your commitment_signed message before I shut down, before I restarted, so you don’t have to send it again”. So, this allows for a more seamless flow, specifically when it comes to simple taproot channels. And that’s the last PR of this newsletter and that completes the whole newsletter as well.

Mike Schmidt: Thanks Gustavo, great job. We want to also thank our guests today, arbedout, Erik, and Misha, who joined us earlier for their segments. And I also want to thank Murch for co-hosting and you all for listening. We’ll hear you next week. Cheers.

Bitcoin Optech Newsletter #393

2026-02-20T00:00:00+00:00

This week’s newsletter summarizes a discussion about recent OP_RETURN usage and describes a protocol to enforce covenant-like spending conditions without consensus changes. Also included are our regular sections describing recent changes to services and client software, announcing new releases and release candidates, and summarizing recent merges to popular Bitcoin infrastructure software.

News

● Recent OP_RETURN output statistics: Anthony Towns posted to Delving about the recent OP_RETURN statistics since the release of Bitcoin Core v30.0 on October 10, which included changes to the mempool policy limits for OP_RETURN outputs (allowing multiple OP_RETURN outputs and allowing up to 100kB of data in OP_RETURN outputs). The range of blocks he looked at was heights 915800 to 936000, with the following results:
- 24,362,310 txs with OP_RETURN outputs
- 61 txs with multiple OP_RETURN outputs
- 396 txs with total OP_RETURN output script sizes greater than 83 bytes
- Total OP_RETURN output script data over the period was 473,815,552 bytes (of which large OP_RETURNS accounted for 0.44%)
- There are 34,283 txs burning sats to OP_RETURN outputs, for a total of 1,463,488 sats burnt
- There are 949,003 txs with between 43 and 83 bytes of OP_RETURN data, and 23,412,911 txs with OP_RETURN data of 42 bytes or less
Towns also included a chart showing the frequency of sizes for the 396 transactions with large OP_RETURN outputs. 50% of these transactions had less than 210 bytes of OP_RETURN data. Also, 10% had more than 10KB of OP_RETURN data.

He later added that Murch subsequently published a similar analysis on X and a dashboard of OP_RETURN statistics, and that orangesurf published a report on OP_RETURN for mempool research.
● Bitcoin PIPEs v2: Misha Komarov posted to Delving Bitcoin about Bitcoin PIPEs, a protocol that allows enforcement of spending conditions without the need for consensus changes or optimistic challenge mechanisms.

The Bitcoin protocol is based on a minimal transaction validation model, which consists of verifying that a UTXO being spent is authorized by a valid digital signature. Thus, instead of relying on spending conditions expressed by Bitcoin Script, Bitcoin PIPEs adds prerequisites on whether a valid signature can be produced or not. In other words, a private key is cryptographically locked behind a predetermined condition. If and only if the condition is fulfilled, the private key is revealed, allowing for a valid signature. While the Bitcoin protocol only has to validate a single schnorr signature, all the conditional logic is processed off-chain.

On a formal level, Bitcoin PIPEs consists of two main phases:
- ● Setup: A standard Bitcoin keypair (sk, pk) is generated. sk is then encrypted behind a spending condition statement using witness encryption.
- ● Signing: A witness w is provided for the statement. If w is valid, sk is revealed and a schnorr signature can be produced. Otherwise, recovering sk becomes computationally infeasible.
According to Komarov, Bitcoin PIPEs can be used to reproduce covenant semantics. In particular, Bitcoin PIPEs v2 focuses on a limited set of spending conditions, enforcing binary covenants. This model naturally captures a wide range of useful conditions whose outcomes are binary, such as providing a valid zk-proof, satisfying an exit condition, or existence of a fraud proof. Basically, it all comes down to a single question: “Is the condition satisfied or not?”.

Finally, Komarov provided real-world examples of how PIPEs could be leveraged instead of new opcodes, and how it could be used to improve the optimistic verification flow of the BitVM protocol.

Changes to services and client software

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

● Second releases hArk-based Ark software: Second’s Ark libraries were updated to use hArk, hash-lock Ark, in version 0.1.0-beta.6. The new protocol eliminates the synchronous interactivity requirement for users during rounds, with its own set of tradeoffs. The release includes various other updates, including breaking changes.
● Amboss announces RailsX: The RailsX announcement outlines a platform using LN and Taproot Assets to support swaps and various other financial services.
● Nunchuk adds silent payment support: Nunchuk announced support for sending to silent payment addresses.
● Electrum adds submarine swap features: Electrum 4.7.0 allows users to pay onchain using their Lightning balance (see submarine swaps), among other features and fixes.
● Sigbash v2 announced: Sigbash v2 now uses MuSig2, WebAssembly (WASM), and zero-knowledge proofs to achieve better cosigning-service privacy. See our previous coverage on Sigbash for more.

Releases and release candidates

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

● BTCPay Server 2.3.5 is a minor release of this self-hosted payment solution that adds multi-crypto wallet balance widgets on the dashboard, a custom textbox for checkout, new exchange rate providers, and includes several bug fixes.
● LND 0.20.1-beta is a maintenance release of this popular LN node implementation, which adds a panic recovery for gossip message processing, improves reorg protection, implements LSP detection heuristics, and fixes multiple bugs and race conditions.

Notable code and documentation changes

● Bitcoin Core #33965 fixes a bug where the -blockreservedweight startup config (see Newsletter #342) could silently override the block_reserved_weight value set by Mining IPC clients (see Newsletter #310). Now, when an IPC caller sets the latter, it takes precedence. For RPC callers who never set this value, the startup config -blockreservedweight always takes effect. This PR also enforces the MINIMUM_BLOCK_RESERVED_WEIGHT for IPC callers, preventing them from setting a value below it.
● Eclair #3248 starts prioritizing private channels over public ones when forwarding HTLCs, if both options are available. This keeps more liquidity available in public channels, which are visible to the network. When two channels have the same visibility, Eclair now prioritizes the channel with the smaller balance.
● Eclair #3246 adds new fields to several internal events: TransactionPublished splits the single miningFee field into localMiningFee and remoteMiningFee, adds a computed feerate and an optional LiquidityAds.PurchaseBasicInfo linking the transaction to a liquidity purchase. Channel lifecycle events now include the commitmentFormat to describe the channel type, and PaymentRelayed adds a relayFee field.
● LDK #4335 adds initial support for phantom node payments (see Newsletter #188) using BOLT12 offers. In the BOLT11 version, invoices included route hints pointing to a non-existent “phantom” node, with each path’s last hop being a real node that could accept the payment using stateless invoices. In BOLT12, the offer simply includes multiple blinded paths terminating at each participating node. The current implementation allows multiple nodes to respond to the invoice request, though the resulting invoice can only be paid to the responding node.
● LDK #4318 removes the max_funding_satoshis field from the ChannelHandshakeLimits struct, effectively eliminating the pre-wumbo default channel size limit. LDK was already advertising support for large channels via the option_support_large_channels feature flag by default, which could have incorrectly signaled support to peers by conflicting with the former setting. Users who want to limit risk can use the manual channel acceptance flow.
● LND #10542 extends the graph database layer to support gossip v1.75 (see Newsletters #261 and #326). LND can now store and retrieve channel announcements for simple taproot channels. Gossip v1.75 remains disabled at the network level, pending the completion of the validation and gossiper subsystems.
● BIPs #1670 publishes BIP360, which specifies Pay-to-Merkle-Root (P2MR), a new output type that operates like P2TR but with the keypath spend removed. P2MR outputs are resistant to long-exposure attacks by cryptographically relevant quantum computers (CRQCs) because they commit directly to the Merkle root of the script tree, a SHA256 hash, rather than a public key. However, protection against short-exposure attacks, such as against private key recovery while a transaction is unconfirmed, requires a separate post-quantum signature proposal. See Newsletter #344 for earlier coverage when the proposal was known as P2QRH and Newsletter #385 when the proposal was known as P2TSH.
● BOLTs #1236 updates the dual funding specification to allow either node to send tx_init_rbf during channel establishment, effectively allowing both parties to fee bump the funding transaction. Previously, only the channel initiator could do so. This change aligns dual funding with splicing, where either side could already initiate an RBF. The PR also adds a requirement that both the senders of tx_init_rbf and tx_ack_rbf must reuse at least one input from a previous attempt, ensuring that the new transaction double-spends all prior attempts.
● BOLTs #1289 changes how commitment_signed is retransmitted during reconnection in the interactive transaction protocol used by both dual funding and splicing. Previously, commitment_signed was always retransmitted on reconnection, even if the peer had already received it. Now, channel_reestablish includes an explicit bitfield that lets a node request commitment_signed only if it still needs it. This avoids unnecessary retransmission, which is especially important for future simple taproot channels where retransmitting would require a full MuSig2 signing round due to nonce changes.

Bitcoin Optech Newsletter #392 Recap Podcast

2026-02-17T00:00:00+00:00

Mark “Murch” Erhardt and Gustavo Flores Echaiz are joined by Sebastian Falbesoner and Oleksandr Kurbatov to discuss Newsletter #392.

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

Download audio

News

● Proposal to limit the number of per-group silent payment recipients (1:13)
● BLISK, Boolean circuit Logic Integrated into the Single Key (26:43)

Releases and release candidates

● Bitcoin Core 29.3 (49:18)
● LDK 0.2.2 (51:16)
● HWI 3.2.0 (52:20)
● Bitcoin Inquisition 29.2 (53:54)

Notable code and documentation changes

● Bitcoin Core #32420 (56:05)
● Core Lightning #8772 (1:02:29)
● LND #10507 (1:03:56)
● LDK #4387 (1:05:48)
● LDK #4355 (1:08:14)
● LDK #4354 (1:09:21)
● LDK #4303 (1:10:52)
● HWI #784 (1:13:10)
● BIPs #2092 (1:15:02)
● BIPs #2004 (1:16:33)
● BIPs #2017 (1:19:44)
● Bitcoin Inquisition #99 (1:26:53)

Transcription

Mark Erhardt: Good morning, this is Bitcoin Optech Newsletter #392. Today, we’re going to talk about a proposal to limit the silent payments recipients, and we’re talking about BLISK, a boolean circuit logic integrated into a single key. And we have a few Release candidates and a bunch of Notable code and documentation changes for you, especially LN stuff this week. So, let’s get right into it. We are joined by two guests, Sebastian and Oleks. Would you like to introduce yourselves?

Sebastian Falbesoner: Yeah, I’m Sebastian. I’m a many years’ Bitcoin Core contributor and also a little more into libsecp lately. And I’m funded by Brink.

Oleksandr Kurbatov: Yeah, my name is Oleks. I have recently joined Blockstream as a cryptography researcher. In the past, I also made a lot of tricks with Bitcoin and zero-knowledge proofs (ZKPs), but yeah.

Mark Erhardt: Thank you. Thank you for joining us. Also with us is Gustavo today again.

Gustavo Flores Echaiz: Hi, Murch. Hi, everyone. Thank you for having me.

Proposal to limit the number of per-group silent payment recipients

Mark Erhardt: Wonderful. So, let me get to the first News item. We’ve seen a discussion, I think we reported on it a few times already, and the context is for silent payments, when you have multiple recipient outputs that are all going to the same silent payments recipient, it could become quite expensive for that recipient to scan the silent payments outputs. And there is now a proposal to limit the number of outputs that can go to a single recipient to 1,000. Sebastian, you’ve been looking at this for some time. Can you provide a little more context on what exactly the issue is here and maybe why it only affects a single recipient? You do have to scan all P2TR outputs anyway, right?

Sebastian Falbesoner: Yeah, so for the historical background, in libsecp, the cryptographical library used in Bitcoin Core and the wider Bitcoin ecosystem, we have been working on implementing a silent payments module for quite a while now. I think it is at least two years. Yeah, I know, getting late! At least two years, we have reached take four or five already; well, take five having been closed recently.

Mark Erhardt: Let me jump in there right now. So, we’ve been promised silent payments. How come this is taking so long? What’s the problem? Who do we have to lean on to?

Sebastian Falbesoner: Two weeks, TM! Yeah, so I think we’re quite far already, but within the last months, one reviewer found a potential issue on the recipient side, on the scanning side. So, the issue is, it could perform quite bad in the worst case, the worst case being that a sender crafts a transaction that fills out a whole block, like maxing out the consensus limit of 1 mega-vbytes. So, this will be a transaction that is non-standard, because the non-standard limit is 100 kvB (kilo-vbytes). And if a sender crafts a transaction where all the recipients are going to one entity, one group – so to give a little context in silent payments, a recipient address not only consists of one public key, but two. So, there is a scan public key and the spend public key, and a group is defined as all recipients that share the same scan public key. The spend public key can be different due to a mechanism called labeling, like you can tweak spend pubkeys. So, it’s a little cheaper to scan, so it’s meant as a mechanism to differentiate the incoming payments. So, it shouldn’t be confused with accounts, because there are privacy drawbacks.

But yeah, to come back to the topic, so we found that if such an adversarial transaction is created with a little more than 23,000 outputs, or it’s a little more, I don’t know the exact number now in my head, but so you just divide the maximum block space by the space it will take for one taproot output, because silent payments only creates taproot outputs.

Mark Erhardt: Yeah, I think 23,000-something is right.

Sebastian Falbesoner: Yeah, something a little more than that, assuming that one taproot output takes 43 vbytes, I think. And yeah, so the scanning we do currently in the module is we go through all the transaction outputs and see if there is a match. And doing that is not just comparing a fixed output, there is some elliptic curve calculation included to detect labels. So, we just have first an unlabeled output candidate and we subtract that from each candidate in the output, and then we look if the result is in one of our labels in our label cache. So, for each output, there is some quite expensive elliptic curve operation to be done for each output. And yeah, if we assume now we have a match, we have to do the same thing again because we derive a different tweak.

Mark Erhardt: Right, let me jump in briefly and give a little more context. So, in silent payments, the nifty thing is we get reusable addresses, because we can send to the payment instructions multiple times without it looking like the same output script onchain. And the way it works is that it takes all of the public key information and creates an Elliptic Curve Diffie-Hellman with a key exchange with the recipient public key; we’ll talk more about ECDH in just a little while. And so, the recipient basically just checks, “If I try to do a key exchange with my public key and the information from the inputs, does any of these outputs look like it’s paying me with that construction”, right? So, this is unique because the inputs are always required to be unique, you can never spend the same UTXO twice. So, if a UTXO is spent, the output will be unique. But if you paid the same recipient multiple times, it would generate the same output script. So, the way we get around this is we increment a counter for every time someone is paid. We tweak it with a +1 basically, and that way we get a new output script every single time. And for everyone else, it looks indistinguishable from any other P2TR output.

So, the way I understand you here is, we have to scan them in order. Now, I’m curious, wouldn’t it work that we require payments to the same recipient to be in order? Like, sure, if you’re paying five people, it could be Alice, Bob, Carol, then me, and then me again. But couldn’t we just require that outputs are ordered in the order that they are going?

Sebastian Falbesoner: Yeah, that was another suggestion in the more recent discussion. But that would be a far more invasive change because the BIP is already out for some time and the BIP says the order doesn’t matter.

Mark Erhardt: Unfortunately, you always learn more the longer you’re pursuing an idea!

Sebastian Falbesoner: Yes. If we do that, we called it the ordered K idea and the limited K idea, so we even had these fancy names already. But the ordered K would be very invasive. I think there were some privacy issues raised, I’m not sure if they are based on a good foundation, but I think my prime argument would be it’s too late for that.

Mark Erhardt: Well, because silent payments hasn’t been adopted that broadly yet. There’s probably like three wallets that use it so far.

Sebastian Falbesoner: Maybe it’s still possible, yeah. I think one argument was also that it’s more secure on the sender side of the libsecp API if we do a limited K because we can error out if it’s not respected. Whereas in the ordered K, we can create some result, but we would still have to give guarantees, “Oh, please never modify the order of this”. So, it’s much more in the hands of the upper layer to follow whatever we write in the docs.

Mark Erhardt: Right. For example, Bitcoin Core will shuffle the outputs on a transaction.

Sebastian Falbesoner: Yeah, for example, yeah. So, things like those you cannot do anymore. Also, I don’t know if you think about batch transactions on exchanges. I don’t know if they shuffle outputs or not, but one would have to be really careful to then keep the order, as otherwise payments cannot be found.

Mark Erhardt: Right. Or, or if someone does a coinjoin and multiple people happen to pay – well, never mind, they’d have to coordinate them anyway to tweak the number.

Sebastian Falbesoner: Yeah. I’m not familiar with those details of coinjoins, if there is some ordering, sorting or randomizing included or not, but yeah.

Mark Erhardt: Right. So, basically the concern is the recipient would have to scan all outputs. And then, let’s say on the last one, the recipient finds a payment to themselves. And then they’re like, “Well, there could be a second payment”, and now they have to scan all of them again. So, with 23,000 payments, if they were ordered exactly reverse and it scanned in the correct order, then it would always be super-slow.

Sebastian Falbesoner: Yes, to give some concrete numbers here, I think it was in the range of about 10 minutes, 9 to 10 minutes on a more modern machine. And one first optimization you can do is just randomize the outputs, because then finding one K is already cut in half. So, I think it’s close to n²-half in the worst case, like you don’t always go to the end, but always closer to the end.

Mark Erhardt: So, of course if he’s nice to you and actually orders them in the right way, then it also takes much longer.

Sebastian Falbesoner: Yes. So, with that, we could go down from roughly 10 to 5 minutes, but that’s still kind of not ideal. So, I think it’s hard to reason what is the right number, but I don’t think we want to be on the same order of magnitude of the block time, if that makes sense, right? I mean, it’s still an unanswered question, “What is a good range to be in?”

Mark Erhardt: So, what would be the constraint here? So, the recipient gets paid by you 23,000 times, and on the machine where they scan for silent payments, they’ll now be slow. So, if this is an exchange, hopefully they have a separate machine to scan for silent payments, and some of the silent payment recipients might be informed a few minutes later. If it’s a home user, congrats on getting paid 23,000 times.

Sebastian Falbesoner: I mean, one detail to that, it doesn’t necessarily mean that the funds go to the recipient. You could have 20,000 outputs with zero sets, right, because there is no reason to respect the dust limit. It’s a non-standard transaction anyway already. And it could be that only in the last find, there is some bigger amount that it’s worth it scanning. I guess you could apply some filter and say if the total amount is below that and then threshold, then just skip it, it’s not worth it. But it’s not necessarily that a high amount of funds go to the recipient. The main cost is the fees, or the bribe for the miner to include the block. It’s a non-standard transaction.

Mark Erhardt: It could even be worse, you make 23,000 payments to the recipient that are all zero sets and then the last payment goes to someone else.

Sebastian Falbesoner: Yes, that is also very much possible.

Mark Erhardt: Right. So, why still 1,000? Isn’t it maybe a little unexpected? We see very few transactions where there are 1,000 payment outputs in the first place. Why would anyone ever need to pay 1,000 people on the same scan key?

Sebastian Falbesoner: Yeah. One thing that was brought up, if one exchange sends to another exchange with a large batch transaction, I mean, I guess they wouldn’t want to use non-standard transactions, but that was one thing that was brought up. And in general, the 1,000 number is still more of a placeholder. I mean, I know in the newsletters it was stated as it was my concrete suggestion, but I gave the feedback, “Oh, let’s keep it as my suggestion. If we say it’s a concrete one, then maybe it’s easier to get feedback”.

Mark Erhardt: I don’t know, it seems still pretty big.

Sebastian Falbesoner: Yeah, I think I wouldn’t have sleepless nights if we go to the order of hundreds or something.

Mark Erhardt: Yeah, 200 or something would probably be fine.

Sebastian Falbesoner: One other suggestion was to just take a tenth of the maximum. So, we would still have the worst-case standard transaction size. So, that would be 2,350-something. But yeah, I’m not sure if that’s really necessary. It’s now a trade-off of what worst-case time are we willing to accept. So, with 1,000, we are at 30 seconds unoptimized. With the randomizing of the outputs, we are on roughly 15 seconds. And then, there is one other interesting optimization that helps both for the worst and the average case. That is a batch inversion. And then, that brings another 2.5X improvement.

Mark Erhardt: Batch inversion being, you find the first output and then you scan, is it the next one or is it the previous one?

Sebastian Falbesoner: It’s more like after you do these elliptic curve point additions, you’re in some internal representation, Jacobian coordinates, and you have to transfer those back to a fine coordinate, like only with XY constants to serialize them, so that the label cache lookup can be done. And that needs one inversion per each transaction output, and you could do those in batches. So, you do that within a single K-value that you look to this inversion at several outputs at once, which is significantly faster.

Mark Erhardt: And the inversion is always different for each tweak, right? You couldn’t just scan for the first 10 tweaks on every output right away?

Sebastian Falbesoner: Yes. So, it’s the result of a calculation where the thing you subtract from the text output is different for each K-value. But for that reason, yeah, it helps also for the average case.

Mark Erhardt: All right. And this is holding up silent payments now?

Sebastian Falbesoner: I think so. Yeah, I’m pretty positive that this is one of the last blockers. Yeah, we did quite spend a long time on alternative scanning approaches. So, there is a thing where you do the scanning in the other direction, where you loop over the labels and look at the result, “Oh, is any of this result in my transaction outputs?” And this has the drawback that it scales not well with the number of labels. So, for use cases with many labels, it gets slower and slower with each additional label. And the functionality as described in the BIP that we implemented, it’s basically independent of the number of labels because the lookup is done in a hash map. So, that has a nice 01 lookup cost property.

In retrospect, I regret a little that we spent so much time into looking that we could have proposed a protocol change earlier, but I don’t know, in my head it was like, “Oh, that’s too late already. That would be silent payments v1 already, like the next version”.

Mark Erhardt: But seriously, yes, it’s implemented now by, I believe, Sparrow, by CakeWallet, and I think Nunchuck just announced that they implemented it. But let’s say you start using v2 now and v2 requires that it’s ordered or limited to 200, or whatever you decide in the end. And for the ones that ruled it out, sure, maybe I assume the silent payments address would have to change for the users, but the implementation cost of that I assume would be pretty low.

Sebastian Falbesoner: Yeah. I mean, the plan now is to not change the version, because we are reasonably confident, or maybe there will be still some feedback that indicates otherwise. But so far, it seems like no one even creates transactions with more than one recipient.

Mark Erhardt: Right. Wouldn’t it also be pretty easy to, if you ever see a transaction that is this big, you ignore it and just scan it in the background in chunks or something?

Sebastian Falbesoner: You mean like do that on a separate thread?

Mark Erhardt: Yeah. Like, I mean most of the time I think we don’t see transactions with that many payment outputs anyway. But then, if you do, how, how urgently do you usually need to know that you got paid? Can you not just chunk it in and scan in background?

Sebastian Falbesoner: Yeah. I mean, this would probably introduce a code path that it’s so rarely executed that I don’t know, you cannot even test it. But yeah, so far there was explicit feedback from two developers that said they’re fine with the limit. They cannot think of any use case. There was one slightly related feedback about we need good API documentation, because the current scanning API is capable of scanning hundreds of thousands of labels easily. But if everyone using that API hands out and creates that many labels already, then that might be not interoperable with every type of wallet. So, for example, light clients, they are more restricted in the number of labels they can use. So, it’s important that we point that out. Like, if you create a lot of labels, then don’t expect that every wallet that will ever exist will be able to import and scan for those.

Mark Erhardt: When you’re talking about API, you’re now talking about the API of libsecp, right?

Sebastian Falbesoner: Yeah.

Mark Erhardt: Yeah, okay, thank you. So, users of libsecp would be predominantly Bitcoin Core, but also other Bitcoin projects that use libsecp or wrap libsecp for crypto.

Sebastian Falbesoner: Yes, exactly.

Mark Erhardt: So, the next step would be to decide what the actual limit is and to improve API documentation to release libsecp and roll out the silent payments?

Sebastian Falbesoner: Yes. Just yesterday on the PR, it’s PR #1765. I think on libsecp, I proposed a limit of 1,000. I proposed API documentation and there’s been positive feedback so far, but maybe I’m sure there will be some more bike-shedding. One open question might be, if you find a transaction that exhausts the K limit, wouldn’t users want to look ahead and see, “Oh, it could be that there is still something hiding in the more than K_max”, so would we want to provide recovery tools for that, or something? But that would complicate the API. But I guess there will be some bike-shedding discussion about that.

Mark Erhardt: I mean, it’s a little bit sort of a discussion similar to, you give an address to someone else and they interpret it to construct a different output script. Like you tell someone, “P2TR public key”, and they P2PKH instead. It’s like, “You’re not following my instructions on how I want to be paid. Did you actually pay me or not?” Like, if you go and dig a hole in my backyard because you have my address and bury money there, did you pay me when you were supposed to drop it into my mailbox?”

Sebastian Falbesoner: Yes.

Mark Erhardt: I feel like it’s good to think about this, but just imposing a limit and widely communicating that you shouldn’t pay more than 1,000 times to the same recipient seems like doing more than this might be overthinking.

Sebastian Falbesoner: Yes, I agree, but I wouldn’t be surprised if that comes up in the discussion. But other than that, I would hope that we are ready soon. That was one of the major blockers over the last few months, I would say. I mean, the investigating of alternative scanning approaches was interesting. It led to a lot of benchmarking data.

Mark Erhardt: I see you’re following the tradition of other Bitcoin developers that say something is engineered properly when it’s over-engineered 140%!

Sebastian Falbesoner: Yeah, I guess you could say so, yeah.

Mark Erhardt: All right. Gustavo, Alex, do you want to chime in on this one?

Gustavo Flores Echaiz: No, I think it was quite clear, thank you.

Mark Erhardt: All right. Do you have any call to action or other information to share, Sebastian?

Sebastian Falbesoner: One small thing. I’m trying to make a signet block with that exact attack. I’m just still working on including it. It’s non-standard, so I have to bribe a signet miner to include it, but once that is ready, I will post it on the mailing list with all the key material and the label data needed, so other wallets can see if they are affected by this attack. Or maybe it reveals other things, right? If you get paid 20,000 times per transaction, even if you don’t have an issue in scanning, it could be that it reveals that, I don’t know, your GUI is crashing because it’s not prepared to get 20,000 times in a single transaction. So, once that is ready, I will share that as well. And otherwise, if there are no further objections, I think we will introduce either that limit or a similar one and, yes, hopefully be able soon to ship the silent payments module in libsecp.

Mark Erhardt: Are you worried about popularizing the attack by talking about it so much?

Sebastian Falbesoner: No.

Mark Erhardt: Okay.

Sebastian Falbesoner: It’s an unusual attack. Also, something to point out, I don’t know if I mentioned that in the mailing list attack, all the others are not affected. It’s only affects that single targeted entity.

Mark Erhardt: Right. It only affects the recipient that is being paid actually. And you still have to buy all that blockspace, right?

Sebastian Falbesoner: Yes.

Mark Erhardt: I mean, 20,000 outputs at 43 bytes is still, well, the whole block is 1 million bytes, so it’s a hundred thousand sats, even at 0.1 sat/vB (satoshi per vbyte), which seems unlikely.

Sebastian Falbesoner: I would be very surprised if we ever see that attack on mainnet. But better to be prepared for it than not.

Mark Erhardt: Okay. Now, stop delaying silent payments!

Sebastian Falbesoner: Yes. Two weeks, TM!

Mark Erhardt: Okay. No, I’m still very excited for that to roll out more broadly. I think it’s one of the more exciting privacy techniques that has come up in the last few years. All right. Thank you, Sebastian, for joining us.

Sebastian Falbesoner: Thanks for having me.

BLISK, Boolean circuit Logic Integrated into the Single Key

Mark Erhardt: We’re going to talk about BLISK next. You can stick around or not. See you! All right, cool. As I said already, we’ll be talking about, “Boolean circuit Logic Integrated into the Single Key” with Oleks, and this is called BLISK. You posted on Delving Bitcoin about BLISK. And the idea here is with MuSig and FROST, you can create threshold signatures and multisignatures in the sense that you can design a certain number of keys to form a quorum. So, you can do with FROST things like 3-of-5; with MuSig, you can only do n-of-n so 2-of-2, 4-of-4, 16-of-16. And with BLISK, you described that you can construct a boolean logic where you can use logic AND and logic OR to combine keys into, well, logic expressions, boolean expressions, I should say. I read that you use ECDH to construct the OR gates and you use MuSig2 to construct the AND gates. And that’s about all that I understood from this. Oh, and onchain, you only see a single public key. You only need to accept a single signature, but offchain, the participants in the output script have to construct that output script in some manner. So, I’m curious, how much effort is that whole out-of-band setup there?

Oleksandr Kurbatov: Yeah, basically we started this research more than one year ago and initially we tried to resolve another problem, totally another. We worked on verifiable key agreement mechanism. For example, if you’re operating in the chat and you have like many, many different participants, to make your networking efficient, you need to have a kind of broadcast encryption key. And if each participant controls their own key, you need to have this verifiable key establishment mechanism. And if you want to have a robust environment, where nobody can break the system on their own, you need to combine all keys together to receive a single value and use it for broadcast encryption. And then, we decided to see on this problem from a different angle. We came to the idea, okay, if Alice – so ECDH, that’s literally what an OR gate does. Because if you have Alice and Bob and they are combining their secrets and their public keys to the single value, if we are asking who exactly can access the key: Alice or Bob, because Alice can derive the same key and Bob can derive the same key. So, that’s literally what an OR gate does.

Mark Erhardt: Right. So, an Elliptic Curve Diffie-Hellman handshake creates a shared secret, which is produced from the public key of one side and the private key of the other side. So, I only got it now when you explained it, but the OR gate basically is, “I know the public key of Alice. So, it’s either Alice’s public key and my private key, or Alice knows my public key, so Alice’s private key and my public key can also construct a shared secret”. Okay, that’s pretty cool. Go on.

Oleksandr Kurbatov: And that’s very important that only Alice or Bob can derive the same key. So, Carol cannot do that, Dave cannot, etc. Then, we have looked on multisignature n-of-n constructions. And that’s literally what an AND gate does. Because if we have Alice and Bob and key aggregation mechanism like MuSig2 key aggregation mechanism, and if we are asking who exactly can produce the signature: Alice plus Bob. So, Alice cannot do that without Bob, Bob cannot do that without Alice, only them together. And yeah, logically, we decided to build a tree or a kind of a circuit where each gate can be represented as an ECDH or MuSig2 aggregation mechanism. And basically, it worked. So, right now you can define the list of public keys of all participants. So, Alice, Bob, Dave, Carol, etc. Then you can write the logic how exactly you want to see your policy, so who exactly must co-sign the transaction to have a valid signature. And then, you need to compile everything. One missing component is ZKPs, because when you are constructing ECDH secret, you need to prove that you have constructed that in the right manner. Basically, that’s it.

Mark Erhardt: So, how are they compiled into a single public key then? Is it just an addition of the public keys? I would assume that that can’t be it, because then maybe there would be cancellation attacks or things like that. So, at a high level, could you explain how you go from the boolean logic to a single public key?

Oleksandr Kurbatov: Right. Just imagine the tree and we have public keys of each participant, except tree leaves. And then, we need to calculate values in nodes. And there is dependency on what kind of node we want to calculate, because for n nodes, we need to make a key agreement or a key aggregation mechanism, like MuSig2. But if you’re operating with OR gate, definitely Alice or Bob, so one of the children, should calculate this secret and appropriate public key. And that’s why we need ZKPs, because we require only one party to calculate the common secret. But no one should be able to forge the tree itself.

So, yeah, definitely we need to first of all define how exactly we need to calculate appropriate nodes in the tree. And one additional note that we need to represent this circuit in CNF form, this Conjunctive Normalized Form. It means we need to have only one AND root gate with a lot of children OR gates. So, yeah, it’s kind of like trusted setup, but this is not a trusted setup because we are using bullet proofs. For example, you can use any proof framework which doesn’t require you to have this toxic waste and trusted setup, so it can be completely verifiable, but this is setup. So, you cannot take only one coordinator who will calculate an entire circuit. You need all parties, like not all parties, but enough forum of them to collaborate, create the final public key.

Mark Erhardt: So, basically, all of the involved participants agree on the boolean expression that they want to implement, then all of them have to participate at various steps, either to contribute to the OR constructions or the AND constructions. And then, you use ZKPs to prove that every party participated correctly for the parts that others cannot look into. When we talk about trusted setup, for example, in the context of Zcash, there is a group, an in-crowd that creates the circuit that is used by everyone later. But in this case, the people that rely on this expression are also participating. So, in a sense, it’s like a trusted setup, but only for the people that are in the trusted crowd, right?

Oleksandr Kurbatov: Yeah, definitely. Everybody should agree on the same policy. It’s how organizations operate. Because we have, I don’t know, CEO signature is required plus, I don’t know, CFO plus CMO, etc. So, all parties are already agreed with the defined policy, and this is totally fine. It’s how, for example, we just created the multisignature. We agreed that we’re going to use this public key, that’s the kind of agreement, and we have the same type of agreement in the BLISK. So, all parties need to make a short interactive round to compute the final public key. And then, what is very interesting is that you can then update the key without interactions with other parties. If, for example, only my key should be changed because, I don’t know, the previous was compromised or, I don’t know, I have lost it, I don’t need to re-DKG (Distributed Key Generation). So, BLISK doesn’t require DKG, I can operate with existing key. I don’t know, I have used that ten years and I can easily connect it to the BLISK instance.

Mark Erhardt: But that generates a new output script, right?

Oleksandr Kurbatov: What do you mean by the output script?

Mark Erhardt: So, the output script, the scriptPubKey that people pay to in the end is a product of all the input public keys and the boolean logic, right? So, if you change one of the keys, it would be a new output script, right?

Oleksandr Kurbatov: Yeah, that’s right. I mean, for example, if you have already set up this public key to the smart contract, you can easily update that. In the case of Bitcoin, you need to have enough quorum to co-sign the new transaction, to transfer money to the new P2TR address.

Mark Erhardt: Sure, but you need to tell everyone else that you update your key, because they wouldn’t be tracking it anymore. So, the non-interactive part is you can unilaterally propose it, but everybody else is involved again in this.

Oleksandr Kurbatov: Yeah, I mean for example, in Frost, if you’re updating your own key, you cannot do that without involvement of all parties, because everybody participates in your DKG procedure. In this case, all other keys can remain the same, but only my part will be updated. So, I don’t need them to store new secrets, new key shares, such like, so we don’t need that.

Mark Erhardt: Right, but they do need to sort of be aware of the new tree construction and what outputs to scan. Yeah, cool. So, the big advantage here is, of course, that you can have more complex restrictions or constructions than just with two out of these three or all of these. Where do you anticipate this BLISK will be used? Because it sounds to me like the setup for these output scripts is pretty heavy with ZKPs and first coming to agreement what the policy should be. Sounds like maybe manual even.

Oleksandr Kurbatov: I have attached benchmarks in the paper and definitely, yeah, you’re totally right. Everything depends on the policy you want to have. If this policy is complex, I don’t know, it requires, I don’t know, a large pool and circuit, definitely the setup takes more time. The signature process will be like very easy, so it’s just an instance of MuSig2 solution. But the setup will be harder and harder depending on the complexity of the circuit. But for example, for real life examples, if you want to emulate threshold 2-of-3 with this construction, or Alice plus Bob or Carol, setup takes milliseconds. And so, yeah, it can be done by, I don’t know, any device. So, the proving system is not quite difficult. So, you’re not proving, I don’t know, the KVM execution trace. You’re proving only the simple operations: ECDH and that’s it. You can prove that efficiently.

Mark Erhardt: Right. So basically, if a wallet wanted to implement this, onchain it looks completely the same. All of the complexity is out of band with the setup where now they might need to be able to verify a ZKP that proves that the ECDH was done correctly, which probably wallets wouldn’t have yet, but could perhaps get through some library, like libsecp or similar. And then, the signature is basically, you just sign regularly and it gets aggregated according to the circuit?

Oleksandr Kurbatov: The same process as in MuSig2. It’s just a schnorr signature. So, verification is the same, so yeah, no difference.

Mark Erhardt: So, when you set up a boolean logic policy like that, would you be able to have key derivation on top of that? So, you can basically have a single output script that is the zeroth iteration of it and then you just tweak it differently, like extended public key sort of stuff?

Oleksandr Kurbatov: That’s a good question. You can tweak that, no problems. But for example, it has the same problem as silent payments have. So, for example, you cannot P2TR, where is the multisignature behind. So, if this taproot is like aggregated MuSig2, you cannot pay the silent payment to this address because they cannot derive an appropriate ECDH and receive a new key.

Mark Erhardt: Sure.

Oleksandr Kurbatov: The same here. So, the final public key, you cannot just create ECDH with this public key and pay, I don’t know, silent payments to this address. So, the tweaking can be done, but the amount of techniques is limited so you can do it properly.

Mark Erhardt: But it sounds to me like you could at least use it as a generator for many different output scripts so you don’t get massive address reuse, with just incrementing or labeling.

Oleksandr Kurbatov: Yeah. I need to think.

Mark Erhardt: I’m just jumping into new topics here. Okay, so basically the idea is maybe this could be used at a enterprise level set up or for smart contracts, or do you think this would be interesting maybe as a bridge setup technique, or how do people use this in the future?

Oleksandr Kurbatov: Yeah. For me, like, what’s the most important part? You cannot express real life by the pure threshold signature. So, if you have a condition, Alice or Bob and Carol or Dave should sign, you cannot express a simple policy by threshold signature. That’s not possible at all. It means if you need to have something more flexible than pure, you’re going to use BLISK.

Mark Erhardt: Well, you could do it in a script leaf of course currently, but that would require leaking a lot more information on what’s going on under the hood, and it would be more expensive onchain. The big advantage here would be the complexity moves out of band and you don’t reveal what’s the business logic underneath. But we could do something like this currently with script, just not as elegantly.

Oleksandr Kurbatov: The reason why we like MuSig2 or FROST is because they are hiding the policy behind. So, we can verify only the single signature, but we have no clue how many participants participated to produce the signature. The same in that, you can hide the policy itself, because the verifier can verify only the single signature. You don’t reveal anything about your policy structure, about your organization structure, so this data is hidden. And probably, that’s just beautiful, yeah.

Mark Erhardt: Right. So, you posted to Delving about this, you mentioned the paper. So, is the next step that this is going the academic research route, or you also have a proof of concept; are you working on a project that is making use of this, or how does this fit into the bigger picture?

Oleksandr Kurbatov: Yeah. We have already done a compiler so you can define the set of public keys, you can write the boolean policy and it will compile with the single public key. So that’s already done. That’s not a production-ready framework, so it’s not recommended to use it in your wallets or applications because it’s not audited, battle-tested, etc. But we’ve just shown that it’s possible, and we use it for benchmarking of different constructions. Recently, just yesterday, I came with the idea that this approach can be extended with DLC contracts. So, you can combine some, I don’t know, events from the real world with the policy defined before in BLISK and combine more interesting, I don’t know, cases, etc. So, probably we will research a bit in this direction. Yeah, finally, I have no clue how it will be used, but I see potential in this approach. Let’s see.

Mark Erhardt: Right. So, basically, you’re providing this new primitive, and now people tend to be pretty creative with this sort of stuff, and you’re just waiting to see what’s coming. Cool. Do you have a call to action, or are you asking for feedback, or what would you like to see as the next step?

Oleksandr Kurbatov: I don’t know. Everything is open source right now, so everybody can reuse that. It was just research we were interested in. So, yeah, the public could use it wisely.

Mark Erhardt: Oh, maybe one more question. So, one of the things that people have been doing is provide security proofs of this. Is there a security proof for this construction already?

Oleksandr Kurbatov: Yeah, in the paper. Yeah, one more interesting point, that we’ve just shown how you can combine MuSig2 and ECDH, but you are not limited only with those primitives. If you have, for example, a post-quantum multisignature scheme and post-quantum key encapsulation mechanism, you can do the same. So, you’re not limited only with elliptic curve points. If you have those primitives, that’s it. So, you can have a post-quantum BLISK, and it will work fine.

Mark Erhardt: All right. Well, that’s pretty cool research. Thank you for sharing. Gustavo, do you have anything else on this?

Gustavo Flores Echaiz: No, this is a very fascinating idea, so thank you for sharing that. Well, maybe my only question would be, do you see any limitations to this protocol that you invented? How far could someone take it?

Oleksandr Kurbatov: Yeah, probably the biggest limitation I see right now is it’s hard to support this technology, for example, by Hardware Security Modules (HSMs). Because if you’re operating with FROST signature or with MuSig2, each HSM can produce their own signature and coordinator will aggregate everything. But if you want to support other cryptographic constructions, like ECDH derivation, etc, plus some interactive rounds, at least set up, you need to use the software and hardware which is ready to support it. Right now, it’s not possible, it’s not feasible. So, it has some drawbacks comparing to existing multisignatures and threshold signatures, but yeah, for wallets, it doesn’t matter; I mean for mobile wallets, for software wallets. So, yeah.

Gustavo Flores Echaiz: Makes sense. Thank you so much.

Mark Erhardt: All right. Thank you for joining us and telling us about BLISK. We will be moving on to the Releases and release candidates section. You’re welcome to hang on, but if you have other things to do, we totally understand. Thank you for your time.

Oleksandr Kurbatov: Yeah, thanks for having me. Take care.

Mark Erhardt: All right. Gustavo, do you want to take it from here?

Bitcoin Core 29.3

Gustavo Flores Echaiz: Yes, I do. Thank you, Murch. So, this week we have four different releases, the first one being Bitcoin Core 29.3. So, this is a maintenance release of a previous major release series. And here, there’s multiple bug fixes that are included. The main ones are those that were related to the wallet migration bug that was discovered in v30 and v30.1. So, as much as some bugs only applied to 30 and 30.1, the fixes were backtracked to apply to 29.3 so that we could just adapt to the new mitigations that have been put in place for this bug. Also, you can check out the Newsletter #387 for more context on this issue. And also, specific on the News section, we covered that incident, but also we covered the PRs that were used to fix that bug.

Also, another important part of 29.3 are the per-input sighash mid-state cache that reduces the impact of quadratic sighashing in legacy scripts, and the removal of peer discouragement for consensus-invalid transactions. What does that mean? So, CVE-2025-46598 was disclosed late last year, where it was discovered that a CPU DoS (Denial of Service) attack from unconfirmed transaction processing was possible. It was judged low severity, but basically this maintenance release 29.3 also includes the fixes that came for that specific issue. So, you can check out the release for more details, but this is basically just a maintenance release that backtracks a few fixes on 29.

LDK 0.2.2

We move forward with LDK 0.2.2. Here, this is another main release that follows up two releases from last week’s newsletter related to LDK as well. Here, the main difference is the update of the feature flag for the splicing feature that has moved to the production feature bit. And we will cover this more in the Notable code and documentation changes, because this is a PR of this week. But there’s also other issues, such as when a restart happens, there could be an operation that is left hanging and the channel manager doesn’t receive the asynchronous confirmation that an operation was completed, followed usually through the follow-up of a block connection. And so, yeah, just a few fixes around a few synchronization events.

HWI 3.2.0

We follow up with Hardware Wallet Interface (HWI) 3.2.0. This is a release that includes support for new hardware wallets, such as Jade Plus, BitBox02 Nova. It also adds support for testnet4, native PSBT signing for the Blockstream Jade hardware wallet. And finally, MuSig2 PSBT fields are added. And there’s also a notable code change related to MuSig2 support in an HWI that we will cover more in detail in a little while. Yes, please, Murch?

Mark Erhardt: Maybe for context, the Bitcoin HWI is a package, a library that is shipped by Bitcoin Core contributors. And it’s, for example, used by Bitcoin Core to interface with a number of different hardware wallets. But I think it’s now also used by other software projects for their interfacing with hardware wallets. So, when hardware wallets get added here, that generally means that these hardware wallets can be used by a number of different software projects, software wallets now as signing devices.

Gustavo Flores Echaiz: That’s exactly right. Thank you, Murch. So, for example, Wasabi Wallet is an example of a wallet that will use HWI for integrating with different hardware wallets.

Bitcoin Inquisition 29.2

So, the final release is Bitcoin Inquisition 29.2, which is based on the second RC of 29.3 Bitcoin Core. The main difference with the previous version of Bitcoin Inquisition is that it implements the BIP54 proposal and disables testnet4. And also, this newsletter includes a notable change that covers the implementation of BIP54 in Bitcoin Inquisition 29.2. Yes, Murch?

Mark Erhardt: For context, Bitcoin Inquisition is meant as the tool for experimenting with proposed soft forks. So, it has a bunch of experimental soft fork support, and it runs on the signet, on the main signet that is run by some Bitcoin Core contributors. So, disabling testnet4 might sound scary for a moment until you think about Inquisition is only meant to run with signet. So, obviously testnet4 does not support these experimental soft forks and mainnet certainly doesn’t either. So, Inquisition is not supposed to work with testnet4. It was an oversight that it did, and it just basically will say, “No, this is signet software, don’t use me with testnet4”, is the background here.

Gustavo Flores Echaiz: Thank you, Murch. Yeah, so mainnet and testnet3 were already disabled, so this is just testnet4 being disabled in addition to other networks that were disabled that that are supposed to be disabled. And also, BIP54 is the new edition of this release, but Bitcoin Inquisition from previous releases includes proposals such as BIP118, ANYPREVOUT (APO), BIP119, CHECKTEMPLATEVERIFY (CTV), and other similar type of covenant or covenant-like proposals.

Bitcoin Core #32420

We move forward with the Notable code and documentation changes. This week we have about 12 different PRs to cover. The first one, Bitcoin Core #32420, updates the Mining IPC interface, which we have covered many times on the newsletter, that allows external Stratum v2 client software to connect to Bitcoin Core to interface with Bitcoin Core for external block template creation. So, here, what is done is that Bitcoin Core will stop including a dummy extraNonce in the coinbase scriptSig when interfacing with external Stratum v2 clients through the Mining IPC interface. So, a new option is added so that any RPC or interface in Bitcoin Core can choose to include this dummy extraNonce or not. And the IPC codepath obviously sets that as false to not include it.

So, basically, what does this all mean? The scriptSig of the coinbase, it has basically two rules related to it. It must be between 2 and 100 bytes. And since BIP34, it must also start with a push of the block height. The dummy extraNonce is included usually for internal usage, such as the internal miner unit tests, they will use that dummy extraNonce. But it was never shipped outside of Bitcoin Core. So, for example, when a real miner used getblocktemplate, getblocktemplate RPC would exclude the coinbase entirely because the miners would build their own coinbase. So, this was mostly an internal tooling for internal mining and related tests. So, when the Mining IPC interface was added and implemented, this was basically overlooked and the dummy extraNonce was shipped to external Stratum v2 clients, and they would then have to either strip it or simply ignore it.

So, this PR basically adapts to the new reality where there’s now a Mining IPC interface. So, it stops including a dummy extraNonce, which use case was pretty much only internal. And there’s also a security reason behind this change. It’s that if an external mining software would strip or ignore the scriptSig entirely or strip the dummy extraNonce from the scriptSig, if a future soft fork happened that required additional commitments in the scriptSig, well, the external mining software that was used to simply ignoring it could just accidentally break consensus, right? So, this is also the rationale behind this change. Any extra thoughts, Murch?

Mark Erhardt: Yeah, I wanted to talk a little bit about the scriptSig field of the coinbase. So, coinbase inputs are special in the sense that they do not commit to a specific UTXO that they’re spending. All inputs on Bitcoin transactions usually tell us what input they are referring to for the spend. But coinbase transactions obviously pay out the mining reward, so they do not spend a UTXO. They still have a previous, like, an outpoint that they commit to, but it’s a fixed value. So, they always fill out the previous txid and the output counter on that with specific values. And then, the field afterwards, which you call a scriptSig, which would be the input script for other inputs, is actually the coinbase field. And the coinbase field here is special because it has special requirements. As you said, it has to be between 2 and 100 bytes. It has to start since, was it BIP34, with the height? And, yeah, so the coinbase field is what would be the input script or scriptSig for other inputs. And, yeah, coinbase inputs are special. Coinbase transactions also can only have a single transaction input, which also is unusual.

Gustavo Flores Echaiz: Thank you, Murch. And just to add on top of that, well, the extraNonce is what allows a minor to add additional nonce values.

Mark Erhardt: Yeah, and to add to that, the extraNonce is not a special field. It’s basically just using the coinbase field after the height to put arbitrary other content. And by changing a single byte in the coinbase transaction, obviously you change the merkle root and by changing – wait a second. Yes, you change the merkle route. I was confused for a moment because the coinbase transaction is obviously ignored for the segwit commitment in the merkle tree for the segwit transactions. But in the regular merkle root, the coinbase contributes of course, so that changes the header of the block that you’re trying to create, and therefore gives you a new sequence of nonces that you can iterate over or time-roll on or version-roll on, or whatever you want to do. So, changing a single byte in the coinbase transaction gives you new block headers to work with and that’s why it’s used as an extraNonce. Once the nonces are exhausted, you can change the coinbase transaction to start over with the regular nonces.

Gustavo Flores Echaiz: Right, and just to bring back to the PR after that great explanation, it’s that this dummy extraNonce is mostly useful for internal mining or testing, because miners will simply create their own coinbase transaction with their desired extraNonce.

Core Lightning #8772

So, we move forward with Core Lightning #8772. This is a fairly simple one. Here, Core Lightning (CLN) removes full support for the legacy onion payment format, which had a fixed length. This was very early days in Lightning. It was completely removed from Bitcoin Core, from CLN and the BOLTs specification in 2022, but it was brought back to CLN in v24.05 after it had found that some older versions of LND were still producing these legacy onion payment formats. So, it added a sort of translation layer to translate the legacy format to the new variable length format. However, this is no longer the case since LND v18.3, so support is no longer needed. Yes, Murch?

Mark Erhardt: Just to clarify, you said it removes full support or do you mean it fully removes support? Like, it removes all support?

Gustavo Flores Echaiz: Yeah, it removes all support. Thank you for making me clarify that. Yes, so it basically removes this translation layer that it had added after. It’s no longer needed because LND new versions simply don’t produce it anymore.

LND #10507

So, this follows up with a PR on LND #10507. So, here, a new boolean field is added to the GetInfo RPC response. So, there was already another boolean field called synced_to_chain. So, what are the differences between these two boolean fields and what is the necessity of the new one? Basically, the new wallet_synced field will indicate whether a wallet has finished up catching on the current chain tip. So, if you simply want to know if your wallet has caught up to synchronizing to the blockchain, you can use that field to know just that precisely.

The other field, synced_to_chain, would consider this, but would only turn true if not only you had fully synced to the current chain tip, but your channel graph router, which validates channel announcements, had also completed its job, and another component called the blockbeat dispatcher, which is a subsystem that coordinates block-driven events internally with different internal parts of LND, that would also have to be completed or synced before returning true. So, this new field allows you to simply know your status with blockchain synchronization, and not worry about full synchronization or up-to-date work from other components.

Mark Erhardt: So, basically that would tell you when you’re up-to-date with your own channels and your onchain payments even before you are up-to-date with the channel graph.

Gustavo Flores Echaiz: Exactly.

Mark Erhardt: Cool. All right.

LDK #4387

Gustavo Flores Echaiz: We move forward. We now have four different LDK PRs to cover. So, the first one, LDK #4387. Here, like I was mentioning in the Release section, because this is part of the new LDK release, the splicing feature flag is changed from the provisional bit 155 to the production bit 63. So, why did LDK use bit 155? Because it saw that Eclair also uses it and it just went along with the same feature flag bit as Eclair to be fully compatible. However, later, the LDK team realized that Eclair uses a custom Phoenix-specific splicing implementation that predates the current splicing specification that is in draft status, right? So, the Eclair team is not going to update or hasn’t updated their splicing implementation until the splicing specification is merged and leaves draft status. Until then, they remain with their custom implementation. So, the LDK team didn’t know this and they had tried to be with the same feature flag bit as Eclair, but later realized that when trying to attempt a splice between LDK and Eclair, this would lead to, first of all, deserialization failures, and then reconnections that would never lead to a successful splice.

So, now the LDK team says, “We’re just going to point to the production bit, because we’re basically implementing the draft specification that will probably get merged over the next few weeks”. Yes, Murch?

Mark Erhardt: Do you know whether this was in the released version already of LDK, or is this on the development branch?

Gustavo Flores Echaiz: That’s a very good question. And, yes, this was in the released version.

Mark Erhardt: But just a bug fix, not just a fix to the development? Okay.

Gustavo Flores Echaiz: Exactly. Yes, so this is why the version with this fix is released, because it was already released.

LDK #4355

So, the next one is a new feature added on LDK #4355, which basically adds support for asynchronous signing of commitment signatures exchanged during either splicing or dual-funded channel negotiations. So, the way it works is that when using an asynchronous signer, when receiving a call to sign the commitment, it will immediately return; and later, the asynchronous signer will call back once its signature is ready. So, this is mostly ready for splicing. So, for example, HSMs could be now used for signing, splicing, commitment signatures in LDKs. For dual-funded channel negotiations, this is simply the foundation, but some more work is required for adding full support to asynchronous signers.

LDK #4354

The next one is a very simple one as well, LDK #4354. This one is something that was missed probably by the LDK team, or was long due. It’s making channels with anchor outputs the default in LDK. The way they do this is they’ve got to put the config option of negotiating channels by default, which means that automatic channel acceptance is removed, because all inbound channel requests before being accepted, the wallet has to ensure it has enough onchain funds to cover fees in the event of a foreclosure. So, this simple change on two config options was necessary to simply make channels with anchor outputs the default in LDK.

Mark Erhardt: So, the difference here is, of course, that with regular channels, the side that opened the channel is always on the hook for the fee for closing. And with anchor channels, the party that closes uses their anchor and brings the fees in the anchor output. So, it’s a CPFP construction, and that means you need to have additional funds available in order to be able to close the channel unilaterally.

LDK #4303

Gustavo Flores Echaiz: Thank you for that extra context, Murch. And the final one of the LDK ones, LDK #4303, this is not a released. So, this is a bug fix on a branch that was unreleased. So, here, two bugs were fixed where an HTLC (Hash Time Locked Contract) could be double-forwarded after your channel manager restarts or your LDK node restarts. So, basically, in one case, you had received an HTLC and you were going to forward it, but on your outbound channel, you were waiting for something to clear for that channel to be ready for you to forward the HTLC. But somehow, your channel manager or your LDK node restarted. So, on restart, LDK would miss that the HTLC was in the internal queue, and it would simply create another HTLC and dispatch both at the same time.

In the other scenario, the HTLC had already been forwarded, settled, and had been removed from, let’s say, the internal logging, but the inbound side still had a resolution for it. So, you would restart before it would fully resolve at that level. So, on restart, it would dispatch another HTLC. And this led to some potential loss of funds. However, this was never released, it never shipped. So, the bug fix came right on time.

Mark Erhardt: Yeah, the problem here would be, of course, if you create the same HTLC twice, you’re essentially paying the recipient twice for what they’re forwarding. So, they make one full HTLC more on the forward, and with the recreating an already settled output, the other side already has the secret, so they can simply take the output immediately. And neither of the two is intended.

HWI #784

Gustavo Flores Echaiz: Thank you for that extra explanation. The follow up is HWI #784. This is something we discussed briefly on the release notes. But basically, PSBT serialization and their serialization support is added for MuSig2 fields, including public keys, public nonces, partial signatures. So, basically, this is HWI getting prepared for implementing MuSig2 signing on hardware wallets. Basically, this is a PR from the HWI repo, #784, where serialization and deserialization of MuSig2 fields is added, PSBT support for that is added, which is basically a preparation for signing MuSig2 transactions by hardware wallets all specified in BIP327. So, probably a next version of HWI will move forward with full MuSig2 support.

Mark Erhardt: So, the problem here is, of course, when you’re creating a MuSig2, you need additional information in order to know how the signatures are being aggregated. And for this construction, you need more information then was included in the regular PSBT setup. So, this is basically a necessary step for hardware signers to be able to sign MuSig2 outputs.

Gustavo Flores Echaiz: Precisely. Give me just a second. Okay.

Mark Erhardt: I can do the BIPs if you want.

Gustavo Flores Echaiz: Yeah, definitely. I think it would be very valuable if you do the BIPs, please.

BIPs #2092

Mark Erhardt: All right. BIPs #2092 is an update to BIP434, which we just introduced recently, which is the feature message to negotiate between nodes what features you want to use and maybe what versions of those features you want to use. So, when we introduced BIP324, the P2P v2 encrypted P2P messages, there is a message ID system there. There’s long and short messages, and this just adds the message ID for the BIP434 feature message. It also introduces, in BIP324, an auxiliary file where these message IDs are stored, because it’s not really part of BIP324, so we decided not to put it in there. But it’s something that other BIPs might want to add to when they designate certain message IDs. So, it’s a separate file in BIP324’s auxiliary files. If you’re looking to reserve any message IDs, check there that you’re not double-booking anything. Did I miss anything?

Gustavo Flores Echaiz: No, that’s perfect.

BIPs #2004

Mark Erhardt: Okay. The BIPs PR #2004 adds Chain Code Delegation as BIP89. BIP89 is a newly-published BIP that it’s basically a way of keeping your transactions more private from a collaborative custody provider. So, when you usually have collaborative custody, where your provider has some of the keys and you have some of the keys, and they co-sign every transaction for you, they would know about all of your wallet activity because you share your output scripts with them, and they can see when you get paid and when you pay, even if you construct the transaction completely on your end with your set of keys. With the Chain Code Delegation BIP, the authors, Jurvis and Jesse, introduce a method where you take all of the responsibility of tracking the funds, and you can get the co-signing of the custodian only when you want it, and you only reveal the transactions where they co-sign, and they only learn about the transactions they participate in. And they do this by not knowing the chain code, which is how you derive from the main secret all of the other keys in the extended public key chain.

So, you, as the customer of the custody service, know the derivation path, and you basically just tell the custodian, “Here, I want to make this transaction. Here’s my proof that it’s me and that it fits the policy per which I’m allowed to spend this amount”, or whatever. And then, the custodian gets the derivation path from me to sign.

Gustavo Flores Echaiz: Yeah, I just want to add, well, first of all, this is a fascinating topic, in my opinion, and a great proposal. But you can check out Newsletter #364 and listen to the related podcast that came with it for extra context. This was heavily discussed there. But also, there’s a blind mode for that. I don’t know how secure it is. I think it’s not as secure as the non-blinded signing mode. But in the blinded signing mode, the delegator or the signer learns nothing, neither the message, neither the public key. It’s only provided a blinded challenge and it signs it and that’s it.

Mark Erhardt: I think that one is more just future work. So, the actual proposal does not fully specify the blinded mode, but I think Jesse basically outlines how it could be implemented if people wanted to work on it. But people should correct me underneath this tweet if I’m wrong about that one.

BIPs #2017

All right. Third PR to the BIPs repository. This is PR #2017 to the BIPs repository, and this publishes BIP110. If you’ve been on Twitter in the last three months, I think you’ve seen mention of BIP110. This is also known as Reduced Data Temporary Softfork (RDTS), a proposal to introduce seven new consensus rules to forbid some types of transactions that some people think shouldn’t be happening. BIP is written up complete enough to be published, and, yeah, it was published now. I should say, it is somewhat controversial, because introducing seven new consensus rules that, for example, forbid the use of OP_IF and IP_NOTIF in tapscript, limiting the height of tapscript trees, and also limiting all push opcodes to only 256 bytes may cause people to have their funds frozen. The authors of the BIP have addressed that to some degree. They do not apply these rules for any UTXOs that exist before activation, but only on new UTXOs that are created after activation of this PR.

So, the soft fork is supposed to be active for one year once it activates. It is also a little controversial per its activation method. It reduced the signaling threshold to 55%, and it has mandatory activation in September after mandatory signaling in August. So, any nodes that have upgraded to RDTS, to the activation client for BIP110, will start forcing every block to signal for activation on this proposal in August. So, if this is not followed or supported by a majority of the hashrate at this point, they will fork themselves off and be on a stale chain tip or slower-moving chain tip that does not follow the rest of the network for not signaling readiness. For more on this, just look at Twitter for three minutes. There’s everybody bashing in each other’s head on it for the past few weeks. Just to be clear, I did review this, I did publish this, I still think it’s a terrible idea, and I don’t think it’s a problem for me saying so.

Gustavo Flores Echaiz: No, absolutely not. I think it’s very, very just rational to say that. Do you know if this has replay protection? Let’s say in the case of a fork, do you know how protected a user would be from double-spending or issues like that?

Mark Erhardt: It does not have replay protection. So, all the transactions that are accepted by BIP110 will be valid on either chain tip. And if you spend a regular transaction, it would flow on both of these. So, with previous soft forks, this was a big concern before Bcash split off. The Bcash developers finally, in the last hours, literally I think in the last two days or so before the proposal, finally changed the transaction format to introduce replay protection when they realized that they didn’t have majority support. And in this case, so some of the concerns are around reorgs that if this proposal had any a reasonable amount of support, there probably would be at least a few reorg blocks. But then also, if the heights diverge drastically, it might be possible for Lightning channels to be resolved differently on the two chain tips, especially if you’re running a Lightning node and using a BIP110 node as the source of truth on this. This may open you up to some loss-of-funds situations. And, yeah, so no replay protection.

If you do want to spend your funds separately on these two chains, you can wait until there’s some block rewards that have been distributed in the network. Any funds spent from a block that can only exist in one of the two chains will spawn, like if it’s spent, all of the outputs on that transaction can also only exist on that chain. And that sort of can infect the whole network. So, if there’s any outputs that only exist on that chain, anything that is spent in transactions with those, or spent from outputs that were created from those, will also only be able to exist on that chain. And that way, funds can be split eventually. The alternative is sending funds to yourself on both chains until you manage to send them to two different addresses. So, if you, for example, have very different feerates on the two networks, you could send it first on the network with the low feerate. Then, once it’s flowed, you can send another transaction on the other chain tip with a higher feerate, sending it to a different address. And then, you’ve also split your funds successfully.

Obviously, if a reorg happened on one of those two chains, this could be resolved in the other direction. So, you have to be careful that this gets a few confirmations. But once you’ve split your funds, you can use that UTXO that only exists on one chain to create transactions that are only valid on one chain. And that way, you can split all of your funds and then you can dump whatever side you want, for example, or create Lightning channels that only exist on one of the two sides. There’s a lot of misinformation around this being inevitable to succeed just because it is a soft fork. And I want to be very clear that soft forks are not inevitable. A soft fork that is enforced by a small minority of the network, especially a small minority of the hashrate and a small number of nodes, and especially a small part of the economic activity of the network, cannot enforce a soft fork. It will stall on a shorter chain that has less PoW. The rest of the network will simply continue to follow the most worked chain and pull away. So, don’t believe everything you read on the internet.

Bitcoin Inquisition #99

Gustavo Flores Echaiz: Thank you, Murch. That was very well needed, I believe. So, now we just have a final PR to cover on the newsletter. This is the Bitcoin Inquisition PR #99. The implementation of the BIP54 consensus cleanup soft fork is added on Bitcoin Inquisition and on signet. So, we discussed many times this proposal. It was merged, I believe, only a few weeks ago, like last month, and also we had the BIP author, Antoine Poinsot, on this show on the last episode, #391, because he basically talked about addressing remaining points on BIP54. So, I don’t believe those points have already been addressed. I believe this Bitcoin Inquisition merges the BIP as is, but there could still be some changes to the BIP proposal. Is that accurate?

Mark Erhardt: No, I think the addressing outstanding points was mostly discussing the concerns that were brought up, and I think neither of the two has actually changed the proposal. So, the two points were specifically whether or not the nLockTime field on coinbase transactions has been described as a valuable extra nonce space for miners. And we discussed the validity or the saliency of that claim and rejected it basically on noticing that it saves you, like, a couple of hashes on the coinbase itself. But there is a number of different things that you can do on the block header itself. Or, if you’re updating the extra nonce or any other field on the coinbase, it’s like 1 more, 2 more hashes on the coinbase transaction to get to this point. It’s probably not something that people would be getting super-excited about. It’s not used right now. And forbidding it is a level playing field. Right now, it’s not being used. If we forbid it from being used in the future, it doesn’t hurt anyone specifically.

The other one was whether or not only forbidding 64-byte transactions creates a consensus scene, where it’s weird that 63-byte transactions are allowed and 65-byte transactions are allowed, but 64-byte transactions are not allowed. This is specifically in reference of the stripped size of transactions, so transactions without witness data, but I really don’t see it being a bigger concern that smaller transactions might be allowed and only one specific size not being allowed. And even so, if we did want to also forbid 63-byte transactions, and I think the smallest possible thing is 62-byte transactions. Yeah, 41 bytes for the input, 10 bytes for the header, 1 byte – sorry, 60 bytes might be possible, but whatever. So, I don’t share that concern. And Antoine looked into these and rejected these, so I don’t think the BIP actually changed.

BIP54, the consensus cleanup as is, is now on signet and I’m looking forward to seeing the PR to Bitcoin Core soon. I think that’ll get a little more review and hopefully move the proposal forward. I think in light of other soft forks currently being proposed, BIP54 uses a very deliberate and different approach. This has been two years of research. These are rules that are engineered to have minimal impact on any users, other than sweeping changes that definitely will disenfranchise established protocols and wallet constructions. So, yeah, my money is on BIP54 activating earlier.

Gustavo Flores Echaiz: Makes sense. Thank you so much, Murch. Well, that completes the PR section and the newsletter. Yes, Murch?

Mark Erhardt: For ‘activating’ meaning adopted by the whole network, not just being enforced by a handful of nodes on the network. Yes, this is the PR section. Thank you, Gustavo, for preparing that and joining me on this Optech Newsletter. Thank you to our guests, Oleksandr and Sebastian, for talking us through the concern around paying silent payments recipients too often, and BLISK, the boolean circuit logic integrated into the single key, which seems to allow some very interesting constructions that also look like a single-sig P2TR output. Unfortunately, who knows how long we can use them with quantum coming any century now. So, yeah. Hear you next week, Gustavo?

Gustavo Flores Echaiz: Yes, thank you much.

Mark Erhardt: All right, that’s it.

Bitcoin Optech Newsletter #392

2026-02-13T00:00:00+00:00

This week’s newsletter summarizes discussion of improving worst-case silent payment scanning performance and describes an idea for enabling many spending conditions in a single key. Also included are our regular sections announcements of new releases and release candidates and descriptions of notable changes to popular Bitcoin infrastructure software.

News

● Proposal to limit the number of per-group silent payment recipients: Sebastian Falbesoner posted to the Bitcoin-Dev mailing list the discovery and mitigation of a theoretical attack on silent payment recipients. The attack occurs when an adversary constructs a transaction with a large number of taproot outputs (23255 max outputs per block according to current consensus rules) that all target the same entity. If there were no limit on group size, it would take several minutes to process, rather than tens of seconds.

This motivated a mitigation to add a new parameter, K_max, that limits the number of per-group recipients within a single transaction. In theory, this change would not be backward-compatible, but in practice, none of the existing silent payment wallets should be affected for a sufficiently high K_max. Falbesoner is proposing K_max=1000.

Falbesoner is seeking feedback or concerns about the proposed restriction. He also notes that most silent payment wallet developers have been notified and are aware of the issue.
● BLISK, Boolean circuit Logic Integrated into the Single Key: Oleksandr Kurbatov posted to Delving Bitcoin about BLISK, a protocol designed to express complex authorization policies using boolean logic. BLISK tries to address the limitations of current spending policies. For example, protocols like MuSig2, though efficient and privacy-preserving, can only express cardinality (k-of-n) but cannot identify “who” can spend.

BLISK creates a simple AND/OR boolean circuit, mapping logical gates to well-known cryptographic techniques. In particular, AND gates are obtained by applying an n-of-n multisignature setup, in which each participant must contribute a valid signature. On the other end, OR gates are obtained by leveraging key agreement protocols, such as ECDH, in which any participant can derive a shared secret using their private key and the other participant’s public key. It also applies a Non-interactive Zero Knowledge proof to make circuit resolution verifiable and to prevent cheating. BLISK resolves the circuit to a single signature verification key. This means that only a single Schnorr signature must be verified against one public key.

Another important advantage of BLISK with respect to other approaches is eliminating the need to generate a fresh key pair. In fact, it allows connecting an existing key to the specific signature instance.

Kurbatov provided a proof-of-concept for the protocol, although he stated that the framework has not reached production maturity yet.

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 29.3 is a maintenance release for the previous major release series that includes several wallet migration fixes (see Newsletter #387), a per-input sighash midstate cache that reduces the impact of quadratic sighashing in legacy scripts (see Newsletter #367), and removal of peer discouragement for consensus-invalid transactions (see Newsletter #367). See the release notes for all details.
● LDK 0.2.2 is a maintenance release of this library for building LN-enabled applications. It updates the SplicePrototype feature flag to the production feature bit (63), fixes an issue where async ChannelMonitorUpdate persistence operations could hang after restarts and lead to force-closures, and fixes a debug assertion failure that occurred when receiving invalid splicing messages from a peer.
● HWI 3.2.0 is a release of this package providing a common interface to multiple hardware signing devices. The new release adds support for the Jade Plus and BitBox02 Nova devices, testnet4, native PSBT signing for Jade, and MuSig2 PSBT fields as specified in BIP373.
● Bitcoin Inquisition 29.2 is a release of this signet full node designed for experimenting with proposed soft forks and other major protocol changes. Based on Bitcoin Core 29.3r2, this release implements the BIP54 (consensus cleanup) proposal and disables testnet4.

Notable code and documentation changes

● Bitcoin Core #32420 updates the Mining IPC interface (see Newsletter #310) to stop including a dummy extraNonce in the coinbase scriptSig. A new include_dummy_extranonce option is added to CreateNewBlock(), and the IPC codepath sets it to false. Stratum v2 clients receive only the consensus-required BIP34 height in the scriptSig and no longer need to strip or ignore the extra data.
● Core Lightning #8772 removes support for the legacy onion payment format. While CLN had stopped creating legacy onions in 2022 (see Newsletter #193), it added a translation layer in v24.05 to handle the few remaining legacy onions produced by older LND versions. These have not been created since LND v0.18.3, so support is no longer needed. The legacy format was removed from the BOLTs specification in 2022 (see Newsletter #220).
● LND #10507 adds a new wallet_synced boolean field to the GetInfo RPC response, which indicates whether the wallet has finished catching up to the current chain tip. Unlike the existing synced_to_chain boolean field, this new field does not require the channel graph router (which validates channel announcements) or the blockbeat dispatcher (a subsystem that coordinates block-driven events) to be synced before returning true.
● LDK #4387 switches the splicing feature flag from the provisional bit 155 to the production bit 63. LDK v0.2 used bit 155, which Eclair also uses for a custom, Phoenix-specific splice implementation that predates and is incompatible with the current draft specification. This caused Eclair nodes to attempt splices using their protocol when connecting to LDK nodes, resulting in deserialization failures and reconnections.
● LDK #4355 adds support for async signing of commitment signatures exchanged during splicing and dual-funded channel negotiations. When receiving EcdsaChannelSigner::sign_counterparty_commitment, the async signer immediately returns and calls back via ChannelManager::signer_unblocked once the signature is ready. Dual-funded channels still require additional work to fully support async signing.
● LDK #4354 makes channels with anchor outputs the default by setting the config option of negotiate_anchors_zero_fee_htlc_tx to true by default. Automatic channel acceptance has been removed, so all inbound channel requests must be manually accepted. This ensures that the wallet has enough on-chain funds to cover fees in the event of a force close.
● LDK #4303 fixes two bugs where HTLCs could be double-forwarded after a ChannelManager restart: one where the outbound HTLC was still in a holding cell (internal queue) but it was missed, and another where it had already been forwarded, settled, and removed from the outbound channel, but the inbound side’s holding cell still had a resolution for it. This PR also prunes inbound HTLC onions once they are irrevocably forwarded.
● HWI #784 adds PSBT serialization and deserialization support for MuSig2 fields, including participant public keys, public nonces, and partial signatures for both inputs and outputs, as specified in BIP327.
● BIPs #2092 assigns a one-byte v2 P2P transport message type ID to the feature message from BIP434, and adds an auxiliary file to BIP324 tracking one-byte ID assignments across BIPs to help developers avoid conflicts. The file also records Utreexo’s proposed assignments from BIP183.
● BIPs #2004 adds BIP89 for Chain Code Delegation (see Newsletter #364), a collaborative custody technique where a delegatee withholds BIP32 chain codes from a delegator, sharing only enough information with the delegator to produce signatures without learning which addresses received funds.
● BIPs #2017 adds BIP110, which specifies the Reduced Data Temporary Softfork (RDTS), a proposal to temporarily restrict data-carrying transaction fields at the consensus level for approximately one year. The rules would invalidate scriptPubKeys exceeding 34 bytes (except OP_RETURN up to 83 bytes), pushdata and witness stack elements exceeding 256 bytes, spending of undefined witness versions, taproot annexes, control blocks exceeding 257 bytes, OP_SUCCESS opcodes, and OP_IF/OP_NOTIF in tapscripts. Inputs spending UTXOs created before activation are exempt. Activation uses a modified BIP9 deployment with a reduced 55% miner signaling threshold and mandatory lock-in by approximately September 2026. See Newsletter #379 for earlier coverage of this proposal.
● Bitcoin Inquisition #99 adds an implementation of the BIP54 consensus cleanup soft fork rules on signet. The four implemented mitigations are: limits on the number of potentially executed legacy sigops per transaction, prevention of timewarp attacks with a two-hour grace period (plus prevention of negative difficulty adjustment intervals), mandatory timelocking of coinbase transactions to the block height, and invalidation of 64-byte transactions.

Bitcoin Optech Newsletter #391 Recap Podcast

2026-02-10T00:00:00+00:00

Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Toby Sharp, Chris Hyunhum Cho, Jonas Nick, and Antoine Poinsot to discuss Newsletter #391.

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

Download audio

News

● A constant-time parallelized UTXO database (25:40)
● Bithoven: A formally verified, imperative language for Bitcoin Script (44:48)
● Discussion of dust attack mitigations (1:43:33)

Changing consensus

● SHRINCS: 324-byte stateful post-quantum signatures with static backups (1:30)
● Addressing remaining points on BIP54 (1:10:08)
● Falcon post-quantum signature scheme proposal (20:05)
● SLH-DSA verification can compete with ECC (23:28)

Releases and release candidates

● LDK 0.1.9 (1:50:27)

Notable code and documentation changes

● Bitcoin Core #33604 (1:53:10)
● Bitcoin Core #34358 (1:54:58)
● Core Lightning #8824 (1:56:20)
● Eclair #3244 (1:58:17)
● LDK #4263 (2:00:07)
● LDK #4300 (2:01:54)
● LND #10473 (2:03:57)
● Rust Bitcoin #5493 (2:07:36)

Transcription

Mike Schmidt: Welcome everyone this is Bitcoin Optech Newsletter #391 Recap. Today, we’re going to talk about a constant-time parallelized UTXO database and workaround there; we have a higher-level language for writing Bitcoin Script that we’re going to get into; there’s an idea to mitigate dust attacks on the network; and then we have our monthly Changing consensus segment, which this month includes BIP54 changing consensus, it also has a few different post-quantum signature discussions around SHRINCS, Falcon, and SLH-DSA verification performance. In order to help us through some of these items, we have a handful of guests. Murch, Gustavo and I are joined by Toby. Toby, you want to introduce yourself real quick?

Toby Sharp: Hi, I’m Toby and I’m a software developer.

Mike Schmidt: Chris has joined us as well.

Chris Hyunhum Cho: Hi, I’m Chris, I’m PhD student at Korea University.

Mike Schmidt: Jonas?

Jonas Nick: Hello everyone, I’m doing cryptographic research at Blockstream.

Mike Schmidt: Awesome. And we will have one more guest later in the program. And if you’re following along in the newsletter, we’re going to go a bit out of order. We have some scheduling constraints and we have our guests here. So, apologies for that.

SHRINCS: 324-byte stateful post-quantum signatures with static backups

But we’re going to jump down actually to the Changing consensus segment, and we’re going to talk about SHRINCS, which is a 324-byte stateful post quantum signature scheme with static backups. Jonas, we covered and we had on Mike to discuss your and his hash-based signature schemes for Bitcoin. That was in Newsletter and Podcast #386. And now, we have you on this month to talk about SHRINCS. Maybe quickly summarize the previous discussion for context, and then how does SHRINCS fit into that broader discussion?

Jonas Nick: Yes, all right. So, I guess last time, Mike talked about these various approaches to post-quantum signatures. One of those approaches is based on assumptions around hashes. Those signatures are not known to be very compact and there are also several degrees of freedom on how to design them. For example, there are two different categories. There are stateful schemes and stateless schemes. Stateful schemes require some sort of state, usually an index, for example, that is going to be incremented every time you make a signature. That is different to the state that we, for example, know from protocols like MuSig or FROST, where you only have state for a single signing session. Here, you have state for the entire lifetime of your public-private key pair. Now, the problem is also that if you were to not properly manage that state, for example, by not incrementing the index, forgetting what the index is, or resetting it to some other number, an older number let’s say, then you reduce your security tremendously; or more directly, it would allow actual forgeries of signatures and therefore people stealing your coins.

Mark Erhardt: I thought it more or less directly leaks the private key. So, does it allow signature forgeries or does it leak the key, or does the distinction even matter?

Jonas Nick: The distinction here does not really matter, no. Maybe let’s say it like this. What you’re revealing when you produce two different signatures with the same state, you reveal part of the secret key and with that part, you can forge alternative messages. So, you cannot produce a signature for any message, but rather for some subset. So, depending on how these two signatures for the same state look like and what message they sign, you might be able to forge a signature for any message or just for a small subset where only one bit is different. But we generally consider it broken, so let’s not reuse state at all.

Mike Schmidt: Right, so is a stateful scheme bad then? Why do we want a stateful scheme?

Jonas Nick: The reason why we want a stateful scheme is that we can create very, very compact post-quantum signatures that way, more compact than, let’s say, lattice-based signatures and more compact than stateless signatures, for some specific applications, such as Bitcoin wallets I should say. And the reason is that in Bitcoin, we usually do very few signatures for a single public key, at least on layer 1, because we try to avoid address reuse. So usually, we receive some coins on a fresh address, and then we create a transaction, sign and send it somewhere else, and then we should typically never reuse the public key unless something goes wrong, we need to bump a fee, etc, then maybe we do two signatures or three or something like that.

So, to understand why these signatures can be very compact, I would need to introduce this concept of one-time signature. So, one-time signature scheme is a signature scheme where you can only sign once per public key. So, only one single message per public key pair. Don’t sign twice, because that would allow forgeries. How do you produce a many-time signature scheme from that? Well, you take a single public key from the one-time signature scheme and you put it in the merkle tree. Or you take many one-time signature schemes’ public key, put it in the merkle tree, and then you have this large tree. You start on the leftmost leaf, first signature you do with that public key. You store the state, you remember, “I’ve already signed with this one”, so for the next signature, you go to the next one, and so on. So, part of your signature is the signature for the one-time signature scheme plus the merkle proof that proves that this public key is actually contained in your overall many-time public key. I should probably say this. So, the public key for this many-time scheme would be just the root of this large merkle tree of one-time signature scheme public keys.

So far, that doesn’t give us any benefits. What gives us benefits is that we don’t have to use a balanced tree. We can use an extremely unbalanced tree, which essentially it looks like just a diagonal. So, the first one-time public key is on layer 1, and the second one on layer 2 of the tree, third one on layer 3, etc. So, that means for the first signature. your signature only consists of the one-time signature and the sibling in the merkle tree, in order to produce the merkle proof. So, the signature for this one-time signature scheme is very small, I think it’s 256 bytes, and then 32- or 16-byte sibling, so you arrive at this very short signature. This is short, this is stateful, but one of the big problems is that this statefulness means that every time, that you cannot really have static backups, which is something that we’re used to in Bitcoin, right? In Bitcoin we have a single seed phrase, or whatever, backed up, and from that we can restore our wallet. And it doesn’t really work with stateful signatures anymore, because every time we make a signature, we have to remember, “Okay, we’ve made a signature with that public key”, so we would have to update our backup such that when we restore our backup on a new device, we know which public keys we’ve already used for signing.

Mark Erhardt: To chime in briefly, one advantage at least of this would be that address reuse finally gets very, very expensive.

Jonas Nick: Yes, that is true. But sometimes, we want to sign multiple times with a single public key, for example to increase the fee or things like that. So, we can’t have static backups. And SHRINCS is a solution to that, because essentially it combines the stateful idea, that produces very compact signatures, with a stateless scheme. So, essentially your public key is a hash of a stateful signature scheme public key and a stateless signature public key. So, we’ve talked about the merkle tree of one-time signatures for the stateful scheme. So, we take that public key and we just add another sibling to that public key, which is a public key for the stateless signature scheme, and that gives us a new merkle root for the entire scheme, where the two children of the merkle root are one public key for the stateful scheme, one for the stateless scheme.

So, what does that mean? It means that, so the example that is probably the best application for this is when you have some sort of dedicated signing device that is able to keep state securely, which in my mind is something different than a Bitcoin Core desktop wallet, where users have access to the wallet.dat so they could back it up, restore it. And that’s bad, because it will lead to state reuse, etc, signature forgery. So, we have a dedicated signing device, you generate the key on the device, this device is able to keep state securely, so you can use this very efficient stateful scheme to produce signatures. But you also have a static backup. A static backup is your whatever secret key. What is important is anytime you import this backup on a new device, the new device will recognize, “Okay, this has been an imported seed, so now I have to use the stateless path because now I don’t know the state anymore”. Or if the signing device would, for whatever reason, lose the state, it becomes corrupted, something like that, then it would just choose to sign with the stateless path. Stateless path, much less compact, so we want to avoid that. It’s like between 3 kB and 8 kB for hash-based signatures depending on which exact parameters you choose.

So, on the device where you initialized your wallet on that, created the seed, signatures will be very compact. If you have to restore your seed on a different device, you probably want to use the stateless path to sweep to a new wallet that uses this, that is able to re-initialize, create new states, and then use another stateful path for this new public key for this new wallet that you created.

Mark Erhardt: Right, so this sounds like something that could be used in enterprise HSMs or with a new generation of hardware wallets, hardware signers. But otherwise, the trade-offs seem very dangerous. It seems fairly easy to accidentally leak your private key under misuse. And it’s still, well, at least it’s only about five times more expensive than current schnorr signatures.

Jonas Nick: Right. I mean, that is one of the open questions how to deal with the state. And I’d like to hear some feedback from wallet developers, especially if they build their own devices. As I said, on a desktop wallet, I’m not so sure in the thread on Delving Bitcoin, I tried to experiment a little bit with using the trusted platform module to store some data that cannot be easily backed up. In principle, it doesn’t even need to do that. It could be a server, but then you trust the server to not replace state. And if they do, they can create a forgery, so that sounds terrible. And I suppose the same is potentially true for mobile wallets, because mobile wallets you now need to make sure that they don’t back up the wallet in the cloud. Maybe they can use the secure element to store state there securely, but that is an open question.

Mike Schmidt: Jonas, what is the maturity of these different pieces, you said these two pieces you sort of put together; what is the maturity of each and then how do you think about the novelty of combining them together?

Jonas Nick: I think that this idea is relatively straightforward. So, really, the one-time signatures that you build from hash-based signatures is relatively easy to do. Building this merkle tree for the stateful path is pretty easy to do. The stateless side, again, there are some degrees of freedom in the design space, where we could go for full SPHINCS+, which would be 8 kB, or use some variant where you would only be allowed to produce 2²⁰ signatures, say, then it would result in 3-kB signatures. So, there’s some design space. If we would just use SPHINCS+, we could essentially do that very quickly because the specification exists. Right now, at Blockstream, we’re experimenting with variants of this and trying to write specifications for various variants and see, learn something about the implementation as well, and play around with these parameters.

Mark Erhardt: Does anyone else want to chime in, maybe Toby or Chris?

Toby Sharp: Sure. About these states that you have to track for these new types of wallet, would that be something that can be reconstituted from the history of the blockchain, or do you have to store it independently and it can’t be known outside of that?

Jonas Nick: Yes, so that is a good question. Let’s say, no, the problem essentially is that the signing device, desktop or whatever, does not know whether their signature makes it to the chain or not, right? So, let’s say every signature makes it to the chain, because the reason why you produce multiple signatures is simply address reuse, for one reason or another, right? As a receiver, you cannot really prevent address reuse. You give out an address, maybe a sender sends multiple times to it, and then you need to produce multiple signatures with the same public key in order to spend all those coins. Okay, so you do that, and as long as you don’t produce any more signatures than that, then yes, you could try to recover your state from looking at the blockchain. You need to somehow ensure that you have the latest blockchain, because otherwise you don’t see your latest state, and that also seems to be rather dangerous. It at least would be a new security model.

But potentially, the bigger problem here is that you don’t know whether every signature you made makes it to the chain. And in the particular case of trying to bump the fee, it is unlikely that your first signature makes it to the chain.

Toby Sharp: So, another thought that I had is rather than just sort of incrementing your state, if you used a large random number as that local state instead, would that enable you to achieve a similar thing, in terms of hashing it into a new form?

Jonas Nick: This is basically the idea behind stateless signature schemes, where you use a really large tree and then you just select a one-time signature scheme at one of those leaves at random, and then the probability that you select the same one twice or multiple times is low enough that we can call it negligible and ignore it. But that requires a large merkle tree. And for the stateful scheme, our advantage that we have by using that is being able to use a relatively small tree and optimize where the first one is really the first leaf at layer 1, second one is at layer 2, etc, such that the merkle trees are really small.

Toby Sharp: Okay, got it. Thanks.

Mike Schmidt: Jonas, I think we have a call to action already that you threw out, for wallet developers or hardware signing device devs to take a look at this and provide their feedback to you. Obviously, there’s the discussion also on Delving that people can chime in on if they want to take a look, regardless of their position in the industry. Anything else before we wrap up that item?

Jonas Nick: No, I think the discussion was about a little bit around how to actually do that in Bitcoin. Would we want to have one opcode for the stateless path and one opcode for the stateful path, and then just use taproot to combine them? You would also be able to do that. That would maybe be more modular. Or would we just have one single opcode that just does SHRINCSVERIFY and does everything under the hood? And they both have their pros and cons. Probably right now, not the best time to decide on this yet.

Falcon post-quantum signature scheme proposal

Mike Schmidt: We have a couple more quantum-related things, Jonas. I know you need to drop, but we’ll jump into them. And as long as we can pick your brain, we will before you have to head out. The second one from Changing consensus was titled, “Falcon post-quantum signature scheme proposal”. And this was based on a post by Giulio Golinelli, who posted to the mailing list talking about enabling Falcon signature verification in Bitcoin. If you reference back to that podcast we had with Mike, we talked about lattice-based versus hash-based. Falcon is a lattice-base proposal, and I believe it’s pursuing standardization under FIPS, which is the Federal Information Processing Standards standardization. Jonas, how do you think about lattice-based schemes, and are you familiar with Falcon? Do you have two cents to add on it?

Jonas Nick: I mean, lattice-based signature schemes are certainly a viable approach that we should explore, because they allow for more of the fancy cryptography that we can’t do with hash-based signatures, such as compact multisignatures, threshold signatures, aggregate signatures, potentially taproot, silent payments, etc. So, I think that’s why they are attractive. And Falcon in particular is interesting because it’s very small, much smaller than the already standardized lattice-based signature scheme. Someone told me it’s 666 bytes per signature. I think that’s actually incorrect, but it’s at least easy to remember. Though much smaller than other lattice-based signatures, it’s kind of famous for being hard to implement, because it uses some floating point operations and that is especially hard to do in constant time. But I haven’t looked very deeply into this. But it’s certainly a fine approach to look into Falcon as well for lattice-based signatures. And there are other lattice-based signatures as well.

Mark Erhardt: So, I think I briefly looked at this Delving post earlier and I saw that the signature is, I think, 900 bytes and the pubkey is 600 bytes, or whatever. So, together, it’s somewhere around 1500 bytes, according to the numbers provided there, which of course would be bigger than your stateful scheme. And my understanding is that the implementation of lattice-based signatures is way more complex, and it’s based on additional cryptographic assumptions that we currently don’t use in Bitcoin. But they’re super-fast to verify.

Jonas Nick: Yeah, exactly. So, that is also something that makes them attractive. And you’re right to point out, of course, public key size is just as important as signature size.

Mike Schmidt: And Conduition did reply in this thread saying something similar to what you both have mentioned, which is the difficulty around implementing in the signing process anyways in constant time.

SLH-DSA verification can compete with ECC

Mark Erhardt: You also have the SLH-DSA thing on your radar, right? That sounds like a Jonas topic.

Mike Schmidt: Yeah, hopefully. Yeah, “SLH-DSA verification can compete with ECC”. This is also from Conduition. He has one of his blogposts, which I think are excellent. I didn’t get a chance to look at this one, but I saw the discussion of the post on the mailing list. He was benchmarking his post-quantum SLH-DSA verification against secp, showing that verification can compete with schnorr verification in common cases. Did you get a chance to look at that one, Jonas?

Jonas Nick: Much less than I should have looked at it because this is really interesting research. Because hash-based signatures, they have a reputation of being rather slow to verify, not super-slow. So, per byte of signature, it’s about the same verification time as schnorr signatures. But since the signatures are much larger, the overall time to verify is usually considered slower. So, Conduition uses this Vulkan-based implementation that makes use of a lot of parallelism, and therefore gets the verification speed to be as fast as verifying a single schnorr signature using libsecp in a single thread. As far as I understand, multi-threaded libsecp verification is still quite a bit faster, I suppose, depending on how many cores you have. But I think this is already showing that SLH-DSA, if implemented correctly, can verify signatures very, very quickly.

Mike Schmidt: Anything else to add from our other guests? No? Doesn’t look like it. All right, Jonas, I think we made it in time for you. We appreciate you joining us and walking us through some of this quantum stuff that you’re much closer to than we are. So, thank you for your time.

Jonas Nick: Perfect. Thank you very much. Bye.

Mark Erhardt: Cheers.

A constant-time parallelized UTXO database

Mike Schmidt: For those following along, we’re jumping back up to the News section, and we’re going to jump into the, “Constant time parallelized UTXO database”. Toby, you posted to Delving Bitcoin about Hornet UTXO(1), a custom, highly-parallelized UTXO database. You’re touting in the post the work you’ve done with constant-time queries. And I also want to understand, and maybe you can lead in with this, what is Hornet Node? How does this Hornet UTXO(1) fit into Hornet Node? What’s some of the work you’ve been doing on specification of the Bitcoin protocol? Maybe give us the way that you’re thinking about these different components, even if we’re just going to zoom in on one today.

Toby Sharp: Sure. And thanks for the invite, Mike, I appreciate it. So, Hornet Node is a completely new alternative Bitcoin client that’s built from scratch, and it’s built around a pure formal specification of the consensus rules. And Hornet UTXO(1), as I call it, is the UTXO database that’s the latest component of Hornet Node that’s required for doing validation. So, maybe I can talk a little bit about that database work, and then we can zoom out back to the bigger picture if you like.

Mike Schmidt: Sounds good.

Toby Sharp: So, the headline in this in the newsletter I guess is that I was able to validate the whole of mainnet in 15 minutes on a high-performance machine, not including signatures, and compared to 2 hours, 47 minutes with Bitcoin Core v30, like for like. And that was enabled by this new low-level, high-performance database that I’ve written specifically designed for the Bitcoin workload. So, if listeners aren’t familiar with what the UTXO database is for, when we’re validating each block, we need to join the transaction inputs together with their matching previous outputs, somewhere in the history of the chain, in order to validate their existence and their spendability in the current block.

So, the question is – and there are like 180 million unspent transaction outputs in total. So, that’s why you need a database and you need good performance. So, there are maybe three things that I use to be able to get this running very fast, and the first key is concurrency. So, rather than locking the database for every operation, this database, the operations are concurrent and lock free. So, that means there’s no mutex required to synchronize serialized access to the database. And this allows me to have a concurrent validation engine, where I have a pool of threads and I can have many concurrent blocks in that pipeline with pools of worker threads, and the worker threads are each doing something different. For example, one thread could be parsing the inputs for block 64, another one is appending the outputs for block 63, another one is querying inputs at block 62. And all of these could be happening in parallel.

Mark Erhardt: Well, the obvious question that you beg right now is, how would it work if you are still adding outputs that are created by prior blocks while you’re looking for the inputs that might not be present yet?

Toby Sharp: Yes, I thought that was going to be the first question. So, a couple of different ways. So, firstly, in terms of the queries, queries specify an effective height parameter. So, each query effectively sees its own block’s view onto the data. And then that leads me to the second key here, which is out-of-order execution with automatic dependency resolution. So, this goes to your question, Murch, about data dependencies. So, traditionally, this would be done in a sequential way. But the key to notice is that even with missing data, there’s a lot of processing that can be done, processing inputs that depend on pre-existing database entries. So, if let’s say block 95 arrives, but block 94 is still missing, well, there’s a lot of work we can do on block 95 already. We can parse the inputs, we can query those that are present, most of which are going to be much earlier in the chain, not many of which are gonna be on the immediately prior block, and we could do partial query and partial fetch of that data. And then, when there’s no more work to be done on that block, we can put it into a stalled state and start work on another block.

So, the way this works is that there’s an automatic dependency resolution of the data flow, so that when the missing block arrives, then you perform the residual query that you need to do, the residual data updates and query, and that means that everything can be kept in the correct state.

Mark Erhardt: Okay, so you basically partially process the block up to the point where you have all the data, then you put it back on the queue and presumably fetch it back when everything before that block height has been processed. And that limits how many things you need to have on the backlog, and allows you to do all of the work lazily when it’s possible to do it quickly.

Toby Sharp: Correct. And the machine that I was running up this on has 32 cores. And so, like you could specify a maximum number of blocks that you could allow in your pipeline concurrently. But it’s actually not difficult to keep all 32 cores fully occupied, because there’s a lot of scope for parallelism here. So, yes, because we can parallelize across blocks, across the operations that are required within a block, across transactions, and we can keep all the latency hidden behind that concurrency. And so, that’s really, I think, essential for high-performance Initial Block Download (IBD) and validation.

Mark Erhardt: So, maybe I misunderstood. I thought that you kept a database of all the transaction outputs, rather than just UTXOs, and you therefore kept a much larger database than just the 164 million UTXOs that we currently have. Did I understand that right?

Toby Sharp: Okay, that’s a good and a detailed question. Let’s see. So, there’s a couple of different choices here that could be made. The choice that I’ve made so far is that all of the outputs are appended to an append-only table that’s stored on disk. But all of the index for that table is only the unspent outputs. So, that means that the structure that you need to keep lean and fast, the index, is as lean as it can be, while the structure that you want fast access to, the table, can remain lock-free and appendable in parallel. But if you didn’t like the idea of that extra data being in the table, then when you reach the point of, let’s say, finishing the IBD, you could recreate that table without the unspent outputs if you wanted to. That could be like a user operation to compactify.

Mark Erhardt: Right. So, basically, during the IBD, you would optimize for speed and allow a higher disk usage to have the transaction outputs all in the database. And then, once you finish the IBD and get into a state where you need to process data a lot less quickly, just one block every 10 minutes roughly, you would just throw away the spent transaction outputs from that database, which would compact it down just to the UTXO set. So, the UTXO set goes to some 170 GB, or something, I think?

Toby Sharp: Oh, I’d have to check, but that sounds about right.

Mark Erhardt: I seem to remember that you wrote something like that!

Toby Sharp: Okay. Yeah, I remember I checked this, but I don’t remember what the number was now. I take your word for it. So, maybe the third thing I could mention about this, we’ve talked about concurrency, we’ve talked about out-of-order execution. The other thing might be just to say the low-level structure. So, yeah, we’ve started to talk about how the data is stored on disk and I mentioned that the index is only the UTXOs. It’s an LSM-style age-stratified index. And I tag each entry with height. So, that’s quite nice. It means that naturally, you end up searching the more recent data first. And it also means that you can rewind the database to a previous state, for example for a reorg, without having to store separate undo data. So, it’s literally just like, you truncate the data and now you’ve rewound it to the fork point, then you can play it forward through the new fork. So, that’s quite nice as well. I don’t use any hash maps. Everything is done with doubly-sorted runs and directories, which optimize the amount of memory for cache coherency. A copy-on-write strategy keeps everything lock free. And for the disk access, I use high queue depth async IO reads, which should be optimal for NVMe performance.

So, the last thing I would just say to wrap up on that is how this fits into Hornet Node. And one of the key points about Hornet Node is its modularity and its strict layering. So, the way this has been designed is that the consensus code doesn’t depend on the database code. There is just a pure interface, and the pure interface says, for each input in the block, give me the corresponding previous outputs. And so, that’s all that the consensus code knows about UTXO databases. It’s just a very pure view. And then, all of the database implementation lives separately in another layer.

Mark Erhardt: So, maybe a less Hornet-Node-related question. Your software is also written in C++ like Bitcoin Core. I assume that you might have taken a look at Bitcoin Core, how it uses its UTXO database. Would it be possible to use your approach also in Bitcoin Core, or what would your thoughts be on that?

Toby Sharp: Yeah, I mean it’s just code, so we can do anything in theory. I think it would be absolutely possible, but I think one of the challenges with Bitcoin Core is that refactors are large work investments, right, and the code tends to be quite intertwined. And so, there isn’t maybe the same separation, strong separation of interfaces, components, and concerns that would make that refactoring straightforward. So, that’s one of the reasons why I thought it’d be an interesting project to kind of reimagine what the consensus code would look like if it was written today, like on a fresh piece of paper.

Mark Erhardt: Talking about the consensus code being re-implemented, so my understanding is that you’re doing both a formal specification of what exactly the consensus code is and you’re re-implementing it. I was wondering, have you cross-compared with Bitcoin kernel to validate how close you are to fully implementing the consensus code?

Toby Sharp: Yeah, and I think the Bitcoin kernel is a great project and something that would be very positive for Bitcoin Core. And I’ve had a conversation with TheCharlatan about these different things, and I think we’ve got a lot of shared values in this, so that’s all good. I think the Hornet Node implementation is not fully complete yet, because there’s one major piece still missing. But in terms of what’s already been implemented, I think it’s accurate. And I’ll be increasing the test surface over time. The specification and consensus code that I’ve written in C++ is written in a declarative style, so it doesn’t have any side effects or mutable state. This makes it much easier to test and audit and answer questions about. But there’s also a domain-specific language that I’m using for specifying the consensus rules at a more pure mathematical level. And that could eventually have a path to formal verification, which would be the strongest guarantees of all.

Mark Erhardt: That sounds super exciting.

Toby Sharp: Thank you, Murch.

Mark Erhardt: Does anyone else have questions? Mike, did you have more prepared here?

Mike Schmidt: I mean, the one is maybe, and I know it was somewhat addressed in the thread, but maybe what comes to mind, Toby, when talking about this sort of architecture and IBD and performance is Libbitcoin. Do you want to just maybe briefly compare and contrast the approaches and performance?

Toby Sharp: Yeah, I would say I’m not an expert on Libbitcoin. So, I know a little bit about it, but not a great deal. And I think in the Delving Bitcoin thread, somebody asked, “Oh, have you compared with Libbitcoin, because that’d be a great comparison?” And I agree, it would be a great comparison. The thing is, I don’t know it well enough to know exactly what would be the like-for-like comparison with that library. So, if anybody maybe who’s listening has more knowledge of Libbitcoin, we could perhaps team up and do a comparison test that would be accurate like-for-like. I think Libbitcoin also has a good strategy of, from what I understand, having an append-only during IBD, which makes it very fast for writing that transaction output to disk, similar to what Hornet does on that side. But I don’t think it has the concurrency, which is the main winner here.

Mike Schmidt: Well, maybe we can ping Eric Voskuil. I’m sure he would love to get in a speed race on IBD. He loves to do those things.

Toby Sharp: That would be great.

Mike Schmidt: Ping him and see. Toby, anything else? A call to action for listeners, other than checking out the Delving posts areas where you think it would be valuable to have Bitcoin fans poke around?

Toby Sharp: Yeah, I guess at this point, I mean Hornet Node is 23,000 lines of code. It’s pretty lean. It’s very modern C++. I have not publicly announced the code yet, and that’s partly for immigration reasons, of all things, because I live in the USA on a work visa, so I can only work for my employer. But I think I would like to get to a point where I can work on Hornet full time, rather than just in my weekends. And so, I think anyone who’s interested could take a look at the website, read the overview, read the paper I published in September, and reach out with either encouragement or suggestions, questions, or funding. All of these things would be appreciated.

Mike Schmidt: For those who are listening and don’t have the newsletter up, it’s hornetnode.org, and you can find some of the materials there, and then obviously revisit the newsletter for the Delving post link.

Toby Sharp: That’s great, thank you. Thanks, Murch.

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

Toby Sharp: Okay. Thank you very much. Thanks everyone.

Bithoven: A formally verified, imperative language for Bitcoin Script

Mike Schmidt: Cheers. “Bithoven, a formally verified imperative language for Bitcoin Script”. Chris, you posted to Delving Bitcoin about your work on, I think I’m saying it right, Bithoven, which is sort of an alternative to miniscript. Maybe talk about why you created such a thing, and then we can compare and contrast with miniscript and see what kind of good things you have in Bithoven.

Chris Hyunhum Cho: Yeah, thanks for having me. And it’s right, it’s Bithoven. And the motivation for building this smart contract is actually, I must tell the problem that I encountered when I first learned about the Bitcoin system and the Bitcoin Script and the miniscript. I just personally feel that Bitcoin secret system and the miniscript is honestly too difficult. And I guess anyone who don’t have an expertise in Bitcoin system would feel very difficult to write the code in Bitcoin Script or miniscript, because you need to understand a lot of semantics of assembly-like opcodes, and you also need to have some basic knowledge cryptography, distributed systems, those kinds of things. And also, I feel the motivation because while Bitcoin has a lot of advantage over Ethereum, the developer ecosystem of Ethereum is more huge. I personally just feel that this is because it doesn’t provide the easy, high-level smart contract language.

So, what I feel the difficulty in miniscript or Bitcoin Script is that first, is about the type system. The type system is very obscure. For example, Bitcoin Script only accepts the byte as an operand for the operation. For example, when the type of bytes are interpreted upon the context, for example, if the byte comes before OP_ADD, which is arithmetic opcode, byte becomes number; and, for example, if OP_CHECKSIG is either public key or signature, and otherwise it’s just bytes mostly. And also, the type of result of these operations are also various open context. And there are some other security concerns, for example, you need to push minimal integer, especially in legacy script. For example, if you want to push the integer 1, then you should use opcode OP_1 instead of OP_PUSHBYTES 1. And it also has a negative zero, which in standard computer science, integer usually uses two’s complement, but in Bitcoin Script number, it uses like sign-magnitude integer.

So, there are like a lot of things we need to check to mitigate the security concerns. Like for example, if you omit OP_CHECKSIG code in your output script, it will make your money loss, because anyone can spend without proving the ownership. And also, the stack management are very tricky. Like some opcodes consume one stack item, some do two, some do three, or some do nothing. And some opcodes push the return onto the stack, some don’t. So, I just think that I need to build a program language that can handle these problems with better usability for developers. Yeah, that was the problem that I’ve seen.

Mark Erhardt: So, you talked a lot about your motivation. Bithoven, as I understand it, is a programming language that uses a style that is similar to C, that allows you to define a smart contract. And then, you’ve created a compiler that compiles it to the script. Would you like to tell us a little more about that?

Chris Hyunhum Cho: Yeah. So, if you see the Bithoven program, if you see, for example, the first line and the second line, it’s the sentence starts with pragma, which is similar to C. And it’s a compiler directive. The first statement states the compiler version that you are going to use, and the second one is the target. And you can pick target either legacy, segwit, or taproot. These naming just are defined by me, and I just use these to adapt to continuous consensus change, like how script works for legacy script, and segwit3.0 and segwit3.1 are different. So, I just make the developer to set the target. And then, there comes stack input definitions, which looks like function parameters, like the argument name and the type. You can define the stack item list that you are going to use as an input stack items. For example, if you are going to provide the signature, you can name the stack item as sig_alice, and then you can set the type as signature. If you are going to provide the preimage, you can just name the item as preimage and set the type string.

These types and the order of stack items are later used in the static analyzer to check the type consistency and check whether there are stack items that are in mislocation, like you need to spend the first item, top stack item, and then second item. But if you spend second-to-top stack item before the top stack item, then the compiler throws the error. And then, after that, you can finally code your program, which compiles down to output script. There are two components. One is statement and the other is expression. In the statement is a C-like statement. You can use the if/else block like C, and you can use older and after statement, which are just inspired by miniscript and have the same semantics. And the others are verify and return statement. Verify statement and return statement both receive the expression. And expressions are the components which are evaluated to the value, and it pushes the value onto the stack.

So, expression includes most of the opcodes that Bitcoin supports, except the manual stack management opcode, like OP_SWAP or OP_PICK as it’s high-level language. For example, you can do math, add, subtract, like A plus B, A minus B, and max, min, and, or, and compare operation, create operation, those kind of things. So, verify statement just push the OP_VERIFY code at the end to verify the final expression value pushed onto the stack. And the return statement is just the final statement of program to push the final item onto the stack, which is required for script to parse in Bitcoin. And if you look at my compiler code, there are four components. One is parser. Parser is defined using R1 parser. It’s kind of, if you define former grammar and the regular expression for the syntax, then the automated parser is generated. And with the design of abstract syntax tree, it’s kind of like intermediate language. We can generate this AST output to process further, and then it goes to static analyzer. In this stage, it checks the type, like wrong use of stale item, and checks some non-security bugs, like for example, if it doesn’t require any signature, it throws the error. And for example, if the public key, the program state is string return, but we check that is this public key actually on elliptic curve or not? Those kind of checks are done in this stage.

Then finally, we just compile to Bitcoin opcodes and handle all the tricky jobs like stack management. We use like OP_SWAP and the Ark stack. And then, the final step is the optimization. For example, If OP_VERIFY is next to OP_EQUAL, just replace two outputs with OP_EQUALVERIFY. So, I guess the biggest advantage of my Bithoven language is very developer-friendly and very easy to write. But I try my best guarantee to secure the code. Yeah, that’s Bithoven.

Mark Erhardt: All right, that sounds pretty exciting. I know that locktimes, for example, are a challenge and I’m actually not 100% sure how much of it is now supported by miniscript. How does Bithoven deal with these sort of constraints? Does it support it?

Chris Hyunhum Cho: Yeah, actually the locktime part is pretty similar to miniscript. Miniscript supports both absolute locktime and relative locktime with order and after syntax, and they are just quite similar. What miniscript doesn’t provide is actually a lot of expressions, like A plus B or A is greater than B, or those kind of nested expressions; and in Bithoven, it supports it.

Mark Erhardt: Okay, cool. Antoine joined us meanwhile, and he has worked a bunch on miniscript. So, I was wondering whether Antoine might have any comments or questions.

Mike Schmidt: Yeah, I want to frame it up a little spicier. Antoine authored a field report for Optech titled, “Field Report: A Miniscript Journey”. And towards the end, he notes, “The future is bright. Contracting on Bitcoin with safe primitives is more accessible than ever”. But now we have Chris here saying that maybe we need to improve our tooling and maybe it’s not as bright as we thought it was those two years ago. So, that’s my spicy frame-up for you, Antoine.

Antoine Poinsot: Yeah, hi everyone. I’m not sure I see the added value of a new language other than the one that is already supported and widely vouched and reviewed. I don’t think that support for additions in expressions is a sufficient reason, but I personally think that it’s one of your first projects in the Bitcoin space, and I think that working and playing with all the weird script edge cases is a very good introduction to the Bitcoin space, which was also my introduction. So, I hope to see more from you.

Mike Schmidt: Go ahead, Chris.

Chris Hyunhum Cho: I just think miniscript is safer obviously, and it prioritizes the safety first. And my first target is not to make the user to lose the money. But Bithoven’s main purpose is more like while sacrificing, maybe not that restricted, but it just emphasizes on the expressiveness of the language. So, yeah, and just manuscript, while it’s a very good language, for example, for general software engineers who don’t have expertise in Bitcoin, just find it just a bit difficult to write about. So, before they, for example, learn about the miniscript to write the perfect and safe Bitcoin smart contract, they can just learn Bithoven first and to understand continuously. Yeah.

Antoine Poinsot: Yeah, so I understand and that also helps to clarify maybe my criticism, which is not on your implementation because I did not look too much into it so I cannot give a criticism of it. I think it’s more on the goal. I think Bitcoin Script is about expressing conditions under which funds are about to be released. So, I don’t think it should be a goal to have expressions in this comparing to regular programming languages. It is not a goal to have regular primitives. I think a goal of the language should be, what useful primitives do we have for expressing who can unlock the money? And I think that miniscript covers all those useful primitives. If we were to add more, such as some covenant-type things, we might want to extend the miniscript language. But yeah, I think it’s more of a ‘where do we want to go’ disagreement.

Mark Erhardt: I want to chime in briefly. So, there’s other people that seem to disagree with this approach. There’s someone working on a BIP that wants to extend the arithmetic operators to larger numbers in Bitcoin. There’s the great script restoration, which also seems to be more in the direction of Chris’s programming language. And if, Chris, you say that your intent is to mostly make experimentation easier and provide a different UX to programmers that maybe is a bit of a difference to miniscript, where miniscript is compatible with output script descriptors and much more tuned towards expressing, well, maybe creating wallet patterns, so that’s my breaking a lance for this new project. Chris, did you have another reply to Antoine?

Chris Hyunhum Cho: Well, I guess while manuscript is perfect for the existing usage, but we have seen a lot of innovation so far in Bitcoin, like as you mentioned, the covenants. So, just my personal thought is that it’s just better to make it more expressive. If Bitcoin has the expressive feature in its Bitcoin Script that can be abstracted away by using the parser or compiler, then there might be in the world some software engineers who have the creativity to use this expressiveness to make something wonderful. Then, yeah, in that purpose. And also, Bithoven is providing static analyzers. So, it tries to prevent money loss bugs, as miniscript does, so where I should refine more and more to be competent enough to compete with miniscript. But, yeah, that’s my thoughts on my Bithoven and miniscript.

Mike Schmidt: A couple things came to my mind, and maybe the guests or Murch can comment on this, but maybe introducing the idea or the policy language, which I think was supposed to be a high-level way to represent some of this, but also the Minsk high-level language, which I think can go from Minsk to policy to miniscript to script. How would we think about those in comparisons to Bithoven?

Chris Hyunhum Cho: Well, I don’t know much about Minsk. I once used the Minsk IDE but I don’t know how much they extend from the miniscript, so could anyone explain?

Pieter Wuille: So, I think that if your goal is to represent conditions under which a UTXO may be unlocked, you can’t do much more approachable than the manuscript policy language, because it’s literally saying either this key or this key after 42 blocks. Minsk is a way of representing the miniscript policy language in language that is more approachable to an existing mainstream language programmer, which is instead of having functions of, or this path, or this path, you have variables, but it’s still an alternative to the manuscript policy language, which is still targeting expressing the conditions under which the money is released. I don’t think it aims to integrate arbitrary computation like Chris’s project.

Chris Hyunhum Cho: I just remembered how the syntax was in Minsk. And yes, I guess Minsk is just inheriting the features of miniscript with more user-friendly syntax. So, it basically doesn’t support various expressions like addition or comparison. And also, for example, in mainstream language, as Antoine mentioned, like OR, and then you just define the conditional path, first path and second path, as the parameter of OR. But, you know, in program language, we usually use an if/else block. So, if you see Bithoven, it supports just the if/else block, but it just compiles down to what OR compiles down to in miniscript. So, as the overhead is not generated, so with zero overhead, it supports more friendly syntax than miniscript, I guess.

Mike Schmidt: I think we did a pretty good dive on that, had a little bit of debate. Chris, I want to thank you for joining us. It sounds like the call to action here, and correct me if I’m wrong, would be for people to play with this and check out the work that you’ve posted; well, I guess the paper that you’ve posted in addition to the Delving post. Anything else that you’d want listeners to look into?

Mark Erhardt: So, in Bitcoin, we have the Bitcoin Improvement Proposal process, where people present these sort of ideas. And I was wondering whether that is perhaps something that you are considering.

Chris Hyunhum Cho: Well, honestly, because the reason I just built this Bithoven to adapt to continuous consensus change is because it’s so hard for me to change the consensus or change the impact on the Bitcoin Core itself. So, if Bithoven gets a lot of popularity, then I will consider. But I will rather follow up what you guys do on the Bitcoin Core so that Bithoven is helpful enough. And my call for action is, I’m just researching in programming language and blockchain. I’m just a PhD student. The reason I just published this open source is I just want to get feedback to improve the usability or performance, or catch the bug that I haven’t found and increase the accuracy. So, if you just search Bithoven in GitHub or Google, you will find my repository. And I also provide the web IDE. So, just feel free to code with Bithoven and feel free to leave any feedback in GitHub or Delving Bitcoin. Thank you.

Mark Erhardt: Bithoven is of course also linked in the Newsletter #391 that we’re discussing.

Mike Schmidt: Chris thanks for your time thanks for joining us. You’re welcome to hang on or you’re free to drop.

Chris Hyunhum Cho: Thank you, everyone.

Addressing remaining points on BIP54

Mike Schmidt: We’re going to jump back into the Changing consensus segment to talk with Antoine about the item titled, “Addressing remaining points on BIP54”. Antoine, maybe you want to make sure that the listeners know what BIP54 is, and then what are the remaining points of discussion?

Antoine Poinsot: Yes, BIP54 is a Bitcoin soft fork proposal named, “Consensus cleanup”, and which aims to fixing a number of vulnerabilities in the Bitcoin consensus protocol. Should I give the updates from the email?

Mike Schmidt: Yeah, so what’s the latest? Maybe where’s the project, and then what are these remaining points of the discussion from the mailing list?

Antoine Poinsot: Oh right, so the latest is that it just got merged into Inquisition. But the remaining point of discussions were actually from the end of December or beginning of January, so I will jump back to those and come back to Inquisition after. Well, I keep being told that the proposal is uncontroversial. Of course, it’s not a very nice thing to say when you are championing the proposal, but it seems that there’s not a lot of pushback against the proposal. There are two exceptions to this, which are, first of all, Luke Dashjr, on the one item of the proposal, mandates that miners would set the nLockTime in the coinbase transactions to a specific value, the specific value being the block height in which the transaction is included, minus 1. And currently, this field is just set to a dummy value, it’s just set to 000. So, it’s not something that miners are giving up some space in their block, or whatnot. Yeah, Murch?

Mark Erhardt: To be clear, there’s opposition to using the field, right? So, he opposes that rather than mandates it?

Antoine Poinsot: Yes, I was going to explain it. So, this item in the proposal mandates that this field is being used for this purpose. And Luke Dashjr explained, well, explain is a big word because he doesn’t want to explain it, mentions that the nLockTime is the perfect place for an extraNonce. So, in order to decipher what Luke said, it’s important to remember that the nLockTime is the last field serialized in a Bitcoin transaction. So, you would expect that it would be some sort of headers of the transaction, like the version of the transaction, the locktime of the transaction, the inputs and then the outputs. It’s not. For some reason, it’s first the version, then the inputs, then the outputs, and then the nLockTime at the very end of the transaction. Because it’s at the very end of the coinbase transaction, it can be used by miners to reuse a midstate of the coinbase transaction, because it’s not on the first word used by the SHA256 algorithm.

Mark Erhardt: Yeah, so the hashing consumes 32-byte chunks and adds them to the previous outputs to make it 64 bytes of input. So, even the header will be multiple chunks with its 80. And the nLockTime being the last field that is consumed from the header means that it is the last thing in the last round that is being hashed. So, if you only had to change that and kept all of the rest of the block the same, you would be able to use the hash product of the previous hash step and just update this tiny, little bit. That’s roughly how I understand it.

Antoine Poinsot: Yes, so say you have a massive coinbase transaction, it can actually save some hash cycles if you do that. If you’re paying out all your hashers in the coinbase outputs directly on the transaction, then you don’t have to rehash, let’s say, 8 kB or 20 kB of transactions. You just rehash the last 32 bytes and then you compress. So, that’s indeed savings, but it’s also a question of what are we trying to save here. Sometimes it doesn’t make sense to just benchmark some things in isolation and just try to improve the thing in isolation, because maybe the thing is not the bottleneck when you actually take a step back and consider how things work in real life. So, for instance, what example could I give? Maybe the serialization of Bitcoin transactions is not the bottleneck in Bitcoin Core for IBD, and maybe it’s looking up the UTXOs in the database, or it’s verifying signatures that is going to be the bottleneck. So, you might optimize all your serialization all you want, you’re never going to improve IBD time. So, it is we should not be looking at optimization with zooming in on some micro-optimization and look in the big pictures how they fit. Yes, Murch?

Mark Erhardt: Sorry. So, very specifically in this case, any byte changed in the header will lead to a new result for the header’s hash, which then of course would be checked against whether it is sufficiently low to parse the difficulty and be a valid block, right? So, if the nLockTime gets to have a mandated value, this hack that is very similar to ASICBoost, where you can keep the midstate of hashing and only change nLockTime, would become unavailable to everyone. And if it remains open, I don’t know why nobody ever has been using it before because it is right there and it would have been available for everyone, then it would be open to anyone and anyone could use it and it would still be sort of an equal playing field. So, whether or not it gets mandated doesn’t really actually affect whether or not mining is an equal playing field. It becomes either more difficult for everyone, or now that this has been discussed, everybody should be using it and it would become easier for everyone.

So, overall, it just feels like a no-op to reserve this for an extraNonce, because either it’s easier for everyone or it’s harder for everyone. You could still use the version field to do some version rolling, you can still use the timestamp to do some rolling. Yeah, sorry for jumping in.

Antoine Poinsot: Yeah, I think it’s a very important point to say that either way, mining keeps being an equal playing field. But I think also, we need to make it clear that it’s not an extraNonce for mining, it’s not really an optimization for the ASICs. So, in the same way that it’s using internal structure in what eventually becomes the merkle root, like covered ASICBoost, but covert ASICBoost enabled to paralyze the operations in the chips. So, it was an optimization for mining, and that’s why I was making my point on the bottleneck. This is an optimization for the mining controllers that are sending jobs to the ASICs, which is currently not a bottleneck at all. Which is if your stupid boards on top of your ASIC is not able to hash fast enough, just buy a Raspberry Pi and that’s done, that’s the end. So, this is not an extraNonce for billion-dollar operations. It’s an extraNonce for the mining controllers. I don’t know how to state that in more accessible terms but it’s essentially not a bottleneck today and it’s very hard to think about scenarios where it would become a bottleneck.

So, that’s what I was asking Luke to clarify when he initially made the comments. I think the very first time he made the comment was in a private message to me on the BIPs repository in the PR. So, on the BIPs repository, I really tried to challenge him to explain it. Then, I mentioned it on the Delving Bitcoin forum, where he does not want to interact. Fair enough. So, I sent it to the Bitcoin-Mining mailing list, a call to miners to update the nLockTime. He came back about the same point, giving no details and trying to, I think in my opinion, cast some doubt with reusing the extraNonce word to try to imply that somehow it’s a mining optimization, whereas it’s not. So, I was trying to explain.

Mark Erhardt: Wait a minute, I don’t follow that argument though. So, what miners do is they go through a bunch of block headers in order to see whether a block header would surpass the difficulty. And the block header has a bunch of different fields, most of which actually are open to being sources of entropy. So, there’s some version rolling. The merkle root cannot be changed, that’s 32 bytes that are locked. And I’m confused. The previous blockhash cannot be changed. The merkle root can be changed, the version can be changed, and the locktime can be changed. The embits are locked, obviously, and the nonce is also entropy. So, I don’t see how it’s not usable at the ASIC level, because you could just count up the nLockTimes and get a new header every time.

Antoine Poinsot: It’s usable on the controller of the ASIC, where you’re going to send a header inside the ASIC and the controller is going to change the extraNonce and is going to send multiple jobs inside the ASIC machine and the ASIC is going to roll the nNonce, it’s going to roll the timestamp and it’s going to roll maybe sometimes the timestamp and the version.

Mark Erhardt: Okay, I’m glad I asked. I thought you meant the controller of the ASICs, like the job allocator rather than the controller in the ASIC. So, now I follow your argument.

Antoine Poinsot: Yeah, okay, maybe just to explain that to the audience as well. So, the way you have the mining farm is that you have the job controller and then you have multiple ASICs. And on top of each ASIC, you have a board that is controlling this specific ASIC, because inside the ASIC, it’s just circuits that are specialized to be hashing headers and rolling the fields in the headers. And the controller, I think at this point, is going to only get a merkle root, but you would have to check that with someone who knows mining more. But they just get a merkle root and change the coinbase transaction, which changes the merkle root in the header, and send a new header inside the ASIC, who then in turn rolls the nNonce, the nVersion and sometimes the timestamp.

Mark Erhardt: So, basically, to make it maybe a little simpler, the bottleneck in the ASIC is the hashing, not the producing new headers. And this being able to roll the nLockTime just allows you to create headers more quickly, but that does not seem to be the bottleneck of the ASIC machine itself. So, in your opinion, reserving the nLockTime to be able to use it as another source of entropy solves a problem that is none right now, because we can already produce enough headers to keep an ASIC busy.

Antoine Poinsot: Exactly, thank you. You have a gift to explain things cleanly. That’s exactly what I meant. And it’s also looking forward in the future, because it might be a non-issue today but might become in the future, and we don’t want to prevent ourselves from extending usage of Bitcoin because we could just use a different fix for BIP54 than this one. And so, that’s what Luke was pointing. It could be useful. Obviously, it’s not being used today because controllers just prefer to be rolling the scriptSig of a coinbase transaction, which is bytes at the very beginning of the serialization of the transaction, because it’s in the inputs. And so, they rehash the whole coinbase before sending the jobs inside the ASIC. Obviously, there is a revealed preference for miners that they don’t care about rolling the nLockTime, but it’s also very hard to think through a situation where they would care about rolling the nLockTime, and that’s what I’ve been trying to get Luke to explain, but he’s never explained because I don’t think there is any such realistic scenario.

Mark Erhardt: All right, so basically, we neither have a bottleneck right now for producing the headers that need to be hashed, nor do we anticipate that that will ever be the case, because rolling the extraNonce in the coinbase is something that ASICs have to do only every four billion hashes anyway, because the nonce field will allow you to generate 4 billion headers already. And then, there’s version rolling and timestamp rolling on top of that. So, in each ASIC, you can already create billions of headers without even rolling the coinbase, so we anticipate that that will not be a problem in the future either. How about we get to the other point, there was something about the 64-byte stripped transactions that there was more on.

Antoine Poinsot: Sure, we can move on to this topic. I just want to finish with maybe some more positive notes, because it might sound like, “This is controversial, why don’t you just use a separate field and be done with it”. The reason is that there are very good reasons for using the nLockTime to store the block height. First of all, well, Luke’s the first one to be saying that we should use Bitcoin as it’s designed for, and locktime is used to store block height, so it’s a very natural place to store it. Furthermore, the same midstate optimization can be used, once we have the block height in the coinbase, to have proofs of a height of a block directly compressed with a midstate. So, the same argument works for the mining optimization and for the use case. And because we have timelock enabled on Coinbase transactions, this enables a simplification in software, where past a BIP54 activation, when we know that miners must set the locktime in the coinbase properly, because timelock is being validated for coinbase, we know that there has never been a coinbase in the past with the same locktime. Therefore, it must mean that this coinbase is unique. Therefore, if we ever bury the BIP54 activation, we don’t need to make BIP30 validation conditionals on the chain.

So, it’s like there is upsides to be using this field for this purpose. It’s not only not giving up against Luke’s argument. So, I think that he’s not convinced me to change, to not get all these upsides for something that is highly theoretical. And that’s what I explained in the email.

Mark Erhardt: I’m sorry, I also have to follow up. I realize that I confused myself. So, we’re talking about two different levels of where entropy for the hashing comes from, and I didn’t properly distinguish that earlier. So, in the block header, we have the version, the previous block header, the merkle root, the timestamp, the embits and the nonce, but the locktime is in the coinbase transaction. So, in order to get the entropy out of the locktime to be relevant for the header at all, it would be a change to the merkle root and not in the header, as I implied earlier, which is incorrect, right? So, the point is, if we’re changing the coinbase transaction currently, we would be changing the extraNonce. And before we ever change the coinbase transaction, there are several fields in the block header that we would be changing. We can version roll, we can change the timestamp, and there is the actual nonce in the block header, which allows us up to 4 billion values.

So, I think I didn’t properly explain that earlier. I was mixing the locktime from the coinbase transaction into the header data, which is not where it is. This is about data that is in the coinbase.

Antoine Poinsot: Yes, and that’s the reason why it only matters for the controllers. So, that’s the reasons to use these fields. There was arguments against. I was not convinced by the arguments, and the reason I’m not are available on the mailing list post in detail. There were also others that reacted to my post saying that worst case, if miners really want to have an extraNonce in for their controllers, they can always add another return output at the end of their coinbase transactions. So, there seems to be, besides Luke chiming in with this counter argument, there seems to be a wide argument among others that it’s a fine place to put the block height.

Mark Erhardt: Please continue.

Antoine Poinsot: Okay, so the other pushback was on the other item from the BIP54 proposal, which relates to 64-byte transactions without witness data. Annoyingly, I’ve seen this argument, so it’s an argument from Jeremy Rubin. It’s a different argument from the previous pushback I had from Eric Voskuil on Delving for invalidating 64-byte transactions. This one is more of an argument for, what if we need 64-byte transactions in the future? And then, suggesting that instead of invalidating the 64-byte transactions themselves, we change the merkle tree algorithm in order to be compatible with any size of transactions. So, these arguments were laid down in a podcast by Jeremy Rubin. I think it was on the Blockspace podcast. And there are two, I think, as far as I remember, two parts to the argument. The first part is, what if with covenants, we have some structures where inside a covenant, we need to use a 64-byte transaction in the future? And of course, it cannot make sense if you don’t change the current Bitcoin protocol, because whether you are inside a covenant or not, as long as you are going to transmit funds, you need an output that is at least 20 bytes, well, 28 with the value. So, the transaction is always going to be more than 64 bytes in any case, whether you’re inside some weird covenant logic.

I tried to substantiate the theoretical case in which it could matter. Jeremy said that maybe we might want some separate structure to transactions in the future, in the same way as we had for segwit with the witness, but for the outputs. If we do this, then the output of a transaction as hashed today could be nil and empty essentially, because the locking information would be in an extension of the transaction format. So, in my opinion that’s pretty far-fetched. At this point, you might as well just make a hard fork, because the existing users on the chain would just have no information how all the coins are even being spent. So, yeah I just think that it’s far-fetched and in any ways that is remotely comparable to how Bitcoin works today, 64-byte transactions cannot be secure and cannot be attached any value. So, I don’t find this argument convincing at all.

So, the alternative suggestions that Jeremy was giving during his podcast was instead of making the 64-byte transactions invalid, you could build a separate merkle tree, let’s say in a coinbase transaction output, in the same way that you have today the witness merkle tree in a coinbase OP_RETURN. You could have the future merkle tree in coinbase OP_RETURN, and the only transaction that you have in your block in the ancient merkle tree is the coinbase transaction. Same reason, it’s like I don’t know if people remember the evil soft fork discussions back I think it was a decade ago. It’s like at this point, you’re creating a soft fork where everybody is forced to migrate to this new block data structure. Otherwise, you do not see any content of the blocks, you are not able to validate the 21-million limit, you are not able to validate any basic consensus rules, and you are not able to make any transaction whatsoever anymore, or seeing their confirmations. So, essentially it’s a forced upgrade.

So, I don’t think it’s very fair to call that a soft fork, because there is usually a connotation that a soft fork is soft. Because what his proposal would be is essentially break all existing users of the Bitcoin protocol, force them to upgrade to a new version of the consensus rules, just to avoid making these insecure 64-byte transactions invalid. So, in my opinion, the trade-off, it’s not worth it. In my opinion, if you weigh – because it’s also, there is always the third way of we just keep the 64-byte transactions in secure transactions in consensus valid, as they are today. There’s always this option. In my opinion, just making them invalid is superior to this. And it’s also superior to just breaking all existing usage of the Bitcoin protocol to move everybody to a new merkle tree.

Mike Schmidt: So, in both situations, it seems like he’s thinking very greenfield kind of soft forks. One is a whole new merkle tree that everyone would have to move to. And then the other one, it’s sort of, if there were a new segwit-like data structure, that were added, then you could have reasonable transactions that would be potentially the 64 bytes. And then, because we’ve outlawed those, you’d have to have additional logic in there to make sure it’s either 63 or 65, or some such thing. Or, I guess it would be a hard fork to make the 64 valid again, right? So, yeah, I think I saw some of his talk on that. I wish we had him on to defend his position, but what are other people saying about 64-byte transactions in Jeremy’s argument?

Antoine Poinsot: I have not heard any public comments about his alternative merkle tree idea. Essentially, it’s an extension block. There have been comments in the past about doing extension blocks, so maybe people can look into those. And there has been opposition, not really, like pushbacks on the desirability of invalidating 64-byte transactions being worth it, but that’s all I’ve seen. I don’t think there has been comments. There has been comments on the mailing thread, with regard to Luke’s objections for nLockTime, but I have not read any on the part that was on Jeremy’s alternative merkle tree ideas.

Mike Schmidt: Maybe we can talk briefly about Inquisition, which you mentioned, which I think happened after this newsletter was published. There’s a few different things that are activated on Inquisition, which is basically a test network, signet. Now, when there’s something like CTV (CHECKTEMPLATEVERIFY) activated, people can jump on and play around with a new cool new feature. What does that look like for BIP54? Obviously there’s not a feature for them to play around with, but are there ways to test some of these vulnerabilities are fixed; like, what can people do? Are there some scripts they can run or things they can do to verify it works?

Antoine Poinsot: Sure. So, as you say, Inquisition is more interesting as a testbed for consensus changes when the consensus changes offer more capability of valid things, whereas this soft fork is essentially really making existing things invalid, like any soft forks, but does not offer new features. And therefore, yeah, it makes less sense to be testing on a public test network. I guess there is always, with Inquisition, the ability to make private signet networks and create maybe semi-private bad blocks and tests that they are indeed rejected by the network. But yeah, that’s pretty limited. I think that the reason I wanted to get it on Inquisition was more to have my implementation meet a certain bar, a certain threshold that is lower than the threshold to get stuff merged into Bitcoin Core; and to get some early feedback from Bitcoin Core contributors, because that would be the set of people that are having a look into Inquisition. I didn’t have feedback from all contributors that would happen if I make a request to Bitcoin Core, but that was a good smaller threshold for me to reach, with review from people, I don’t know, who just have more experience with C++ than I do, or maybe have feedback on the way I organized the test vectors, which was one big thing that was improved during the review process for Inquisition.

Mike Schmidt: Excellent. Anything else that you’d point people to on BIP54 as it sort of progresses along? What should people know? What should they be looking out for?

Antoine Poinsot: Well, I think I want to let things bake for a little bit. I’ve collected the feedback I got on Inquisition during the review of Inquisition to improve the BIP. So, I will be improving the BIP. Maybe I can help participate in some private testing with some custom signet private network if people are into this. Well, one thing, one big blocker is to get miners to be forward-compatible with the proposal, because currently they all set the nLockTime to various values, mostly to 0 to a dummy value, and we need them to be setting it to the block height minus 1, not in order to activate the soft fork, but in order for them to be producing valid blocks whether the soft fork is activated or not. Because currently, they only produce valid blocks if the soft fork is not activated. So, in order to make it safe to activate the soft fork, we need them to have forward-compatible blocks.

So, that is my main non-technical task at the moment, reaching out to miners and explaining and trying to explain that I’m not asking them to vouch for the south fork, just to be compatible whether or not it happens. And yeah, for information, I know that Optech is going to have a new summary for the consensus cleanup topic. Also, there is a bunch of links there. And I think somebody is working on a website for the BIP, so that might be something to look out for.

Mike Schmidt: All right, we’ll look forward to that. Yeah, and Murch, thank you for that open PR to the Optech topic. We’ll be refreshing that hopefully in the next couple of days here. So, Antoine, thanks for joining us, thanks for participating in a few of these discussions. Murch, do you have anything else for Antoine? I know you bowed out there for a second.

Mark Erhardt: Yeah, sorry, I might have missed it. But I think the buy-in from miners or the awareness of miners would also be drastically improved as the project moves forward in parallel in other venues. So, I think it coming out on Inquisition will help, and hopefully it also coming out on Bitcoin Core eventually might help, so let’s just keep the ball moving.

Antoine Poinsot: Yeah. Okay, thanks for having me.

Discussion of dust attack mitigations

Mike Schmidt: Thanks for joining us, Antoine, cheers. And our final jumping around here, we’re going back up to the News section to discuss the last news item titled, “Discussion of dust attack mitigations”. This was a Delving post by Bubb1es, who wasn’t able to join us on the show.

Mark Erhardt: So, basically, we describe as a dusting attack when someone reuses addresses that existed or had been used before, in order to reduce the privacy of the users by just sending minuscule amounts of satoshis to, well, previously used addresses. And there are various ways how people try to mitigate this loss of privacy. So, the attackers’ agenda here is that the victim might combine these UTXOs with other UTXOs in their wallet, and thereby reveal more information about the existing previously-used address in the context of the wallet of the victim. So, by using the tiny amounts together with new UTXOs, it would tie them together in the shared input heuristic, where the base assumption is that all of the inputs in a transaction belong to the same wallet.

So, the way I understand the proposal of Bubb1es is now that the minimum fee rate has been dropped by a factor of 10, and it only costs a few satoshis to spend UTXOs, so for example, P2TR keypath inputs can be had for a mere 6 sats and P2WPKH costs only 7 sats, and even a P2PKH output, legacy output, would only be 15 sats now, so it becomes drastically cheaper to scrounge up these dust UTXOs. And the underlying worry Bubb1es has is that even when previously your wallet might ignore these UTXOs because they were so small, it would pick them up now because the minimum amount for inputs to make them viable to pay for themselves is so much lower.

So, the idea is instead of leaving them floating in your wallet, you actively burn them by spending them to a zero amount OP_RETURN output. And there was then just a discussion about the viability of this approach. The idea is to spend every single UTXO separately in order to make it not leak any more information about the wallet. But some other disputants in the conversation proposed that you could use a, I think it was ANYONECANPAY? Yeah, ANYONECANPAY|ALL sighash and that would allow other people to add their dust inputs and reuse the same output. So, ANYONECANPAY|ALL means your input commits to all of the outputs, which is that single zero amount OP_RETURN output, for which the proposed content would be ash, as in ashes to ashes. And with the ANYONECANPAY other inputs, you do not commit to other inputs. So, therefore, other people can expand your transaction by adding more inputs to it that also all get burned to the same OP_RETURN output. And because the amount is zero, all of the amount of the inputs gets turned into transaction fees. So, the more people add their inputs to the transaction, the more space-efficient it becomes to burn these transactions and it all gets turned into fees, which hopefully makes a miner pick up the burned transaction.

Now, of course, these inputs get combined, but they actually subvert the common input heuristic by incorrectly making the surveillant think that these inputs belong together, but actually they come from different wallets. So, it models wallet clusters. There was a previous work ten years ago by Peter Todd, who proposed dust-b-gone as a very similar approach. He was using the none, instead of ANYONECANPAY|NONE. And the way I understood it, that would have additionally allowed anyone to use that input for its value to their own transactions. Basically, you just make the input available to pack into any transaction at all. So, other people could use your UTXO after seeing the transaction, and rebind it to their transaction and grab the funds for themselves, also incorrectly associating the dust UTXO with their wallet instead of the victim’s wallet. So, this is basically the idea.

The hope would be, if these transactions float around the network, when other people want to do this, they might keep track of those transactions and add their own UTXOs to it, which would make it more efficient and support surveillance.

Mike Schmidt: So, the two tools here, the recently proposed one that we’re talking about in this Delving post is ddust, and then the one that Murch referenced, that was Peter Todd’s tool from ten years ago, was called dust-be-gone. So, if you’re curious how people are proposing you can handle this or have handled this in decades past, check out those tools in addition to the Delving thread. Anything else on that one, Murch? All right. I’m glad we were able to get through those two segments in two hours. And we can move to the Releases and release candidates segment, as well as Notable code and documentation changes, both authored by our very own Gustavo, who’s here to walk us through them.

LDK 0.1.9 and 0.2.1

Gustavo Flores Echaiz: Thank you, Mike, thank you, Murch, and this was a very interesting conversation. But I’m glad we get to this part. So, this week, we have two releases of LDK, 0.19 and 0.21. These are both maintenance releases which fix a critical issue related to the ElectrumSyncClient structure. So, basically, what was happening here is that unconfirmed transactions were treated as confirmed transactions when syncing a wallet. So, for example, if you had an unconfirmed transaction such as a channel opening transaction, the ElectrumSyncClient would try to obtain the merkle proof for that transaction. However, since it was unconfirmed, that wouldn’t work and it would kind of get stuck until the transaction would confirm, and then it would be able to obtain the merkle proof; or the transaction would drop out of the mempool if it was replaced, or something like that happened. So, the fix here makes it that the unconfirmed transactions are treated as such so that LDK doesn’t try to fetch for its merkle proof. And this fix applies to both versions.

However, the second version, 0.2.1, this has some additional fixes that apply to things that were added after v0.2, which are specifically the AttributionData structure related to the attributable failures proposal. This is now public as a structure, which allows it to construct messages elsewhere in the software before the permissions that allow to build. Previously, it was preventing the construction of some messages. And also, splicing. When a peer doesn’t support splicing, it will now properly fail immediately when trying to splice a channel with a peer, instead of not failing immediately. So, those are the two releases of the week, maintenance releases related to LDK. They’re not all as official releases in the LDK repository, you have to click on the tags section to find them. But yeah, there they are. Any extra thoughts here, questions? Perfect.

Bitcoin Core #33604

We move forward with the Notable code and documentation changes. This week we have two Bitcoin Core PRs, as well as many related to the Lightning implementations, and finally one for Rust Bitcoin. So, first of all, on Bitcoin Core, we have a correction of a behavior related to the assumeUTXO implementation. So, basically, when a node that uses assumeUTXO, it will first get a snapshot block, it will sync towards the latest chain tip, and it will download blocks previous to that snapshot block in the background. When the node is downloading those blocks in the background, it will skip peers that don’t have that snapshot block, because it wants to make sure that it’s only downloading blocks from peers that have that same snapshot block, because it’s unable to handle a potential reorg. However, once the node has fully synced and is no longer doing background validation, this restriction about peers would still apply unnecessarily.

So, what this PR does is that it removes that restriction after background validation has been done, so that Bitcoin Core isn’t necessarily filtering peers out, or at least is not applying that specific restriction for peers that don’t have that snapshot block. Obviously, most peers will still have that snapshot block, because most peers are still synced to the same best chain. But this was just an unnecessary restriction that was kept, even after background validation was done.

Bitcoin Core #34358

We move forward with #34538. In this second PR related to Bitcoin Core, a bug occurred when trying to remove transactions via the removeprunedfunds. So, this is actually an underlying issue with a util related to removing transactions. So, it’s not at the API endpoint level of removeprunedfunds, but it’s the underlying util that had the issue. So, when you were removing a specific transaction using the removeprunedfunds RPC, it would mark all of its inputs spendable again. But what if you also had another competing transaction that was spending those same inputs. The bug was that it would make those UTXOs, those inputs, spendable again, even if you had another transaction that was spending them. So, then, your wallet could construct a conflicting transaction with those UTXOs. So, now the bug ensures that the inputs are marked as spendable again, only if another transaction doesn’t also spend. Any extra thoughts, comments here? Perfect.

Core Lightning #8824

We move forward with Core Lightning #8824. This is a fairly simple one, where basically a new layer is added to the askrene plugin, which is called auto.include_fees. And this means that when you use askrene, which is a plugin specifically for pathfinding that was based on a previous plugin called renepay, which is an implementation of Pickhardt Payments related to René Pickhardt, basically what this new feature does is that it will deduct the routing fees from the payment amount, effectively making the receiver pay for the fees. So, this is just an extra feature added to the askrene plugin, quite simple to understand. And the way askrene works is through layers. So, this is just an extra layer that is added to indicate that the routing fee has to be deducted from the payment amount.

Mark Erhardt: If any of the Core Lightning (CLN) people are listening, I can only recommend not to do this in case they have similar issues with that as we do, because subtract_fee_from_outputs as a feature on the Bitcoin Core wallet has been an endless source of bugs and pain. So, unless you are very confident that turning around the whole paradigm of how fees and the sending amount fit together, that has at least been a terrible idea on Bitcoin Core.

Gustavo Flores Echaiz: Thank you for that comment, Murch. Yeah, that’s important to point out. The PR is now merged, but I think that the CLN team still appreciates your feedback on that.

Eclair #3244

We follow up with Eclair #3244. Here, two events are added when making payments. The first one, PaymentNotRelayed, is emitted when you couldn’t relay a payment to the next node. So, specifically, I believe when you’re making the payment yourself and you’re trying to make the payment and it fails, this is when this is emitted. And the second event, which is called OutgoingHtlcNotAdded, this is emitted when you couldn’t add an HTLC (Hash Time Locked Contract) to a specific channel and, from what I understand, this means that you were relaying a payment from someone else. So, the first event would be when you’re trying to make a payment, and the second event is when you’re relaying an HTLC, so someone’s trying to use your node as a routing node to make a payment. Usually, these events indicate that there’s insufficient liquidity, so it should maybe help you build an heuristic for liquidity allocation.

However, the PR notes that it’s important to consider that a single event isn’t enough proof to indicate that you’re missing liquidity. So, it’s better to wait for multiple failure events before adding more liquidity, because a malicious sender could try to game these events to get you to allocate liquidity for free. So, important to consider this as a heuristics for liquidity allocation instead of triggering allocation just by one single event.

LDK #4263

We move forward with two PRs related to LDK. The first one, LDK #4263, adds a new optional parameter to the pay_for_bolt11_invoice API, which allows a caller to embed arbitrary metadata. This optional parameter is called custom TLVs (Type-Length-Values). And basically here, the difference, let’s say, between using a payment description and using a TLV is that you don’t have to handle the payment hash or the preimage. You can directly embed metadata on the payment onion. And this is specifically used for programmatic uses of data embedding and then data parsing, so for example, when making a payment, if I want to basically say that this payment should be considered for a specific programmatic use case, such as an order ID or an authentication token, or any other structured data that the receiving node or application needs to process the payment programmatically. There’s an important note added that this is specific to BOLT11 and not to BOLT12. And also, very important to note that this is something that was already present in a low-level endpoint called send_payment. So, this is just an addition to a higher-level endpoint that is more commonly used, so that a caller doesn’t have to go through the lower-level endpoints. Any comments here? Perfect.

LDK #4300

We move forward with three final PRs, the next one on LDK, #4300. Here, support for generic HTLC interception is added, which is built on a mechanism that was introduced when async payments were added in the last few weeks to LDK and expands its prior capabilities. So, in Newsletter #230, we covered that LDK added functionality for intercepting HTLCs that had fake short-channel IDs (SCIDs). So, this PR expands that use case to be able to intercept specifically SCIDs that are calling for interception. But the main goal is for offline private channels that are useful for LSPs to wake up sleeping clients. So, in Newsletter #365, we covered the implementation of LDK of BLIPs #55, also known as LSPS5, which defines how clients can register for webhooks to receive push notifications from the LSP to be woken up when receiving a payment. That newsletter covered the client-side implementation.

This PR that I’m discussing right now basically builds the foundation for building the LSP or server-side implementation of LSPS5. And it all would also enable additional LSP use cases, but this is the focus of this PR, is enabling LSPS5, which allows LSPs to wake up clients that have signed up for webhooks when receiving a payment when offline. Any questions, comments? Perfect.

LND #10473

We’re very close to the end. We now have LND #10473. So, in Newsletter #386, I discussed the introduction of an experimental gRPC subsystem called switchrpc, which had the BuildOnion, the SendOnion, and the TrackOnion RPCs. And basically, this subsystem was introduced so that external controller software could handle pathfinding and simply use LND for HTLC delivery. So, one problem that was remarked at that moment is that the SendOnion RPC wasn’t fully idempotent, which means that it wasn’t necessarily safe to dispatch multiple attempts of the same payment, because you could find yourself making twice the same payment and thus losing funds. So, bringing back to the PR of this week, LND #10473 basically completes the previous work and makes SendOnion fully idempotent, which enables clients to safely retry requests after network failures without risking duplicate payments.

The way it does this is by every time the SendOnion RPC is called, LND will give it an attempt_id before making the dispatch of the HTLC. That registration allows for this behavior. So, if the external controller then tries to make a second payment, LND will recognize that the same attempt_id was used, and thus identify correctly that this was a duplicate and not dispatch the payment. So, yeah, if a request has already been processed, the DUPLICATE_HTLC error will be returned. Yes, Murch?

Mark Erhardt: Brief question. So, the attempt_id, is it created on the side of the caller or on the side of the processor? And if it’s created on the side of the processor, it must be created deterministically from the input or something, otherwise how would the duplicate be found? Did you happen to say that in the description?

Gustavo Flores Echaiz: Yes, that’s a very good question. So, I just read the description before describing this and I cannot find information specifically about who determines what is the attempt_id. If I quote what is written, basically the first step is the registration, and the handler’s first action is to call InitAttempt, and this write-ahead style approach creates a durable record of intent to dispatch that serves as the idempotence anchor.

Mark Erhardt: So, it sounds like the receiver side is parsing and creating the attempt_id and checking whether it’s a duplicate. So, it is not something that the caller has to keep track of.

Gustavo Flores Echaiz: Yeah, exactly. From what I understand, that’s exactly right. This is something that is handled by LND and not by the external control. Perfect.

Rust Bitcoin #5493

We finish with Rust Bitcoin #5493, where the ability to use hardware-optimized SHA256 operations on ARM architectures is added. So, this is something that was done on x86 architectures, covered in Newsletter #265, so about two-and-a-half years ago, but it was missing implementation on ARM architectures. So, this hardware-optimized algorithm is added to make faster SHA256 operations. And benchmarks show that hashing is approximately five times faster with using this hardware acceleration algorithm on these operations, specifically when you’re processing large blocks. So, yeah, this was the final PR and this completes the section and the whole newsletter, unless, Murch, please, if you have any questions.

Mark Erhardt: I think that might have trailed a little bit because there might have not been a SHA instruction on ARM until recently. So, this is something that becomes available on the chip instruction set. And I seem to recall that this is a fairly recent development that SHA256 is part of the instruction set on some chips. I don’t recall exactly whether it was just added to ARM, but that might be part of the explanation here.

Gustavo Flores Echaiz: That would make a lot of sense. Thank you, Murch, for adding that. The PR description doesn’t specifically point to that. From what I can see, it just says that this was missing, and so the author had to add it. But yeah, that would make a lot of sense. Thank you, Murch. And yes, this completes the newsletter.

Mike Schmidt: Awesome. Thanks, Gustavo.

Mark Erhardt: Yeah, thanks.

Mike Schmidt: Thank you also, Murch, for co-hosting. And we want to thank our guests, Jonas Nick, Antoine, Chris, and Toby for joining us. Always an interesting and long one when we do that Changing consensus segment. So, we appreciate you all also for listening. We’ll hear you next week. Cheers.

Mark Erhardt: Cheers.

Bitcoin Optech Newsletter #391

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

This week’s newsletter links to work on a constant-time parallelized UTXO database, summarizes a new high-level language for writing Bitcoin Script, and describes an idea to mitigate dust attacks. Also included are our regular sections summarizing discussion about changing Bitcoin’s consensus rules, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software.

News

● A constant-time parallelized UTXO database: Toby Sharp posted to Delving Bitcoin about his latest project, a custom, highly parallel UTXO database, with constant-time queries, called Hornet UTXO(1). This is a new additional component of Hornet Node, an experimental Bitcoin client focused on providing a minimal executable specification of Bitcoin’s consensus rules. This new database aims to improve Initial Block Download (IBD) through a lock-free, highly concurrent architecture.

The code is written in modern C++23, without external dependencies. To optimize for speed, sorted arrays and LSM trees were preferred over hash maps. Operations, such as append, query, and fetch, are executed concurrently, and blocks are processed out of order as they arrive, with data dependencies resolved automatically. The code is not yet publicly available.

Sharp provided a benchmark to assess the capabilities of his software. For re-validating the whole mainnet chain, Bitcoin Core v30 took 167 minutes (with no script or signature validation), while Hornet UTXO(1) took 15 minutes to complete validation. Tests were performed on a 32-core computer, with 128GB RAM and 1TB storage.

In the discussion that followed, other developers suggested Sharp to compare performance against libbitcoin, which is known for providing a very efficient IBD.
● Bithoven: A formally verified, imperative language for Bitcoin Script: Hyunhum Cho wrote on Delving Bitcoin about his work on Bithoven which is an alternative to miniscript. In contrast to miniscript’s predicate language for expressing the possible satisfactions for a locking script, Bithoven uses a more familiar C-family syntax with if, else, verify, and return as its primary operations. The compiler handles all stack management and makes similar guarantees to the miniscript compiler regarding all paths requiring at least one signature and similar. Similar to miniscript, it can target various Script versions.
● Discussion of dust attack mitigations: Bubb1es posted to Delving Bitcoin about a way to dispose of dust attacks in onchain wallets. A dust attack happens when an adversary sends dust UTXO’s to all the anonymous addresses they want to know about. Hoping that some will be spent unintentionally with an unrelated UTXO.

The way most wallets choose to handle this today is by preventing spending of the dust UTXOs by marking them as dust UTXOs in the wallets client. This can become an issue in the future if the user restores from keys and the new wallet client doesn’t know these UTXOs are marked and “unlocks” the dust UTXOs to be spent. Bubb1es suggests another way to prevent this dust UTXO attack by creating a transaction with the dust UTXO that uses the entire amount and has an OP_RETURN output making it provably unspendable. This is possible because Bitcoin Core v30.0 has a lower minimum relay fee rate (0.1 sats/vbyte).

He then lists out a few risks with implementing a wallet that handles dust UTXOs like this.
1. Fingerprinting issues if only a few wallets implement this.
2. If multiple dust UTXOs are broadcast at the same time, then there can be correlation.
3. Rebroadcasting might need to be done if fee rates go up.
4. It can be confusing to sign for dust UTXOs in multi-sig and hardware signing setups.
AJ Towns mentioned that the minimum relay size is 65 bytes and explains that using ANYONECANPAY|ALL with a 3-byte OP_RETURN would make it more efficient.

Bubb1es then provides an experimental tool ddust to demonstrate how this would be done.

Changing consensus

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

● SHRINCS: 324-byte stateful post-quantum signatures with static backups: Following-up on the Hash-based Signature Schemes for Bitcoin, Jonas Nick detailed on Delving Bitcoin a specific hash-based quantum-resistant signature algorithm with potentially useful properties for use in Bitcoin.

In the paper, there was discussion of the trade-offs between stateful and stateless hash-based signatures, where stateful signatures can have significantly reduced cost at the expense of complex backup schemes. SHRINCS offers a compromise where a stateful signature is used when the fidelity of the key+state can be known with certainty, but falls back to stateless signing at higher cost if there is doubt that the state is valid.

The two schemes chosen for SHRINCS are SPHINCS+ for stateless signing and Unbalanced XMSS for stateful signing. The public key posted in the output script is a hash of the stateful and stateless keys. Because these hash-based signature schemes return the signing public key as part of verification, the signer provides the unused public key along with their signature and the verifier checks that the returned public key hashes with the provided public key to the key specified in the locking script. The Unbalanced XMSS scheme is chosen to optimize for cases where relatively few signatures are needed from a key.
● Addressing remaining points on BIP54: Antoine Poinsot wrote about the remaining points of discussion for the consensus cleanup soft fork.

First up for discussion is the proposal to enforce that the coinbase transaction’s nLockTime be set to one less than the block height. Here the discussion centers around whether this change unnecessarily restricts mining chips’ ability to use this field as an extra nonce as future miners run out of nonce space in the existing version, timestamp, and nonce fields. Several posters mentioned that the nLockTime field already has consensus enforced semantics and is therefore not a prime candidate for additional nonce rolling. Various proposals for alternate nonce space were made, including additional version bits and a separate OP_RETURN output.

The other change discussed is the proposal to make 64-non-witness-byte transactions invalid in consensus. Such transactions are also restricted by default relay policy, but a consensus change would protect SPV (or other similar) light clients from certain attacks. Several posters questioned whether this change is even worthwhile, given that other mitigations exist, and it introduces a potentially surprising validity gap for certain types of transactions (e.g. CPFPs for certain protocols).
● Falcon post-quantum signature scheme proposal: Giulio Golinelli posted on the mailing list proposing a fork to enable Falcon signature verification to Bitcoin. The Falcon algorithm is based on lattice cryptography and is seeking FIPS standardization as a post-quantum signature algorithm. It requires about 20x more space on chain than ECDSA signatures while being about twice as fast to verify. This makes it one of the smallest post-quantum signature schemes so far proposed for Bitcoin.

Conduition posted some limitations of the Falcon algorithm, especially around the difficulty of implementing signing in constant time. Others discussed the question of whether a post-quantum signature algorithm for Bitcoin should be designed with future STARK/SNARK-friendliness in mind.

Note: While the mailing list post describes it as a soft fork, it appears to be implemented as a flag-day disjunction in the P2WPKH verification path which would be a hard fork. Further work would be necessary to develop a soft fork client for this algorithm.
● SLH-DSA verification can compete with ECC: Conduition wrote about his ongoing work benchmarking his post-quantum SLH-DSA verification implementation against libsecp256k1. His results show that SLH-DSA verification can compete with schnorr verification in common cases.

Releases and release candidates

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

● LDK 0.1.9 and 0.2.1 are maintenance releases of this popular library for building LN-enabled applications. Both fix a bug where ElectrumSyncClient would fail to sync when unconfirmed transactions were present. Version 0.2.1 additionally fixes an issue where splice_channel didn’t fail immediately when the peer doesn’t support splicing, makes the AttributionData struct public, and includes several other bug fixes.

Notable code and documentation changes

● Bitcoin Core #33604 corrects the behavior of assumeUTXO nodes. During background validation, the node avoids downloading blocks from peers that don’t have the snapshot block in their best chain because the node lacks the necessary undo data to handle a potential reorg. However, this restriction persisted unnecessarily even after background validation had finished, despite the fact that the node could handle reorgs. Nodes now only apply this restriction while background validation is ongoing.
● Bitcoin Core #34358 fixes a wallet bug that occurred when removing transactions via the removeprunedfunds RPC. Previously, removing a transaction marked all of its inputs as spendable again, even if the wallet contained a conflicting transaction that also spent the same UTXOs.
● Core Lightning #8824 adds an auto.include_fees layer to the pathfinding askrene plugin (see Newsletter #316) that deducts routing fees from the payment amount, effectively making the receiver pay for the fees.
● Eclair #3244 adds two events: PaymentNotRelayed, emitted when a payment couldn’t be relayed to the next node likely due to insufficient liquidity, and OutgoingHtlcNotAdded, emitted when an HTLC couldn’t be added to a specific channel. These events help node operators build heuristics for liquidity allocation, though the PR notes that a single event shouldn’t trigger allocation.
● LDK #4263 adds a custom_tlvs optional parameter to the pay_for_bolt11_invoice API, enabling callers to embed arbitrary metadata in the payment onion. Although the low-level endpoint send_payment already allowed for custom Type-Length-Values (TLVs) in BOLT11 payments, it wasn’t properly surfaced on higher-level endpoints.
● LDK #4300 adds support for generic HTLC interception, building on the HTLC holding mechanism added for async payments and expanding the prior capability, which only intercepted HTLCs destined for fake SCIDs (see Newsletter #230). The new implementation uses a configurable bitfield to intercept HTLCs destined for: intercept SCIDs (as before), offline private channels (useful for LSPs to wake sleeping clients), online private channels, public channels, and unknown SCIDs. This lays the groundwork for supporting LSPS5 (see Newsletter #365 for the client-side implementation) and other LSP use cases.
● LND #10473 makes the SendOnion RPC (see Newsletter #386) fully idempotent, enabling clients to safely retry requests after network failures without risking duplicate payments. If a request with the same attempt_id has already been processed, the RPC will return a DUPLICATE_HTLC error.
● Rust Bitcoin #5493 adds the ability to use hardware-optimized SHA256 operations on compatible ARM architectures. Benchmarks show that hashing is approximately five times faster for large blocks. This complements the existing SHA256 acceleration on x86 architectures (see Newsletter #265).

Bitcoin Optech Newsletter #390 Recap Podcast

2026-02-03T00:00:00+00:00

Mark “Murch” Erhardt and Gustavo Flores Echaiz are joined by Liam Eagen to discuss Newsletter #390.

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

Download audio

News

● Argo: a garbled-circuits scheme with more efficient off-chain computation (0:48)
● LN-Symmetry update (26:05)

Selected Q&A from Bitcoin Stack Exchange

● What is stored in dbcache and with what priority? (34:21)
● Can one do a coinjoin in Shielded CSV? (24:02)
● In Bitcoin Core, how to use Tor for broadcasting new transactions only? (36:47)
● Brassard-Høyer-Tapp (BHT) algorithm and Bitcoin (BIP360) (38:31)
● Why does BitHash alternate sha256 and ripemd160? (39:24)

Releases and release candidates

● Libsecp256k1 0.7.1 (41:09)

Notable code and documentation changes

● Bitcoin Core #33822 (42:59)
● Bitcoin Core #34269 (44:50)
● Core Lightning #8850 (47:38)
● LDK #4349 (49:16)
● Rust Bitcoin #5470 (50:54)
● Rust Bitcoin #5443 (51:26)
● BDK #2037 (52:51)
● BIPs #2076 (55:49)
● BIPs #1500 (59:39)

Transcription

Mark Erhardt: Good morning. This is the Bitcoin Optech Newsletter Recap for Newsletter #390. We are today not joined by Mike, so I get to do the honors of leading us through the newsletter today. But we are joined by a guest, which is Liam. We will be talking about the news item that is Argo. And we also have an update on LN-Symmetry, the regular segment of Selected Q &A from Bitcoin Stack Exchange, a single Release, and a few Notable code and documentation changes. I’m also joined by Gustavo. Do you want to introduce yourselves, Liam?

Liam Eagen: Sure. I’m Liam, I have recently published this Argo work with Ying Tong Lai. It’s like a new garbling scheme. It’s in the sort of family of BitVM-type protocols, if people are familiar, there’s been this newer version of BitVM that uses garbled circuits that reduces onchain costs a lot. I had previous work called Glock that was similar to this, but Argo is a new garbling scheme that’s even better. So, that’s what I’ve been working on lately.

Argo: a garbled-circuits scheme with more efficient off-chain computation

Mark Erhardt: Great. Right, we’re jumping right into the News section here. The first item is Argo, which Liam is already starting to talk about. We had Liam on, I don’t even remember, a few months ago to talk about Glock, which was a garbled lock scheme that was about, I think, a thousand times more efficient than other approaches to BitVM at that time, because it made use of applying the assumptions to all parts of the setup. But now, you’re back and you have an even better algorithm, or not algorithm, maybe scheme.

Liam Eagen: Yeah.

Mark Erhardt: Do you want to introduce it yourself or should I give my high-level overview?

Liam Eagen: Go ahead.

Mark Erhardt: All right. So, my understanding is that you discovered or came up with a way of translating the algorithmic operations of an algorithmic circuit to elliptic curves. And now, you can do basically the encoding of an algorithmic circuit with elliptic curve operations. And this makes it very efficient to encode on the wire and allows you to more efficiently calculate all of the stuff that was happening in the garbled locks before. And that’s roughly where I got, and the rest of it is all the moon math stuff that you can tell us about now.

Liam Eagen: Yeah. So, the basic primitive that we want in these kinds of protocols is a conditional disclosure of secrets. So, there’s one party that we call the operator, or the garbler in this case, who will provide a proof; and if that proof, this is like a zero-knowledge proof, is invalid, then somebody else, the evaluator, should learn his secret. So, it’s like conditionally revealing a secret if a proof is invalid. And there are several approaches to this that use different variants of these garbled circuits protocols. My previous work on Glock had a special type of designated verifier SNARK. There’s also the work of the BitVM Alliance to implement a Groth16 verifier using a garbling technique called Yao. And that had garbling table sizes of about 50 GB. And with Argo, we can also construct a garbled circuit for a Groth16 verifier, but our garbling table is about 15.5 MB, so it’s more than 2,000 times smaller.

Mark Erhardt: Okay. So, just to recap, the basic idea is if the other party cheats, you learn a secret and you can take their money or some sort of collateral they put up. So, pretty much similar to LN-Penalty in the LN. But the things that you can express are much more complicated. You can express all sorts of smart contracts or other conditional phrases.

Liam Eagen: Yeah, exactly, anything you can make a proof about. So, one application, like in the BitVM space, people are focused on making bridges. So, you’d have a bridge that verifies some L2 side system thing, and, yeah.

Mark Erhardt: Right, so you made the proof tables about 2,000 times smaller. You can express roughly the same things and support the same things. Are there any downsides to this? Is this way more computationally intensive, or something like that, or is it just an improvement?

Liam Eagen: So, to the point about computational cost, it’s actually much cheaper. I don’t have the most recent Groth16 garbling times on hand, but I think it’s roughly this order of magnitude. It’s like 40 seconds to generate a Groth16 Yao garbled circuit; and an Argo garbled circuit takes about, I think, 16 milliseconds. So, it’s also many orders of magnitude faster.

Mark Erhardt: Holy smokes. That sounds like quite the breakthrough then.

Liam Eagen: Yeah, it’s very exciting. I think it uses some really cool techniques, and it’s very nice. I’ve enjoyed working on it. The only downside is that the representation that you take the proof as input – so, we’re talking about a garbled circuit. This garbled circuit takes an input. The input is a proof. In the Yao-based schemes, it’s feasible to accept a proof with what we will call compressed points. In Argo, we don’t know how to do that yet. So, the size of the proof has doubled. And this translates to increased onchain costs. So, I don’t know, I mean there’s a bunch of other details, but basically it’s roughly double the amount of data onchain.

Mark Erhardt: Double the amount of data, but I believe the prior improvement was that it was much smaller onchain. That doesn’t seem super-bad. Wasn’t it something like you could now express it in 80 bytes?

Liam Eagen: So, the reduction from BitVM2 to garbled circuit schemes like Glock or BitVM3 was, I think, about 500X less data. And I guess, I probably should have this, but I think that it’s about 10 kB you’d put onchain, thereabouts, maybe 20 kB, something like that to commit to a proof.

Mark Erhardt: So, this is not just when there is a penalty scenario or someone cheating, but actually just using it always requires 10 kB, which means it’s pretty expensive.

Liam Eagen: So, this is one piece of larger protocols, and there are a lot of degrees of freedom in how one designs these BitVM bridges. It’s possible to design the bridges such that in the happy path, if nobody disputes the proof, then you don’t have to put the 10 kB onchain. Although, you could design it in such a way where you always put the 10 kB onchain.

Mark Erhardt: Right, I mean if you can avoid it, you’d probably want to, although cheap block space is the topic of the time, I guess. Right, okay, so do you think you could give us a very short explanation of what the difference between a binary circuit and an arithmetic circuit is? Or is it maybe not that important? I don’t know.

Liam Eagen: No, I think it’s not too bad. People might’ve heard of a binary circuit. You think of a circuit has gates and it has wires. Each wire in a binary circuit is either 0 or 1. It can take on one of two values. And each gate is like a logical operation. So, like taking the bitwise AND or bitwise XOR, or something like that. In an arithmetic circuit, you instead allow your wires to take on a larger set of values. So, you think like values in a finite field like mod p. Then you can have gates that operate on mod p values. So, you can add or multiply wires in a single gate. The crucial trick that Argo exploits is we actually – so, you can go from binary to finite fields, but then you can even go further and imagine that a wire takes on an elliptic curve point. And now, your gate might be adding two elliptic curve points. And the nice thing about these SNARK verifiers is that they’re very algebraic. So, all of the operations, well, more or less all of the operations that the SNARK verifier circuit does are things like add curve points or evaluate pairings over curve points. And so, by working with these arithmetic circuits, you have very few operations.

Mark Erhardt: Right. It sounds like expressing something in an algorithmic circuit instead of a binary circuit would make you need a lot fewer gates, because you can express more complex operations in each gate. And then, being able to translate it to elliptic curve points sounds like it would be much more efficient to calculate on them. So, that’s sort of also what I got out of the writeup. But overall, that sounds like a huge breakthrough. Does that mean, when we talked last time, I think you said something that Glock would take several more years until there would be anything coming out of it in terms of production-ready products or schemes; does that mean that you made a big step towards using this?

Liam Eagen: Yeah, I think so. One really nice property that Argo enables that other schemes don’t is permissionless evaluation. So, in the Glock scheme, the garbler, the person who provides the proof, is fixed in advance, but so is the person who is able to challenge an invalid proof. This person is also fixed in advance. With Argo, we can remove the second constraint. So, anybody can challenge an invalid proof.

Mark Erhardt: That sounds very useful.

Liam Eagen: Yeah. The obstruction to doing this in the past was the extremely large amount of data that you’d need for all of these garbling tables. So, by making them 2,000 times smaller, it’s possible to design bridges that support permissionless challenging, or at least get much closer to that.

Mark Erhardt: Well, 15.5 MB doesn’t sound bad at all. And yeah, anybody being able to challenge it makes it a lot more approachable to systems with a lot of users, I’d say. So, my understanding is, I hope my listeners are not going to burn me at the stake now, my understanding is that Citrea is using a BitVM-style bridge. Is this the sort of thing that would be at the end of your research efforts, or what do you envision will this enable?

Liam Eagen: Yeah, Citrea is using BitVM2. So, speaking for myself, the motivation for working on these BitVM-style bridges is that with Bitcoin as it is now, this is the closest we can get to a bridge that would verify Shielded CSV. And that’s earlier work that I did with Robin Linus and Jonas Nick, and that would allow for very efficient private payments on Bitcoin. And so, that’s what I’m interested in doing. But I guess to answer your question, yes, Argo can be used to construct a better bridge than the BitVM2 bridge that Citrea uses, just across essentially every dimension. So, it’d just be cheaper and more operators, more efficient, etc.

Mark Erhardt: Right. And when you’re talking about scalable, cheap private payments, I know that Shielded CSV uses basically a nullifier. So, it reminds me a little bit of the scheme that shielded transactions in Zcash use. I think it’s essentially an account-based model and you can move funds in this, well, shielded account, or whatever, by making your Shielded CSV transaction, and people just learn that whatever you did was valid. So, do you have more insight on how that all works? We haven’t had anyone talk about Shielded CSV in a while.

Liam Eagen: Oh yeah, sure. So, yeah, I think that’s a fair, accurate summary. Shielded CSV is, well, CSV stands for Client-Side Validated. So, it’s one of these client-side-validated-type protocols which have existed for a long time in the Bitcoin space. But it uses SNARKs to recursively compress the transaction history. And it’s true, every transaction puts 64 bytes onchain. It’s a bit of a weird thing, but it’s like a nullifier plus a signature compressed into a single thing. And from the nullifier, nobody learns anything. They don’t learn your identity, they don’t learn the structure of your transaction. All of that’s kept offchain and proved offchain. And so, I think these protocols are cool. They’re still kind of research-y. I don’t know that they’re ready for someone to seriously start productionizing. There’s still some research-type questions in my mind. But yeah, in comparison to, say, Zcash or Monero, where the transactions are published into the mempool and then put onchain, Shielded CSV reduces the onchain footprint by a lot. I think an Orchard transaction on Zcash is something like 5 kB and I don’ know how big Monero transactions are, but probably similar order of magnitude.

Mark Erhardt: That sounds pretty cool. And I’m sure that there’s at least a bunch of people that would be excited to see more private payments on Bitcoin. There’s this lawsuit going on with the very private contract on Ethereum. What was it called?

Liam Eagen: Oh, Tornado Cash?

Mark Erhardt: Thank you. Tornado Cash. Sounds like a little bit like Tornado Cash, right? You put the funds in, you see it on the input side, and then if it ever comes out of the Shielded CSV, client-side validation universe, it would be completely disconnected. Is that apt comparison?

Liam Eagen: Yeah, I think so. I mean, there’s a bunch of these things. It’s like, that’s sort of how the shielded pool on Zcash works. Similarly, money moves in and money moves out. But yeah, that’s how it would work.

Mark Erhardt: Okay, well we got a little sidetracked here talking about Argo. You put your paper out, you said there’s another paper coming soon. Is there anything else that you want to share about this work, or any call to actions?

Liam Eagen: Yeah, so I’m working actually with Robin Linus and my co-author on Argo, Ying Tong. We have a company called Ideal Group, and we are looking to build a bridge using Argo. So, we’ve implemented Argo, or at least we haven’t audited it yet, but I think it’s quite production-ready, or close to it. And then, we want to implement the bridge. So, I guess if people are interested in that, we’d like to chat, and we’d ultimately really like to see this get used for Shielded CSV. So, after we make the bridge, we want to make the Shielded CSV part.

Mark Erhardt: Okay, that sounds good. Maybe some of our listeners will become aware of you that way. Have you, well, this can get very philosophical, so if you don’t have an answer, please feel free to say so, but this sounds sort of like it might move a bunch of transaction activity and blockspace consumption towards these sidecar systems or sidechain systems. Have you any opinion how that might influence the dynamics of the blockspace market, or like Ethereum got very top-heavy at some point, right?

Liam Eagen: What do you mean top-heavy?

Mark Erhardt: Like, more of the economic activity happened on second layers than on the base layer, and it sort of caused security and finality issues in some sense. Ethereum got less valuable compared to all the tokens on top of it. There can be some interesting dynamics there. Have you guys looked into that in the pursuit of your bridge?

Liam Eagen: Yeah, it’s a good question. I’m not an expert on these types of things, but I do think some things I’ve heard while being involved in this BitVM kind of work. I think the case of Ethereum and the case of Bitcoin are somewhat different in that the L2s for Ethereum don’t, well, I don’t know. I mean, I don’t want to make too strong of a claim, but they don’t really fundamentally offer more expressivity, right? On Ethereum, you can do anything that you can express with a smart contract. Whereas if you’re adding something like private payments or even DeFi stuff to Bitcoin that’s not possible on the L1, you can make the blockspace more valuable. So, even if the L2s were just buying blockspace, that could increase aggregate demand for blockspace. I don’t know if you’d see the same effect that you’re describing on Bitcoin.

Mark Erhardt: Yeah, I guess because Bitcoin doesn’t actually permit all of these things, the cannibalism wouldn’t be the same way, where on Ethereum, just the things that were happening on Ethereum before outright moved to the sidechains and because it was cheaper or compressed in the terms of transaction fees, or I guess, gas; and in Bitcoin the base layer is just, we prove that something happened correctly. So, we can’t do a lot of the things. Yeah, I don’t know. Maybe we, we can find some other people that have spent more time on focusing on that issue and they can weigh in on this. All right. I think that’s it from me about it. Gustavo, do you have any questions or comments?

Gustavo Flores Echaiz: No, I think this was pretty clear. Thank you so much, Liam, for taking the time to explain this to us and good luck with the Ideal Group, with your company. I’m looking forward to seeing the next paper you guys will publish that hopefully just closes the loop in towards making Argo a viable bridge. Thank you.

Liam Eagen: Thank you.

Mark Erhardt: Yeah, thanks for joining us and congratulations on becoming a founder. All right, you’re free to hang on. We do have actually later a question about Shielded CSV and actually, if you want, I’ll just pull it up right now.

Can one do a coinjoin in Shielded CSV?

So, one of the Stack Exchange questions was, “Can one do a coinjoin in Shielded CSV?” to which Jonas Nick pointed out that Shielded CSV basically updates singular accounts, and therefore there would not be a huge improvement where you would expect that Shielded CSV always takes 64 bytes, but that is because each nullifier only updates one account. So, if you have multiple participants in order to create a multi-account setup, you’d have multiple onchain transactions to set it up. Do you think that Shielded CSV would be a viable way of mixing or coinjoining, or what do you think about that?

Liam Eagen: I think what Jonas said sounds right to me, that when you have multiple parties, you have multiple onchain transactions. I think I would ask, like taking a step back, what are we trying to do by doing a coinjoin with Shielded CSV? Because the protocol itself is already private.

Mark Erhardt: Right. Essentially, everything going into and then coming out of Shielded CSV is a ginormous coinjoin, isn’t it? Not necessarily the amounts are equal, but yeah, it’s just one black box that things go into and out of. That’s a fair point. All right. I have one more actually that, well actually, I’ve got that one. Thank you for joining us, thank you for your time. If you want to hang on, you’re free to do so, but if you have other stuff to get to, we understand.

LN-Symmetry update

All right, moving on, we have a second news item. And unfortunately, Greg Sanders was not able to join us today, but he made an update to his prior work on LN-Symmetry. We reported on that over 100 newsletters ago, in Newsletter #284, so that’s two years roughly. Greg rebased his work, his initial proof of concept for LN-Symmetry, and put out a new client or implementation for signet. So, my understanding is that it’s now good enough to test on Inquisition. He improved that anchor bumping works now. You can make transactions, use P2A to expedite them. And he also was experimenting with LLM-supported development, vibe-coding an implementation based on OP_TEMPLATEHASH, OP_CHECKSIGFROMSTACK (CSFS), and OP_INTERNALKEY which is not quite ready yet and also can’t be used on Inquisition yet, because TEMPLATEHASH isn’t live on Inquisition. But yeah, I haven’t seen too much replies on that yet. I was hoping to pick Greg’s brain on this, but he was unfortunately not able to join us. So, that’s all I have for you on this topic. Gustavo, did you take a better look at that?

Gustavo Flores Echaiz: I took a little bit of look. Well, it’s good to see that at least he has updated his proof-of-concept work. I think the last time he did this was about two years ago, so LN and Bitcoin both have changed a lot since then, so this just rebases it to the latest changes. I just think the next step would be to get OP_TEMPLATEHASH inside Bitcoin Inquisition, and that way, the whole thing can be tested together. So, that step seems to be missing. I don’t think Sanders has any control on that. But besides that, this is a huge advance compared to the previous state of the proof of concept from two years ago.

Mark Erhardt: Well, I don’t know about no control. Greg is one of the co-authors of OP_TEMPLATEHASH and Inquisition is pretty accessible to PRs adding experimental soft forks. So, I guess it might be work that still needs to happen, but once someone gets to it, hopefully that would happen. Well, maybe just as a recap, we talked about this a little bit last week with René, but LN-Symmetry, the big advantage would be, with LN-Penalty, the current channel update mechanism, where the commitment transactions are asymmetric in order to allow one side to punish the other side for publishing an outdated state, LN-Symmetry uses symmetric commitment transactions, where every participant of a channel has exactly the same commitment transaction. And it updates to the correct latest state by simply overwriting prior versions of the commitment transaction. So, if someone publishes an outdated state, any other channel participant can just override it with the newest state and thereby enforce the actual channel state.

The huge advantage of this is that it would allow multiple participants in a Lightning channel, which with LN-Penalty would be very difficult, because the asymmetry is not easy to break out into more parties, and it is very difficult to assign blame when an old state is published, which party should lose their funds, and how those funds are distributed to the other parties. In a two-participant scenario, it’s always clear, there’s a blamed party and it defaults to giving all the funds to the other party. In a multiparty channel, who would get the money? So, there are some other trade-offs and some people are generally super-concerned about not having a penalty mechanism, what new dynamic that might open up. But if you assume that we haven’t seen the penalty used that much and it would still work without a penalty system, this could give us channels with many different parties. Of course, not too many, because setup and updates to the channel would require all the parties to be online and to participate.

But a Lightning channel that has five parties, for example, would satisfy money allocation to all of those five parties among those five parties. So, it would be much more cost-efficient and liquidity-efficient because you don’t have to tie up funds for five times, what is it? Five times, four times, is it five faculty channels? Anyway, 120 channels or so become a single five-party channel, and you can just shift money between all of those five parties, which sounds super-cool and much more efficient. Any further thoughts on LN-Symmetry?

Gustavo Flores Echaiz: Yeah, isn’t another benefit also the reduction in required storage for LN nodes, which would allow eventually even maybe hardware wallets to run like LN node software? Because from what I understand, the current LN storage growth is linear. And however, for LN-Symmetry, it would just be constant. You simply replace the older state with new state, and you can just use Lightning within simpler devices such as hardware walls.

Mark Erhardt: That’s a really good point. Yes, with LN-Penalty, you have to hold on to every previous state of every channel. And you would actually also want to hold on to all of the HTLCs (Hash Time Locked Contracts) that were on those prior states. So, if an old commitment transaction with HTLCs were broadcast, you would be able to execute the HTLCs on that too. But with LN-Symmetry, the problem of storing a backup becomes much simpler because having an old, outdated state doesn’t put you in the position that you might lose all of the funds in the channel by accidentally broadcasting it. So, it becomes more secure or easier for backups. And on the other hand, you only need to keep the latest state, so storing the state of your channels is much easier. And I don’t know if we’ve ever discussed this here on the show, but I just thought this is maybe an under-discussed aspect of splicing.

When you splice an LN-Penalty channel, your backup is reduced to a fresh start, because you have a new channel now, all of the prior history is sort of finalized. And I hadn’t even ever considered that, but basically splicing-in funds or splicing-out funds, once the splice is confirmed onchain means that your backup state is reset and you can throw away the old backup, which is kind of cool.

What is stored in dbcache and with what priority?

All right let’s move on to the selected Q&A from Bitcoin Stack Exchange. So, the first question that we have here is, “What is stored in dbcache and with what priority?” The user that asked this question was talking about running their node intermittently about 10% of the time, and they had a lot of memory, 64 GB, and wanted to be able to have the entire UTXO set in memory to make the node behave as efficiently as possible. But unfortunately, that’s not how Bitcoin Core does things. The dbcache only stores the UTXOs that are necessary to validate currently unconfirmed transactions. So, any transactions a node learns about and needs to check the inputs on, for those inputs, it will retrieve the UTXOs from disk and put them into the dbcache. And then, for any blocks that are processed that create new transaction outputs, it will also put those transaction outputs into the dbcache.

The UTXO set, I’ve said this quite a few times here on the show, but the UTXO set is actually stored on disk by Bitcoin Core, and only the UTXOs that are relevant to the transactions and blocks that we’re currently processing will be loaded. Yeah, I think that was roughly that question.

Can one do a coinjoin in Shielded CSV?

Next question is, “Can one do a coinjoin in Shielded CSV?”, which we already discussed with Liam a little bit. But basically, the idea here is we have a client-side validated system where funds are flowing in a basically account-based model. And we only put proofs onchain that whoever spent money in the client-side validated universe did so correctly and was authorized to do so. And basically, the whole thing is a ginormous coinjoin itself, not same amounts, but a black box. Things go in and go out. Also, this is currently a paper. It sounds like Ideal might be working on making this a real thing eventually.

In Bitcoin Core, how to use Tor for broadcasting new transactions only?

Okay, question number three, “In Bitcoin Core, how to use Tor for broadcasting new transactions only?” So, Vasil Dimov, the author of the private broadcast feature that will be released in Bitcoin Core v31, responded to this old question by pointing out that in Bitcoin Core v31, the private broadcast feature will become available, which we discussed two weeks ago, that was Newsletter #388, where we will make an ephemeral connection to a Tor node through the Tor network, or to a clearnet node through the Tor network. And we just basically handshake with the node, hand it our transaction, and then disconnect. And we do this several times until we see the transaction come back to us organically on the P2P network through the gossip. And once we see our own transaction come back to us, we forward it as if we had just learned about it. So, yeah, this old question got a new answer because the feature people were asking for is finally coming out.

Gustavo Flores Echaiz: Yeah, it was published more than five years ago, and it seems like the person asking the question exactly wanted this feature. And now, the feature is out and perfectly answers this question.

Brassard-Høyer-Tapp (BHT) algorithm and Bitcoin (BIP360)

Mark Erhardt: Right, and five years in Bitcoin time is almost a whole lifetime. So, they were just ahead of their time, I guess. In question number four, we have someone asking about the Brassard-Høyer-Tapp (BHT) algorithm, which apparently is an algorithm to find hash collisions. And they are wondering whether this could be used to diminish the security of addresses in Bitcoin. And the user, bca-0353f40e, points out that existing addresses cannot be attacked with this algorithm because the algorithm can only be used to create colliding addresses, and both of the collision partners or colliding addresses have to be rolled at the same time in order to make the algorithm work. So, existing addresses cannot be.

Why does BitHash alternate sha256 and ripemd160?

Final question from this Bitcoin Stack Exchange, “Why does BitHash alternate sha256 and ripmed160?” Sjors asked and answered this question, and he had this question in the context of BitVM3, which has the BitHash function. The takeaway that I had from reading his answer is that there are very few functions, opcodes on Bitcoin Script right now that can interact with 32-byte numbers. And one of them is SHA256 and the other one is RIPEMD. But RIPEMD only returns a 20-byte result. So, by alternating these two, it enables the users or the creators of BitVM3 to change. I should have asked Liam about this now that I think about it! Either way, the alternating algorithms allow for a change to happen. If you fed single bytes into one algorithm always, it would return the same thing apparently, and that’s not useful. One downside is that you lose 12 bytes, because RIPEMD only returns 20 bytes. But honestly, I’m a little out of depth on that question. That’s all I have.

Libsecp256k1 0.7.1

All right. This brings us to the Releases and release candidates segment. This week, we have for you only Libsecp256k1 0.7.1, which is a maintenance release for the library. I looked at the changelog. It looks that predominantly there are two things changed here. There’s a new unit test framework, and this unit test framework allows the tests to be run selectively and in parallel, which sounds very useful if you’re working on libsecp. And there was a performance issue fix, which made it if there was a flag present on the compiler, I think, then it would use a slower – would default to a C Compiler or something. Anyway, works faster now, and just maintenance release, no biggie. Did you have more on this one?

Gustavo Flores Echaiz: No, just I think it’s a pretty minor release, minor one for people that are using it. There’s an increase in the number of cases where the library attempts to clear secrets from the stack. I think this was one of the major issues it had before. And also, it’s fully backwards compatible with the previous version.

Mark Erhardt: Yeah. Oh, talking about the ABI, I don’t remember, something-interface, it is backwards compatible. There are no breaking changes in the interface. All right. Over to you, Gustavo, Notable code and documentation changes.

Bitcoin Core #33822

Gustavo Flores Echaiz: Perfect. Thank you so much, Murch, for leading the way. This wasn’t an easy newsletter, a lot of complex topics in hand. So, now we start the Notable code and documentation changes section with two PRs around Bitcoin Core. The first one, #33822, is an update to the libbitcoinkernel API interface. And for those of you who don’t remember what libbitcoinkernel is, It’s an interface that allows external projects to work with Bitcoin Core’s block validation and chainstate logic via a reusable C library. So, this allows you to simply leverage Bitcoin Core’s kernel, or central engine, around block validation and chainstate logic and you don’t have to deal with the remaining parts of Bitcoin Core. And this PR, specifically what it does is that it adds block header support by adding not only a block header type, but a lot of methods associated to creating headers from 80-byte serialized data, copying block headers, destroying, and then also obtaining all the attributes of a block header, such as the version, the timestamp, the previous blockhash, the difficulty target, and so on.

The other important part of this PR is the header processing methods. So, two new methods are added which allow you to validate and process block headers without requiring the full block. And the second one returns the block tree entry with the most cumulative PoW. So, you basically get anything you need to work around block headers with this improvement. So, now, through the libbitcoinkernel API interface, you can do pretty much anything that is required for working with block headers. Any extra thoughts here? Perfect.

Bitcoin Core #34269

We move on with Bitcoin Core #34269. This is an important PR because it follows a bug that came up a three newsletters ago, where if you were migrating a legacy wallet that was unnamed and the migration failed at the same time, you could see your funds disappear. So, this was a bug that was present in v30 and v30.1, and specifically v30.2 fixed it. I just want to reiterate that this was a very low-likelihood issue that would only happen if your wallet wasn’t name and something went wrong during migration. So, what this new PR does, #34269, actually it’s miswritten here, but the question is that this disallows creating or restoring to unnamed wallets. You can still restore old legacy unnamed wallets, you can just not create new unnamed wallets or restore an old one and keep it as unnamed. So now, you’re forced to name your new wallets when you’re using createwallet, restorewallet RPC commands, as well as the wallet’s tool, create and createfromdump commands. The GUI, the graphical user interface already enforced this restriction, but the RPCs and underlying functions did not. But just to make clear that you can always restore legacy unnamed wallet, you can just not create new unnamed wallets through the RPC methods. Yes, Murch?

Mark Erhardt: Right, so we have been requiring wallets to be named for several years now, and that is sort of becoming an assumption about wallets that they do have a name. So, basically, we move here to just disallowing the creation of new wallets without a name. And, yeah, Gustavo already mentioned the context with the wallet bug. Please, if you haven’t heard it yet, do not attempt to migrate your wallet with Bitcoin Core v30.0 or 30.1. There was a bug. If you have a very old unnamed wallet, it might delete your wallet directory if something fails during the migration and you have this unnamed wallet situation. So, if you update to v30.2, this problem has been mitigated. Just as a reminder, please do not try to migrate wallets with v30 and 30.1.

Core Lightning #8850

Gustavo Flores Echaiz: Thank you, Murch. We move on with Core Lightning #8850. This is just a PR that removes features that were previously deprecated. These were, for the most part, very old features that had mostly been renamed or some things had been changed on the specification so it had been given a new name, which what are we talking about specifically? The option_anchors_zero_fee_htlc_tx was a previous version of the current anchor outputs implementation. So, I believe these were all deprecated on v23. And also, decodepay RPC is replaced by just decode. Some fields called tx and txid in the close command are replaced by txs and txids, so these are mostly naming changes. And finally, the last one, estimatefeesv1 was just an original response format to return fee estimates in the bcli plugin, which is the plugin from Core Lightning (CLN) that interfaces with Bitcoin Core. So, this was the last one, just simply an original response format that was later updated. So, here just a regular maintenance PR that removes several deprecated features that had been deprecated for several versions already.

LDK #4349

We move on with LDK #4349. Here, some validation code is added to ensure that when LDK parses an offer, it will make sure that it follows all the bech32 padding rules, as specified by BIP173. So, previously, LDK would accept offers that had invalid bech32 patterns. However, Eclair and Lightning-KMP, which are other implementations, would correctly reject them. So, the changes are that when Rust LDK will receive an offer and will start parsing the offer, it will call validate_segwit_padding() to ensure that the offer corresponds with the correct padding. And the correct padding is that the end of the offer or any bech32 format, the last part must be either 4 bits or less or must be all zeros. So, now LDK will properly validate the padding around offers. And I believe also, the PR was open in the BOLT specification, PR #1312, so that a test vector is added on BOLT12 to check for invalid bech32 padding. Perfect.

Rust Bitcoin #5470

We move on with two PRs from Rust Bitcoin. So, over the past few weeks, we’ve seen Rust Bitcoin add multiple PRs that simply enforce protocol rules for proper validation of Bitcoin transactions. For example, Rust Bitcoin #5470 in this newsletter adds validation to the transaction decoder to reject transactions with zero outputs now, because obviously valid Bitcoin transactions must have at least one output.

Rust Bitcoin #5443

And the second one, Rust Bitcoin #5443, here validation is added to reject transactions where the sum of the outputs exceed MAX_MONEY which is 21 million bitcoin. This check is related to the value overflow incident, which I believe was one of the first bugs in Bitcoin, CVE-2010-5139, to be precise, which was the historical vulnerability where an attacker figured out how to create extremely large output values that surpass the amounts of possible bitcoins in existence. So, these are just maintenance features added to Rust Bitcoin. Yes, Murch?

Mark Erhardt: The sequence of all of these PRs introducing checks for consensus rules makes me think that there is a new contributor to Rust Bitcoin, just going through all the old CVEs and checking that they also are fixed in Rust Bitcoin!

Gustavo Flores Echaiz: Yes, it could very well be because these are all done by the same person, jrakibid. He basically first opened an issue, he ran some test vectors on Rust Bitcoin, and found all these issues, and now is going at fixing one by one.

Mark Erhardt: Wow, cool. That’s good work.

BDK #2037

Gustavo Flores Echaiz: Perfect, thank you, Murch. We move on with BDK #2037, where a new method called median_time_past() is added to calculate the median-time-past (MTP) for CheckPoint structures. So, MTP is the median timestamp of the previous 11 blocks, and is used to validate timelocks as defined by BIP113. So, in Newsletter #372, we covered how BDK refactored several types and structures to be in preparation for enabling cash merkle proofs, but also MTP. So, a few newsletters later, now the method for calculating MTP is added as a follow-up on that. Any thoughts here, Murch?

Mark Erhardt: Do you know what the CheckPoint structure is in the context of BDK, because Bitcoin Core recently removed the CheckPoints? And there’s other things that use MTP in Bitcoin Core, but CheckPoints aren’t even there anymore.

Gustavo Flores Echaiz: Right. No, to be honest, I believe it’s not related to the checkpoints.

Mark Erhardt: Maybe that’s just a data structure in BDK. But anyway, MTP is, for example, also used by locktime transactions. There’s two different ways of doing CLTV (CHECKLOCKTIMEVERIFY). One is height-based, one is MTP-based. And the proposed consensus cleanup soft fork, BIP54, is also proposing an MTP-based rule around the zeroth block or the first block of a new difficulty period. So, presumably anyone that is looking into these things might also want to have MTP functionality.

Gustavo Flores Echaiz: Yeah, I found a description for it. So, basically, here is an issue in BDK that explains the CheckPoint design. So, “At its core, CheckPoint represents a sparse, singly-linked chain of block references used to track which blocks we know about, detect reorgs by finding points of agreement between local and remote chains, and anchor transactions to specific blocks, and also calculate MTP time”.

Mark Erhardt: Okay, so it just is a name for a construct in BDK and doesn’t have anything to do with the CheckPoint as we think of them, as points in the blockchain.

BIPs #2076

Gustavo Flores Echaiz: Exactly, that’s exactly right. Thank you, Murch. So, we finish off this newsletter and the code and documentation changes section with two PRs merged in the BIPs repository. The first one, BIPs #2076, adds BIP434 to the BIP repository. BIP434 defines the P2P feature message that allows peers to announce and negotiate support for new features. So, in about four newsletters ago, in Newsletter #386, we covered that Anthony Towns had posted to the Bitcoin-Dev mailing list about his proposal for this BIP, and now it’s merged. So, what this proposal is, is that it’s a generalization of the P2P feature message. As previously proposed in BIP339, instead of requiring a new message type for each feature, this is a single reusable message format for announcing and negotiating any multiple P2P upgrades. So, this could benefit the proposal we’ve talked about previously as well, which is peer block template sharing, that mitigates problems with divergent mempool policies. So, you can check out #386 for more context on this. Yes, Murch.

Mark Erhardt: This is notably a huge improvement over the current mechanism of how we negotiate features, which is whenever there’s a new feature on the P2P layer, you update the version number of the protocol, the P2P protocol to be clear, and you assume that anyone that has updated to a specific version number of the P2P protocol will understand these messages, even if they don’t have the feature. Instead, having the BIP434 P2P feature messages, you will now be able to communicate with your peers; well, if it gets adopted, to be clear. You can communicate which features you support, and if there’s multiple different modi in which you can run those features, you can communicate about what version of it you would like to use. So, the idea is to make it much more flexible and to be able to communicate about what features your node supports, and then coordinate with your peer whether or not you will be using those features.

Gustavo Flores Echaiz: Is it correct to say that this is a proposal that looks to, let’s say, create a sort of layer between different implementations of a Bitcoin node? So, for example, if, let’s say, we all use Bitcoin Core, then we can know which features we support by Bitcoin Core version; but would it be correct to say that this allows for different implementations of node software to communicate on the support of features?

Mark Erhardt: Right. This is going to be very helpful if there’s more different node implementations or if nodes have services or features that other implementations do not have. So, for example, in ancient times, I think it was Bitcoin Unlimited, or something, had a P2P service where you could request UTXOs from a node. And there was another one. Anyway, this would make it much more flexible, or even just you could fork Bitcoin Core and add a feature to it and then use this feature message to communicate with peers about it.

BIPs #1500

Thank you, Murch. So, the last one in this list is the BIPs #1500, which adds BIP346, which defines a new opcode, OP_TXHASH, that allows to create a covenant and reduce interactivity in multiparty protocols. This opcode generalizes OP_CTV (CHECKTEMPLATEVERIFY), and when combined with OP_CSFS, can emulate SIGHASH_ANYPREVOUT (APO). Maybe, Murch, you want to give us a deeper dive into what all this means.

Mark Erhardt: Yeah. So, TXHASH had long been discussed as a more general way of doing CTV, and the author finally came back and finished up the proposal. So, I think this, this has been discussed for two or three years and it finally was ready for publication. So, it just came out last week, I think. Anyway, the general idea here is that you can use a flag array to indicate which properties of the transaction that spends a UTXO have to have certain characteristics, and then you can provide those characteristics. So, where CTV I think basically commits you to a very stringent template, the TXHASH opcode would allow you to set what parts of the templates are being enforced for a UTXO that’s being spent with TXHASH. Well, that’s roughly all I have here.

Anyway, yeah, we got two new BIPs published recently. There’s a couple more coming soon, I think. It always helps when people read those BIP drafts and leave their comments and thoughts. Or once you’re published, if you want to keep abreast of what people are proposing, they are reasonably mature. So, these are pretty readable now, if you want to catch up.

Gustavo Flores Echaiz: Thank you, Murch. Listeners can read the newsletter or listen to the episodes #185 and #272 for previous reference on this opcode. So, it was first introduced in #185 and in #272, we already had the draft BIP. So, this BIP has been in proposed mode for at least almost three years, two-and-a-half years, so it’s great to finally see it being merged. Thank you, Murch, for your explanations and also for merging these BIP PRs.

Mark Erhardt: I only reviewed them. The authors wrote them, so kudos to them. Thank you very much for joining us to this newsletter recap. Thank you, Liam, for explaining Argo to us and answering some of our other questions about cryptography and wicked moon math schemes. And thank you, Gustavo, for taking care of the Notable code and documentation changes as usual. We’ll hear you next week.

Gustavo Flores Echaiz: Thank you.

Bitcoin Optech Newsletter #390

2026-01-30T00:00:00+00:00

This week’s newsletter summarizes a more efficient approach to garbled circuits and links to an LN-Symmetry update. Also included are our regular sections with selected questions and answers from the Bitcoin Stack Exchange, announcements of new software releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure software.

News

● Argo: a garbled-circuits scheme with more efficient off-chain computation: Robin Linus posted to Delving Bitcoin about a new paper by Liam Eagen and Ying Tong Lai describing a technique that will enable 1000 times more efficient garbled locks. The new technique uses a MAC (message authentication code) that encodes the wires of a garbled circuit as EC (elliptic curve) points. The MAC is designed to be homomorphic, enabling many operations within the garbled circuit to be represented directly as operations on EC points. The key improvement is that Argo works over arithmetic circuits, in contrast to binary circuits. With an binary circuit, millions of binary gates are needed to represent a curve point multiplication, whereas with this arithmetic circuit, you only need a single arithmetic gate. The current paper is the first of several pieces needed to apply this technique to BitVM-like constructs on Bitcoin.
● LN-Symmetry update: Gregory Sanders posted an update to Delving Bitcoin about his previous work on LN-Symmetry (see Newsletter #284).

Sanders rebased his previous proof-of-concept work on the BOLTs specifications and CLN implementation to the latest updates. The updated implementation now works on Bitcoin Inquisition 29.x on signet with TRUC, ephemeral dust, P2A, and 1p1c package relay. It supports cooperative channel closure, fixes a crash that prevented the node from restarting correctly, and expands test coverage. Sanders asked other developers to test his new proof-of-concept on signet with Bitcoin Inquisition.

Sanders also leveraged LLM capabilities to migrate his work from APO to OP_TEMPLATEHASH+OP_CSFS+IK (see Newsletter #365), modified a BOLT draft and created a CLN-based implementation. However, Sanders added that since OP_TEMPLATEHASH is not yet live on Bitcoin Inquisition, this update can only be tested in regtest.

Selected Q&A from Bitcoin Stack Exchange

● What is stored in dbcache and with what priority? Murch describes the purpose of the dbcache data structure as an in-memory cache for the a subset of entire UTXO set and goes on to detail its behavior.
● Can one do a coinjoin in Shielded CSV? Jonas Nick points out that the Shielded CSV protocol doesn’t support coinjoins currently, but that client-side validation protocols do not inherently preclude such functionality.
● In Bitcoin Core, how to use Tor for broadcasting new transactions only? Vasil Dimov follows up to this older question pointing out that with the new privatebroadcast option (see Newsletter #388), Bitcoin Core can broadcast transactions through short-lived privacy network connections.
● Brassard-Høyer-Tapp (BHT) algorithm and Bitcoin (BIP360) User bca-0353f40e explains that the capability for a collision attack on multisignature addresses using the Brassard-Høyer-Tapp (BHT) quantum algorithm to diminish SHA256 security would not affect addresses created before the capability.
● Why does BitHash alternate sha256 and ripemd160? Sjors Provoost outlines the rationale around BitVM3’s BitHash function, a hash function tailored for Bitcoin’s Script language.

Releases and release candidates

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

● Libsecp256k1 0.7.1 is a maintenance release of this library for Bitcoin-related cryptographic operations which includes a security improvement that increases the number of cases where the library attempts to clear secrets from the stack. It also introduces a new unit test framework and some build system changes.

Notable code and documentation changes

● Bitcoin Core #33822 adds block header support to the libbitcoinkernel API interface (see Newsletter #380). A new btck_BlockHeader type and its associated methods enable creating, copying, and destroying headers, as well as fetching header fields such as hash, previous hash, timestamp, difficulty target, version and nonce. A new btck_chainstate_manager_process_block_header() method validates and processes block headers without requiring the full block, and btck_chainstate_manager_get_best_entry() returns the block tree entry with the most cumulative proof-of-work.
● Bitcoin Core #34269 disallows creating or restoring unnamed wallets when using the createwallet and restorewallet RPCs, as well as the wallet tool’s create and createfromdump commands (see Newsletters #45 and #130). While the GUI already enforced this restriction, the RPCs and underlying functions did not. Wallet migration can still restore unnamed wallets. See Newsletter #387 for a bug related to unnamed wallets.
● Core Lightning #8850 removes several deprecated features: option_anchors_zero_fee_htlc_tx, renamed to option_anchors to reflect changes on anchor outputs, the decodepay RPC (replaced by decode), the tx and txid fields in the close command response (replaced by txs and txids), and estimatefeesv1, the original response format used by the bcli plugin to return fee estimates.
● LDK #4349 adds validation for bech32 padding when parsing BOLT12 offers, as specified in BIP173. Previously, LDK would accept offers with invalid padding, whereas other implementations, such as Lightning-KMP and Eclair, would correctly reject them. A new InvalidPadding error variant is added to the Bolt12ParseError enum.
● Rust Bitcoin #5470 adds validation to the decoder to reject transactions with zero outputs, as valid Bitcoin transactions must have at least one output.
● Rust Bitcoin #5443 adds validation on the decoder to reject transactions where the sum of the output values exceeds MAX_MONEY (21 million bitcoin). This check is related to CVE-2010-5139, a historical vulnerability where an attacker could create transactions with extremely large output values.
● BDK #2037 adds the median_time_past() method to calculate median-time-past (MTP) for CheckPoint structures. MTP, defined in BIP113, is the median timestamp of the previous 11 blocks and is used to validate timelocks. See Newsletter #372 for previous work enabling this.
● BIPs #2076 adds BIP434 which defines a P2P feature message that would allow peers to announce and negotiate support for new features. The idea generalizes BIP339’s mechanism (see Newsletter #87) but instead of requiring a new message type for each feature, BIP434 provides a single, reusable message for announcing and negotiating multiple P2P upgrades. This benefits various proposed P2P use cases, including template sharing. See Newsletter #386 for the mailing list discussion.
● BIPs #1500 adds BIP346 which defines the OP_TXHASH opcode for tapscript that pushes onto the stack a hash digest of specified parts of the spending transaction. This can be used to create covenants and reduce interactivity in multi-party protocols. The opcode generalizes OP_CHECKTEMPLATEVERIFY and, when combined with OP_CHECKSIGFROMSTACK, can emulate SIGHASH_ANYPREVOUT. See Newsletters #185 and #272 for previous discussion.