MuSig2 in Practice, APO, CTV & Bitcoin Soft Forks

Hi, you're listening to Stephan Livera podcast, a show about Bitcoin and Austrian economics brought to you by swan dot com. Have you wondered about MuSig2 and Taproot use in practice? Are you also thinking about some of the soft fork upgrades that are being discussed and proposed for Bitcoin, such as APO, nPreVout, and Check Template Verify (CTV)? Well, today I'm speaking with Brandon Black, who joins me to talk about his experience with implementing MuSig2 in practice, as well as some of his thoughts on APO, CTV, and his particular proposal, which hopefully will help educate the community on what the options are and perhaps- That informs the pathway forward. So for this episode, we do get into some of the more advanced details around Bitcoin scripting and some of the trade-offs and what are some of the ins and outs, but I also think this is useful information, and for those of you interested in the software conversation, just skip forward to about halfway through this episode. Anyway, now on to my chat with Brandon. Brandon, welcome to the show. Great, thanks to be here. Glad to be here. Yeah, so Brandon, I saw, your, well, a couple things. You were recently writing about your experience implementing MuSig2 at BitGo, and of course, your proposal in relation to a kind of combination of APO and CTV. So, you know, let's, let's hear first a little bit about you. I know it sounds like you've been, working in Bitcoin development for a while.

Yeah, thanks. I've, I've been working in Seventeen, that was my first Bitcoin job. Kind of been watching the space since long before that, and it was great to, to finally get into it full time. yeah, I'm basically been working on Bitcoin wallets the whole time. I, I did some work at Casa on their, their wallet in the early days there, and then, spent some time trying to do a Bitcoin hardware device startup that didn't end up panning out, and then spent a couple of years at BitGo.

Fantastic. And so, yeah, so let's get into the experience Understand, at the time of Taproot activation, it was, you know, obviously it was, it was a bit earlier, what was the experience at that time, and how were you, you know, assessing it at that point?

Yeah, yeah, it was, it was a really cool experience, you know, when I, even from when I first got into Bitcoin development, I wanted to bring MuSig to, to a production wallet. So I joined Casa, I guess it was about two years before, or three years even, before, Taproot activation, and I was like, you know, a new Bitcoin developer, super excited, I wanted to do Taproot yesterday. Of course, it was still years before Taproot would even activate. so it was awesome when I got the opportunity to join BitGo, and

With the Taproot activation on mainnet, but we had hoped to make that a MuSig two wallet from the get-go. And, and of course, as I went researching the status of the MuSig two code and the MuSig two specification, you know, reading through the paper, the spec, talking to, Jonas Nick a little bit, I realized that it just wasn't production ready yet. So we launched without MuSig two, while we waited for the spec to be finalized.

And there were multiple iterations there. So as I recall, there was MuSig,

And, and then later, MuSig2. So I guess you were still sort of waiting for things to shake out a little bit there, right?

Yeah, by the time we started coding for Taproot, it was pretty clear that MuSig2 was gonna be the most likely path forward. We did evaluate the other options, you know, at, at Bicco, they're, you know, they're working on or they've deployed, I think, an ECDSA TSS implementation, so Bicco's not afraid of doing the kind of more complicated protocols that Mu

When you said ECDSA, TSS,

that's Threshold Signature Scheme. Yes, correct. Gotcha. Yeah, so that's, you know, pre Schnorr, you were already looking at advanced, you know, versions of doing this right? Right, right. And

Bitcoin has to do that because they support many coins, and not all coins have Schnorr signatures, so they, they need to have a broad range of cryptographic primitives to do, to do their offering on all the chains they offer.

Yeah.

anyway, so we were looking at the different options, but it was No, it wasn't fully specified when we started on Taproot.

Great. and I guess just for people who aren't familiar, what's your actual role with BitGo?

Well, truth be told, I left BitGo about a little under a month ago now. Oh, okay. I was the manager of the Bitcoin team. I started as an engineer and then ended up picking up the management of the team. which was a, a great experience. I, I, BitGo is an awesome company to work for, and I, I have great respect for them,

but I schemes that were available and, you know, why MuSig2, and I, I guess also, there's also that conversation around Frost. So, do you want to just explain for us, you know, why MuSig2 and, you know, how you were thinking about, you know, Frost as well at that point?

Yeah, yeah. the, the shortest answer to that is that MuSig2 is beautifully simple. you know, I talked to, to Jonas Nick about it, I think at Bitcoin Miami '22, and, and we were, we were talking about there's kind of this parallel in the MuSig2 construction, in the way the keys are aggregated and also in the way the nonces are produced. In, in both cases, you're kind of protectin- protecting against a rogue key or a rogue nonce attack, and the protections are similar. And the result is a protocol that's very easy to reason about and very short to implement, as I mentioned in that Optech field report I wrote, you know, the, the reference implementation is only four hundred and sixty-one lines of Python. I've implemented it twice, once in C and once in JavaScript, and in both cases, it's, it's pretty easy to get it correct and to match the spec, and then to have it be auditable against the spec. so that's really the main reason to use MuSig2 over a lot of the other options. then So when can you not use MuSig2? Bitcoin, in this case, is, is in a really good position to use MuSig2 because the way the Bitcoin wallet is constructed, the three keys are described as the Bitcoin key, the user key, and the backup key, and the vast majority, probably over ninety-nine percent of all signings happen on the Bitcoin key and the user key. Moreover, in the Bitcoin wallet construction, when a transaction is initially created, we know which two keys will be signing at transaction creation time. So that makes it easy for us to use MuSig2, which is a n of n multi-sig protocol, because we know which are the most likely keys, so we can put those in the MuSig2, and we know which ones are gonna sign from the construction of the transaction. I talked to, Jameson Lapp at Casa about Casa's situation, whether they could use MuSig2, and in their case, when they start assigning, they don't have a clear answer as to exactly which keys are gonna sign out of a wallet. And so for them, they'd have to start three separate-- I think it's three, more than one separate MuSig session, to try and figure out which keys are eventually gonna sign and get-- collect multiple signatures from each signer. It, it really complicates the process for some wallets, To, where let's say Casa might need to use Frost or might need to use on-chain multisig because they don't have the same clear answers to those questions when they start signing.

