Not everybody understands that blockchains themselves don’t scale. And this may create some tricky implications if we want to onboard large numbers of people to Bitcoin. This is why some of the discussion nowadays is about soft forks and covenants. Brandon Black rejoins me to talk about some of his ideas on how many people can use Bitcoin with current tech, and how covenants such as CTV (Check Template Verify) could help improve this. We discuss:
- How many people can use Bitcoin
- Why not build L3?
- Thoughts on block size
- “Rush to the exits”
- Different kinds of forks
- Covenant proposals explained in english
- Concrete proposals
- Commercial demand
- Unforeseen risks
- Value density
Links:
Prior Episode:
Sponsors:
- Swan.com (code LIVERA)
- CoinKite.com (code LIVERA)
- Mempool.space
Stephan Livera links:
- Follow me on X: @stephanlivera
- Subscribe to the podcast
Podcast Transcripts:
Stephan (00:01.37)
Brandon, welcome back to the show.
Brandon Black (00:03.734)
Thanks for having me again.
Stephan (00:05.574)
So today we’re gonna talk about covenants. Now, bit of context, right? So for listeners who are newer to the space, or maybe you’re just watching because you wanna learn a little bit about the technical aspects of Bitcoin, I see that there’s a lot of discussion now about covenants and in particular this idea of CTV and we’re gonna talk about some of the other forms of covenants today. And I know that some people…
are a little confused on this topic, or they sometimes see it like, oh, is this like an attack on Bitcoin? Like what’s going on here? I think what I’ve seen is there’s a lot of people talking about various forms of covenants, and it can be a bit confusing. And so from what I’ve seen at least, I’ve seen you, Brandon, being quite good at articulating the benefit of this in a, let’s say, plain English way, whereas I think a lot of people who are talking about this online…
Bless their hearts, but they’re very technical and it’s sort of into the detail and it’s kind of hard to really get in English what is exactly going on here. So if we had to just start and let’s say, you know, we’re going to ask this broad question, are covenants necessary for Bitcoin, right? So that’s a question we’re trying to explore today. So let’s start with your elevator pitch, Brandon. What is your elevator pitch for covenants in Bitcoin?
Brandon Black (01:24.714)
Yeah, great question. And I think that before I answer that, I want to really quick say, there are many, many kinds of covenants. And really the conversation today is focusing on one specific kind of covenant, which is a covenant about what outputs are created by the next transaction you go to make. There are many others that we could do. We could talk about amounts and other things, but really when people talk about covenants right now, they’re mostly talking about the outputs created by
A next transaction. Okay. So now the elevator page for that specific kind of covenant, which is most talked about today Right now we have Bitcoin with lightning network, it’s an amazing system about 100 million people can use that and can make all the payments they want to
I think that we need more people to be able to use Bitcoin without going to custodians, without going to wallets of Toshi, without going to Coinbase, whatever the custodian of choice might be. And in order to get more than 100 million people to use Bitcoin in a non custodial way, we need some way of sharing pieces of Bitcoin or UTXOs, the technical term.
and covenants, specifically the type of covenant that creates a next output, enables more people to use Bitcoin.
Stephan (02:48.89)
Got it. And just for people who aren’t familiar, what is an output? And, you know, what is an output basically?
Brandon Black (02:56.706)
Thank you, yeah. So Bitcoin is kind of a strange system in terms of computer systems. We usually have accounts in computer systems and so with an account system, you add and remove Bitcoin from your account would be the way that would work. But Bitcoin isn’t an account system, it’s a coin system. And in Satoshi’s original writing, he always talks about coins, people hold coins. A coin is a unit of Bitcoin that has not yet been spent. These are initially created by the mining process.
And new coins are created each time you spend some previous coins. Nowadays we use the term UTXO or output to refer to these things because the coin term got confusing. So when I say the word output, what I mean is a unit of Bitcoin, an atomic unit of Bitcoin that must be spent in a single transaction. That’s one of the properties of Bitcoin, much like when you pay with cash bills, you have to spend some specific units of Bitcoin, some specific outputs, and the result will be some new outputs.
There’s this kind of magic changer in between where you give some bills to someone and you get back some bills and they keep some. But there’s always atomic units at the beginning and the end every Bitcoin transaction and that’s an output. And right now with Bitcoin the way it is, there’s a pretty hard limit that if we want people to have their own outputs, meaning their own individual one lightning channel per person, we can only support about 100 million people using Bitcoin because we simply cannot create and destroy enough outputs per year.
Stephan (04:08.838)
Got it, okay.
Brandon Black (04:25.302)
to support more than that many people using Bitcoin, unless we have covenants that restrict the next output creations.
Stephan (04:32.45)
Yeah. And so let’s dig into that number as well, because people might be confused about where we’re getting that restraint from. Like where’s this hundred million number coming from? And obviously this is kind of like a ballpark number, right? It’s not maybe like scientific to the exact number, but just kind of ballpark, I guess, yeah, something between 10 to a hundred million people could use Bitcoin and Lightning today. You know, so could you just explain where that number is coming from?
Brandon Black (04:52.074)
Yeah, that’s exactly right. It actually came from the original lightning paper. They did the math on if people wanna do one or two channel management operations per year, the Bitcoin network throughput, which is about seven transactions per second, can only handle about 10 to 100 million people using Bitcoin with one to two channel management operations per year. So it’s actually quite.
That’s 100 million people with one to two per year. So, it’s really, like I said, a 10 to 100 million is really the practical limit if people do more than two channel net actions per year. So the original Lightning paper, when they realized that, their thought in designing Lightning was, we can support the whole world on Lightning by gradually increasing the block size of Bitcoin to about 133 megabytes. So that’s…
Honestly, that is one other option we have for getting more people on Bitcoin, increasing the block size. I’m not saying it’s an option I like, I’m not saying it’s something that I think we should do as a Bitcoin community, but if we want to get more people on, we want to get plebs all around the world to use Bitcoin, we’re going to have to do something.
Stephan (05:59.694)
Yeah, right. And so as you were saying, and to, you know, for context, the Lightning white paper, I believe is 2014 or 2015, right? This is like pre the block size wars. And obviously nowadays trying to do a block size increase would be much more contentious, obviously, given the block size wars and also given all the ordinal inscription, BRC 20 stuff, because now the argument would be, hey, even if you do just increase the block size, there might just be a lot more JSON and JPEG spam. Right. So.
Brandon Black (06:25.994)
More DGens!
Stephan (06:28.854)
I think that’s another point to consider. So for a lot of people, and let me just put this explanation out there just to keep it accessible for everybody, right? If you’re totally new, the way your Lightning Wallet works, if it’s non-custodial, it needs to do a channel open and potentially some channel splicing and channel management, and then potentially a channel close operation. So that’s really what we’re talking about here, because if you just sort of, even just do some basic maths, right? Let’s say there’s 4,000 transactions in a block, there’s six blocks an hour.
there’s 24 hours in a day times by 365, you multiply that all out, it comes out to something like 210 million transactions per year, like as you said. And so if you thought that, okay, each person is only going to do, let’s say two transactions per year, that kind of gets you again in that same ballpark of 100 million users. And that’s again, that’s not even counting coin joint transactions. That’s not even counting high value, let’s say I’m buying a house or something like that, and I’m doing a big on-chain transaction for that. That’s not even counting those transactions.
So in reality, it’s probably less than that. It might well be more like 20 or 30 million people once you account for people doing multiple transactions. And so that, I guess, reality means that in a world of eight billion individuals, in a world with probably hundreds of millions of companies, that means, you know, if 1% of eight billion is 80 million, that means theoretically less than
1% of the world in the long run, far-flung future, less than 1% of the world can actually self-custody. So what do you think the implications of that would be?
Brandon Black (08:07.922)
I get off into economics and theory much farther at this point, but I think it is good to think about. I think we’ve already seen what happens with a money system that is limited in how many people can really meaningfully use it, because that’s what happened with gold. Gold was great money for many, many years until the population of the world and the distribution of the world meant that…
not sufficient people relative to the powers that be could directly use gold. And so then custodial gold became the standard. Everyone had their gold in a storage place and they had certificates for their gold instead of real gold. And once that became the norm, it became possible as everyone, you know, all the conspiracy theorists get all talking about manipulating the price of gold and all this stuff. But there’s some element of truth in that. And I think
the manipulation of the price of gold plus the confiscation through 6102, those things are made possible by the fact that it can’t be used non-custodially by a high enough percentage of the people. When gold could only be held by the 1%, only transacted by the 1% because it was too costly to manage and to divide and everything, then we saw this happen with gold. So I think if Bitcoin is also limited to that 1%, as you said, we’re gonna see a similar thing.
And look, my honest opinion here is that Bitcoin might be a really good money system for a few decades, even with just the limitations it has right now. But as a Bitcoiner, I want to do better than that. I want to build a system that lasts longer and that is better money for more people for a longer time for generations. And so that’s why I care about getting Bitcoin into the hands of more than 100 million people.
Stephan (09:50.918)
So yeah, and so I guess just for the sake of argument, for the sake of Steelman, I could say, well, it would still be an improvement on the current system today. Well, we have one Federal Reserve, and let’s say there’s, you know, last I checked this number, it might be in the range of 40,000 fiat banks existing in the world today, right? The world we would be talking about in this hypothetical Bitcoin and Lightning, maybe high net worth people plus some Lightning banks, the equivalent of Walters-Satoshi or Blink and others, we might have
50 million lightning banks. And so you do at least have the possibility where people could leave and withdraw from one lightning bank and go to another lightning bank. You can leave the bank of Stephan and go to the bank of Brandon. And so maybe that is enough, or at least that’s better than what we had in the gold system where you couldn’t easily verify things externally and you sort of had to trust the state.
Brandon Black (10:47.562)
Yeah, like I said, I think Bitcoin could be great for a few decades in that way, but it’s also capturable when it’s high net worth individuals and banks that hold it, then they can be regulated, they can be controlled. And then it’s still going to keep the Bitcoin out of the hands of people that need it most. The Edward Snowden’s, the Julian Assange’s, the people that really need Bitcoin can’t access it when it’s only in those 50 million.
banks and high net worth individuals, because all of those people are captive. They are necessarily captive because of their stake in the physical world that’s controlled by the guns of the government.
Stephan (11:21.262)
Yeah, and so I think that may be where some of the debate in the community will lie. They may say, well, look, decades from now, maybe there’ll be people set up in all kinds of different jurisdictions, the El Salvador’s of the world and other kinds of things. But I think ultimately it comes down to this question of who should Bitcoin be for? And so I think that is the question that listeners have to answer. Do you believe in a world where that would be enough? I guess that’s the question. Do you believe that, let’s say, 50 million banks, lightning banks around the world is enough?
Or do you think it should be more than that, such that you could stop any fractional reserve banking practices or censorship practices? Right.
Brandon Black (11:56.954)
I mean, not your coins, not your keys, not your coins, right? Do we believe in not your keys, not your coins? If we believe that as Bitcoiners, then we have to do better than 50 million banks. I’m not gonna use a bank.
Stephan (12:11.47)
Right, and so the other question people may have, we’ve sort of touched on this before, is some people may have this view of, why can’t you just build things on another layer? Like just build it on lightning or build layer three. What’s the problem with that kind of view?
Brandon Black (12:26.71)
Yeah, I mean, I think we already nailed that, fortunately. Like Bitcoin, we have these outputs, these UTXOs, and there’s a limit on how many management actions you can take per year. And as of now, that’s a pretty hard limit. Like the Bitcoin network, we aren’t gonna raise the block size, and so there’s a hard limit on how many UTXO management actions we can make per year. And so we simply cannot build layers that support more people right now, because right now,
The only way to share a UTXO management action is for everybody involved in that sharing to sign every single change that’s gonna happen with it. Because we don’t have a way for me to promise to make a change to a UTXO to you and for you to believe that. What an output creation covenant does is it lets me promise to make a change to a UTXO to you and it to be an absolutely.
indelible promise enforced by Bitcoin. Because the covenant, the output covenant, restricts what outputs can be created at the consensus level. And so we can now coordinate and share UTXOs without trust. And so it’s fundamental to being able to build layers that allow trustless sharing of UTXOs specifically without having every single person sign every single change.
Stephan (13:28.824)
I see.
Brandon Black (13:52.502)
And so that’s why we can’t do these layer twos or layer threes that enable this without this building block of an output restriction covenant.
Stephan (14:00.546)
I see. And now here there may be some people who say, well, what about other alternatives? What about raising the block size? Why is that insufficient or not a good answer?
Brandon Black (14:14.794)
Well, I’m ready to get cancelled. I’m personally not entirely against raising the block size. I wouldn’t say that’s absolutely a wrong answer. I don’t think it’s the time right now. I think we can tell it’s not the time because of the number of JSON blobs being mined right now. It’s clearly not yet. But it could be the time someday in the future to raise the block size. So I’m not excluding that as an option.
Stephan (14:39.415)
Yeah, and just a quick note with those JSON blogs, what Brandon is referring to is like the BRC 20 and some of these different protocols, kind of people colloquially call them ordinals, but there’s kind of a range of these different protocols. But yeah, go on, Brandon.
Brandon Black (14:53.63)
Yeah, so I think we should be open to the changes that are necessary and appropriate to building this better system for money. And it’s, like I said, clearly not the time right now to raise the block size. And we can tell that because of the junk happening. If it was time to raise the block size, all that junk would already be priced off the chain. And that’s just like economically tautological.
So what we do need to do right now, I would say, is increase the concentration of value in individual transactions for key holders. Right now, the most secure way to hold your keys, let’s say, is with a three of five multi-sig from someone like CASA or other people that might support that, or your own three of five multi-sig. That’s kind of the gold standard at the moment in holding your own keys.
Right now, moving coins in a three of five multi-sig costs like $50 or something or maybe even more. And that’s bad. So how do we improve that for people? Well, one thing we can do is by making multi-sig less costly through protocols like Frost and Music. But another thing we can do is enable people to trustlessly share UTXOs so that people who have, let’s say, similar goals, similar ways they use Bitcoin can collaborate.
to make smaller and fewer transactions when they need to move funds between each other or even inside and out through the Lightning Network. If we can coordinate and share our transactions, then each of our transactions can more easily price out some of these JSON blobs that are polluting, according to some people, our block space. And so there are things we can do through cryptography like Frost and Music.
and then also through covenants and sharing UTXOs that let us price this other stuff maybe off the network. And then once we’ve done everything else we can think of to price that stuff off the network, maybe someday in the future, it’s time for a block size increase because we’ve already done everything else we can.
Stephan (17:02.55)
And so as an example, people talk about like multi-party lightning channels. As an example, where maybe instead of having a two-person lightning channel, we could have a five-person channel or a ten-person channel and that kind of thing. And so maybe that’s one idea where we can amortize the cost of, let’s say, in that future, hitting the chain in fiat terms costs $200. But because we’re dividing it by ten people, that’s $20 each. Right? That’s an example, right?
Brandon Black (17:29.846)
Yeah, exactly right. And we know we need to be very realistic.
covenants of the basic sort, the CTV sort, won’t immediately enable many-party lightning channels. But they might enable something like John Law has a post, which is very, very technical, but gets into this concept called timeout trees. And it might enable something like that, which timeout trees enable you to kind of have a shared UTXO which spawns many one-to-one lightning channels, which is almost the same as a many-party lightning channel, but not actually the same.
And it does enable many more people to use Lightning because you can have a single UTXO and from that one UTXO you can spawn many channels to many different pairs of people. Typically I think in his protocol it’s all the channels are from one party to the central holder of the UTXO, kind of the coordinator. But it’s done trustlessly. Instead of right now that’d be wallet of Satoshi with output restriction covenants like CTV, you can make that a trustless version of…
a kind of semi-custodial relationship where there’s a central coordinator, but you don’t have to trust them. You can always exit on chain if you have to.
Stephan (18:43.842)
Right, and so that’s kind of this idea of unilateral exit. Now, one other thing that people may be thinking there is, okay, well, even if you created all these off-chain channels that haven’t hit the chain yet, what about this kind of exit problem? Like, what if lots of people need to hit the chain? Aren’t you kind of just setting them up to fail in the future if they’re not actually able to, you know, because it still has the same blockchain limits, right?
There’s still 210 million transactions per year, roughly. So how do you answer that kind of critique?
Brandon Black (19:16.342)
Yeah, and people talk about this rush to the exits problem. And it’s absolutely the hardest thing to reason about and let’s call it worry about with any of these many party UTXO sharing protocols. People talked about it with ARC when it was announced and proposed and same with Timeout Trees. And I think the way to look at it is…
Brandon Black (19:43.19)
We aren’t gonna solve everything right now.
But we can start small, we can start getting people sharing UTXOs. And so even if right now the only people sharing UTXOs are the relatively wealthy Bitcoiners who can create kind of semi-small shared UTXOs, maybe 10 people. If you have a 10 person shared UTXO, there’s not really any rush to the exits, no worse than a lightning exit really, right? Lightning closes are fairly large transactions.
And it’s about the same if you have a 10 person UTXO exiting on chain. It’s gonna be similar in magnitude to a lightning channel force close. So we can start there. And yeah, maybe when you try to get 10,000 people in one, we have this rush to the exits problem, but that’s not where we’re gonna start. We can start scaling with 5X or 10X with UTXO sharing without really worrying about that rush to the exits. I think people tend to go like.
to the extreme and say, well, yeah, there’s this extreme version of this where it causes all these problems because no one’s ever gonna get their transactions confirmed because there’s a hundred million people exiting all at the same time. But we’re not gonna do that tomorrow. We’re gonna start with building the protocols. We’re gonna start with getting a few people using it. We’re gonna reduce costs, right? Even if I get only a 5X reduction in my on-chain costs, because I’m in the five person share of GTXO, well, that’s $10 instead of 50. That’s great. Let’s start there.
Stephan (21:08.106)
Okay, yeah, and to be clear, that’s in one context. There’s also other possible protocols that are being enabled here. So that’s also part of what we’re getting at. So one other thing people might be thinking is, what about side chains? Why not have side chains instead of covenants?
Brandon Black (21:28.074)
You know, the arguments on both sides of sidechains are fascinating. I think I can’t personally escape the argument that sidechains result in an effective block size increase on the miners. Doesn’t, it has different properties than a block size increase for everyone. Not everyone has to care about the sidechains necessarily, but for the miners.
the side chains, even with the blind merge mining that people talk about, like there’s all these ways they try to kind of avoid this problem, but the result seems to always devolve to you. Miners will be incentivized to run the nodes for all the side chains. And if the miners have to run the nodes for all the side chains, it’s effectively that they’ve increased the block size of Bitcoin because their verification work is, and their block templating work is equivalent to if we’d increased the size of the Bitcoin blocks.
And that increase in work for the miners, the increase in the complexity of building templates, the increase in the complexity of transaction acceptance and confirmation is a centralizing force on miners. We already have a problem of mining being too centralized with few pools. If we make it more costly to select transactions and blocks, we’re gonna have further centralization in the mining industry. And I think we need to be fighting in the exact opposite direction.
So that to me is the thing that says I’m just not interested in sidechains. I don’t want to further pressure miners to centralize.
Stephan (22:58.798)
Okay, gotcha. And so, if we were to talk about some of the different kinds of changes that have occurred in Bitcoin’s history or possible changes, right? There’s things like soft forks and hard forks and different variants of those. Can you just outline what some of those are?
Brandon Black (23:22.294)
Yeah, great question. I saw a talk actually, it was in one of the Miami conferences. I know Jameson and some other folks were on a panel and they were talking about soft forks versus hard forks. And one of the key points that I took away from that was not all hard forks are bad and not all soft forks are good. And I think that’s something really important to think about. You can have a soft fork because soft forks just mean that it doesn’t.
make valid a transaction that was otherwise invalid. Because if it did that, the previous nodes would break off from the network. So you can make a soft fork that disables OpChekSig and makes everyone’s coins unspendable, right? That’s a soft fork change to Bitcoin. That would obviously be a bad soft fork. And so since we can imagine obviously a bad soft work, we have to…
find some other metric for evaluating changes to Bitcoin. People have built their brains around this hard fork, soft fork idea, but it’s not the only way to evaluate changes. So I like to look at it more in terms of kind of scope and risk. In Bitcoin, we’ve had, at least since I’ve been conscious of Bitcoin changes, which was a couple of years into it, two major changes that really did surgery on how the Bitcoin protocol works, and that was SegWit and Taproot.
So those are big high risk changes. We’ve had many smaller changes. We’ve had check lock time verify and check sequence verify that were added to support lock times and lightning network. And they’re trying to think about this, but there have been other smaller soft fork changes. And we need to think about those things very differently. One can really dramatically shift the incentives of the network.
and the other one enables some additional scripting capabilities.
Stephan (25:25.61)
Okay. And so I guess one other thing to… We haven’t really gone deep into exactly what is Bitcoin’s scripting engine and we’re not looking for like a super technical explanation, but could you just give us a sense of like, what is Bitcoin’s scripting engine? What does it mean for being able to make layer twos?
Brandon Black (25:50.434)
That is a hard, hard question. So Bitcoin.
We don’t know the mind of Satoshi when he was designing Bitcoin, obviously, but we can at least try to think about his goals and what he was building an electronic cash system with this ledger that we update to move funds around within a network. He had a couple of choices he could have made there. And one would have been to say, you know what, I’m going to hard code into the blockchain, into the consensus, exactly the ways people can restrict their coins. He could have said, you know, all you can do is set a public key.
And when you want to spend it, you need a signature. And that’s the only way you can lock and then spend Bitcoin. But he was conscious of the idea that, or at least, again, I’m theorizing here. It seems like he was conscious of the idea that people would want to have different kinds of restrictions on how their funds are spent. They might want to have multi-signature. He added an OPCHEC multi-sig. But they might also want to have a couple of different ways it could be spent. You know.
This one super secure key or my family’s multi-sig. And so realizing that he couldn’t predict all the possible futures, I think he gave us… I’m talking like he’s a god or something. He gave us a scripting language. And so that scripting language lets us combine different conditions on spending Bitcoin. It’s a pretty simple language. It’s not very… it’s hard to program in. But it lets us have enough expressivity to express a variety of different restrictions on our coins through different branches in a script.
And that’s really what the scripting language is about. It’s about ways to describe in a difficult to use but expressive enough language what kind of restrictions there are on spending some coins.
Stephan (27:34.93)
Got it. And so, yeah, in simple terms, it’s kind of like you are making a program that allows you to unlock these coins and having different opcodes gives you different ways you can lock those coins up. And so kind of loosely speaking, that’s what Bitcoin scripting helps us do. And you might.
think, like listeners might think, wait, hang on, why do I want to lock up my call? I just want them to be accessible to me all the time, right? But the reality is by using some of these constructs, you can build things that have better functionality. And I’ll give an example, and obviously you’re familiar with this, but just for listeners, checkLockTimeVerify and CSV, checkSequenceVerify. So these relate to an absolute lock time and a relative lock time. And this is what we use.
and it’s used by the Lightning Protocol developers in Lightning. And that’s actually what allows a routed network. So in Lightning, when you have your connection with other nodes, and those nodes are in turn connected to other nodes on the Lightning network, when they’re forwarding and receiving these payments, they need this relative lock time capability to be able to do this feature of saying, okay, I’ve received the coins upstream, and I’m not going to release the coins downstream until I’ve got my upstream coins that came in. And in the kind of, if you dig into the…
the coding of it, they’re using these lock times to achieve that. So that’s an example of how these opcodes that might seem like they’re restricting the coins, they’re actually used to achieve something like the Lightning Network as an example. And so I guess it’s interesting because a lot of people came to Bitcoin in more recent years. And so CLTV and CSV,
came in and I can’t remember the exact day, but maybe 2014, 2015, something like this. And so there’s a lot of people who’ve come to Bitcoin now saying, oh, as it is now is great, let’s just freeze it now. But it’s almost like, imagine it this way, if CLTV and CSV were invented today, would we be able to soft fork them in or would it be sort of a big controversy? Oh, you’re trying to lock, you’re trying to time lock coins.
Brandon Black (29:47.082)
Yeah, no, that’s exactly right. And that’s why I talked in El Salvador, I think we need to think about what it means to be a covenant. And I kind of alluded to it at the beginning of this conversation, even, you know, covenants just mean restrictions. And we already have restrictions, right? What you could say that the Czech SIG opcode that is the basic thing we all use for our single SIG Bitcoin is the Czech SIG. You could say that that’s a covenant, right? It’s a signature covenant. We have time covenants.
So this word covenants has become a bit of a bugaboo and along with, as you said, the idea of changing Bitcoin becoming a bit of a bugaboo. I wanted to dive in a little bit more on Lightning because I think it’s really a fascinating case study in changing Bitcoin to support layer twos or layers. The original Lightning paper was…
limited because check sequence verify didn’t exist yet. And so because check sequence verify, the relative time locks you mentioned didn’t exist in Bitcoin yet, the original Lightning Paper had channels that were limited in how long they could possibly stay open. And at the beginning of the channel, the time locks were longer using the absolute time lock of check lock time verify. And then as the channel aged, those time locks would shrink in.
to the point where the channel would become unusable. And so the Lightning developers talked to the people who worked directly on Bitcoin Core. They discussed various ways to solve that. And Check Sequence Verify was the solution that came up with, because with the relative time locks, you can now have channels that live forever. And that’s the Lightning network that we all know and love today. But can you imagine the Lightning network where you had to close channels every two months? It would have been so much more difficult to use. So…
Even from the lightning paper itself to the implementation of lightning network that took years as everyone talks about the years it took to put lightning, Bitcoin was modified over that time to facilitate a better lightning network that is more usable today.
Stephan (31:50.322)
Got it. And so I think that hopefully helps spell out some of the ideas around relative size of changes to Bitcoin and the impact of changes to Bitcoin. I think it’s also important to spell out that this is opt-in, right? Like the idea of this is, if you don’t wanna use covenants,
You don’t have to, you can just keep using your standard single signature and your multi-signature and your lightning today and just not use any of the other CTV stuff. That’s at least the goal that the developers or the people who are pro CTV or other Covenant. So let’s walk through, let’s list out some of the ways that you believe Covenant could help scale the users or the payments of Bitcoin.
What are some of the high level ideas, as you’ve mentioned some already, but just to spell those out for listeners, what are some of the benefits that you could see with covenants such as CTV?
Brandon Black (32:50.006)
Yeah, we talked about really some of the best ones already, which is like the timeout trees that John Law mentioned, where you can have a untrusted party with whom you hold some funds in a timeout tree. And whenever you want, you can spawn a lightning channel with that untrusted party. And through that lightning channel, you can make payments for the duration of the timeout tree. That’s a, I think a great proposal.
It sounds in some ways similar to ARC by Barack, so that’s another proposal that’s out there. Both of these proposals rely on the thing that we already mentioned, which is that with CheckTemplateVerify in particular, the untrusted coordinator can commit to, until sometime in the future, you have the absolute ability to trustlessly exit this construct.
because it’s locked into a check template verify that restricts the outputs of where it can go. At some time in the future, I as the coordinator can claim all those coins. And so the one thing that affects the trust here is that the users must come online periodically. So that’s probably the, as of now, and there’s lots of work being done. That’s probably the most compelling use for check template verify that would be good for users. Because with this structure,
of periodically timing out trees of transactions or lightning channels, depending on what proposal you’re talking about, arc or timeout trees, the coordinator remains trustless.
but they can also recover their liquidity if users become unresponsive. And while people feel, oh, that’s kind of scary. What if the coordinator becomes evil? Well, the more likely case, just because of…
Brandon Black (34:41.494)
Why is it more likely? The more likely case is that this actually helps users. The most common way that people use their Bitcoin is they lose their freaking keys. It’s not theft. I guess it’s rugs if you don’t hold your keys in the first place, and then it’s people lose their own keys. I actually don’t know which one of those is actually more common, but those are the two most common ways people lose their Bitcoin. And with something like this ARK or these Timeout Trees, a user, if they lose their keys, they can say to the coordinator, hey, I lost my keys.
When this times out, can we coordinate a process where I get my coins back or minus some finder’s fee? But instead of losing all your coins, you probably get some back because the coordinator is incentivized to be nice about that kind of stuff. And I think that’s a really compelling user story that people, I think a lot of us in Bitcoin, we discount that, right? We’ve gotten good at holding our own keys and keeping them alive on steal or whatever. But is your grandma gonna make a steal backup of her seed? No, she’s gonna have it on our computer and she’s gonna lose the password.
And with these timeout trees or with Arc, at the end of the timeout, whatever that is, she can probably get at least most, if not all of her coins back. But in the meantime, if people hold their own keys, it’s completely trustless. And that mix of properties, I think is amazing for users.
Stephan (35:58.246)
Great. And are you able to explain non-interactive channels and any thoughts on that?
Brandon Black (36:07.302)
Yeah, I can do a little bit. I’m not the best person on that. I wish I had a little bit more depth on it.
Brandon Black (36:16.026)
Long and short here, with CheckTemplateVerify, we kind of already talked about how CheckTemplateVerify lets me restrict where the next step of these coins can possibly be. And with Lightning, the way that we make a channel work in Lightning is that both parties sign each update to the channel. And that lets us coordinate payments in either direction because without trusting each other, we coordinate signing. Okay, I sign the updates, and it’s most important that I sign when I’m paying you. And it’s…
Most important that you sign when you’re paying me, right? Because otherwise, how do I know that you’ve actually kind of transferred the coins with Enlightening? But with CTV, one party can not interactively transfer funds on a channel to the other without needing to sign it and get the kind of the counter signing thing with penalty that happens in Lightning because with CTV, you can say the only possible place this output script can go is this specific set of outputs that pays you more than me now.
And so you can make channels where one party can unilaterally send funds in one direction. And so you could have an LSP that without the user needing to be online, they can actually transfer funds down to the user. Or inversely, you could have a payments only channel where you don’t have to be online, but you can, from a phone, you can text updates about essentially to your receiving party because it’s a non-interactive channel in one direction.
And so that’s basically the structure that is possible when you don’t have to sign both sides each time you wanna make a channel update because you can restrict the exact outputs and change that trust dynamic in the lightning channel. So single direction, non-interactive channels is the thing that I know at least a little bit about. And it takes one set of signatures out in a single direction channel.
Stephan (38:07.066)
Right. Okay. And yeah, so now let’s talk through some of the different covenants proposals, right? Because there’s a, that’s the other aspect, because there’s, I think for a lot of people who aren’t deeply into the technical weeds here, they’re hearing all these different covenants ideas. And it sounds a bit like, Whoa, there’s CTV, there’s TX hash, there’s op cat, there’s APO, there’s check sync from stack, there’s op vault. Like we need to sort of disaggregate some of these.
So would you mind just walking us through some of these just one by one if you could kind of give us the sort of simple explanation of what these things do. So let’s just start with CTV. So, you know, what’s CTV in English?
Brandon Black (38:48.562)
CTV in English. I’ve actually come around to it recently to kind of a new explanation of CTV in English that ties right into what I was just saying. We’ve probably, many of us heard of the idea of a pre-signed transaction, where you can make a transaction and pre-sign it and then put it away somewhere safe, but that lets you anytime in the future send that transaction without having to go to your signing key and make a new signature for it, right? CTV lets you…
make that same kind of a concept, a predefined transaction, but without having to sign it.
So it’s a pre-signed transaction without having to sign. So it saves space when you’re doing that kind of thing. And it also saves accessing secret key material to do that kind of thing where you’d want a pre-signed transaction. It also therefore, people may have heard of the idea of deleting keys. The original vaults concept that I read about involved making a temporary signing key to construct your vault structure, and then signing a bunch of transactions in the vault, and then deleting the key. Well, cryptographically speaking, there’s no such thing as a deleted key.
It is impossible fundamental information theory to prove the deletion of a key. With CTV, since there’s no signing involved, you can make that same kind of a vault structure without having to trust this impossible deleted key concept. So that’s CTV in a nutshell. It lets you do everything you could do with pre-signed transactions without having to do the signatures or deal with the key material related. So that’s CTV.
Stephan (40:16.866)
Okay, great. So let’s now talk about Tx hash. This is another one. What is Tx hash in English?
Brandon Black (40:27.134)
Wow. TxHash lets you restrict any aspect of the next transaction when you make your coins. The idea with TxHash, the Bitcoin transaction that goes on the blockchain has many little details about the coins being spent and the coins being created in it. And TxHash lets you specify any little piece of that transaction and then restrict that.
or do some basic logic on that. You can do things like the amount must be equal between an input and an output, or all amounts must be equal, like for a coin join. And TxHash lets you do all of those kinds of restrictions because it lets you pick and choose pieces of the transaction and put a hash of those pieces into your program, into your logic for restricting your coins. As you can kind of imagine, being able to pick and choose every little piece of a transaction is a…
complex thing to describe. Transactions can have any number of inputs and any number of outputs. So how do you make an operation that can pick pieces of that and put them in your program? And so that’s the complexity. So I would say TX hash is very cool and it’s also very complicated to describe and to work with because of having to pick and choose every little piece of the transaction you want to look at. One other thing to say about TX hash is that it
within at least the proposal for it right now, it has a default mode and the default mode is almost identical to check template verify. It uses the same opcode in Bitcoin script. You couldn’t activate both TxHash and CTV as written because they use the same opcode. Because the way we upgrade Bitcoin script is that we take opcodes that were previously not available and we describe new behavior for them. And so TxHash and check template verify.
use the same opcode or one of the same opcodes. So they currently collide with each other, which is okay because the default mode for TxHash is the exact same thing as check template verify, which is it restricts the exact next transaction outputs in the same way as CTV does. All right, so that’s TxHash to the best I can do in English. It’s a pretty complex idea, but it lets you pick and choose and restrict any part of the transaction.
Stephan (42:50.278)
Right. And now, what about OpCat?
Brandon Black (42:55.634)
Upcat is deceptive, much like meow. It’s this tiny little change. It can literally be coded. I think it’s either 12 or 16 lines of code change. And listeners, I think are gonna be blown away by this. All it does is take two things in your kind of program space where you’re writing your locking conditions and smashes them together. Concatenate, it’s short for concatenate. And so that’s all it does.
But because of programming and the fact that there are other script opcodes around us with opcat, you can emulate checksig from stack. You can emulate cat. You can emulate most of TX hash. These scripts are kind of ugly and difficult to reason about. But it’s, it’s this, it’s this very strange and difficult to, to wrap your brain around property of opcat.
which is that in 12 or 16 lines of code, you could end up really changing the dynamic of what can be done with scripting.
Brandon Black (44:05.39)
to the point that I like up cat, I like the simplicity of the code, but I personally feel a little bit uncomfortable about the idea of adding up cat, which kind of brings us back to this topic from earlier about like how big our changes, what are the impacts of changes. CTV has a very limited change scare factor, if you will, it does a very specific, very simple to describe thing. Tx hash is…
kind of a little bit more because it lets you reason about the amounts in a transaction and then cat lets you do all kinds of stuff in 12 to 16 lines of code, get all this stuff that could happen. So, that’s opcat. It’s very simple to code but very complex to reason about the implications of.
Stephan (44:50.486)
Okay, and just for completeness, I mean, you actually already answered this on the last podcast you did with me, but just for completeness sake, what’s APO, any prev out, in English?
Brandon Black (45:01.79)
Yeah, and any prevout is a new way to restrict transactions by signing them. So we talked about how CTV lets you restrict transactions without signing. APO lets you make a signature that could be valid for several different transactions because it doesn’t specify exactly which coins you’re spending in it. And that
It’s a very interesting new property we can have on signatures. Right now, all the signatures that we make restrict at least one specific coin being signed. There are ways to restrict only the one. You can have a signature currently that takes one of your inputs, but lets other people add pieces of their coins. So the same transaction, that’s called a anyone can pay signature. With any prevout, you can say, I’m gonna let this spend any of my coins.
that were sent to the same address, as long as they’re spent in this way. So you can kind of make something like a CTV with this, where you say, if you sign with APO and what’s called the all flag in terms of signing the outputs of a transaction, you’re saying any coins that are sent to this address, by signing this, I’m saying they can be spent to exactly those outputs, very similar to CTV. For the purpose of lightning,
APO is a very helpful opcode or not opcode, it’s a cache mode. Um, because it lets the.
Brandon Black (46:37.95)
It lets new channel states replace old channel states on chain. Because it doesn’t commit to specific coin being spent, you can say this new channel state can replace any previous channel state because all the channel states go to the same address. And so that’s kind of why APO is very useful is that ability to restrict any coins that go to the same address and let new channels keep using the same address throughout the updates to the channel.
Stephan (47:03.766)
Yeah. And so that’s also where, so listeners, you can check out my earlier episode with Christian Deco, where we talk about APO, L2. Also, I’ve got an episode with Greg Sanders talking about LN symmetry. So APO is basically the one that most Lightning Protocol developers would like so that they can get LN symmetry, which makes backups easier and potentially enables, you know, more advanced forms of the Lightning network, let’s say. So that’s that one. And then…
Check SIG from stack. What’s that?
Brandon Black (47:35.19)
Yeah, so I wanna throw one little tibet-o-ap-o in here, which actually ties into CheckSig from stack. APO itself isn’t directly a covenant opcode or something, right? It’s a new way of signing, so that doesn’t seem like a covenant. But because it signs in a way that doesn’t restrict the specific inputs being spent, it can actually be shifted where the signature goes in your locking script and used just like CTV.
Stephan (47:38.563)
Oh yeah, shotgun.
Brandon Black (48:03.434)
So you can use APO by throwing a signature in your locking program instead of in the way, like normally you put a signature in your unlock, right? With APO, you can put the signature in the locking side and it acts a lot like CTV in that case. And so that’s why it comes up in these covenant discussions is because soon after APO was proposed, people realized that you could start putting signatures in your locking script and then use it like a covenant.
And that made the whole conversation around APO more complicated, because now it’s not just a new way to sign transactions, it’s also a way to get a covenant into Bitcoin. And then people have that whole conversation about covenants. So that’s something important about APO. To flip that around, so you can use APO to get something like CTV, you can also use CTV to get something like APO. And the way you do that is with CheckSig from Stack. Because with CheckSig from Stack, you can…
check a signature against whatever data you might have in your script, which might be a hash that was verified with CTV. So CTV verifies the hash and then you check a signature on that hash and you effectively replicated the behavior of any prevout. That starts to get a little bit hard to think about, but that’s probably the way to tie these three proposals together is that CTV plus checksig from stack about gets you APO and
APO about gets you CTV by adding a signature to it. As a result of this aggregate versus disaggregate functionality, CTV plus CS, check-sig from stack, CSFS, is a little bit more flexible. You can do a little bit more with it. So we talked about how cat is this tiny change that does everything. Check-sig from stack is a small change that does something.
The other thing that you can do with check sig from stack is you can check signatures on other data. So this doesn’t this enables about the same kinds of things on Bitcoin as you can currently do using the concept of scriptless scripts or discrete log contracts or adapter signatures these are all terms that are thrown around.
Brandon Black (50:16.182)
CheckSig from Stack lets you do a lot of those same things where an oracle says something and then you have a check against that oracle in your script. But it lets you do them kind of more directly in script as opposed to in these scriptless scripts. So that’s the other thing that CheckSig from Stack allows is those kind of oracle type applications in script.
Stephan (50:35.222)
Okay, and now not directly related but OpVault is something that kind of is spoken about as well. So can you just explain a little bit about the idea of OpVault even though I’ve done an episode with James Obey as well for listeners.
Brandon Black (50:48.642)
Yeah, I- I’m fault.
First of all, Upvault uses CheckTemplateVerify to accomplish its goals. So any conversation about Upvault is implicitly saying Upvault plus CTV, at least everyone that I’ve seen. Because the way Upvault works is that you make an intermediate transaction when spending some coins from a specific address. And that intermediate transaction says, wait a few minutes, it could be any number, and then spend it to this specific
destination using CTV. And that restriction during those few minutes, there’s an opportunity for the user of OpVault to send their coins to some safe location, whatever that might be. So you can imagine you might have a hot wallet, single SIG that’s built using OpVault. And so every time you make a spend with that, you have to wait 30 minutes, let’s say. During those 30 minutes,
If that spend was illegitimate, because someone stole your phone and was trying to send all your coins to themselves, if you can see that in those 30 minutes and send them to a Kasa vault, or send them to Coinbase even, you can send them wherever you want, as long as you have an address you can encode into your OpVault restricted address. And so this is a great, I think to me at least a great addition to Bitcoin, where you can have your spending Bitcoin available in an effectively hot wallet.
but it’s a hot wallet with a pause. And that’s, I think, a very powerful construct.
Stephan (52:20.11)
Right, okay, yeah, so it basically allows people to sort of have a get out of jail free card, it’s sort of, like they could sort of have this concept where maybe their main setup gets compromised somehow, and they could sort of have a watchtower that watches the chain and then pulls the coins to their secondary setup. And that’s, you know, achieving, like you said, CTV and vault, or using CTV and vault to achieve this security feature. And…
I think it’s also important to add that this could be layered on top of multi-sig. So that user could be using multi-sig and layer on a vault on top of that. So that’s why people like Jameson Lopp, CTO and founder of CASA has spoken positively of that vault feature. And I believe NVK from CoinKite might also be interested in that feature too. So I think let’s talk a little bit about some of the different proposals that are floating out there. Because that’s also, you know, like we’ve spoken through some of these
concepts that relate to Covenants, but now there’s different, I guess, combinations of proposals out there. There’s people who, let’s say, you know, there’s just bare CTV, only CTV, and then there’s people who want, let’s say, you know, APO or, you know, APO and CTV and OpVault. So could you just explain some of these different combination proposals and at least where we are today with those in December 2023?
Brandon Black (53:39.958)
Where we are today. As of now, none of these proposals has gained very much traction. Just to be very, very clear about that. Different people, James Eberin proposed CTV plus APO plus vault, which is in a very powerful set of tools. He called it the covenant tool soft fork. I’m working on one myself right now. I’m not gonna shill it right now. It’s not quite ready yet.
Brandon Black (54:08.034)
So yeah, long and short, none of these have much traction. In terms of combinations, most of these proposals don’t really conflict or cause weird interactions. I already mentioned the one that does conflict, which is Tx hash and CTV, but it conflicts in a way where if you do either one, you get CTV. So it’s kind of an okay conflict, let’s call it.
Brandon Black (54:30.966)
So yeah, where are we today? Many people want just CTV. That seems to be the thing, the closest to consensus, but it doesn’t give us L2 Ln symmetry on its own. And so that’s why we see these things of like CTV plus APO because obviously lightning development and lightning users are a very important part of the Bitcoin ecosystem. And so as of right now, we find ourselves in this very strange political situation for Bitcoin right now.
where really for the first time in Bitcoin’s history, to make a change to Bitcoin, you need to build kind of a, or it seems like, I guess I don’t know, we don’t know what it takes to change Bitcoin right now. It seems like you need to build kind of a political coalition. I think that’s a bad thing.
Stephan (55:14.762)
Right. And there’ll be people who disagree with that very idea, right? They’ll say we shouldn’t have a we shouldn’t be having any political coalitions. It should just be about is this good or bad for Bitcoin, etc. Right.
Brandon Black (55:23.686)
Yeah, yeah. So I’m not a fan of it, but that’s the way it seems, right? Many people won’t even talk about a soft fork unless it enables L2 or Ln symmetry now. And that’s a weird situation because we talked already about check sequence verify being added for Lightning. You know, many, many Bitcoin users didn’t care at all about check sequence verify, but it was good for Lightning and it didn’t really hurt anybody else’s use of Bitcoin. So there was no reason not to do it really.
And, and I, it’s so hard to know what even is the right thing to say about this, because it’s just the nature of the evolving system of Bitcoin that right now, it seems like we need this political coalition to move Bitcoin forward to change anything about Bitcoin. But that’s a difference than the past. Maybe that’s a good difference. Maybe it’s good that we now have to, you know, get lightning and on chain and
let’s say custodians who want vault all on board together in order to move Bitcoin forward. Maybe that’s the way it should be. But that doesn’t feel right to me necessarily. So I think it’s a it’s a weird time in Bitcoin. Yes, where we are in 2023 December. That’s where we are. It’s a weird time in Bitcoin. Things are different than they ever have been in the past. There are a lot of different a lot of people trying to move this conversation forward of, you know, let’s make Bitcoin better for more plebs to hold their own keys.
And we don’t know what it’s going to take and we don’t know what proposal is going to kind of carry forward. But I don’t remember everyone all of your listeners to join the conversation. We have a pretty active conversation going on X nowadays with lots of people asking questions. We’re having spaces pretty often. So anyone is welcome to join and ask questions about the future of bitcoin and to kind of join this conversation about how and if we change bitcoin going forward.
Stephan (57:18.886)
Yeah. So the other big question people will have is what about unforeseen, you know, consequences, right? And so obviously rightly or wrongly, some people are pointing to, you know, this recent ordinals and inscriptions and BRC 20 and all these other things. As though that was uniquely enabled by SegWit and Taproot. And so in their view, it seems like, oh, see, you’ve got air on your face because you enabled this thing and now it’s blown up in your face. Now.
we can disagree, like maybe that’s not actually correct because some of these things were like, as some of the online commenters are saying, all this BRC 20 stuff would have fit or is less bytes than an opreturn anyway. So it could have easily been done with that already. But if you could answer the underlying sort of criticism or question, which is, hey, what if you enable this additional covenant feature in Bitcoin, this additional opcode or…
Sig hash flag like APO or something like that and it blows up in our face.
Brandon Black (58:20.362)
Yeah, I absolutely understand people’s trepidation. We, they say that money is one of the things humans are most emotionally attached to, the cause of relationship strife and all this other stuff. So we get very emotional about our money. And so we talk about the impact on people’s use of their money right now, where many people right now can’t use their money because fees are so high from the BRC 20 JSON blobs.
So I get the emotion, I absolutely get it, and I wanna emphasize that.
Brandon Black (58:56.374)
So yeah, unforeseen consequences. How do we deal with that? I think we talked a fair amount about it in this, which has been great, what’s the scope of different changes? And so if you kind of look at everything we just talked about from, in terms of what the scope of different things is, the greatest scope change that we’ve talked about in this conversation is Opcat. Opcat dramatically changes the abilities of Bitcoin scripting.
We talked about Tx hash. That’s probably the next most flexible, maybe a tie between Tx hash and check sync from stack.
Brandon Black (59:38.602)
Now I think txthash is more flexible, it lets you do more. And so the point I’m getting at here is that the more flexible something is, the much more likely it is to have unforeseen consequences. So segwit was a big change, changed how we do scripting in Bitcoin fundamentally and moved a bunch of data out of the transaction body, essentially, and made it verified separately with a separate commitment. Taproot was another big change. It was a new segwit version, it was a new script verification, it was a new way of doing addresses. None.
of the chains we’re talking about are that big. Opcat maybe gets close in terms of the risk of unforeseen consequences. And then it’s like a huge step down from there to TxHash and then CheckSig from stack and then APO and then CTV. So of everything we’ve just talked about in terms of proposal, oh, I forgot Vault. Vault would be right around APO. So it’s yet TxHash, CheckSig from stack, APO and OpVault.
and then CTV in terms of the scope of the changes and how impactful they could be in terms of unforeseen consequences. And that’s simply because.
Stephan (01:00:38.362)
Gotcha. And so in that context, it’s like CTV is the minimal from what you’re saying.
Brandon Black (01:00:42.73)
Yeah, exactly. Both all of, in my personal opinion, this is now getting very far off into opinions here, anything from Checksig from Stack down is pretty clearly safe in that there’s not, there’s not, we can safely reason about all of the behaviors that it enables. Checksig from Stack is at the threshold of that where there may be some things we can’t fully reason about.
the behaviors that are enabled by it, but APO is very clear. Vault is very clear and CTV is very clear. And you can see that that’s why James O’Byrne proposed those three things for activation together because they’re all clearly below the line of unforeseen. Yeah, yeah, we can very clearly, you know, it’s hard obviously for the average non-programmer, Bitcoiner to reason about these things. So I’m just making that statement, but you can ask, you know, any core developer and they’ll probably tell you about the same thing.
Stephan (01:01:24.986)
safety. Right. Yeah.
Brandon Black (01:01:38.178)
that those three proposals, you know, we can very clearly reason about the consequences of those things.
Stephan (01:01:45.646)
Okay, yeah, and so I think the other element is, could the change be, and I believe I’ve heard James Obey refer to these ideas of like, how confident are we that the change is not pathological in the sense that it’s only impacting those users who opt into it. So I think that’s also an important component to bring up here because in a CTV or APO or OpVault world, how confident are we
that only those users who want to use CTV, APO, or OpVault are the ones getting impacted by it.
Brandon Black (01:02:21.362)
Right, we’re talking about externalities here of using these new things.
Brandon Black (01:02:30.11)
It’s absolutely true that any change we make to the protocol has some level of externality, right? When we enabled check sequence verify, which gave us the usable Lightning network that we have today, that changed the behavior of users of the Bitcoin network. And by the fact that it changed the behavior of users, it did impact everyone using the network. So we have to accept just that.
It’s a fact, it’s a global broadcast network, a change you make to the behavior of some users has some effect on everyone. So what is the level of effect caused by different changes in terms of the behavior of people? Looking at it that way.
Brandon Black (01:03:17.11)
First of all, there’s a huge step separation. In segwit is a massive change in the way people can use the network. Taproot is a fair amount smaller. And then there’s about a mile of distance between those two things and literally anything, including opcat that we’re talking about in terms of externalities on the rest of the network. The reason I say opcat is the top there is it’s very likely that opcat enables
more side chaining than I personally would love to see on Bitcoin. And so opcats at that threshold were like, this might have a significant externality. It might not. I’m not saying it does for sure. I can’t make that claim, but it might. And so that’s why I feel nervous about opcat is it might enable side chaining and that could have a significant externality. When we go below the opcat level of expressivity down to checksicrum stack or Tx hash or APL or CTV or OpVault. All of those.
are at the level of, yes, they’re going to change the way some people use the network, but literally nobody else uses the network has to care about it. It might have some minor effect on, you know, how fee markets evolve at different moments because let’s say up vault, when people spend their coins, it now takes two transactions. So that’s going to have some impact on the on the fee market or, you know, CTV. If 10 people are sharing a UTXO, maybe.
on the occasions when a few of those blow up at the same time, because some design for a CTV, a CTV based sharing requires everyone to go on chain because there was a bug in it, let’s say. We’re gonna see some impact in fees. So that’s the only impact that happened at this kind of up vault or CTV or APO levels is that the behavior of some users is gonna change and have some level of marginal impact on fees.
Stephan (01:05:06.222)
Okay, yeah, okay, so I think those are probably, so I guess just to sort of revise, I mean, I’ve got a few more questions, but just to sort of revise some of the, let’s say, key implications that people might be interested in. So for example, a person who wants ARC, as explained by Barack, would want CTV or TX hash, generally speaking, or I think, was it APO plus checksig from stack, right, would enable ARC.
This idea of time-out trees is enabled just by bare CTV. This idea of LN symmetry is enabled by APO, or CTV plus Check Seek from Stack. And then obviously vaults enabled by OpVaults and CTV, let’s say. So I guess those are some of the ideas around scalability of Bitcoin, security of Bitcoin, and maybe usability of Bitcoin that could be improved, let’s say.
as an example in the ARK context, listeners, you can check out that episode, but the high level way to think about it is you’re creating these virtual TXOs. It’s almost like you can onboard new users without having to do an on-chain transaction. And so that could, you know, depending on if you like the ARK model and the ASP model, that could enable a lot more people to actually use Bitcoin and still have a unilateral exit. And so that could also be important in that maybe it takes some load off the chain. And so that could be valuable
to everybody else to make it feasible for us to be non-custodial and thus enable more than let’s say 50 million Lightning Banks. We could have maybe, I mean, it’s hard to know the numbers, but like it could massively take volume off the chain that in turn enables more people to use Bitcoin non-custodial. Now, I guess the main challenge questions I think people would have for a covenant proponent.
They might say, well, what about proving out commercial demand for these things? Right? Like maybe this is just a bunch of like, quote unquote, Bitcoin wizards who are kind of hacking away and they’re all kind of arguing about what’s like the best or their pet project. Where’s the commercial demand?
Brandon Black (01:07:20.734)
Yeah, that’s a great question. And frankly, it ties back into that question of, you know, do we have to do coalition building? And the kind of the, how do we change Bitcoin? Should we change Bitcoin? All those questions, they tie in here. So when the changes were made to Bitcoin to enable Lightning, you know, the Lightning network didn’t exist. There wasn’t any proof of commercial viability for the Lightning network.
Is that something that’s now required to change Bitcoin? Well, maybe. Bitcoin’s a much different system than it was when Lightning was introduced in 2015 and people started building it.
Brandon Black (01:07:54.838)
So yeah, do we need to have proof of commercial viability? I don’t know. I’ve heard people say things like, well, check sequence verify was obviously useful or taproot was obviously useful. So of course we did those things. We didn’t need to prove commercial usability for those things. But I think that’s disingenuous. I think what’s the honest truth is that the Bitcoin ecosystem has changed since then. And maybe the requirements for changing Bitcoin as a result have changed. Right, right.
Stephan (01:08:21.002)
Right. It’s like a rising bar over time that maybe in early years, it wasn’t such a big deal because Bitcoin was so much smaller. Now, I mean, last I checked, it’s about 840 billion dollar network today and it’s going to probably next few years, it’s going to multiply. And so maybe that means the threshold has to rise for what kind of change is acceptable.
Brandon Black (01:08:40.474)
Right, right. And so I think it’s great to be asking those questions and I don’t think we have a clear answer. I certainly don’t have a clear answer for that. It’s also the kind of the flip side.
Brandon Black (01:08:56.374)
when we were talking about doing the Taproot soft fork, people talked about we’ll do Taproot and then soon after we’ll do Anyprevout. And so companies were actively building products that depended on Anyprevout. And then those companies had to die because the Bitcoin network never activated Anyprevout after the Taproot soft fork. And I’m not a fan of Anyprevout. This is not me saying we should have done Anyprevout right then. I’m just saying this is a fact of what happened.
is that companies started building and they spent money and resources and time, the most valuable things in the world, they spent on developing products that depended on APO and then APO never happened. It hasn’t happened yet, right? So how do we say that we need to build products or prove out market validity when we actually can’t as a Bitcoin community say that we even know how to change, how to do something? So my personal take, now we’ll go off into opinion land here, is that
we should make some change. And that’s kind of why I end up falling in, even though I like other things too, I fall into the CTV only camp most of the time, because CTV is the least risky change that’s currently being considered for Bitcoin. And by doing CTV and proving as a community of all the Bitcoiners that we can indeed still change Bitcoin, at least for now, then.
we can start saying, okay, let’s prove out commercial validity. And we can say, yeah, when commercial validity is proved for things, we’ll continue changing the Bitcoin network. But right now, if we say you have to prove commercial validity before we change the network, no one’s going to believe that they’re going to say, you’re going to screw us. Like you screwed the APO people.
Stephan (01:10:36.11)
Yeah, and maybe this is just going to be a stiff answer, but maybe that is the answer, that you just have to prove out commercial validity to even have a chance. And you know what, maybe there’s a lot of hodlers who are like, yeah, don’t, I don’t want to change unless you’ve proven it out first on CigNet, Regtest, and Inquisition, and some of these other kind of…
proving grounds, let’s say, or on liquid as an example. They might say, look, you should prove it out on liquid, prove it out on SIGNET, Inquisition, prove it out over there, and if you can sort of really see commercial demand there, okay, now we can have the conversation, we should have a soft fork to bring it into Bitcoin.
Brandon Black (01:11:11.822)
So to be clear, like there are CTV vault implementations, James OB did one on Cygnet. There’s, I don’t think it’s running anymore, but Jeremy ran a, Jeremy Rubin that is, ran a CTV specific Cygnet for a while with lots of applications that worked on it. So it’s also, the other thing I’ll say is here, it’s hard to know what it.
what it means to prove commercial viability because people have built things on CTV and had built things on APO and they had products that were close to ready to launch but then no one would actually take action to activate them on Bitcoin. So if we’re gonna have that as the bar as a Bitcoin community, we have to have commercial validation before we activate something.
we at least also should be incumbent on us as the Bitcoin community to set that bar in a clear way. Is it a product demo? Is it a wait list to sign up for a product? What does it mean to prove commercial validity before we launch some feature on the Bitcoin network? Because right now, I’ve seen a lot of things done for both APO and CTV that to me showed clear commercial demand and clear interest from the business community, and they’re not on Bitcoin.
Stephan (01:12:30.022)
Yeah, and it could just be that maybe that wasn’t enough. I don’t know. I’m just speculating, right? Like maybe that was just not enough. Like that maybe a few people kind of talking about it wasn’t enough to sort of get people interested into it. And maybe, and I’m not saying this is a good thing, but it may be that we have to see another really high fee.
Brandon Black (01:12:34.294)
Hehehehehehe
Stephan (01:12:50.938)
demand market before people then are open to more of these ideas of saying, oh, okay. You know, as we saw in the recent fee spike, it went up to off the top of my head around 700 Satoshi’s per V by in that range. Um, and in Fiat terms, that was maybe 50 or $60 per, you know, to get next block transformation, uh, confirmation. And maybe we have to see a sustained high fee market before then people are like, oh, okay, yeah, all right, let’s talk about CTV or APO or something.
I don’t know, maybe that’s one thing. I know some Covenant promoters, I believe some CTV promoters are already talking about activation now. So do you know exactly what’s happening with that and why they’re talking about that?
Brandon Black (01:13:36.17)
Yeah, it’s been an interesting conversation.
Brandon Black (01:13:42.378)
Everything old is new again. So Jeremy Rubin pushed for activation almost two years ago, I think. And, uh, that was considered an attack on Bitcoin by some because he proposed specifically a speedy trial activation, which
There are many arguments about activation methods. I am not interested in them. I don’t care. Some would say that speedy trials and attack because it lets the miners decide whether something activates or not. I don’t know. I don’t care. It’s not my area. So talking about activation right now, it’s almost the same thing. People have been researching for years now the things you can do with CTV.
We’ve seen significant advancement in the state of that art with ARK and Timeout Trees, even in that time since Jeremy Rubin tried to push for activation of CTV, we’ve seen more clarity on what kind of vaults you can build with just CTV alone. And when people get excited, they get interested in something that enables features that they think are very valuable for Bitcoin, that are gonna make Bitcoin better for the rest of the world to use, they wanna see it on Bitcoin. And so some of those folks…
at moments, myself included, we’ll say things like, we should activate CTV now, we should push an activation client now and start signaling to activate CTV. So it comes out of excitement and passion for Bitcoin and then frustration that we haven’t even seen a movement on a new soft fork since Taproot, right? Taproot, it was four years from SegWit to Taproot and now it’s been…
over two years since Daproot activated and we hadn’t even seen talk about it. So that’s, I think what’s going on there. No one’s actually made a client yet. There’s one person who’s saying they’re going to make at least a branch of the software that’s ready for activation signaling starting in January, not signaling starting January, code ready in January for signaling at some point in the future. I don’t have a strong opinion on any of this really. Like I said, I’m not a big activation
Brandon Black (01:15:47.87)
nerd. I think CTV is something that we should do on Bitcoin. I said that clearly in El Salvador. I think Check, Teflit, Verify clearly belongs as part of the Bitcoin scripting system, much like Check, Sequence, Verify and Check, Lock, Time, Verify. I don’t like politics and I don’t know how to play or talk about how we get it there or what the activation should look like or anything like that.
I hope we can continue moving the conversation forward, and then people that do know what activation should look like, or who have opinions about it at least, can then have the conversation about activation.
Stephan (01:16:21.326)
Yeah, okay. And so, yeah, I think that’s probably the key thing. And I guess if you could just maybe articulate some of this point, you made it earlier, but it would be good if you could sort of elaborate a bit on this idea about value density of Bitcoin transactions. Like what’s your vision here around value density and why does that help?
Brandon Black (01:16:46.218)
Yeah, I mean, that’s kind of the flip side, like you said, of the, you know, if we can share fees, then we can outbid these, these JSON blobs or whatever is, is making it hard right now to use Bitcoin. And so the other way to think about that is every transaction on Bitcoin is competing with every other transaction on Bitcoin. And so therefore the more valuable an individual transaction is, or an individual byte of a transaction is, the more likely it is going to be to get confirmed. Right?
If I want to spend some on-chain Bitcoin, I don’t consider those bytes valuable enough to spend $50 on a transaction fee, but I would say it’s valuable to spend $5 on a transaction fee. So how can I make my transactions dense enough that the effective fee to me is only $5? And so one way to do that is with Lightning.
So I actively use lightning and the reason I can actively use lightning is that I can open a channel for say $50 And then I can use that channel for weeks months or even years to spend and receive Bitcoin And I do this many times a week and then when I close it I pay $50 again But I’ve spent $100 now over many exchanges of Bitcoin And so the value density for me is let’s say only one or two dollars or even less per spend
Yeah, much less than that. It’s only a few cents per spend in terms of what I’ve done with my bytes on the Bitcoin blockchain. So I’ve made the density of that, those couple of on-chain Bitcoin transactions very high for me by using Lightning. We can make it even higher if we also share UTXOs. If I could open my Lightning channel in a pool with you and…
who knows, and Shinobi and 10 other people, then the 13 of us all get together and open a lightning channel. And now it’s not only my 200 or 300 transactions on lightning that get split into, or shared into one or two on chain transactions, it’s mine and yours and Shinobi’s and 10 other people.
Brandon Black (01:18:44.27)
And so the result is that the value density per byte of Bitcoin transaction has gone way up because we use lightning and we shared our UTXO on lightning. And so now we can bid even if we spent $500 on that on-chain transaction, it’s worth it, the value density of that on-chain transaction, because we got tens of thousands of movements of funds for those $500 of on-chain transaction fee. And so that’s what I mean by value density and how important it is that…
that we continue along the path that was kind of started with Lightning and is continued by Music2 and Frost and then continue along that path of increasing the value density of each byte on Bitcoin through these additional technologies, some of which can be done purely off-chain like Music and Frost, with Tapper at least, and then others we need to do at least some of the work in the on-chain verification like Lightning and ARK or Timeout Trees.
All of these things are about increasing the value density of each byte on the Bitcoin transaction and Bitcoin blockchain so that we can effectively spend and move funds no matter what the fees do.
Stephan (01:19:49.042)
Great. So yeah, I think it’s a great idea to move towards this idea of increasing value density. So yeah, we’ve spoken about a lot of things, you know, CTV, APO, all these different ideas. Do you have any closing thoughts for listeners on covenants and why covenants are necessary for Bitcoin?
Brandon Black (01:20:14.07)
I think my closing thought is really, covenants are fundamental to how we use Bitcoin. And as Bitcoiners, I think we can all work hard to keep thinking for ourselves and realize that words can either positively or negatively impact our understanding of a subject. It seems like the word covenants.
is a word that may negatively impact many people’s understanding of concepts like check template verify or any prev out or even TX hash. It might be better when we are thinking about these things to not say covenants, but instead to say check template verify, which does this one very specific thing. I don’t know for sure. It’s just a thought that I think is important for us to think about in, in how we program our brains, everything we listen to, everything we say programs our brains.
I know people have negative associations with covenants, so think about what your brain is doing when it hears the word covenant. It’s kind of my closing thought. And see if that’s helping you or hurting you in understanding these concepts. If it’s hurting you, replace that word with something else and find a different way to think about these things. Because a covenant is just a restriction, just like a checksig is just a restriction.
We always restrict our Bitcoin because that’s the point. I want to spend it the way I want to and not the way anyone else wants to. So I need covenants to do that. Of course I need covenants to do that. But maybe that word isn’t the best way to talk about it.
Stephan (01:21:40.662)
Okay. Well, yeah, thank you. I think this is going to be probably an ongoing conversation because I think there’s a lot of people who are going back and forth on these ideas, but yeah, as before, thank you for joining me again and yeah, I hope to chat again soon, Brandon.
Brandon Black (01:21:54.87)
Thanks so much, Stephan. I look forward to talking.