{ "episodeId": "SLP537", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "t_scale": { "name": "t scale.", "role": "guest", "tag": "T" } }, "segments": [ { "speaker": "stephan", "time": "00:00", "start": 0.38, "text": "I think that we need more people to be able to use Bitcoin without going to custodians, without going to Wallet of Satoshi, without going to Coinbase, whatever the custodian of choice might be. And in order to get more than a hundred 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, a next output, enables more people to use Bitcoin." }, { "speaker": "t_scale", "time": "00:45", "start": 44.6, "text": "Brandon, welcome back to the show." }, { "speaker": "stephan", "time": "00:47", "start": 46.94, "text": "Thanks for having me again." }, { "speaker": "t_scale", "time": "00:49", "start": 48.81, "text": "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, what, 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's, 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 to really get in English what is exactly going on here. So if we had to just start and, let's, let's say, you know, we're gonna ask this broad question, are covenants necessary for Bitcoin, right? So that's the 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?" }, { "speaker": "stephan", "time": "02:04", "start": 123.74, "text": "Yeah, great question. And, and I think that before I answer that, I wanna really quick say there are many, many kinds of covenants, and really the conversation today is focusing 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 pitch 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- A hundred 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 Wallet of Satoshi, without going to Coinbase, whatever the custodian of choice might be, and in order to get more than a hundred million people to use Bitcoin in a non-custodial way, we need some way of sharing pieces of Bitcoin. Or UTXO is the technical term, and covenants, specifically the type of covenant that creates a, a next output, enables more people to use Bitcoin." }, { "speaker": "t_scale", "time": "03:20", "start": 199.73, "text": "Got it. And just for people who aren't familiar, what is an output? And, you know, what, what is an output basically?" }, { "speaker": "stephan", "time": "03:26", "start": 205.88, "text": "Thank you. Yeah. So Bitcoin is kind of a strange system in terms of computer systems. We usually have accounts in computer systems, and, and so with an account system, you, you, 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's always talked about coins. People hold coins. Well, a coin is a unit 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 U-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, you give some bills to, to someone and you get back some bills and they keep some, but, but there's always atomic units at the beginning and the end of 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 a hundred million people using Bitcoin because we simply cannot create and destroy enough outputs per year to support more than that many people using Bitcoin unless we have covenants that restrict the next output creations." }, { "speaker": "t_scale", "time": "05:00", "start": 300.05, "text": "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 is 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 ten to a hundred million people could use Bitcoin and Lightning today, you know? So could you just explain where that number is coming from?" }, { "speaker": "stephan", "time": "05:21", "start": 321.32, "text": "Came, 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 ten to a hundred million people using Bitcoin with one to two channel management operations per year. So it's actually quite, that's a hundred million people with one to two per year. So, so it's really, like you said, ten to a hundred million is really the practical limit if people do more than two channel interactions per year. So the, the original Lightning paper, when they, 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 a hundred and thirty-three megabytes. So honestly, that is one other option we have for getting more people on Bitcoin, increasing the blocks, block size. I'm not saying it's an option I'd like, I'm not saying it's something that community, but if we wanna get more people on, we wanna get plebs all around the world to use Bitcoin, we're gonna have to do something." }, { "speaker": "t_scale", "time": "06:21", "start": 380.88, "text": "Yeah, right. And so as you were saying, and, and to, you know, for context, the Lightning white paper, I believe, is twenty fourteen or twenty fifteen, 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 twenty stuff, because now the argument would be, hey, Block size, there might just be a lot more JSON and JPEGs, right? So 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 four thousand transactions in a block, there's six blocks an hour, there's twenty-four hours in a day, times by three hundred sixty-five, you multiply that all out, it comes out to something like two hundred and ten million transactions per year, like as you said. And so if you thought that, okay, each person is only gonna do, let's say, That kind of gets you, again, in that same ballpark of a hundred million users. And that's, again, that's not even counting coinjoin 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 twenty or thirty 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 one percent of eight billion is eighty million, that means theoretically less than one percent of the world in the long run, far, far-flung future, less than one percent of the world can actually self-custody. So what do you think the implications of that would be?" }, { "speaker": "stephan", "time": "08:25", "start": 504.85, "text": "You know, I get off into economics and theory much farther at this point, but- But I think it is good to think about. I think we've already seen what happens with a, a money system that, that is limited in how many people can really meaningfully use it, because that's what happened with gold. You know, 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, and once that became the norm, it became possible, as everyone, you know, all the conspiracy theorists get all, all talking about manipulating the price of gold and all this stuff. But there's some element of truth in that, and, and I think the, the manipulation of the price of gold plus the confiscation through sixty-one o two, 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 one percent, only transacted by the one percent, because it was too- too costly to, to manage and to divide and everything. then we saw this, this happen with gold. So I think if Bitcoin is also limited to that one percent, as you said, we're gonna see a similar thing And, 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 wanna do better than that. I wanna 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 a hundred million people." }, { "speaker": "t_scale", "time": "10:03", "start": 603.43, "text": "I see, yeah. And so I guess just for the sake of argument, for the sake of steel man, I could say, \"Well,\" It would still be an improvement on the current system today, where 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 forty thousand 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 wallet of Satoshi or Blink and others, we might have Fifty 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, you know, 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." }, { "speaker": "stephan", "time": "10:56", "start": 656.16, "text": "Yeah, like I said, I, I think Bitcoin could be great for a few decades in that, in that way, but it's also captureable. 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 gonna keep the Bitcoin out of the hands of people that need it most, the Edward Snowdens, the Julian Assanges, the people that really need Bitcoin can't access it when it's only in those fifty million banks and high net worth individuals, 'cause 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." }, { "speaker": "t_scale", "time": "11:29", "start": 688.85, "text": "Yeah. And so I think that may be where some of the debate in 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, you know, 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, fifty million banks, lightning banks around the world is enough," }, { "speaker": "t_scale", "time": "12:02", "start": 722.35, "text": "Fractional reserve banking practices, core censorship practices. Not your" }, { "speaker": "stephan", "time": "12:06", "start": 725.63, "text": "keys, not your coins, right? Do we believe in not your keys, not your coins? If we believe that as, as Bitcoiners, then we have to do better than fifty million banks. I'm not gonna use a bank." }, { "speaker": "t_scale", "time": "12:17", "start": 737.24, "text": "Right. And so, and so the other question people may have, and 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, what's" }, { "speaker": "stephan", "time": "12:32", "start": 752.47, "text": "Yeah, I mean, I think we already nailed that fortunately. You know, we've 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. The, like, the Bitcoin network, we, 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, and so we simply can't 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, the covenant The output covenant restricts what outputs can be created at the consensus level, and so we can now coordinate and share your t x o's 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. 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." }, { "speaker": "t_scale", "time": "14:01", "start": 840.77, "text": "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?\"" }, { "speaker": "stephan", "time": "14:10", "start": 850.46, "text": "Well I'm ready to get canceled. 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, but it, it could be the time someday in the future to raise the block size. So I'm not excluding that as an option. And just a" }, { "speaker": "t_scale", "time": "14:34", "start": 873.69, "text": "quick note, with those JSON blobs, what Brandon is referring to is like the BRC20 and some of these People colloquially call them ordinals, but there's kind of a range of these different protocols. But yeah, go on, Brandon." }, { "speaker": "stephan", "time": "14:47", "start": 887.06, "text": "Yeah. So, so I think it's we, 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, it's clearly not the time right now to raise the block size, because, 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 t so what we do need to do right now, I would say, is increase the concentration of value in individual transactions for keyholders. Right now, you know, the, the most secure way to hold your keys, let's say, is with a three of five multisig from someone like Casa or other people that might support that, or your own three of five multisig. That's kind of the gold standard at the moment in holding your own keys. Right now, moving coins in a three of five multisig costs like fifty dollars or something, or maybe even more. And that's bad. So, so how do we improve that for people? Well, one thing we can do is by, by making multisig less costly through protocols like Frost and MUSIG. But another thing we can do is enable people to trustlessly share UTXOs so that people who, 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 co-ordinate Coordinate and, and share our transactions, then each of our transactions can more easily price out some of these JSON blobs, that are polluting, polluting, according to some people, our, our block space. a-and so the, the, there, there are things we can do through cryptic, cryptocryptography like Froste and Musig, 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, 'cause we've already done everything else we can." }, { "speaker": "t_scale", "time": "16:46", "start": 1005.97, "text": "I see. And so as an example, people talk about like multi-party lightning channels as an example where maybe instead of having a two-person multi-- you know, 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 two hundred dollars, but because we're dividing it by ten people, Right? That, that's an example, right?" }, { "speaker": "stephan", "time": "17:14", "start": 1033.85, "text": "Yeah, exactly right. And, and we, we know we need to be very realistic. Covenants of the, the basic sort, the, 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 a timeout tree is 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, to, to many different Typically, I think in, I think in his protocol, 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, instead of right now, that'd be wallet of Satoshi with output restriction covenants like CTV, you can make that, an, a trustless version of a kind of just 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." }, { "speaker": "t_scale", "time": "18:24", "start": 1103.91, "text": "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 been hit, 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, if they're not actually able to, you know, because it still has the same blockchain limits, right? There's still two hundred and ten million transactions per year" }, { "speaker": "t_scale", "time": "18:54", "start": 1133.87, "text": "Critique." }, { "speaker": "stephan", "time": "18:56", "start": 1135.51, "text": "Yeah, and people talk about this, this rush to the exits problem, a-and it's, it's absolutely the, the hardest thing to reason about and, 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, and I think the way to, to look at it is, 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, the relatively wealthy Bitcoiners who can create, create kind of semi-small Shared UTXO to ten people. If you have a ten person shared UTXO, there's not really any rush to the exit, it's no worse than a Lightning exit really, right? Lightning, Lightning closes are fairly large transactions. And it's about the same if you have a ten percent UTXO exiting on chain, it's gonna be similar in magnitude to a Lightning channel forced close. So we can start there. And yeah, maybe when you try to get ten thousand 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 five x or ten x 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 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, you know, getting a few people using it, we're gonna reduce costs, right? Even if I get only a five x reduction in my on-chain costs, 'cause I'm in the five percent share of DTXO, well, that's ten dollars instead of fifty, that's great. Let's start there." }, { "speaker": "t_scale", "time": "20:37", "start": 1236.7, "text": "Okay, yeah. And to be clear, that's in one context, there's also other possible protocols that are being enabled here, Thinking is, what about sidechains? Why, why not have sidechains instead of covenants?" }, { "speaker": "stephan", "time": "20:53", "start": 1253.08, "text": "The arguments on both sides of sidechains are, 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 side chains 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 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, 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, and con-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, the thing that says, \"I'm just not interested in side chains. I don't want to further pressure miners to centralize.\"" }, { "speaker": "t_scale", "time": "22:17", "start": 1337.48, "text": "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 type, different variants of those. Can you just outline what some of those are?" }, { "speaker": "stephan", "time": "22:37", "start": 1356.81, "text": "Yeah, 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, and I think that's something really important to think about. You know, 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 that, if it did that, it would-- the, the previous nodes would break off from the network. So you can make a soft fork that disables OP_CHECKSIG and makes everyone's Coins unspendable, right? That's a soft fork change to Bitcoin, and that would obviously be a bad soft fork. And so we, since we can imagine obviously a bad soft fork, we have to find some other metric for evaluating changes to Bitcoin. you know, people have, have built their brains around this hard fork, soft fork idea, but it's not the only way to evaluate changes. So I, I like to look at it more in terms of It's kind of scope and risk. In, in Bitcoin, we've had, at least since I've been conscious of, of Bitcoin changes, which was a couple years into it, two major changes that, 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, you know, we've had, check time-- no, check lock time verify and check sequence verify that were added to support, lock times and Lightning network, and they're, I'm trying to think about this, but there, there have been other smaller soft fork changes, a-and we need to think about those things very differently. One can really dramatically shift the incentives of the network, and the other one, you know, enables some additional scripting capabilities." }, { "speaker": "t_scale", "time": "24:28", "start": 1468.35, "text": "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, a just a sense of like, w-what is Bitcoin's scripting engine? And what does it mean for being able to make layer twos?" }, { "speaker": "stephan", "time": "24:45", "start": 1484.92, "text": "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, we can at least try to think about His goals and, and what he was-- 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 gonna hard code into the, 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, is set a public key, and when you wanna spend it, you need a signature, and that's the only way you can lock and coin. 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, their funds are spent. They might want to have multi-signature, he added, an op-check 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. a-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." }, { "speaker": "t_scale", "time": "26:26", "start": 1585.5, "text": "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 wanna lock up my coin? 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, check lock time verify and CSV check sequence verify. 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 In Lightning, and that's actually what allows a routed network. So in Lightning, when you have, you know, your connection with other nodes, and those con- those nodes are in turn connected to other nodes on the Lightning network, when they're forwarding and, you know, receiving these payments, they need this relative locktime capability to be able to do this feature of saying, okay, I've received the coins upstream, a-and I'm not gonna release the coins downstream until I've got my upstream coins that came in. And, you know, in the kind of, if you dig into the, you 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, you know, 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, CSV came in and I can't remember the exact date, but maybe twenty fourteen, twenty fifteen, 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," }, { "speaker": "stephan", "time": "28:35", "start": 1715.22, "text": "Yeah, no, that's exactly right, and that, and that's why, you know, I talked in, in El Salvador, you know, I think we need to think about what it means to be a covenant, and I kind of alluded it to 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, the CHECKSIG opcode, the, the, the basic thing we all use for our single sig Bitcoin is the CHECKSIG. you could say that that's a covenant And, and along with, as you said, the, the idea of changing Bitcoin becoming a bit of a bugaboo. I, I wanted to, 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, 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 Locktime 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, the people who worked directly on Bitcoin Core, they discussed various ways to solve that, and Check Sequence Verify was the solution they 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, every two months? It would have To use. So, so even from the Lightning paper itself to the implementation of Lightning Network, that took years, as Al-- Alwyn talked about, the years it took to implement Lightning, Bitcoin was modified over that time to facilitate a better Lightning network that is more usable today." }, { "speaker": "t_scale", "time": "30:27", "start": 1826.78, "text": "And so I think that hopefully helps spell out some of the ideas around, you know, 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- If you don't want to use covenants, you don't have to. That 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, the goal that, the developers or the people who are pro, you know, CTV or other, covenants. So let's, let's list out some of the ways that you believe covenants Could help scale the users or the payments of Bitcoin. Like, 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?" }, { "speaker": "stephan", "time": "31:17", "start": 1877.25, "text": "Yeah, we, we talked about really some of the best ones already, which is like the timeout trees that, 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 And through that lightning channel, you can make payments for the duration of, of the timeout tree. That's, that's a, that's a, I think a great proposal. It sounds in some ways similar to ARC by Baroc, that's another proposal that's out there. both of these proposals rely on the, the thing we already mentioned, which is that with Check Template Verify, in, in particular, the untrusted Coordinator can commit to until some time in the future, you have the absolute ability to trustlessly exit this construct because it's, 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, the one thing that, that affects the trust here is that the users must come online periodically. So that's probably the, as of now, and, and there's, there's lot, lots of work being done, that's probably the most compelling use for Check Capital Verify that would be good for users. Because with this, with this structure of, of periodically timing out trees of transactions or, or lightning channels, depending on what proposal you're talking about, ARC or, timeout trees the coordinator remains trustless, but they can also recover the liquidity if users become unresponsive. And well, people feel, \"Oh, that's kind of scary. What if, what if the, the coordinator becomes evil?\" Well, the more likely case, just because of-- Why is it more likely? It's-- 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. It, I guess it's, it's rugs if you don't hold your keys in the first place, and then if 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 the, this ARC 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 might get-- you'd 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, we've gotten good at holding our own keys and, and keeping them alive on steel or whatever. But is your grandma gonna make a steel backup of her, of her seed? No, she's gonna have it on her 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 could probably get at least most, if not all of her coins back. But in Of properties, I think is amazing for users." }, { "speaker": "t_scale", "time": "34:11", "start": 2050.92, "text": "Great. And, are you able to explain non-interactive channels and, and any thoughts on that?" }, { "speaker": "stephan", "time": "34:17", "start": 2056.97, "text": "Yeah, I can do, I can do a little bit. I, I'm, I'm not the, the best person on that. I wish I had a little bit more depth on it. Long and short here, with CheckTaple Verify, we've kind of already talked about how CheckTaple Verify lets me restrict where the next step of these coins can possibly be. And before, with Lightning, the way that we make a channel work Already 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 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 Lightning? But with CTV, one party can non-interactively transfer funds on a channel to the other without needing to sign it And get the kind of the, the counter-signing thing with penalty that happens in Lightning, because the, with CTB 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, 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 s-- actually s-- transfer funds down to the user. Or inversely, you could have a payments-only channel where, where you don't have to be online. But you can, you know, from a phone, you can text updates, but essentially to your, to your receiving party because it's a non-interactive channel in one direction. A-and so that's basically the, the structure that is possible when you don't have to sign both sides each, 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, so single direction, non-interactive channel is the thing that I know at least a little bit about, yeah. and it, it takes one set of signatures In a single direction channel." }, { "speaker": "t_scale", "time": "36:07", "start": 2166.76, "text": "Yeah. So now let's talk through some of the different covenants proposals, right? Because there's a-- that, 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 TXR, there's OpCat, there's APO, there's Trezise from Stark, there's OpVault, like we need to sort of disaggregate some of these" }, { "speaker": "t_scale", "time": "36:35", "start": 2195.42, "text": "Explanation of what these things do. So let's just start with CTV. So, you know, what's CTV in English?" }, { "speaker": "stephan", "time": "36:42", "start": 2202.22, "text": "Alright, CTV in English. I, I've actually come around to it recently to kind of a new explanation of CTV in English that, that jump, 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, you know, 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? Right. CTV lets you make that same kind of a concept, a predefined transaction, but without having to sign it. So, so it's, 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 deleted key-- deleting keys, the original vaults concept that I read about involved making a temporary signing key to- 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, 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, that, that's CTV." }, { "speaker": "t_scale", "time": "38:10", "start": 2289.66, "text": "Okay, great. So let's now talk about TX hash. This is another one, w-what is TX hash in English?" }, { "speaker": "stephan", "time": "38:17", "start": 2296.65, "text": "Wow. TX hash lets you restrict any aspect. Of the next transaction when you make your coins. the idea with TXHash, the, 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, 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, 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, a complex thing to describe. You know, 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, the complexity. So I would say TixHash is very cool and it's also very complicated to, 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 op code in Bitcoin script. If you couldn't activate both TX hash and CTV as written, because they use the same op code, because the way we upgrade Bitcoin script is that we, we take op codes that were previously not available and we describe new behavior for them. And so TX hash and Check Template Verify use the same op- Code or, or one of the same opcodes, so they, they currently collide with each other, which is okay because the default mode for tx hash 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. alright, so that's, that's the exact to the best I can do in English. It's a pretty complex idea, but it, it, it lets you pick and choose and, and, and restrict any part of the transaction." }, { "speaker": "t_scale", "time": "40:26", "start": 2425.61, "text": "Okay, back to the covenants discussion in a moment, but first, Swan Bitcoin is the leading Bitcoin financial services brand. You can use swan dot com or the Swan app available on your smartphone, Apple or Android, to buy Bitcoin in a safe and easy way. Swan makes it easy for you to buy Bitcoin, whether that is using a larger smash buy an automated recurring purchase plan where you can set up and buy a certain, a set amount of Bitcoin, and with Swan, it's easy to automatically withdraw that Bitcoin into your self custody for free. Now, for those of you who are high net worth investors, consider Swan Private. Swan Private is a service where you get a dedicated Bitcoin concierge. This is somebody who you can pick up the phone and call, they can advise you on all manner of things, whether that comes to your acquisition strategy, they can give you some tips on how you want to self-custody that. Swan Private also includes support for things like corporate accounts, retirement accounts, trust accounts. You will get access to Swan Private events as well as original Bitcoin research. So for those of you interested in that, go to swanprivate dot com, or otherwise go and stack zats with swan dot com. Next up, when it comes to using Bitcoin, we need to hold it using our own private keys. Now, of course, we're discussing in this episode how many people can actually do this, but if you're listening now, there's a good chance you are still able to do this. So of course, check out CoinKite dot com. They are the makers of the Coldcard, which is my favorite Bitcoin hardware device. Now they've got new devices coming out, notably the Coldcard, the Q device. They also have some cheaper devices such as the TapSigner, which is also another example That is, really simple to use with NFC. But anyway, the point of these devices is you are trying to segregate the private keys for your Bitcoin away from internet connected devices, so you can use these devices to generate the private keys for your Bitcoin and also to sign Bitcoin transactions that relate to spending Bitcoin. And you can even use the address explorer feature on these devices, such as the Coldcard, to check which addresses are truly yours. So that's also a really cool feature that you can use, and it gives you a little bit more- More peace of mind that, yes, you do really control that address. Now, over at CoinKite, they have a range of devices, so they've got the Coldcard, the TapSigner, they have metal, metal seed backup devices that you can use to stamp and punch out your twelve or twenty-four word seed, and of course, other accessories such as the BlockClock, the BlockClock Micro, and the BlockClock Mini. You can find all of this over at CoinKite dot com. Use code Livera for a discount on your Coldcard. And finally, mempool dot space. Mempool dot space is the leading Bitcoin and blockchain visualizer. You can use this to search Bitcoin transactions, you can use this to target the fee level for the Bitcoin transactions that you are about to do. I use it very often whenever I'm about to send a Bitcoin on-chain transaction, and mempool dot space can give you that view of how many sat you need to attach to that transaction to get it confirmed. They've, they're continually rolling out new features such as Such as mempool dot space goggles, which is the latest feature. This allows you to see what's going in the mempool. It allows you to see, it's like having x-ray specs that allows you to see which transaction types are coming through. There are twenty-five different categories, you can even mix and match, you can keep an eye on those inscriptions or bare multisig, or you can narrow your focus down onto what you want to see. And of course, they have a mempool accelerator program which will be launching soon, so if you wanna get on the waitlist for that, you can" }, { "speaker": "t_scale", "time": "44:05", "start": 2644.55, "text": "X slash accelerator. And now back to the show with Brandon. And now, what about OpCat?" }, { "speaker": "stephan", "time": "44:12", "start": 2651.54, "text": "OpCat is, is deceptive, much like meow. it's this tiny little change, it can literally be coded, I think it's under twelve or sixteen lines of code change, a-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, concatenates, short for concatenate, and so that's all it does. But because of programming and, and the fact that there are other script opcodes around us With OP_CAT, you can emulate CHECKSIG from STACK, you can emulate CAT, you can emulate most of TXHASH. These scripts are kind of ugly and difficult to reason about, but it's this very strange and difficult to, to wrap your brain around property of OP_CAT, which is that in twelve or sixteen lines of code, you can end up really changing the dynamic of what can be done with scripting to the point that I, I like OpCat, I like the simplicity of the code, but I personally feel a little bit uncomfortable about the idea of adding OpCat, which kind of brings us back to This topic from earlier about like how big are changes, one of the impacts of changes. Cat- CTV has a very limited change, scale factor, if you will. It does a very specific, very simple to describe thing. TX hash is kind of a little bit more 'cause it lets you reason about the amounts in a transaction and then CAT Let's you do all kinds of stuff, in twelve to sixteen lines of code, get all this stuff that can happen. So, so that's up to you. It, it's very simple to, to code, but very complex to reason about the implications of." }, { "speaker": "t_scale", "time": "45:48", "start": 2747.66, "text": "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 Prove Out in English?" }, { "speaker": "stephan", "time": "45:57", "start": 2757.39, "text": "Yeah, Any Prove Out is a, a new way to restrict transactions by signing them. So we talked about Actions 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 could 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, a- A signature currently that takes one of your inputs but lets other people add pieces of their coins to the same transaction, that's called a \"Anyone Can Pay\" signature. With any prove out, you can say, \"I'm gonna let this spend any of my coins that were sent to the same address, in-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 the, what's called the, 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 opco-- or not opco, the SegWash mode, because it lets The elect-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 the channels keep using the same address throughout the updates to the channel." }, { "speaker": "t_scale", "time": "47:48", "start": 2868.02, "text": "And so that's also where, so listeners, you can check out my earlier episode with Christian Decker, 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, you know, more advanced forms of the Lightning network, let's say. So that's that one. And then check sig from stack. What, what's that?" }, { "speaker": "stephan", "time": "48:16", "start": 2895.59, "text": "Yeah, so I, I, I wanna, Well, taproot APO in here, which, which actually ties straight into Checksum 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. So you can use APO by throwing a signature in your locking program instead of in the-- like normally you put a signature in your unlock, right? With APO, you 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 EPO more complicated, 'cause now it's not just a new way to sign transactions, it's also a way to get a covenant into Bitcoin, that-- and then people have that whole conversation about covenants. So that's something important, important about APO. To flip that around, so, 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 an E-prove out. That starts to get a little bit hard to think about, but that's probably the, 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 Kat is this tiny change that does everything. Check Sig from Stack is a small change that does some things. The other thing that you can do with Check Sig from Stack is You can check signatures on, on other data. So this doesn't, this enables about the same kinds of things on Bitcoin as you can currently do using the, the concept of scriptless scripts or discrete log contracts or adaptor signatures. These are all terms that are thrown around. 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, in your script. and 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 Checksec from Stack allows, is those kind of oracle type applications in script." }, { "speaker": "t_scale", "time": "51:04", "start": 3063.6, "text": "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 Obie as well for listeners?" }, { "speaker": "stephan", "time": "51:16", "start": 3075.87, "text": "Yeah, Op-OpVault. First of all, OpVault uses CheckTemplateVerify to accomplish its goals. So any conversation about, any conversation about OpVault is implicitly saying OpVault plus CT- At least everyone that I've seen. because the way our vault 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 thirty minutes, let's say. During those thirty minutes If that spend was illegitimate, 'cause someone stole your phone and was trying to send all your coins to their, to themselves, if you see, you can see that in those thirty minutes and send them to a Casa 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." }, { "speaker": "t_scale", "time": "52:38", "start": 3158.24, "text": "Right. Okay. Yeah. So it basically allows people to sort of have a get out of jail free card, 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, 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 multisig, so that user could be using multisig 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?" }, { "speaker": "stephan", "time": "53:55", "start": 3235.0, "text": "Where we are today, as of now, none of these proposals has gained very much traction, just to be very, very, very clear about that. different people, you know, James Obrien proposed CTV plus APO plus Vault, which is in, in, you know, 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. so yeah, long and short, none of these have, have much traction in most of these proposals don't really conflict or, 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, it's kind of an okay conflict, let's call it. 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 or L 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" }, { "speaker": "t_scale", "time": "55:21", "start": 3321.18, "text": "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, et cetera, right?" }, { "speaker": "stephan", "time": "55:30", "start": 3330.11, "text": "Yeah, yeah. So I, so I'm, 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, 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, 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 from 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 to vault all on board together in order to, 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, in twenty twenty-three 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 gonna take, and we don't know what proposal is gonna kind of carry forward. But I'd love every, everyone" }, { "speaker": "stephan", "time": "57:05", "start": 3425.33, "text": "with lots of people asking questions, we're having spaces pretty often, so anyone is welcome to, to join and ask questions about the future of Bitcoin and, and to kind of join this conversation about how and if we change Bitcoin going forward." }, { "speaker": "t_scale", "time": "57:17", "start": 3437.42, "text": "Yeah. So the other big question people will have is, what about unforeseen consequences, right? And so obviously, rightly or wrongly, some people are pointing to, you know, this recent- Ordinals and inscriptions and BRC twenty 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 egg 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, you know, as some of the online commenters were saying, all this BRC twenty stuff would have fit, or it's less bytes than an op-return anyway, so" }, { "speaker": "t_scale", "time": "57:58", "start": 3477.69, "text": "So 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 op code or sig hash flag like APO or something like that, and it blows up in our face?" }, { "speaker": "stephan", "time": "58:15", "start": 3495.12, "text": "Yeah, I, I absolutely understand people's, people's trepidation, you know? We, we, they say that money is one of the things humans are most emotionally attached to, and, you know, the, the cause of relationship strife and all this other stuff. So, so we get very emotional about our money, and so we talk about the, the, the impact on people's use of their money right now, where they, they, many people right now can't use their money because fees are so high from the, the s- BRC20 JSON blobs. so I get the emotion, I absolutely get it, and I, I wanna emphasize that. so yeah, unforeseen consequences. How do we, how do we deal with that? I think we talked a fair amount about it in this, which has been great, you know, what's the scope of different changes? And so, you know, 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 OP_CAT. OP_CAT 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 CheckSig from Stack. no, I think TX hash is, is more flexible. It lets you do more. And so the, the point I'm getting at here is that the, 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 changes we're talking about are that big. OPCA 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, yeah, TXHash, yeah, CheckSig from Stack, APO and OP Vault and then CTV in terms of the scope of the changes and, and how impactful they could be in terms of unforeseen consequences." }, { "speaker": "t_scale", "time": "01:00:27", "start": 3627.98, "text": "Gotcha. And From what, from what you're saying." }, { "speaker": "stephan", "time": "01:00:31", "start": 3631.37, "text": "Yeah, yeah, exa-exactly. You know, both, all of, you know, in my personal opinion, this is now getting very far off into opinions here, anything from check-sig from stack down is pretty clearly Safe, in that there's not, there's not, we can, we can safely reason about all of the behaviors that it enables. Check, sig from SAC 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, and you can see that, that's why James Obrien proposed those three things for activation together, because they're all clearly below the line of unforeseen." }, { "speaker": "t_scale", "time": "01:01:12", "start": 3672.81, "text": "Right. Yeah." }, { "speaker": "stephan", "time": "01:01:13", "start": 3673.59, "text": "Yeah. Yeah. We can very clearly, you know, it's hard, obviously, for, 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 Clearly reason about the consequences of those things." }, { "speaker": "t_scale", "time": "01:01:31", "start": 3691.15, "text": "Okay. Yeah. And so I think the other element is could the change be-- and I, I believe I've heard James Obie, refer to this idea of like, how confident are we that the change isn't 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." }, { "speaker": "stephan", "time": "01:02:03", "start": 3723.77, "text": "Right. We're kind of talking about externalities here of using these new, new things. It, 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, 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 this, the level of effect caused by, by different changes in terms of the behavior of people? Looking at it that way, first of all, there's huge step, 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 OP_CAT 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 Then I personally would love to see on Bitcoin. And so OpCat at that threshold where like this might have a significant externality, it might not. I'm not saying it does for sure, I, I can't make that claim, but, but it might. And so that's why I feel nervous about OpCat, is it might enable sidechaining, and that could have a significant externality. When we go below the OpCat level of expressivity, down to Checksum Stack or TXHash or, APL or CTV or OpVault, all of those are at the" }, { "speaker": "stephan", "time": "01:03:50", "start": 3830.14, "text": "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 OpVault, when people spend their coins, it now takes two transactions, so that's gonna have some impact on the, on the fee market or, you know, CTV, if, if ten 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, 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 happen at this kind of vault or CTV or APO levels is that the behavior of, of some users are gonna change and have some level of marginal impact on fees." }, { "speaker": "t_scale", "time": "01:04:36", "start": 3876.7, "text": "Yeah, okay. So I think those are probably, so I guess just to sort of revise, I 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 Barak, would want CTV or TX hash, generally speaking, or I think it was it APO plus CheckSig from Stack, right? Would enable ARC This idea of timeout trees is enabled just by bare CTV, this idea of LN symmetry is enabled by APO or CTV plus, CheckSig from Stack. and then obviously vault enabled by OpVault and, or, and CTV, let's say. so I guess those are some of the ideas around scalability of Bitcoin, security of Bitcoin, a-and, maybe usability of Bitcoin that could be improved, let's say, as an example in the ARC context. listeners, you know, 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 ARC 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, to make everybody else to make it feasible for us to be non-custodial and thus enable more than, let's say, fifty million lightning banks. We could have maybe, I, I mean, it's hard to know the numbers, but like 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, you know, 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?\"" }, { "speaker": "stephan", "time": "01:06:44", "start": 4004.58, "text": "Yeah, that was a great question. And, and frankly, it ties back into that question of, you know, do we have to do coalition building and, and the kind of the-- How do we change Bitcoin? Should we change Bitcoin? All those questions, they tie in here. so when, 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 so yeah, do, do we need to have proof of commercial viability? I don't know. I've heard people say things like, \"Well, well, Check Sequence Verify was obviously useful, or, 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, I think that's disingenuous. I think what's, what the honest truth is that the Bitcoin ecosystem has changed since then, and maybe the requirements for, for changing Bitcoin as a result have changed." }, { "speaker": "t_scale", "time": "01:07:39", "start": 4059.72, "text": "Right. It's like a rising" }, { "speaker": "t_scale", "time": "01:07:44", "start": 4064.22, "text": "Still, because Bitcoin was so much smaller, now, I mean, last I checked, it's about an eight hundred and forty billion dollar network today, and it's gonna-- probably next few years, it's gonna multiply, and so maybe that means the threshold has to rise for what kind of change is acceptable." }, { "speaker": "stephan", "time": "01:07:57", "start": 4077.83, "text": "Right, right. And so, so I think it's great to, to be- Asking those questions, and, and I don't think we have a clear answer, I certainly don't have a clear answer for, for that. It's also the kind of the flip side when we were talking about doing the Taproot soft fork. People talked about, \"We'll do Taproot and then soon after, we'll do any prevout.\" And so companies were actively building products that depended on any prevout, and then those companies had to die because the Bitcoin network never activated any prevout after the Taproot soft fork. And I'm not a fan of any provout. This isn't me saying we should have done any provout 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, hasn't happened yet, right? So how do we, 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, and I'll go off into opinion land here, is that we, we should make some change, and, 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 CTV is the least risky change that's currently being considered for Bitcoin, and by doing CTV and, and proving as a community of, of, of all the Bitcoiners that we can, 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 gonna believe that. They're gonna say, you Just like you screwed the APO people." }, { "speaker": "t_scale", "time": "01:09:47", "start": 4187.14, "text": "Yeah, and maybe this is just gonna be a, a, a stiff answer, but maybe that, that is the answer, that you just have to prove out commercial validity for, 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 wanna change unless you've proven it out first on SigNet, Regtest, and Inquisition, and some of these other kind of proving grounds, let's say, or on Liquid as an example. They might say, \" See commercial demand there. Okay, now we can have the conversation, we should have a soft fork to bring it into Bitcoin." }, { "speaker": "stephan", "time": "01:10:21", "start": 4221.99, "text": "So, so to be clear, like there are CTV vault implementations, James Obie did one. On Signet, there's, for-- I don't think it's running anymore, but Jeremy ran a, Jeremy Rubin, that is, ran a CTV specific Signet 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, 'cause people have built things on CTV and had built things on APO, and, and, and they had, you know, they had products that were close to ready to launch But then no one would actually take action to, to activate them on Bitcoin. So, so, if we're gonna have that as the bar, as a Bitcoin community, of that we have to have commercial validation before we activate something, we at least also should be, should be incumbent on us as the, the, the Bitcoin community to say, to set that bar in a clear way. is it a product demo? Is it, is it, a, a waitlist 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, and clear interest from the business community, and they're not on Bitcoin yet." }, { "speaker": "t_scale", "time": "01:11:38", "start": 4298.4, "text": "Right. Yeah. I, and it could just be that maybe that wasn't enough. I, I don't know. I'm, 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" }, { "speaker": "t_scale", "time": "01:11:54", "start": 4314.93, "text": "A good thing, but it may be that, we have to see another really high fee 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 seven hundred satoshis per vbyte in that range, and in fiat terms, that was maybe fifty or sixty dollars per-- you know, to get next block transforma- confirmation. And maybe we have to see a sustained high fee market before then people are like Alright, let's talk about CTV or APO or something. I, I don't know, I-- But maybe that's, that's one thing. I know some covenant promoters, I, I believe some CTV promoters are already talking about activation now. So, do you know exactly what's happening with that or why they're talking about that?" }, { "speaker": "stephan", "time": "01:12:42", "start": 4362.39, "text": "Yeah, it's been an interesting conversation. everything old is new again. So, so Jeremy Rubin pushed for activation almost two years ago, I think, and, that was considered an attack on Bitcoin by some because he, 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 trial is an attack because it lets the miners decide whether something activates or not. I, I don't know, I don't care, it's not my area. so talking about activation right now is, is, it's almost the same thing. People have been researching for years now the things you can do with CTV. We've, we've seen significant advancement in the state of that art with ARC 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, and when people get excited, they get interested interested in something that, 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, and so some of, some of those folks, at moments myself included, are, will say things like, \"We should activate CTV now, we should push an activation client now and start signaling to, to activate CTV.\" so it comes out of, it comes out of, you know, excitement and passion for Bitcoin, and, and then frustration that we, that we haven On a, a new soft fork since Taproot, right? Taproot, it was two, it was four years from SegWit to Taproot, and now it's been, over two years since Taproot activated, and we haven't even seen talk about it. So that's, that's, I think what, 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 a, a, at least a branch of the software that's ready for activation signaling starting in January. Or not, not signaling starting in 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 nerd. I think CTV is something that we should do on Bitcoin, and I said that clearly, in El Salvador, you know, I think CheckTaproot verify clearly belongs as part of the Bitcoin scripting system, much like CheckSequence verify and CheckLockTime verify. I don't, I don't like politics and I don't know how to play or, or talk about how we get it there or 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." }, { "speaker": "t_scale", "time": "01:15:15", "start": 4515.97, "text": "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, this point, you, 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, you know, why does that help?" }, { "speaker": "stephan", "time": "01:15:40", "start": 4540.21, "text": "Yeah, I mean, that's kind of the flip side, like you said, of, of the, you know, if we can share fees, then, then we can outbid these, these JSON blobs or whatever is, is making it hard right now to use Bitcoin. And so the, 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, 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 fifty dollars on a transaction fee, but I would say it's valuable to spend five dollars on a transaction fee. So how can I make my transactions dense enough? The, the effective fee to me is only five dollars. And, and, and so one way to do that is with Lightning. So I, I actively use Lightning, and the reason I can actively use Lightning is that I can open a channel for, say, fifty dollars, 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 fifty dollars again, but I've sent, spent a hundred dollars 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, 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, and Shinobi and ten other people, then the thirteen of us all get together and open a Lightning channel, and now it's not only my two hundred or three hundred transactions on Lightning that get split into or shared into one or two on ten transactions, it's mine and yours and Shinobi's and ten other people. And, and so the result is that the value density per byte of Bitcoin transaction has gone way up. Because we use Lightning and we share our UTXO on Lightning, and so now we, we can bid, even if we spent five hundred dollars 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 five hundred dollars of on-chain transaction fee. and so that's, that's what I mean by value density and how important it is that, that we continue along the path that, that was kind of started with Lightning and is continued by MuSig two and Frost and then continue along that path of increasing the- The value density of each byte on Bitcoin through these, these additional technologies, some of which can be done purely off-chain like Mosaic and Frost, with Taproot at least, and then others we need to do at least some of the work in the on-chain verification like Lightning and ARC or timeout trees. All of these things are about increasing the value density of each byte on the Bitcoin transaction, on Bitcoin blockchain. So that we can effectively spend and move funds no matter what the fees do." }, { "speaker": "t_scale", "time": "01:18:42", "start": 4722.46, "text": "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, you know, why covenants are necessary for Bitcoin?" }, { "speaker": "stephan", "time": "01:19:02", "start": 4742.29, "text": "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 prevout or even tx hash. It might be better when we are thinking about these things to, 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, 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, so think about what your brain is doing when it hears the word covenant, is kind of my closing thought, and see Understanding these concepts. If it's hurting you, replace that word with something else a-and find a different way to, to think about these things, because a covenant is just a restriction, just like a chequesig is just a restriction. We always restrict our Bitcoin, 'cause that's the point. I wanna 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." }, { "speaker": "t_scale", "time": "01:20:28", "start": 4828.84, "text": "Okay, well, yeah, thank you. I think, this is gonna 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, a-as before, thank you for joining me again, and, yeah, hope to chat again soon, Brandon." }, { "speaker": "stephan", "time": "01:20:42", "start": 4842.41, "text": "Thanks so much, Stefan. I look forward to talking." } ] }