I see, because here we're talking about the different combinations, right? We're talking about how many keys there are and which combinations would be signing in that scenario. So just so I'm clear then, are we talking-- So you mentioned the Bitcoin key, the user key, and a backup key, and, one part I'm maybe a little bit unclear on is my understanding, it's an N of I'm confused then about the backup key, or is it actually more like a two of two setup of, of any of those three?

Yeah, great question. The, if you think about on-chain multisig, if you have a two of three on-chain multisig, that means any two of those three keys can sign. You can construct that by, in a small multisig, it's easy. You can say, "If I have a two-of-three multisig, there are three pairs of two keys which could sign this transaction." And because of the beauty, the wonder of TapScript and Taproot, you can say, "I put..." You could do it with, as we did in the original Bitcoin implementation, three separate two-of-two paths.

Yeah.

And that gets the same exact security function as a two of three on-chain multisig.

Then if we use

MuSig, we put the most common signing two of two as the key path and the less common two of twos as script paths and get the same security behavior as a two of three on-chain multisig, but without having to dis-dis-display all three keys on-chain.

I see. Yeah. And so this is relying on that idea of key paths and script paths spending. And so the key path spend is the one that's the most Most arguably, you know, that's the one you want to do most of the time, and then if you need to use those other pathways, that's where you actually are showing the script that you want to, sign against, right? Is that, is that right?

Yeah, exactly. And, and with Bitcoin, again, it's, it's two of three, you always know exactly which two keys have signed, right? If you sign the, the key path, you know exactly it's the Bitcoin user key. If you sign one of the, the key, one of the script paths Ambiguity in the Bitcoin construction. Obviously, with more complex constructions, you could have ambiguity in what's actually available in the script path.

Yeah. and, it is interesting as well that you, you know, there's more talk now about the use, actual use of Taproot, because I think that was a line that, maybe sometimes shitcoiners or maybe detractors of Bitcoin will sometimes come out and say, "Oh, look, see, you're not even using Taproot yet," and yet, you know, here we are, MuSig2 is, And LND, so it, it seems like it, it takes some time for the development work, but it is happening, in fairness.

Absolutely. But one of my biggest lessons in my, in my years as a Bitcoin developer has been patience. Like I said, I wanted to do Taproot from twenty seventeen, and of course, you can't, you have to be patient. I wanted to do MuSig when we started working on Taproot in, in twenty twenty. You have to be patient, it's just the way of these things. So, yeah, people are like, "Oh While all of us throughout the ecosystem are working on developing the code and, and, and, you know, getting it audited, making sure that we've got things close enough to right, you know, we're not gonna be perfect, but we, we kinda have to find this balance of spending enough time vetting it to get it right.

Got it. Okay. And so while we're here, do you mind spelling out some of the benefits? Like, what are the benefits that you see for a developer or for a Bitcoin business to use MuSig2?

So the single biggest benefit is a reduction in on-chain fees. if I recall correctly, it's forty-three and a half percent cheaper to use, Taproot key path than a native SegWit two of three script. so this lets you use a multisig construction like the BitGo wallet with no additional on-chain cost relative to a plain, pay-to-witness pubkey hash address. I mean, it's, it's-- there's a slight cost, but it's, it's marginal as opposed to being a significant cost to use Use multisig before Taproot and MuSig. there's also somewhat of a privacy benefit, especially in a case like the BitGo wallet, where on the BitGo wallet, again, ninety-nine plus percent of all signings happen on that key path, and as far as the BitGo, sorry, the Bitcoin blockchain is concerned, those key path spends look exactly like any single-sig wallet. Traditionally, everyone could identify transactions from the BitGo wallet because BitGo was most of the two-of-three traffic on the network, but now, that BitGo traffic can start shifting over to Something that looks just like a one of one.

I see. And so hopefully the, I guess the, the, the goal in this case is if lots of people are all using Taproot and it looks like Taproot single signature spends, everyone looks the same, and so there's a bit more of an anonymity set to hide in, in that particular perspective. Now, typically there's still, there may still be other methods of tracking, for example, the transaction graph, but at least from the script type heuristic, it's looking the same, correct?

Yeah, exactly. I mean, yeah, but the Heuristic is obviously still out there, although hopefully as, as Dan Gold and others work on payjoin stuff, we'll start to break that common input heuristic as well and, and gain some on-chain privacy.

Yeah. Okay. So then summarizing the key benefits, as you said in your, blog post for Bitcoin Optech, it looks like a native SegWit input is a hundred and four point five vbytes and a MuSig key path input is fifty-seven point five vbytes. So, yeah, like you said, it's like about forty percent saving. And so just to Because I guess it depends how often you are spending out of that wallet, right? So if you're, you know, if we're thinking about a user who just does a transaction once a year, they might be like, "Who cares? Like, it's forty bytes." But in the case of production-grade large wallets, that would be a meaningful saving because, you know, if you're a BitGo and you're being, let's say, a custodian for people, or maybe you are the intern, the custodian for exchanges and brokers out there, they may be doing a lot of transactions, Is that, have I got it right there?

Yeah, you've got it exactly right. The, the, one of BitGo's main customer groups is, exchanges that BitGo cosigns for, and those customers do tons and tons and tons of transactions, and they also just have a lot of small UTXOs. You know, they get small deposits from users, trading on their platform, and they need to consolidate those, and, and those consolidation fees can eat significantly into their, into their revenues. so it really does matter to them that we get these, these fees Makes Bitcoin more efficient. We can get more transactions into blocks this way, which some people think is a bad thing, but that's a separate topic.

Yeah. Okay. and so, yeah, so the main benefit being small size transactions, and the point is it's not trivial, like it actually is quite a meaningful saving, and so can you tell us a little bit, of your views on the choice of scripts that you, you know, you went with there?

