Brandon Black (aka Rearden Code) joins me on the show to talk about his experience implementing MuSig2 at BitGo, and also his thoughts on the future Bitcoin soft fork discussion re: APO (ANYPREVOUT), CTV (Check Template Verify), and his educational proposal on moving forward:

• MuSig2 benefits
• Implementing MuSig2
• MPC vs Script
• What are APO and CTV? 
• Brandon’s combo proposal
• Upgrade hooks

Links:

• Twitter: @reardencode
• Combined APO + CTV proposal
• MuSig2 Field report on Bitcoin Optech

Sponsors:

• Pacific Bitcoin Festival (code LIVERA)
• CoinKite.com (code LIVERA)
• Mempool.space
• Base58 

Stephan Livera links:

• Follow me on Twitter @stephanlivera
• Subscribe to the podcast

Podcast Transcripts:       

Stephan Livera 00:01:04  

Brandon, welcome to the show. 

Brandon Black 00:01:05  

Great thanks to be here, Glad to be here. 

Stephan Livera 00:01:07  

Yeah. So, Brandon, I saw your, well, a couple of 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 hear first a little bit about you. I know it sounds like you’ve been. Working in Bitcoin development for a while. 

Brandon Black 00:01:30  

Yeah, thanks. I’ve been working in Bitcoin. I think I joined cost at the end of 2017 of my first Bitcoin job. Kind of been watching this space since long before that and it was great to finally get into It full time. Yeah, I’m basically been working on Bitcoin wallets the whole time, but I did some work at Casa on 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. 

Stephan Livera 00:01:56  

Fantastic. And so, yeah. So, let’s get into the experience around MuSig2, and a little bit of what happened with Taproot. So, as I 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 assessing it at that point? 

Brandon Black 00:02:15  

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 MuSig2 to a production wallet. So I joined Casa. This was about two years before, 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 Even activate. So, it was awesome when I got the opportunity to join BitGo and the first thing we did there was start building the Topper wallet at BitGo. We were able to launch that concurrent with the Taproot activation on Mainnet. But we had hoped to make that a MuSig2 wallet from the get go and of course, as I went researching the status of the MuSig2 code and the MuSig2 specification, you know, reading through the paper, the spec talking to Jonas Nick a little bit, I realized that it just was not production ready yet. So, we launched without MuSig2 while we waited for the spec to be finalized. 

Stephan Livera 00:03:09  

And there were multiple iterations there. So, as I recall, there was MuSig like just MuSig1, let’s say, and then MuSigDN and then later MuSig2. So, I guess you were still sort of waiting for things to shake out a little bit there. 

Brandon Black 00:03:21  

Yeah, by the time we started coding for Taproot, it was pretty clear that MuSig2 was going to be the most likely path forward. We did evaluate the other options, you know it. It picked out they’re, you know, they’re working on it or they’ve deployed, I think, an ECDSA TSS implementation. So, pick is not afraid of doing the kind of more complicated protocols. That MuSig2DN basically is somewhat similar to those other protocols, and having to do commitments. 

Stephan Livera 00:03:44  

Yeah. And then you said ECDSA TSS that’s threshold signatures game. 

Brandon Black 00:03:46 

Yes, correct.  

Stephan Livera 00:03:47 

Gotcha, yeah so, that’s, you know, pre snore, you were already looking at advanced you know. Versions of doing this. 

Brandon Black 00:03:56  

Right, and BitGo has to do that because they support many coins and not all coins have snore signatures so that they need to have a broad range of cryptographic primitives to do their offering on all the change they offer anyway.  

Stephan Livera 00:04:09  

Yeah, yeah. 

Brandon Black 00:04:11  

So, we were looking at the different options, but it was pretty clear that MuSig2 would be the right option, even though it wasn’t fully specified when we started on Taproot. 

Stephan Livera 00:04:17  

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

Brandon Black 00:04:23  

Well, truth be told, I left BitGo about a little under a month ago now. 

Stephan Livera 00:04:26  

Okay. 

Brandon Black 00:04:32  

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 great experience. I BitGo is an awesome company to work for and I have great respect for them, but I have moved on about a month ago. 

Stephan Livera 00:04:40  