Yeah, it-- I mean, we talked a bit about this with the comparison between Bitcoin and, and Casa in, in using MuSig2. you know, there's, there's a huge design space in Taproot scripts, and it's, it's non-trivial, let's say, to pick which scripts. Like for the Bitcoin case, with this MuSig2, address type, we could have used, two of two MuSig key path and then a single script path with a OpCheckSig add-style multisig In the TapScript, we could have done what we ended up doing with two, two of two, just plain OpCheckSig script paths, or we could have put all three two of two options also in the script in case there's a break in MuSig two and we're not able to sign, with that key path anymore. So, so you really have to consider in, in picking scripts to use with TapScript, what your specific wallet's needs are and what types of wallets you're gonna be using this with. If I was designing a, a, a wallet for, for hard It's a different style of script than I was designing a wallet for BitGo to use with a, you know, production exchange hot wallet. and maybe even a, the same exchange customer of BitGo might use different address type, they might use the, the previous three script style taproot address for their cold wallet, but their hot wallet, they might use the MuSig2 and two scripts address type. so there's just a lot of design space there in, in the tapscript world, and unlike with kind of If the previous SegWit or legacy addresses on, on Bitcoin, it's hard to come up with a, a set of obvious best practices. Each wallet designer in, in the Taproot world has to evaluate their own specific needs before they can pick what scripts to use.

I say, yeah, that makes sense. So I guess the key, elements there are how much of your script you're exposing, what is the size of the script, these are the considerations that come into it, right?

Yeah, the size of the script you're exposing, and then, and then how much fallback you need. Like, what's, what, how much money are you risking, let's say if there's a break in MuSig two and we can't sign with MuSig two, how costly is it gonna be to use those backup key paths, and is that an acceptable trade-off that we can't sign with that most common or that easiest or that, that cheapest signature type?

so yeah, there's, there's that,

and then there's also, as you said, yeah, exposing Bitcoin Twitter may have seen some of the drama, you know, the big fight, the beef between, Rob Hamilton and, Rhyn Dale on, MPC Gang versus, the Script Boys. I'm curious if you have any thoughts on the, that, that great debate that's happening, the MPC Gang versus Script Gang.

Oh, it's so good. It's so much fun. I, I, I think the, the, the humor they put into it, they're, they're both great, you know, X posters, whatever we call these days, and I've really just enjoyed the, the points that they make because what they've ended up doing is in a, in a humorous way. Exposing a lot of the trade-offs, the benefits, the, the downsides of each of these things. You know, we see that MPC protocols, really with the exception of MuSig2, tend to get expensive and a little bit harder to reason about, and we see that, you know, scripts are large on chain and, and-- but we see that, you know, scripts are expressive and they can show what you're doing. So, it's just great, it's wonderful fun.

Yeah. Okay, so then I guess, from in terms of what Doing, you would put MuSig2 in a, let's say, a slightly different category to the more complex style MPC like Frost, and then even then, there's another big jump from there to what we're seeing, you know, as I'm sure you would have seen. I think there was a recent, exploit or something, someone correct me if I'm wrong, but I believe there was an exploit at, Fireblocks with MPC, but it was not related to, it was not like a MuSig2 or a Frost MPC, right?

Yeah, exactly right. There's, There's Frost and then there's other MPC, and they're, they are each different. so for, for to kind of compare them, the Frost signing protocol is round optimized, it's pretty minimal, similar to MuSig2. the cryptography is a bit more complex, but it doesn't have major online requirements where there's, you know, many rounds going back and forth in it. But the distributed key generation in Frost is still pretty involved. and then MuSig2, both the key generation And the signing are kind of, can be done pretty easily offline. anyone who has the public keys can make a MuSig aggregate key without talking to the others public, the other owners.

Right. It's like a non-intrusive setup. It's like a beautiful thing about MuSig. You can do.

Yeah. and, and, and then, then there's, on the far side of that, there's the ECDSA TSS, wherein both the key generation and the signing require this significant online interaction with a lot of commitments going back and forth to protect the protocol as Which opens up potential, not necessarily actual, but potential vulnerability space.

Okay. Yeah. Interesting. And so, just to make sure everyone's following along there, do you mind just sort of spelling out at a high level like MPC versus script, like what, what are they, just to make sure everyone can follow along?

Yeah, yeah. So in general, MPC is a broad category of ways for multiple people to collaborate on creating a single cryptographic result that'll be seen On chain, typically a digital signature. and so this, you know, MuSig2 falls into that category, as does Frost, as does ECDSA-TSS. They're all ways for a group of people to collaborate creating a single signature. and then script, of course, is Bitcoin script where the execution path for spending some Bitcoin is visible on chain and there's some satisfaction that's provided that usually contains a digital signature, but may also contain other information like what path to take through that path on the script.

Back to the show in a moment. The lead sponsor of Stephan Livera podcast is Swann dot com, and Swann is organizing a festival for Bitcoin, Pacific Bitcoin Festival, is coming October fifth and sixth in LA, California. This is going to be an amazing experience with so many awesome speakers ranging from people like Max Keiser and Stacey Herbert, Vijay Boheti, Preston Pish, Greg Foss, Corey Klipstein, Lynn Alden, Jimmy Song, and so many more. There's going to be a main stage for dedicated talks, panels, and fireside chats, and this is all Be Bitcoin only stuff, by the way. There will also be a Swan Dome where there will be deep dive sessions, as well as other events and things going on through that week. So make sure you book your tickets and check your calendar days and all of that. And of course, there is a VIP ticket where those VIPs will get preferred seating and viewing areas for the main stage, they'll have a private lounge for networking and connection, there'll be an open bar for access by the VIPs, as well as complimentary lunch. So check out the tickets over at PacificBitcoin dot com. Use code LIVERA for a discount there. mempool.space is the leading Bitcoin and blockchain visualizer out there. I use it all the time when I'm about to send a Bitcoin transaction because it helps me target my fee, whether I'm looking for a low, medium, or high priority transaction fee. It's just a really handy way to target the fee and set it appropriately. Mempool.space allows you to view Bitcoin transactions, you can view Bitcoin, Bitcoin blocks, you can scroll the mempool blocks, they have a range of other features that relate to things like the Lightning Network and mempool.space Space is free and open source software, so you can run it yourself. So keep an eye out for some upcoming features, the team is always working on new features. I'm looking forward to the Mempool Accelerator program, which is coming soon. Go and check it all out at mempool dot space. Back to the show. Okay, yeah, gotcha. And so where, let's say, you know, Team, you know, Miniscript or Miniscript Gang or whatever they're calling themselves, Rob and his gang, can-- like, I guess what they're getting at with the idea of Miniscript is this idea that you can have more complicated pathways and it's easier for people to collaborate and reason about those complicated pathways and have, like, some kind of, you know, backout pathway five years from now or ten years from now as, like, a get out of jail free or, you know Side, as you're mentioning, is it shows more on chain, literally, it's showing on chain what are the public keys, and it's a bigger cost in terms of transaction size, but you get some benefits there, right?