Okay, Gotcha. Okay, Great well, so let’s talk a little bit about the different schemes that were available. And you know why MuSig2 too, and 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. 

Brandon Black 00:05:05  

Yeah. Yeah, the shortest answer to that is that MuSig2 is beautifully simple. You know, talk to Jonas Nick, about it. I think it. Bitcoin, Miami 22. And we were talking about this kind of this parallel in the MuSig2. Two construction and the way the keys are aggregated and also in the way the nuances. Are produced In both cases, you’re kind of protecting against a rogue key or 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 reference implementation is only 461 lines of Python. I’ve implemented it twice, once in C and once in JavaScript, and in both cases 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 we have to kind of get into when can you not use MuSig2 BitGo in this case is going to really good position to use MuSig2 because the way the Bitcoin wallet is constructed, the three keys are described as the BitGo key, the user key, and the backup key, and the vast majority probably over 99% of all signings happen on the BitGo 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 end of end 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 going to sign from the construction of the transaction. I talked to Jameson Lopp at Casa about Casa situation, whether they could use MuSig2 too, and in their case when they start assigning, they don’t have a clear answer as to exactly which keys are gonna assign out of a Wallet and so for them they’d have to start three separate. I think it’s three more than one separate MuSig2 session to try and figure out which keys are eventually going to sign and get collect multiple signatures from each signer. It really complicates the process for some wallets where the BitGo wallet was kind of perfectly positioned to use MuSig2 or let’s say Casa might need to use Frost or might use to use on chain multi-SIG. Because they don’t have the same clear answers to those questions when they start signing. 

Stephan Livera 00:07:27  

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 BitGo 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 N setup, so does that mean all three keys have to sign and I’m confused about the backup key? Or is it actually more like a two of two set up of any of those 3? 

Brandon Black 00:07:53  

Yeah, great question. The If you think about on chain MultiSig, if you have a two of three on chain multi-SIG, that means any two of those 3 keys can sign. You can construct that, but in a small MultiSig it’s easy. You can say if I have a 203 MultiSig, there are three pairs of two keys which could sign this transaction and because of the beauty, the wonder of tap script and Taproot. You can say I put you could do it with as we did in the original big goal implementation. 3 separate two of two. Paths. Yeah, and that is the same exact security function as a 203 on-chain MultiSig. Then it would 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 display all three keys on chain. 

Stephan Livera 00:08:29  

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 arguably you know that’s the one you want to do most of the time and. And if you need to use those other pathways, that’s where you actually are showing the script that you want to assign against, right? Is that right? 

Brandon Black 00:09:08  

Yeah, exactly. And with BitGo, again two of three, you always know exactly which two keys have signed, right. You signed the key path, you know exactly it’s the big one. Use your key if you sign. One of the key, this one of the script paths. You know exactly which two key signed and the other script path. You know exactly which two keys. There’s no ambiguity in the Bitcoin. Construction, obviously with more complex constructions you could have ambiguity and what’s actually available in. The script path. 

Stephan Livera 00:09:30  

Yeah. And it is interesting as well that you know, there’s more talk now about the use actual use of Taproot, because I think that was the line that maybe sometimes shitcoiners or maybe detractors of Bitcoin will sometimes come and say, oh, look, see, you’re not even using Taproot yet and yet, you know, here we are. MuSig2 too is, you know, it’s being used. And even with L&D, they’ve just put out Taproot channels in L&D, so it seems like it. It takes some time for the development work, but it is happening in fairness. 

Brandon Black 00:10:00  

Absolutely. But one of my biggest lessons in my years as a Bitcoin developer has been patients. Like I said, I wanted to do Taproot from 2017, and of course you can’t. You have to be patient. I wanted to do MuSig2 when we started working on Taproot in in 2020. You have to be patient. It’s just the way of these things. So. Yeah, people are like, oh, you’re not using Taproot. It’s like because we’re working on it. We’re all of us, throughout the ecosystem are working on developing the code and you know, getting it audited, making sure that we’ve got. Things close enough to right. You know, we’re not going to be perfect, but we kind of have to find this balance of spending enough time vetting it to get it right. 

Stephan Livera 00:10:37  

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 to? 

Brandon Black 00:10:48  