Yeah, yeah, absolutely. And one thing to point out is that I'm a huge fan of Taproot, and Taproot helps to limit the downsides of script because if you use Taproot, you can have each of your separate script paths that would otherwise all show up on chain hidden, except for the one that you choose. So let's say you have some secret backup path that is just a single sig that you gave to your mother. unless you tell people about that, you can be using your Taproot wallet with, let's say, a really secure three of five all the time, and no one will ever know that that secret single sig is there unless you tell them. And that's really a beautiful thing about Taproot is, is that when you design a Taproot wallet, you can have many different paths that let you have a recoverable wallet, and still use it in a secure- way day to day, or, or sorry, a more secure way, let's say. and the great thing about MPC versus scripts is that you can combine these things, as we did at BitGo, right? We've got a MPC-based key path and then scripts as backups. and that's really, I think, what the future of Bitcoin on Taproot is gonna look like. wallets will have, whether it be a MuSig or a Frost key path and then some complex set of recoverable scripts down below that, so that the wallet gets really the best of both

Great explanation. I think, it helped, helped me understand a little bit better as well. So would you say, you know, that explanation you just gave, would you say that's applicable for large custodian companies like BitGo, but not as relevant for everyday plebs or small businesses? Or do, do you see that as like maybe five, ten years down the line, most people will use some kind of setup like that where they have MPC for the, you know, the key path and some kind of miniscript, enabled technology for their script path spending?

It's hard to predict the future, of course. I think those who use on-chain, which over time on Bitcoin will trend towards being somewhat bigger holders, will end up using, some kind of, yeah, MPC key path plus script recovery paths. it's what many people are kind of working towards if you look at the, Oh, I've lost the name of it. The wallet that, the Wizard Sardine folks are working on. Oh, Liana. you know, they're kind of-- Yeah, Liana, yeah, they're going in that direction. you look at, BitGo, you know, it's kind of heading that direction. Everyone is really looking in that direction of MPC plus script as the way to hold Bitcoin. and, and even the, the OpVault proposal that's out there from, James,

James Obrien. James Ob All of the keys involved, but then there's also this, this vault structure, hidden under there. So, so yeah, I think that's really where holders of on-chain Bitcoin are gonna go, would be my suspicion.

Right. And then when you think about Lightning, of course, it makes sense for them to use, more of an MPC pathway for most of their, you know, for example, Lightning doing Taproot channels, right? Like that would make more sense for them too, right?

Yeah, absolutely. And if you look at Lightning or other kind of proposed Layer

To keep their on-chain footprint as small as possible and their-- and again, to maintain the privacy, as we already talked about for using Taproot key path, you, you kind of blend in as long as you don't have to use the backup paths.

Okay. So when it comes to using MuSig2 down to brass tacks, in terms of the nonce generation, so one part that you spell out in your article is around, nonce generation and having to be more careful around that, as well as the multiple rounds of interaction required with the hardware security module. So can you just explain a little bit of that and elaborate on that process for us?

Yeah. Unlike script multisig, where the signing, each party can just sign and then share their Signature. with MuSig2, the parties do have to collaborate to make the signature, and as a result, if you're using some kind of hard-to-access key, you're gonna have to make two trips to it in the typical case. the, the specification allows for nonce is to be pre-generated to kind of elide that extra trip to the key, but it's difficult to do that correctly because nonce storage is a big challenge for MuSig implementations. so in general, the, the high-level thing to- To mention here is that a reuse of a secret nonce in any of these signing protocols, ECDSA, Schnorr, MuSig, etcetera, reusing the nonce, the secret nonce, leaks your secret key. Like this is a fact. Jo-Jonas, you know, showed me the math on it at one point, I was like, "Oh yeah, it really is just that simple. You basically do some subtraction and you get the secret key if the nonce is reused." So in single signature protocols, this is easy to solve. You use a deterministic nonce that depends on the message being signed and the secret key and a few other bits of data, and that nonce will never be reused with a-- in a, in a way that would leak the secret key. The, the key thing here is that the, the nonce must never be reused and generate a different signature. The resulting signature bytes must be identical if the non-- if the same nonce is used, and that is true with the deterministic nonces, in ECDSA, single sig or... No single sig or, or basically anything. with these multi-signature protocols, now you have to have, multiple parties collaborating to produce the nonce, and so they can't use a single deterministic nonce because the other party could then make their nonce change and get a different signature from the party that used the deterministic nonce. In the MuSig spec, they didn't make one carve out for that, which is the last party to produce nonce and the, and to sign can use a deterministic nonce. And why is that? Because they have all of the data that's gonna go into the signature, and so they can be absolutely certain they will only use the same nonce if the exact same signature bytes will be produced, because they've already got the nonce from the other parties. Now, this is all kind of hard to reason about, which gets to the point of nonces are difficult, and they aren't Especially difficult in multi-signature protocols. so signers that can't use a deterministic nonce have to be extremely careful that when they generate a secret nonce, they have to hold onto it across the-- until the second round of the protocol, and then as soon as they get the second round, they have to make sure they get rid of that secret nonce because it, it becomes toxic. If they were to use it again, it would leak their secret key. And that's kind of the summary of, of nonces and how multi-signatures make them more difficult to get right.

Right, I see From conversations I've been looking at in terms of frost, there were conversations about pre-computing some of these and having them stored with the different hardware wallets and hardware devices and things like this. Did you look at anything like that or is it more, you know, in the case of, you know, this setup, it's more like you're just doing it per transaction?

Yeah, for the, for the Bitcoin solution, we use the deterministic generation on the hardware security module, because we always-- the hardware security module is coded to sign second in each of the- The two, these are the ways it's used. and then the client key, the user key, signs with the random nonce and it is per transaction generated, signs, thrown away. I should say generated, read from storage, thrown away, and then signs. We're, we're very careful to make sure that, that nonce is thrown away as soon as possible to avoid reuse.

I see. Yeah. So there's lots of, you know, bits and pieces to make it, to do it correctly, but, at the same time, there are benefits, as So, yeah, let's see, if more other, you know, if more and more custodians and more and more Bitcoin users start, start to use, start to use this.