So, the single biggest benefit is a reduction in on-chain launching fees. If I recall correctly, it’s 43.5%. Cheaper to use a Taproot key path than a native SegWit two of three. Script. So this lets you use a MultiSig construction like the bit go wallet with no additional on chain cost relative to a plane pay to witness pub key hash address. I mean it’s there’s a slight cost but it it’s marginal as opposed to being a significant cost to use multi state before Taproot and MuSig2. There’s also somewhat of a privacy benefit, especially in a case like. The bit go wallet where. On the Bitcoin wallet, again, 99 plus percent of all signings happen on that key path, and as far as the bit go, sorry, the Bitcoin blockchain is concerned. Those Keypath 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. 

Stephan Livera 00:11:50  

I see and so, hopefully the I guess 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 a anonymity set to hide in that particular perspective. Now to be clear, 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? 

Brandon Black 00:12:15  

Yeah, exactly. I mean, yeah, the common PC input heuristic is obviously still out. There, although hopefully as Dan Gold and others work on pay join stuff, we’ll start to break that common input heuristic as well and gain Some on chain privacy. 

Stephan Livera 00:12:27  

Yeah. Okay so, then summarizing the key benefits, as you said in your blog post for Bitcoin optech, it looks like a native segment input is 104.5 V bytes and a MuSig2 key path input is 57.5 V bytes. So yeah, like you said, it’s like about 40% saving and so. Just to put that in context as well, 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 40 bytes. But in the case of production grade large wallet, that would be a meaningful saving because you know, if you’re 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, so 40% is actually a, you know, a meaningful saving in that case is that have I got it right there. 

Brandon Black 00:13:20  

Yeah, you’ve got it exactly right. The one of Bitcoin’s main customer groups is exchanges that they BitGo co-signs for and those customers do tons and tons and tons of transactions and they also just have a lot of small UTXO’s. You know, they get small deposits from users trading on their platform and they need to consolidate those. And those consolidation fees can need significantly into their revenues. So it really does matter to them that we get these fees down and of course, it also 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. 

Stephan Livera 00:13:55  

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 know you went with there. 

Brandon Black 00:14:12  

Yeah, I mean, we talked a bit about this with the comparison between BitGo and Casa in in using MuSig2 You know, there’s. A huge design space in Taproot scripts and it’s non trivial, let’s say to pick which scripts like for the BitGo case with this MuSig2 to address type we could have used two of two MuSig2 key path and then a single script path with an OP check SIG ad style multisig in the tap script we could have done what we ended. Up doing with Two of two just playing off. Check Sig script paths. Or we could have put all three, two of two options also in the script in case there’s a break in MuSig2 to and we’re not able to sign with that keypad anymore. So, you really have to consider in picking scripts to use with tap script. What your specific wallets needs are and what types of wallets you’re going to be using with this with. If I was designing a wallet for hard cold storage. I would have used a different style of script than I was designing a wallet for BitGo to use with a, you know production exchange wrap hot Wallet and maybe even the same exchange customer of BitGo might use different address type. They might use 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 the tap script world. And unlike with kind of the previous segment or legacy addresses on Bitcoin, it’s hard to come up with a set of obvious best practices. Each wallet designer in the top world has to evaluate their own specific needs before they can pick what scripts to use. 

Stephan Livera 00:15:57  

I see. 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? 

Brandon Black 00:16:08  

Yeah, the size of the script exposing and then and then how much fall back you need. Like what’s what, how much money are you risking, let’s say if there’s a break in MuSig2 and we can’t sign with MuSig2, how costly is it going to 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 the keys  

Stephan Livera 00:16:33  

Yeah, Okay great, and so now some listeners are, you know, people who are following Bitcoin. Twitter may have seen some of the drama. You know, the big fight, the beef between Rob Hamilton and Ryan Dale on MPC gang versus the script boys. I’m curious if you have any thoughts on the that great debate that’s happening the. MPC gang versus script gang. 

Brandon Black 00:16:58  

Oh it’s so good. It’s so much fun. I think the humor they put into it, I they’re both great, you know. Ex posters, whatever we call. It these days. And I’ve really just enjoyed the points that they make because what they’ve ended up doing is in in a humorous way, exposing a lot of the trade-offs, the benefits. 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 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. 

Stephan Livera 00:17:41  

Yeah. Okay So, then I guess from in terms of what you’ve been doing, you would put MuSig2 to 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 fire blocks with MPC but it was not related to. It was not like a MuSig2 or a Frost MPC, right? 

Brandon Black 00:18:12  

Yeah, exactly. Right. there’s MuSig2, there’s frost, and then there’s other MPC. And there, there are each different. So, for to kind of compare them, the Frost signing protocol is round optimized. It’s pretty minimal, similar to MuSig2. To 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. And make a MuSig2 aggregate key without talking to the others public the other. Owners. And that’s a beautiful thing about MuSig 

Stephan Livera 00:18:55  

Right. It’s like a non-interactive setup you can do. I see. 

Brandon Black 00:18:58  

Yeah, And then there’s on the far side of that there with 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 it’s being operated, which opens up potential not necessarily actual but potential vulnerability space. 

Stephan Livera 00:19:20  

Okay yeah, Interesting. And so just to. Make sure everyone’s following along. Yeah. 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? 

Brandon Black 00:19:32  

Yeah, so in general, MPC is a broad category of ways for multiple people to collaborate on creating a single cryptographic result that will be seen on chain, typically a digital signature. And so, this, you know, MuSig2 falls into that category as this 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. 

Stephan Livera 00:21:59  

Okay, yeah, gotcha. And so where let’s say, you know team, you know Miniscript or Miniscript gang or whatever they calling themselves Rob and his gang can like, I guess what they’re getting out with the idea of mini script 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. Some kind of, you know, back out Pathway 5 years from now or 10 years from now as like a get out of jail free or a you know as a I forgot my password sort of set up but the downside 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? 

Brandon Black 00:22:43  

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. 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 SingleSig that you gave to your mother. Unless you tell people about that, you can be using your Taproot wallet with a, let’s say, a really secure three or five all the time. And no one will ever know that that secret SingleSig is there unless you tell them. And that’s really a beautiful thing about Taproot is that when you design a Taproot. Call it. 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 Sorry, a more secure way, let’s say, and the great thing about MC versus script is that you can combine these things as we did at BitGo, right. We’ve got a MPC based keypath and then scripts as backups. And that’s really I think what the future of Bitcoin on Toproot is going to look like. Wallets will have, whether it be a MuSig2 or a Frost keep and then some complex set of recoverable scripts down below that so that the wallet gets really the best. Of both worlds. 

Stephan Livera 00:23:57  

I see. Yeah, that’s a yeah. That’s a great explanation. I think it helps help 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 you? Do you see that as like maybe 5-10 years down the line? Most people will use some kind of setup like that where they have NPC for the, you know, the key path. And some kind of mini script enabled technology for their script path spending. 

Brandon Black 00:24:30  

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. I’ve lost the name of it. The wallet that the Wizards sardine folks are working on. 

Stephan Livera 00:24:56  

Liana, Yeah. 

Brandon Black 00:24:58 

Yeah Liana They’re going in that direction. You look at BitGo is, you know, it’s kind of in that direction. Everyone is really looking in that direction of NPC plus script as the way to hold the Bitcoin and even the op vault Proposal that’s out there from James Wilburn? Yeah, that also. Is that also was looking in that same direction? There’s probably going to be a key path that might be all of the keys involved, but then there’s also this, this vault structure hidden under there so yeah, I think that’s really where holders of on chain Bitcoin are gonna. Go would be my suspicion. 

Stephan Livera 00:25:32  

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? 

Brandon Black 00:25:45  

Yeah, absolutely. And if you look at lightning or other kind of proposed layer two type solutions, they’re all gonna have some kind of MPC involved to. To keep their on chain footprint as small as possible, and again to maintain the privacy as we already talked about for using Taproot key path, you kind of blend in as long as you don’t have to use the backup paths. 

Stephan Livera 00:26:02  

Okay, so when it comes to using MuSig2 to 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. 

Brandon Black 00:26:26  