Yeah, I'm optimistic. I think it's a, it's a really great protocol for Bitcoin. It kind of keeps the Bitcoin ethos of, of keeping it simple, keeping it easy to reason about, et cetera.

Okay, great. so let's get into this proposal that you've put up, which relates to some of the soft fork discussion around checkpoint verify AnyProveOut and, TXHash and CheckSig from Stack. So, do you wanna just give us a bit of an overview, like why did you-- why did you do this, combination proposal?

Why did I do this? That's a great question. in many ways, it comes down to education. I've noticed in talking with many folks about CheckTemplateVerify and about AnyProveOut, that there is kind of a lack of clear understanding, in the community about these protocol-- these proposals, I should say. and it, it- Kind of to a comical degree, the, the folks who really want CTV don't understand APO, and the folks who really want APO don't understand CTV, and many folks understand neither. And, and so, so part of what I, I, I wrote this proposal for is to show there's a lot of common ground in these proposals. They, they do a lot of the same, they offer a lot of the same things. They're, they're looking at it from different angles, but they're not actually that different. And so by putting them in, in one proposal, I'm hoping to, to kind of move the conversation forward on, on what we think the right types of, call it template hashes we want to allow in this hopefully next soft fork for Bitcoin. I, I think that this is the right direction to be going, allowing kind of commitments that don't s- fully commit to what's being spent, but commit to how it's being spent, which is basically what both any prevout and check template verify allow, is the right direction for Bitcoin to go. And that- And it comes down to the details of exactly in which way we do that.

Okay. So, for, for listeners who maybe aren't familiar, maybe it would be great to hear from your perspective, if you could just talk through, like, from your perspective, what's CTV and what's your, you know, and from your perspective, what's APO, and then we can sort of go into your proposal.

Sure. So CTV or Check Template Verify is, tries to maximally constrain a spending Bitcoin transaction without constraining what input is being spent into that transaction. And the reason it does that is essentially to, avoid, infinite hash loop where you have to know the hash of the input in order to know the hash of the Check Template Verify, and then you need to know, and you loop all forever to, to get the correct hash. And so checktemla verify, I, I actually in, in writing my proposal realized I think there's kind of a, a glitch in it when using Tapscript, but that's a separate topic. The, the point is though, it, it maximally constrains the way it is spent without constraining what is being spent.

Okay. So, and so it

exactly specifies the outputs that are gonna be created, and it specifies the amounts of those outputs, specifies how many inputs are gonna go into the transaction, you know, really constrains things quite significantly on what's going to be

Okay. Yeah. So it, it gets a bit complicated, right? Because I think, people might be used to things that already exist today. So, you know, multisig, obviously, we've been talking about that exists today, and time-related things like check sequence verify or CLTV, that, you know, but they relate to being able to spend an output, whereas in this case, we're talking about- How you can, I guess the, the idea is that we're gonna use, you know, the, the, the, the proposal of CTV and the idea of CTV is that you can use it for things like vaults without having to precompute, hashes, as I understand, and, and that there might be other uses like non-interactive lightning channels or maybe it, it's gonna be used as part of coin pools and payment pools and things like this. would you say that's a fair summary?

Yeah, yeah, because the, the CTV hash commits to what outputs will be created, and once you get an output on chain that commits to a CTV hash, if it's a plain CTV where there's no other kind of side spending hatches, the plain CTV is going to exactly guarantee that the only way some coin can be spent is to create a specific set of outputs And so it's as good as being paid, right? So if I, if someone like, let's say an exchange creates, CTV output that commits to paying me and, and they can show that there's no other escape hatch in that, I, I can accept that I've been paid, even though my output doesn't exist in the UTXO set, because it exists in a CTV, I have been paid. There's no other way for that coin to be spent. And that's really what a lot of the CTV use cases revolve around that idea that, that a Virtually creates some UTXOs that can be then really created later when you need them, but they're not actually created when the CTV is created.

Right. And as I understand, that could be useful in context where maybe the fees are really high right now and the exchange needs to do a quick, like a lot of users wanna withdraw all at once, and so long as those users, users have opted into a CTV context, they could sort of not receive the output right now, but be provably sure that they will get it. Is that a fair?

Yeah, yeah, that's one of the use cases. You know, Jeremy Rubin called that the, the congestion control use case. but then there's also like the, the Baroque arc proposal. I know you've talked to him as well. In there, there, there is an escape hatch, but it's a time-delayed escape hatch. So, the arc pool creates a CTV output that commits to everyone's UTXOs, but four weeks later, the arc pool can reclaim that. So during those four weeks, you've got a virtual output that you could escape on-chain with but the idea is that you stay in the arc pool and you spend that by, by basically paying it back to the pool in the meantime. So there's different ways you can use these commitments to creating an output, whether they be kind of permanent, like in an exchange congestion control, or whether they be temporary, like in an arc pool, but it's a very powerful ability to, to create a commitment to create an output.

Yeah. And I guess maybe some users at this point or listeners are anticipating this or maybe the objection from their perspective is, "Wait, why do I wanna even Use all this at all, like I just want some- I just want the exchange to just pay me out now. but I guess the way I'm understanding it is, well, that might be possible, the exchange could just pay you out now, but that might be a much higher fee, and in a high fee environment when it's congested, if you're, if more people are willing to opt into a CTV environment, let's say, then this enables certain things, and in the case of Ark, it enables a, another whole layer two that could be useful for people. So is

Yeah, no, I, I agree. The general thought that I, I focus my Bitcoin work on is, is around how do we get more people to be able to effectively use Bitcoin? You know, whether it be on chain through Lightning, through some future thing like ARC and, and CTV, by allowing these kinds of commitments to UTXOs is clearly going to let at least some more people use Bitcoin effectively than we can right now. Now, do we need that right now? Not really, 'cause fees have been relatively low, even despite the ordinal spike. They never got Not as high as they did back in the day. So, so people have asked, "Well, why now?" and I think it's, you know, we have to build for the future. I've been in Bitcoin long enough now, as I mentioned earlier, to know that things take a long time to build. So if we're gonna have these next round of, of, call it scaling technologies available when we need them, we really have to be building them now.

Okay, gotcha. Okay, so that's CTV. Can you now give us your, you know,