Yeah, unlike script MultiSig. Where the signing each party can just sign and then share their signature with MuSig2 to 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 specification allows for nonsense to be pre generated. To kind of elide that extra trip to the key, but it’s difficult to do that correctly because non storage is a big challenge for MuSig implementations. So in general the high level thing to mention here is that a reuse of a secret nonce in any of these signing protocols, ECS, a Schnorr, MUSIG, etcetera. We’re using the nonce, the secret nonce leaks your secret key like this is a fact. Just, 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. And a few other bits of data and that node will never be reused with a in in a way that would leak the secret key the. The key thing here is that the nonce must never be reused and generate a different signature. The resulting signature vice must be identical if the not if the same nonce is used, and that is true with deterministic nonceses. In ECDSA, a single SIG or snore single Sig 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 use the deterministic knots. In the MuSig2 SPAC, they didn’t make one carve out for that, which is the last. Party to produce nonsense and vote and to sign can use a deterministic knots 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 produce. Because they’ve already got the nonces from the other parties. So, this is all kind of hard to reason about, which gets to the point of nonces are difficult and they are 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. Did they have to hold on to it across the until the second round of the protocol? And then as soon as they get the second route, they have to make sure they get rid of that secret notes because it becomes toxic. If they were to use it again, it would leak their secret key. And that’s kind of the summary of nonces and how multi signatures make them more difficult to get right. 

Stephan Livera 00:29:15  

Right. I see. And so, I’m you know, 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? 

Brandon Black 00:29:35  

Yeah, for the for the BitGo solution. We use the deterministic knowledge generation on the hardware security module because we always the hard security module is coded to sign second in each of the two in each of 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 very careful to make sure that nonce is thrown away. As soon as. Possible to avoid reuse. 

Stephan Livera 00:30:09  

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 you said. And so yeah, let’s see if more other you know, if more and more custodians and. More and more. Bitcoin users let’s start to use start to use this. 

Brandon Black 00:30:28  

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

Stephan Livera 00:30:37  

Okay, great. So, let’s get into this proposal that you’ve put up, which relates to some of the soft fork discussion around check template verify any Prev out and TX hash and check SIG from stack. So, do you want to just give us? A bit of an overview like Why did you do this? Combination proposal. 

Brandon Black 00:30:59  

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 check template verify and about any Prev out that there is kind of a lack of clear. Pending in the Community about these protocol, these proposals, I should say kind of to a comical degree, the folks who really want CCTV don’t understand a PO and the folks who really want a PO don’t understand CTV and many folks understand neither and so part of what I wrote this proposal for is to show. There’s a lot of common ground in these proposals. They do a lot of the same. They offer a lot of the same things. They’re looking at it from different angles, but there’s not actually that different. And so by putting them in in one proposal, making a table of the differences, I’m hoping to kind of move the conversation. Word on what we think the right types of call it template hashes. We want to allow in this hopefully next software for Bitcoin. I think that this is the right direction to be going allowing kind of commitments that don’t fully commit to what’s being spent but commit to how it’s being spent. Which is basically what both any Prev out and check template verify allow is the right direction for Bitcoin to go and then it comes down to the details of exactly in which way we do that. 

Stephan Livera 00:32:22  

Okay, so 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 from your perspective what’s APO and then we can sort of go into your proposal. 

Brandon Black 00:32:37  

Sure. So, CTV or Check Temple 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 get the correct hash and so check to verify I actually in writing my postal realize I think there’s kind of a glitch in it when using TypeScript. That’s a separate topic the point is though it maximally constrains. The way it is spent without constraining what? Being spent. And so, it exactly specifies the outputs that are going to be created, and it specifies the amounts of those outputs. Specifies how many inputs are going to go into the transaction. You know really constrains things quite significantly on what’s going to be created, but not what input goes into creating that. 

Stephan Livera 00:33:35  

Okay yeah, So, it gets a bit complicated, right? Because I. Like people might be used to things that already exist today, so you know MultiSig. Obviously, we’ve been talking about that exist today and time related things like check sequence verify or CLTV that you know, but they relate to being able to spend and output. Whereas in this case we’re talking about how you can. I guess the idea is that we’re going to use. You know the proposal of CTV and the idea of CTV is that you can use it for things like vaults without having to precompute patches as I understand and that there might be other uses like non interactive Lightning channels or maybe it is going to be used as part of coin pools and payment pools and things like this. Would you say that’s a fair summary? 

Brandon Black 00:34:22  