Comparing it, I think is the best way. So now that we've talked about CTV a bit, let's, let's compare APO. what APO enables is unlike CTV, it doesn't deliberately try to maximally constrain the outputs, because APO is compatible with SegWit single, where it only commits to one of the outputs of a transaction. And now in some cases, that's a very powerful ability. the other thing that APO does is it allows some constraints on the input side as well. There's two modes of APO, there's, any prove out and any prove out any script in the Any prevout only mode, it still commits to the input script being spent, so the, the, the output script pub key that is being spent is still committed to, even though not the transaction being spent. and that lets-- that can be useful in certain kinds of contracts that CTV couldn't satisfy because CTV doesn't commit to the inputs at all. so, so where CTV can spend anything that sat-- CTV can spend anything that to the outputs specified, potentially APO can only spend things that also have the correct input script.

I see. And so my understanding there is that the way, you know, Christian Decker and maybe AJ and whoever else is involved- involved were thinking about trying to minimize the footguns involved so that the wallet developers would, you know, not shoot themselves in the foot, and so that it's kind of like you're only opting into this environment, and it's, it's specifically, you know, in the case of L2 or nowadays, I think people are calling it LN symmetry, that was, that was the reasoning, right?

Yeah, a lot of things went into the design of APO, and what you're talking about there is that they, they decided from an abundance of caution to use a new tap script key So that existing scripts that are already out there couldn't be signed using SigHash and E-PrevOut. An important kind of point of clarification on, on this is that because the signer selects the SigHash mode when they sign for a transaction, that was kind of the foot gun they were worried about is, what if a wallet signer Signed an existing script once using any prevout, well now all outputs to that same script are spendable immediately because they've signed with any prevout. And they-- so, so if you think about, you've got a wallet, you've got a bunch of addresses, and the address, each address might have a bunch of UTXOs associated with it. If you sign one of those UTXOs with any prevout, all of the UTXOs on the same address can be spent in the same way, yeah, because you don't specify which UTXO you're spending when you sign with any Key version in specifying any provout, because it prevents that specific footgun of, of some existing script being signed that way.

Back to the show in a moment. Are you looking to learn to build with Bitcoin? If you're interested in the topics covered in this episode, I think you'll really be interested in some of the classes that are offered by Base fifty-eight. Base fifty-eight is a Bitcoin protocol school. This is the place to get guidance in your Bitcoin developer education. Of course, you could do it hard mode on your own, but with Base fifty-eight, you get guided pathways. There are online Well as in person intensive classes where you can learn in a guided pathway from Bitcoin and Lightning experts. So they have a Taproot intensive in person class coming up soon. This will cover using Taproot, Tapscript, Schnorr, Frost, and MuSig2. This in person Taproot intensive class is coming up just prior to TapCon in Atlanta from the fourth to the sixth of September, and this class is on again in Austin, Texas, the thirteenth to the fifteenth of November. So if you are interested and you wanna build your skills, or maybe you are a beginner And you wanna get started with Bitcoin development, there's something for everybody here. Go to base fifty eight dot info or see the link in description. When it comes to securing your coins, coinkite dot com is the place to go to get the hardware gear that you need to secure your coins. The Coldcard Mark IV is an ultra secure device and it works at all ranges of Bitcoin levels. If you are a beginner, you can just buy this device and buy a USB-C cable to plug it into your computer and use it easily with wallets such as Specter Desktop or Sparrow or Electrum. Ectrum or even Nunchok, and if you're intermediate or advanced, you can use all kinds of advanced features, whether that is using a passphrase, whether that is using it in airgapped mode, or whether you wanna use multi-signature. The Coldcard is such a reliable device, and it works in all kinds of configurations, and the way you set it up is basically you plug it in, either to the wall or into your computer if you're a beginner, and you can write down and create a pre-pin and a post-pin. You'll have two anti-phishing code words, and Generate a wallet where you write down twelve or twenty-four words, and then you can move that information back and forth with the client, such as Sparrow or Specter or something else, and use that to sign transactions. So go to CoinKite dot com and use code Livera for a discount on your cold cards. Back to the show. Okay, gotcha. and so the main use people talk about with APO generally is this idea of LN symmetry, but as I understand from listening to some Christian Decker talks, I think he's mentioned that there are ways that you could- Sort of hack things around and you could use APO for a lot of the similar things that people talk about for CTV, maybe one or two use cases aren't possible, but it's kind of a more hacky method, maybe a more costly on-chain method, right?

Yeah, that's, that's exactly right. You can get a lot of the CTV behavior by using any prevout, any script with sig hash all. That's a similar commitment to the CTV hash. the one thing it doesn't do that CTV does is it doesn't sufficiently constrain the, the way the transaction is spent to be able to predict transaction IDs at the next level. So some of the things that, you know, Jeremy Woo wrote about when he was talking about CTV a couple years ago were kind of trees of CTVs.

Yeah.

And in some of those cases, you need to be able to predict transaction IDs based on what transaction ID is input, and APO doesn't constrain sufficiently to predict future transaction IDs. the other thing, as you said, yeah, there's a higher cost to using APO in that way because with CTV, you put a thirty-two byte hash on chain and then you check it against the transaction that's spending it. If you wanna use APO in this way, you have to put a pub key thirty-three bytes and a sixty-five byte sign Signature all on chain to get the same result as just a thirty-two byte hash would have given you with CTV.

Okay, gotcha. and so then, let's talk a little bit about, I, I understand you had, I guess th-those were some of your critiques of APO. I mentioned, I think I saw, on, some of your online discussion you were critiquing APO, and then you had like a modification, or I think you made a pull request to a particular part of APO, and then now you've come

Yeah, yeah. So yeah, so that's some of my, some of my kind of issues, if you will, with, with APO. You know, it, it's like it accidentally creates a covenant, kind of like CTV, but because it's accidental, it's not very good. And I'd, I'd rather see if we're going to have covenants created, that we do it in a deliberate and conscious way. so then I was like, I, I looked and I, and I created my original pull request against the APO BIP, which allows it to be used and, and I think, I haven't verified this fully, but I think fully emulate CTV, by separating out some of the flags involved. the, the any pre-vout implies anyone can pay, if that means anything to, to the listeners. and my pull request makes it not imply anyone can pay, it lets you specify anyone can pay separately, and that, that lets it then more- Or fully emulate CTV, it's still much more bytes on chain, but at least now it's a deliberate, conscious, we're doing any prevout which enable the type of covenants. Let's make sure that we're making those covenants useful and, and kind of go forward with that would be the idea there. and then kind of continuing to, to research this over the, the months, realizing that I think it might be better, as Russell O'Connor had posted previously to the mailing list, to do covenants using some form of TX hash and checksum signature from Stack,