Yeah, yeah, because 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 plain CTV where there’s no other kind of side spending hatch. The plain CCTV 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 a CTV output that commits to paying me and they can show that there’s no other escape hatch in that I can accept that I’ve been paid. Even though my output doesn’t exist in the UTXO set because it exists in the CTV, I have been paid. There’s no other way for that coin to be. And that’s really what a lot of the CTV use cases revolve around that idea that CTV virtually creates some UTXO’s that can be then really created later when you need them, but they’re not actually created when the TV is created. 

Stephan Livera 00:35:18  

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 want to withdraw all at once. And so long as those users have opted into a CCTV context, they could sort of not receive the output right now but be provably sure that they will get it. Is that a Fair way to say it. 

Brandon Black 00:35:40  

Yeah. Yeah, that’s one of these cases, you know, Jeremy Rubin called that the congestion control use case. But then there’s also, like, the barracks art 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 in the ARC pool creates a CTV output that commits to everyone’s. UTXO’s. But four weeks later, the art 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 art pool and you spend that 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 create a commitment to. Create an output. 

Stephan Livera 00:36:31  

Yeah. And I guess maybe some users at this point or listen. Are anticipating this, or maybe the objection from their perspective is wait, why do I want to 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 Arc, it enables another whole layer too. That could be useful for people. So, is that how you’re seeing it, or how do you see that? 

Brandon Black 00:37:09  

Yeah. No, I agree. The general thought that I focus my Bitcoin work on 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 CTV. By allowing these kinds of commitments to UTXO’s 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 as high as they did back in the day. So, people have asked. Right 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 going to have these next round of call it scaling technologies available when we need them, we really. Have to be building them now. 

Stephan Livera 00:37:57  

Okay, gotcha. Okay. So that’s CCTV. Can you now give us? Your you know. Your layman’s explanation of what is APO? Any profile? 

Brandon Black 00:38:07  

Yeah. So comparing it I think is the best way. So now we’ve talked about CV a bit. Let’s compare APO what APO enabled. This is unlike CTV. It does not deliberately try to maximally constrain the outputs because API is compatible with SIG hash single where it will commit 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. Tied as well, there’s two modes of APO. There’s any Prev out and any Prev out any script in the any Prev out only mode it still commits to the input script being spent. So, 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, where CTV can spend anything that’s CTV can spend, anything that to the outputs specified. Potentially APO can only spend things that also. Have the correct input script. 

Stephan Livera 00:39:17  

I see. And so, my understanding there is that the way you know, Christian Decker and maybe AJ and whoever else is involved. We’re thinking about trying to minimize the foot guns 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 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. 

Brandon Black 00:39:44  

Yeah, a lot of things went into the design of APO and what you’re talking about there is that they decided from an abundance of caution. To use a new tap script key version so that existing scripts that are already out there couldn’t be signed using SIG hash, any Prev out an important kind of point of clarification on this is that because the signer selects the SIG cash 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 Prev out. Well now all outputs to that same script are spendable immediately because they’ve signed any Prev out. And they so. If you think about, you’ve got a wallet, you’ve got a bunch of addresses and the address each address might a bunch of UTXO’s associated with it. If you sign one of those UTXO’s with any Prev. Out all of the ethos on the same address can be spent in the same way, because you don’t specify which UTXO you’re spending when you sign with any Prev out and so. That’s why they chose to use a different key version in specifying any Prev out because it prevents that specific foot gun of some existing script being signed that way. 

Stephan Livera 00:43:00  

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. These cases are not possible, but it’s kind of a more hacky method, maybe a more costly on chain method, right? 

Brandon Black 00:43:27  

Yeah, that’s exactly right. You can get a lot of the CTV behavior by using any Prev out 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 way the transaction is spent. To be able to predict transaction ID’s at the next level, so some of the things that you know Jeremy even wrote about when he was talking about CTV a couple of years ago, we’re kind of trees of CTV. And in some of those cases, you need to be able to predict transaction ID is based on what transaction ID is input and APO doesn’t constrain sufficiently to predict future transaction ID is the other thing I just said, yeah, there’s a higher cost to using API in that way because with CTV you put a 32 byte hash on chain and then you check it against the transaction that’s spending it. If you want to use APO in this way, you have to put a pub key 33 bytes and a 65 byte signature all on chain to get the same result as just a 32 byte hash would have given you with CTV. 

Stephan Livera 00:44:32  

Okay, Gotcha. And so then let’s talk a little bit about. I understand you had, I guess those are some of your critiques of APO. I mention 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 app and. Then now you’ve come up with this. Proposal yourself. Do you want to just elaborate there for us? 

Brandon Black 00:44:57  

Yeah, So, yeah, that’s some like some like kind of issues, if you will with APO, you know. 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 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 looked and I created my original poor request against the APO bip, which allows it to be. Used and I think I haven’t verified this fully, but I think fully emulate CTV. By separating out some of the flags involved the any Prev out implies anyone can pay if that means anything to the listeners and might pull request makes it not imply anyone can pay let you specify. Anyone can pay separately and that lets it then more fully emulate CTV. It’s still much more bytes on chain. But at least now it’s a deliberate conscious we’re doing any prep out which enable the type of covenants. Let’s make sure that we’re making those covenants useful and kind of go forward with that would be the idea there. And then kind of continuing to research this over 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 check signature from stack which then can cover both use cases, any Prev out and check template verify. 

Stephan Livera 00:46:17  

Okay, so do you mind just spelling out for us, you know, what’s TX hash and what’s check seek from stack? 

Brandon Black 00:46:23  

Yeah, so TX hash is a very, very broad idea and my proposal deliberately constrains it. But in General TX hash. It would be a Bitcoin script op code that hashes some portions of the transaction currently being validated and puts them on the stack for later use in a script. The general proposal that Russell O’Connor originally made had a had kind of had a bunch of flags where you be like I want to hash the inputs I want to hash this input. I want to hash this one hash that and you could pick with a bunch of flags. 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 take quality check the proposal I made was TX hash is probably something we want to do in Bitcoin someday, but right now we have concrete use cases for check, template verify and any Prev out 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 Unchained bytes and using this. So that’s the TX hash side, a very constrained TX hash that’s just the same hashes that would be used at any Prev out or CTV, but where you have one OP code that can create the hashes for either of those other proposals. And then check SIG from stack. Is comparing it to the existing check SIG operations in Bitcoin script check SIG hashes the transaction based on the signatures 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 check SIG function. Check SIG from Stack 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 OPTX hash to create a hash and it goes on the stack and then you have op check SIG from stack that can read that hash and check a signature against it, you can put those two things together. To check different hashes than you can using regular OP CheckSigs . 

Stephan Livera 00:48:33  

Yeah, Okay I think I’m following. 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? 

Brandon Black 00:48:48  

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 want to 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 a spend amount policy where transaction 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 execution speeds and the risks of certain types of recursion that could be written and stuff. If we do full transaction introspection. And so that’s why I think at this moment in Bitcoin’s history, the approach 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. 

Stephan Livera 00:50:01  

Okay, yeah,  I think it 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? 

Brandon Black 00:50:32  

Yeah, it’s a combination of threaded 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 the table in it that shows exactly what data is hashed in each of the codes that that we can at least start talking about how these things are very similar and what specific items from each we want to get into a into a change to Bitcoin. 

Stephan Livera 00:51:07  

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 upgrades with the Lightning network. And so, your proposal enables that. 

Brandon Black 00:51:22  

Yep, yep. And then the CTV camp wants our vault, and they want potentially arc. And they want congestion control and a bunch of other things that I don’t fully understand. And there’s the. The guy who posts about the Enigma network, which is very hard to think about. 

Stephan Livera 00:51:34  

Oh, Poly yeah, because he’s talking like transaction cut through and it’s very complicated. So yeah. 

Brandon Black 00:51:34  

Think about yeah, 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 right, because this proposal allows each of the things that CTV offers and each of the things that APO offers, we can get those both and do it in a way where. We talked about those APO covenants that that have to be large on chain with the 65 byte signature and the 33 byte key with this proposal, those same exact covenants. Possible no additional covenants, the same ones, but they’re only 33 bytes instead of 65 + 33. And so that’s like if we’re going to enable those things, let’s not make it wasteful to do it. Let’s do it in a way that is compact and efficient, and that’s why I kind of am in favor of this method of doing APO and CTV. 