And check template verify.

Okay. So do you mind just spelling out for us, you know, what's TX hash and what's check sig from stack?

Yeah. So TX hash is a very, very broad idea, and, and my proposal deliberately constrains it, but in general, TX hash would be a, a Bitcoin script opcode that hashes some portions of the transaction currently being validated and puts them on the stack for later use in a script. The general pro- Proposal that, that Russell O'Connor originally made had a, had kind of had a bunch of flags where you'd be like, "I wanna hash the inputs, I wanna hash this input, I wanna hash this, I wanna hash that," and you kind of pick with a bunch of flags which things you want to hash into the, into the hash that goes on, onto the script stack. and then the later script components can validate that hash in whatever way they want. They can validate it with a signature, or they can validate it with a comparison, just a quality check. The proposal I made was

Use cases for CheckTemplateVerify and anyPreOut. So let's make a version of TX hash that only does the things we have concrete use cases for and specify those in a kind of a compact sort of way so that we're not, for lack of a better word, wasting on-chain bytes in using this. so that's the, the TX hash side, a very constrained TX hash that's just the same hashes that would be used in any prevout or CTV, but where you have one opcode that can create the hashes for either of those other proposals And then CheckSig from Stack is comparing it to the existing CheckSig operations in Bitcoin script. CheckSig hashes the transaction based on the signature's specified hash mode and then verifies the signature against that hash, but that hash never appears in the script. Stack, it's just inside the CheckSig function. CheckSigFromStack takes the hash to check the signature against from the existing script stack or script arguments. And so now we can hopefully start to see where these two things come together. If you use OP_TXHASH to create a hash and it goes on the stack, and then you have OP_CheckSigFromStack that can read that hash and check a signature against it, you can put those two things together to, to check different hashes than you can using, regular OP_CheckSigs.

Okay. I think I'm following. I'm- I'm still kind of, you're obviously this is above my level, but, let me just ask another question, based on what I've read, I've heard of a term known as transaction introspection. Is this related to that?

Yes. so transaction introspection, as is available on the Liquid network, is being able to take specific pieces of the transaction and put them onto the stack for use in a script. So the, one of the common ideas would be, I wanna get the input amounts and put them on the stack so that I can do math on them and check how much is being spent. So you could do like a velocity or, or a spend amount policy where transactions or coins locked to this script can only be spent A maximum of one Bitcoin at a time, let's say, because you could introspect on the transaction and see how much is being spent as part of your script verification. TX hash is a much more limited version of that because it doesn't put the actual amounts or anything on chain, it only puts a hash of the contents of the transaction on chain. There have been concerns about kind of the, the execution speeds and the, the risks of certain types of recursion that could be written and stuff if we do full transaction introspection. And, and so that's why I think at this moment in Bitcoin's history, the approach is, is to constrain things using a very specific hash that goes on chain and not to do full introspection where you put the values out of the transaction on chain.

Okay. Yeah. I think, I think it's sort of started to click a little bit for me. So I guess as you've explained, right? We've explained, you know, what your view of CTV is, what your view of APO is, and now what you're trying to do with this approach, which I guess you can sort of say it's trying to, let's say, thread the needle to allow only what we want without opening other doors, let's say. And so the idea is this proposal, is there to sort of show this is what threading the needle might look like. Is that sort of what you're getting at?

Yeah, yeah, it, it's a combination of threading the needle and maybe, you know, it's hard in the Bitcoin space right now trying to coalition build. There's the, you know, there's APO camp and there's CTV camp, and like I said, they don't really seem to fully understand each other, and so I'm really hoping that by putting together a single proposal that does both, again, with a table in it that shows exactly what data is hashed in each of the modes That, that we can at least start talking about how these things are, are very similar and what specific items from each we want to get into a, into a change to Bitcoin.

I see. And so in terms of what these things are, what these things are being enabled, so as an example, the APO camp wants LN symmetry or other potential, you know, upgrades with the Lightning Network, and so your proposal enables that.

Yep. Yep. And then the CTV camp wants OpVault, and they want potentially- And they want congestion control and a bunch of other things that I don't fully understand. There's the, the, the guy who posts about the Enigma Network, which is very hard to talk about.

Yeah.

Yeah.

Yeah, 'cause he's talking about like transaction cut through and it's very complicated, so yeah.

Yeah, yeah, and I, and I think some of his ideas are probably realizable in practice, but probably not all of them, and it's very hard to separate those two things out. But yeah, that's, that's, that's right. Because this proposal allows each We can get those both and do it in a way where we, we talked about those APO covenants that, that have to be large on chain with a sixty-five byte signature and a thirty-three byte key. With this proposal, those same exact covenants are possible, no additional covenants, the same ones, but they're only thirty-three bytes instead of sixty-five plus thirty-three. And so that's, like, if, if we're gonna enable those things, let's not make it wasteful to do it. Let's do it in a way that, that is compact and efficient

In favor of this method of, of doing APO and CTV.

Okay. Yeah. Sorry, I think it sort of cut out for a little bit there, so I didn't quite catch all of that, but you were saying, you were talking about the fee, sorry, the size of the transaction and, could you just spell out in your proposal and contrast that against, you know, CTV and APO in terms of how large the transactions would be?

Yeah. So with plain APO to do covenants, you have to have a thirty-three byte key and a sixty Same APO covenants, but with just a thirty-two byte hash on a, on an opcode on chain. And so that's kind of the efficiency. If we're going to allow these kinds of covenants, let's do it efficiently and nicely.

I see. And then your proposal as compared to just bare CTV, how, how does that stack up?

So this is the downside of, of my proposal, because my proposal uses op success style upgrade, details not important, it only works in Tapscript, whereas the CTV proposal as written allows CTV in legacy On-chain in SegWit and in TapScript, and the result is that for the use case of a what's called bare CTV, where the, the locking script of the transaction is exactly equal to the, the, hash it's going to be spent in and the one op code, this is significantly larger. I think it's, seventeen vbytes or something. It's quite a bit larger on-chain than bare CTV. So that's probably the single biggest downside of my proposal relative to the others, as others have said on- On X and elsewhere, there's nothing against doing what I've written here and CTV itself. I'm, like, again, I'm, I'm really mostly trying to, to educate and, and to bring awareness to the similarities here and maybe the right thing to do is actually to implement my proposal and CTV or my proposal and APO or APO and CTV. I don't know what the right path is here, but I think we should at least be able to be clear-minded in talking about it.

I see, okay, yeah, because that also seems to be, you know People talking about the idea of just having, you know, let's just have CTV and APO. do you have any objections to that or do you think that that would be unnecessarily, Costly or in some other, have some other downside.

I am totally fine with CTV and APO. I think that APO is-- has been developed to be extremely specific to kind of the LN symmetry, L2 and point time locked contract use cases. it's very focused on enabling those as opposed to focused on being a general script upgrade, and that's probably partially deliberate, because there's like, there's been this concern over how general covenants might get and the risk Of general covenants in Bitcoin. personally, I would rather have something more general than APO and not constrain it to these specific use cases. So I'm not against APO being activated, though, I just wish-- I hope that we can be clear about the ways in which it's been constrained to satisfy certain objections.

I see. And there's one other area you mentioned in your gist on GitHub, which is upgrade hooks of your proposal. So can you spell out what, what are those upgrade hooks and what would that mean for us?

Yeah, so I made it Very specific in my proposal in which cases a script validation fails versus in which case something that's not expected causes it to immediately succeed. And this is, this is how Bitcoin upgrades over time. This is how soft forks are possible, is that there are certain types of Bitcoin outputs that anyone can spend, they're not currently checked for validation, and that means that we can, in the future, restrict how those are spent and keep a compatible upgrade where old nodes will accept the new spends and new nodes will- Codes will validate it against the new rules. That's how SegWit was done, it's how Taproot was done, it's how all of these upgrades happen. And by being very conscious in the design of my, my proposal of where things instantly succeed, we can have new hash types. Right now, it specifies CTV and APO hashes, you could have new hash types, and they would be soft fork upgradable. we could have new key types, new signature types on the ChexSig from Stack, and they would be upgradable, et cetera. So, Of consciously making sure there's good ways to soft fork future upgrades to both TX hash and CheckSigh from Stack.

Okay, yeah, that's interesting. and as you mentioned, the idea is to have, have it so that the old nodes are still forward compatible, that they won't reject, the transactions that hypothetically, let's say the Bitcoin network says, "Yes, let's do this proposal from Brandon, let's do TX hash plus CS, CheckSigh from Stack, or this, or this proposal version of it," then, we sort of-- most people will get what they want, basically. The Opio, Opio camp will be happy because they get the LN symmetry and pTLCs, the CTV guys will be happy because they can do, you know, CTV use cases as well, and the, existing nodes who don't even want to upgrade, they won't have to fork off the network. I guess that's kind of what we're getting at, what you're getting at here, right?

Yeah. And then also, when we wanna add new ways of using TX hash, we can also Areas in the way Taproot was soft fork, where I wish Taproot had had more ways to upgrade. one, one specific example of this is that the, the exact shape of the Taproot control block, if it's not matched, the transaction validation fails, as opposed to potentially succeeding in a way that would allow us to soft fork a different style of control block. I'm, I know there are good reasons for the exact way that it is. I was just in that specific case disappointed that it wasn't upgradable in that way. So when designing proposals, I, I will certainly be trying to- Ensure that soft fork upgrades are possible wherever it is safe to do so.

Okay, great. Well, yeah, I think those are probably some of the key points, I guess. for listeners who are concerned about covenants generally, do you have any thoughts for them on that, as in, you know, w- Covenants, are they good, are they bad? Like what, what would be the big risks in your view?

I would say there's really no risk to CTB style covenants, effectively. People are always concerned about, "Oh, what if someone locks your Bitcoin in a way you don't want?" But that problem already exists. Someone could lock it to a multisig you didn't choose. We always, when we are gonna receive some Bitcoin, we specify the address, and so no one can trick us into receiving covenanted Bitcoin or multisig Bitcoin. It's our address, we chose the address. So CTV has absolutely, I would say, no risk, obviously code bugs aside, right? There could be a bug that creates a risk, but, but in terms of the design idea of a non-recursive covenant like CheckTemple Verify With recursive covenants, which anyProvOut does enable recursive covenants, they're extremely expensive and hard to use, but it does enable them. I would say there's, a, a concern that I don't personally share, but that some people have expressed over the ability to create long lived counters on chain with recursive covenants. there's this proposal that Jeremy Rubin wrote up, I shouldn't have proposal, this idea, not even a proposal, called Spookchains that uses CT, or sorry, APO- counters to, to do something somewhat similar to the hash rate escrow in the drive chains proposals. Again, it's not practically usable and it doesn't concern me, but, but at least some people Wonder about what might be enabled by these kinds of counter type executions of, of, of essentially very, very slow block by block looping using something like a recursive covenant from APL.

I see, yeah. And as I, yeah, okay. Yeah, 'cause I, I think I had heard some people chatting a bit about that, but it didn't seem like a very realistic, concern, at least from what I could understand. but okay. and so I guess where to from here? What are you hoping people do in terms of this proposal? And the, just the general discussion.

My, my honest hope is that people spend the time to understand the things they're objecting to before they object, and that applies to me too. When I first started objecting to APO, I hadn't really fully understood it, and huge shout out to, to Rusty Russell for helping me understand APO better so that I could have good objections to it instead of, instead of half-baked objections. So, so reflecting on my own experience, really hoping that people will use what I've written to- To understand these things more fully and then to comment on them intelligently, so that we can figure out where we are in terms of the IETF rough consensus idea of, of how we get, how we move forward with Bitcoin.

Great. Okay. And, lastly, where can people find you online and find your work?

Yeah, I'm reardoncode, r e a r d o n code on most platforms.

Fantastic. Well, thank you, Brandon. I think it's been a very educational episode, so thanks for joining me. Thank you very much. If you're enjoying the show, make sure to leave a like and share it with your friends. Thanks for listening, and I'll see you in the citadels.