Stephan Livera 00:52:29  

Okay. Yeah, sorry. I think it’s 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? 

Brandon Black 00:52:46  

Yeah. So, with plain APO to do covenants, you have to have a 33 byte key and a 65 byte. So get your own chain. Yeah, with my proposal, you can build those exact same APO covenants, but with just a 32 byte hash and 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. 

Stephan Livera 00:53:06  

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

Brandon Black 00:53:12  

So, this is the downside of my proposal, because my proposal uses up success style upgrade detail is not important. It only works in tap script whereas the CTV proposal as written allows CTV in legacy on chain, in SegWit and in tap script and the result is that for the use case of a what’s called Bear CTV where the locking script of the transaction is exactly equal to the. Cash. It’s going to be spent in and the one OP code. This is significantly larger. I think it’s 17 bytes or something. It’s quite a bit larger on chain than bear, CTV, so that’s probably the single biggest downside of my proposal relative to the others. As others have said 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 educate 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. 

Stephan Livera 00:54:22  

I see, Okay yeah, because that also seems to be, you know, there are some people talking about the idea of just having, you know, let’s just have CTV and. APO’s. 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? 

Brandon Black 00:54:40  

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

Stephan Livera 00:55:25  

I see, and there’s one other error you mentioned in your gist on GitHub, which is upgrade hooks of your proposal, so can. You spell out. What are those upgrade hooks and what would that mean for us? 

Brandon Black 00:55:36  

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 how Bitcoin upgrades overtime. 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 in 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 validate it against the new rules. That’s how SegWit was done at how Toproot was done. It’s how all of these upgrades happen. And by being very conscious in the design of 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 checks. From stack and they would be upgradable etc. So, that’s kind of the idea of consciously making sure there’s good ways to soft fork future upgrades to both TX hash and CheckSig from stack. 

Stephan Livera 00:56:44  

Okay, Yeah, that’s interesting. And as you mentioned, the idea is to 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 CheckSig from stack or this or this proposal version of it. And then we sort of most people will get what they want. Basically, the APO camp will be happy because they get 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? 

Brandon Black 00:57:27  

Yeah, and then also when we want to add new ways of using TX hash we can also soft workflows. I was in researching all of this. I kind of came across some areas in the way Taproot was soft fork, where I wish Taproot had had more ways to upgrade one specific example of this is that the exact shape of the Taproot control block. If it’s not matched, the transaction valuation 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 will certainly be trying to. Ensure that soft fork upgrades are possible wherever it is safe to do so. 

Stephan Livera 00:58:17  

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 covenants, are they good? Are they bad? Like what? What would be the big risks in your view? 

Brandon Black 00:58:35  

I would say there’s really no risk to CTV 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 covenant to Bitcoin. For 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 in terms of the design idea of a non-recursive covenant like check template verify with recursive covenants which any prove out does enable recursive covenants, they’re extremely expensive and hard to use, but it does enable them. I would say there’s a concern that I don’t personally share, but that some people have expressed over the ability to create long lived. Hunters on chain with recursive covenants, there’s this proposal that Jeremy Rubin wrote up shouldn’t have proposal this idea, not even a proposal called spook chains that uses APO counters to do something somewhat similar to the hash rate escrow in the drive change proposals. Again, it’s not practically usable, and it doesn’t concern me, but at least some people wonder about what might be enabled by these kinds of counter Type executions of essentially very slow block by block looping using something like a recursive covenant from APO. 

Stephan Livera 01:00:08  

I see. Yeah, cause I think I had heard some people chatting a bit about that, but it didn’t seem like a very realistic concern for 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? 

Brandon Black 01:00:29  

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 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 reflecting on my own experience, really hoping that people use what I’ve written 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. This idea of how we get how we move forward with Bitcoin. 

Stephan Livera 01:01:09  

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

Brandon Black 01:01:13  

Work. Yeah, I’m reardencode, R-E-A-R-D-E-N CODE on most platforms. 

Stephan Livera 01:01:18  

Fantastic. Well, thank you, Brandon. I think it’s been a very educational episode. So, thanks for joining me. 

Brandon Black 01:01:23  

Thank you very much. 

Stephan Livera 01:01:25  

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.