podcast: https://stephanlivera.com/episode/339/

Stephan Livera:

So Jeremy, welcome to the show.

Jeremy Rubin:

Yeah, thanks for having me on.

Stephan Livera:

So Jeremy, you’ve been chatting a little bit and obviously building on this idea of Check Template Verify, and I think there’s a lot of people in the community who would really benefit from hearing from you exactly what it is, and talking a little bit about this journey of how you came to where it is now. And just for listeners who haven’t heard of you before, or maybe they don’t know a lot about you, do you want to just give us just a brief intro and background on you and your history in Bitcoin?

Jeremy Rubin:

Yeah, so I first got interested in Bitcoin in 2011. You know, I mined a little bit in my dorm room and then shut my computer off when it got too loud and hot, regrettably. And then I really made more of a splash in the scene in 2013, 2014. I did a project called Tidbit, which was mining in the web browser at a time when that still would’ve been profitable, believe it or not. And we got a bunch of legal trouble with that, sort of had a little bit of a personal crisis—do I stay or do I go? I decided to stick around and started a bunch of projects—this hundred dollar giveaway at MIT, the Digital Currency Initiative. And since I graduated in 2016, I’ve been doing Bitcoin Core contribution.

Stephan Livera:

Fantastic. And so our topic today is around Check Template Verify, and it might be good if you could help us set the scene for how you got started thinking about Check Template Verify, and what was the motivation around it?

Jeremy Rubin:

Yeah. So back in, I think it was 2017, Byron Gibson said to me, Hey, why don’t you give a talk at the BPASE at Stanford. It was like Blockchain Protocol Analysis & Security Engineering or something like that. Now it’s Stanford Blockchain Conference. And I was like, Oh, I have no idea what I’m going to talk about. Let me think about it. Well, like covenants are kind of this cool thing. Maybe I’ll do a talk about different covenants that you could do in Bitcoin that might be safe to include and have some beneficial properties. Covenants at the time were viewed pretty negatively as like something that you could do to Bitcoin that could maybe do a lot of harm. So I thought that they were okay and interesting, so I wanted to maybe prod the research in that direction. Covenants are restrictions on how Bitcoin can be spent. And so if you want to feel like I’m fully in control of my coins, that could be a bad thing. What if somebody sends you a coin that has a covenant on it, and it says that you can’t use it to buy cheeseburgers. Like, that would be very unfortunate if you got the Bitcoin just to buy cheeseburgers. And that’s a joke, but maybe it could be something more serious. Like, Hey, here’s a Bitcoin and you can’t use it unless it’s KYC AML’ed by one of these government agencies—like that would be very, very serious. And so covenants are kind of viewed with a heavy amount of skepticism. Even the name itself, covenants, like people are familiar with it primarily through real estate transactions, where covenants historically were used—at least in the states—in very racist manners, where it’d be like, You cannot sell this house to a black person. And even if you’re not a racist and you buy the house that says you can’t sell it to a black person, that covenant continues to restrict who you could sell the house to. So you can’t even choose. And in order to get around from that, we had to constitutionally strike down all those covenants and remove them from property transfers. So covenants kind of really scare people because they could have all these really negative things that could happen with Bitcoin. And I wanted to show like maybe they’re not so bad. Maybe, instead of thinking about how covenants could impact coins that you receive, maybe you could think a little bit more about how you could use covenants for the coins that you own. And I came up with some examples and some ideas, and then I spent a couple years really trying to figure out ways of introducing covenants to the Bitcoin community in a way that people would accept. And I had very limited success—until May of 2019. And I went to a San Francisco BitDevs. I gave a presentation and I said, Hey, here is sort of the simplest form of covenant possible. It’s actually basically useless. However, once you have this basically useless type of covenant, here’s how you can work with it to sculpt the clay and build lots and lots of really fantastic applications. And the community at first—as the presentation started—they already knew covenants were really bad. And as I presented and shared more, slowly faces lit up a little bit. And people were like, Actually, maybe this isn’t so bad. Maybe this is a form of covenants that were okay. And I think it’s kind of interesting, because what my goal was with Check Template Verify in its original form is I wanted to move the Overton window of discussion. I wanted to give people a concrete example of a covenant that didn’t really have a lot of these negative downsides of other forms of covenant, but still provided a lot value. And it did that. And what ended up resulting from that in the years that followed was you had people who were maybe hesitant about covenants saying, Maybe they’re okay. And you had people who were hesitant before getting convinced that actually like, Maybe more generalized, fully fleshed out covenants that are not this simple version would also be okay and maybe we should pursue those too. So it’s kind of opened the community up to considering covenants a lot more seriously. And now there’s sort of a crossroads in the community of like, Well, is this Check Template Verify concept delivering enough functionality? Is it reviewed enough that it’s something that we would want to adopt right now? And what are the trade-offs or risks and what other approaches might we want to take? That’s all what’s in the mix right now, in discussion.

Stephan Livera:

And just for people who—maybe they’ve really not heard about it—can you just give like a very basic explanation? What is Check Template Verify? What does it actually do to our coins if we use it?

Jeremy Rubin:

So all that Check Template Verify is, is the ability to—at the time that you create an address, or you create an output spend to an output—you can pre-commit to specific transactions you might want to have happen in the future. So the basic example, and sort of a building block for a lot of smart contracts that you might want to do using it, is an undo send button like you have in Gmail. I sent a coin—I fucked up—like I don’t want to do that. I’m going to claw it back. I’m going to take that coin back. Now obviously we don’t want Bitcoin sends to be invertible normally, and you’d want to be able to verify if this is an invertible spend, but hey, let’s say that you’re withdrawing funds from your cold storage. It actually might be nice if you had the ability to undo the move from cold storage to hot storage for like one day, just in case you sent to the wrong address. So a covenant can kind of help with things like that. And that’s an example of a single-step covenant. Where the magic comes in for Check Template Verify is that you can actually do a step that then has another step. So you could say: first it goes to this transaction and then the outputs of that transaction go to another transaction. And so by layering up these simple covenants of saying, And then from this coin, do this other transaction, you can build very complicated flows of funds that are programmatically controlled. You can provide multiple alternatives. So rather than just this specific transaction, you could say one of these 10 transactions is the action that I want to take. And so that’s sort of the building block that’s Check Template Verify. All it is, is a fancy way of committing to a transaction in advance of spending the funds.

Stephan Livera:

And so it might be good to also think about some of the overarching design goals and questions. And as you were writing about in your series, the Advent Calendar—so listeners I’ll put that in the show notes so you can go and check out Jeremy’s series—I had a read through it. And so there were a few interesting and important points that you raised in that series. So it might be good to just talk a little bit about some of those and how they might apply in a Check Template Verify world, or just in the Bitcoin world in general—how do we think about these aspects? So from your point of view, what were some of the most important aspects that we have to think about, for a Bitcoiner?

Jeremy Rubin:

Yeah, so I think that one of the funny complaints I get about Check Template Verify is that it’s not doing enough, like, Oh, we could make something more generic that does this or does that. The point of Check Template Verify is to be this minimum viable piece of functionality that lets you do a bunch of different useful things. It’s not designed to be the most powerful thing because, Hey, we should probably be relatively conservative about adding something really powerful that might change the properties of Bitcoin really fundamentally. So it’s not trying to be that. And so sometimes people will review it and they’ll be like, We could come up with something way better and way more general, way more powerful—why don’t we go ahead and do that? And it’s like, Well, then you’d have to convince the whole community that that’s the right security trade-off for Bitcoin. And so that’s one of the points, is that Check Template Verify—it’s designed in a stupid way to make it low risk. Like, the actual implementation is incredibly conservative with the amount of changes or security properties that it would modify for how Bitcoin works. That’s sort of one thing that I think is important to understand of like, inherently, it is a conservatively-designed upgrade. And that’s not necessarily something that—like maybe let’s say when we’re doing Taproot, Taproot is a little bit more ambitiously designed. We’re trying to get in all of these things at once that we want to do, and we definitely cut it off somewhere. Like we don’t have cross input signature aggregation, but we crammed in tons and tons of features and tons of applications and use cases into Taproot. Check Template Verify is just very, very simple. So that’s one thing that I think is important to understand. The other thing that I think is really just one of these key takeaways, and something to think about for any sort of change to Bitcoin, is a lot of people like to think about a stack. They go, What’s the stack? And what are we building on top of this? And what they think is: you should have a very strong foundation. And on top of that foundation, you should start building a better layer. And what you end up getting is a—well, let’s not call it a pyramid scheme—but you get a pyramid, right? Like you have a very strong foundation, then you build another layer and another layer and another layer, but at no point are the layers above more ambitious, in a sense. I mean, obviously you can do things in Lightning that you can’t do on the base layer, but that’s sort of the way that a lot of Bitcoiners think is like, Oh, we can’t do really sophisticated smart contracts right now because the foundation needs to be way more decentralized. And for example, people will criticize Ethereum—they’ll say, Ethereum is not decentralized, and so the smart contracts on it are stupid. That’s a very common complaint I’m sure you’ve heard. And what I want people to maybe internalize is it might not be a stack. It actually might be an arch. And covenants and the smart contracts you can build on them might be a keystone technology. So if you don’t know like how arches work, basically you’re building two curving, very unstable piles of bricks. And then it reaches the top, at which point you insert a large stone that puts pressure on the arch as it’s forming, and actually stabilizes the whole thing. So if you think about it that way, of Bitcoin being a little bit like an arch, you can start saying, Oh, actually maybe some of these smart contracts are going to reinforce some of the really critical properties we want Bitcoin to have: the stability, the strength, the resilience. Maybe, until we have some of these keystone technologies, we don’t get any of it at all. So I think that that is a very critical point that I bring up again and again throughout the Advent Series that, Hey, some of the applications that we could maybe build with CTV really do reinforce and make Bitcoin a better Bitcoin, not just adding things that nobody cares about like crypto kitties or something like that. It’s actually adding things like privacy, scalability, decentralization, and self-custody. And that’s the reason why I’ve been so motivated to push Check Template Verify forward.

Stephan Livera:

Yeah. Because I was actually going to ask you that question of, Does Bitcoin even need smart contracts? So that’s part of the question, right? And it depends on how you answer that question, because of course people could say, Well, Bitcoin already has timelocks, it already has multisignature, it already has certain basic forms of smart contracts. So this is one of the arguments that happens between Bitcoiners and shitcoiners, essentially, who come out and be like, Oh, see, the contracts are not expressive enough. And we should have like the Ethereum Java—the virtual machine, and so on. So could you help, I guess, put that into context then—in a Bitcoin sense, why, in your view, do smart contracts help Bitcoiners in their goals?

Jeremy Rubin:

So one point of clarification: when people say Ethereum has smart contracts, Bitcoin doesn’t, it’s definitely a case of people talking past each other. And if you want to make a metaphor for it, it would be like saying, In our country we have a legal system. Okay, cool. And then somebody might say, Oh, well like in our country, we also have a legal system—we only have employment contracts though. And you go, Okay yeah, those are contracts—that is contract law. That is a legal system. But when the Ethereum people say, We have a legal system, they’re really talking about the ecosystem, that there’s lots of different types of things that can compose and combine together. And Bitcoin does not really have—yet—that sort of broad ecosystem where things work together. That’s something that I’m hoping to see with Check Template Verify, is that people build different components that are reusable and composable. And we start seeing a little bit more of an ecosystem of applications emerging, if that makes sense.

Stephan Livera:

Yeah. And so bringing it back to those broader ideas that Bitcoin people tend to care about—we care about things like being able to, for example, self-custody our coins. We care about being able to make sure there’s no more than 21 million coins. We care about availability—being able to spend or receive coins when we wish to. And also scalability, as in being able to do this at scale, not just a few Internet nerds, a few thousand of us out there, but actually millions and someday billions of people. So maybe if you could talk through some of those high-level ideas and how you see Check Template Verify assisting in some of those ideas that would be useful for people.

Jeremy Rubin:

Yeah. So I think vaults is something that is most intuitive for the everyday user, because it’s something everybody can directly benefit from, rather than passively benefiting. Even though there is also a passive benefit which we can talk about, I think it’s kind of interesting. The direct benefit is: what do you do with your Bitcoin? Are you going to keep it on an exchange? Everybody kind of knows Not your keys, not your coin. If you don’t, at one point you could have executive order 6102 from 2022 that goes and says, Look, you no longer have any Bitcoin on exchanges. They all have to be forfeited to the government, and we’re going to pay you out at some fair market value or not pay you out at all. So if you self-custody, that can’t really happen. There’s a group benefit of like the more people who self-custody, the less effective those types of measures would be. But at an individual level, I don’t really know a single person who is just like really, really happy with their custody solution. Nobody’s just ranting and raving about like, Oh, I feel so secure. I never worry about any—everybody’s very worried about like, Okay, what happens to my coins? What happens if somebody tries to get them while I’m walking around and tries to mug me? What happens if somebody breaks into my home? What happens if I die and then my family doesn’t get access? So people are very concerned with all of these different what if questions. And one of the things that I think would be maybe a small benefit, would be if there were tools that let people more easily control how their Bitcoin moved. To do that, it makes sense to maybe go through a concrete user story. So right now let’s say that I either earn some Bitcoin or I buy some Bitcoin on an exchange, and now I’ve got some Bitcoin. What do I do with it? Okay. I’m going to withdraw it because I don’t want to keep it on the exchange—or somebody’s going to pay me. But let’s say it’s a lot of money and I want to do cold storage. So, Okay, I’m going to generate some offline keys. Maybe I’m using one of those metal plates or a Coldcard or some sort of offline device to generate a key. And then I send the Bitcoin there. But then how do I get it back? Let’s say that I’m a responsible Bitcoiner and I’ve got all of my net worth in Bitcoin, and I need to pay for my rent or groceries. Okay, well what do I do? Well, I’ve got to go to my cold storage and bring it online in some capacity. And that is a risk for a lot of people. You have the propensity to mess up when you go and bring your funds online. Also, you can kind of think about if somebody’s watching you and they’re saying, Oh, well I know that Jeremy goes and gets his coins on the first of every month and I’m going to wait and see where he’s going to go find where he keeps his little metal plate. And so all of those are very risky and scary things that could happen as behaviors. And so what I think the general issue is—and we can talk about multisig too. Like maybe you’ve split it up, but if you’ve got to withdraw from your multisig, you still need to go to three places. And so if you need to withdraw funds once a month because you don’t want to have too much funds in your hot wallet, well, then you’ve got to make sure that your multisig setup is not so inconvenient that you can’t do it every month. So if you wanted to say, have your keys in completely different countries, nobody’s going be traveling to three different countries or two different countries every month—that’s infeasible for most people. So it ends up being a thing where it’s like, Oh yeah, it’s a multisig, but I keep one key in my instant pot, hidden. And I keep the other key in my office desk drawer or something like that. That’s not where I keep my keys, if anybody’s keen to go look in those places. And so you end up degrading how much security you want because the inconvenience factor is too high. Now what you can observe out of this is that we’ve co-mingled the emergency behavior with the everyday activity. The everyday activity, which is withdrawing a little bit of coin, is not something that should use the same access patterns as your emergency backup procedure. And that is a big problem. So now I’ve set the stage: that was a lot of setup, but it’s kind of nuanced to understand how Check Template Verify can help. With Check Template Verify, what I can do is I can deposit funds into a vault that is basically a time release Bitcoin capsule. And once a month—let’s say it’s 10 Bitcoin—and I’m going to have it over the next 10 months. Once a month, I have the option to pull out one Bitcoin. Now, once I pull it out, I can do whatever I want with it. But if I were to, say, have this going onto my cell phone, and then my cell phone gets hacked. Now I’m obviously going to lose whatever balance is on that phone at the time. But for whatever balance is in the vault, I know my phone got hacked and I have a backup procedure that redirects the funds back into my cold key, back into my multisig. It could even send it to my wife and kids, for example. So you could have whatever emergency procedure be something that you can trigger if you’ve experienced a negative outcome. And what that means is that your cold storage actually stays permanently cold, because unless you have an emergency, you never need to bring it online. Nobody’s there to observe your access patterns. When you’re traveling for the holidays, you can leave one at your folks home, you can take one and have it in your office desk drawer and do one in like a bank, safe deposit vault—whatever you want to do. But you can make it pretty inconvenient for you to access it regularly, and then only have to do it in an exceptional circumstance. And that enables people to have a lot more security. The other property that’s really critical about how Check Template Verify works in particular compared to some alternatives, is that this whole setup is not interactive. So there’s never a point where, let’s say, I have funds on the exchange. I can directly move from the exchange into my vault. There’s no day where I’m saying, Okay, well today I’m going to take custody of 10 Bitcoin and then I’m going to move it to the vault. I can directly do it into a vault. And that’s actually a really important use case, and a good segue into some of the other topics. But I’ll pause there for a sec.

Stephan Livera:

Yeah, sure. So essentially we can think of it as like this way that potentially might help people have more control, let’s say, around how they manipulate or manage their stack, whether that’s their cold stack, and, let’s say, a hot wallet that they’re using for more day-to-day receive and spend—that they would periodically flush out any extra into their cold stack: multisig or hardware wallet, whatever the cold storage setup is. And so I guess there’s a few things that go into that, because then we’re going to need a whole new—like this is early days, right?—we’re going to need a whole new raft of tooling and equipment and things that will work with that. Obviously CTV is an important base part of this, but then we’re going to need wallets that work with it. We’re going to need hardware wallets that would support that. We’re going to need exchanges who know how to speak CTV. And of course we’ve seen sometimes exchanges can drag their feet as we saw them with, say, SegWit and so on. But of course, this is the idea, is you’re building in the direction that might give more sovereignty and ideally more availability as well. I think one other point that I’d be curious for you to touch on for listeners as well is just around that idea of congestion control, and this idea that you can sort of manipulate depending on the state of the mempool. So for listeners who are new, the idea is if there’s a lot of transactions all hitting the mempool at once, you’re going to pay a lot to try to get into the next block, but what if we could sort of strategically time it to go at the off-peak times? Maybe if you could explain how CTV could help in that case?

Jeremy Rubin:

Absolutely. I do want to just quickly respond to this idea of tooling and integration. It is something that CTV is very carefully designed to make it so that you can still use it, even if exchanges refuse to implement it. And that is sort of critical to this non-interactive property of how these transactions are created. You can literally create a Taproot address that contains the covenant inside of it. And as long as the right amount of coin is sent to that Taproot address—which is sort of the payment instructions that you’ve given to your exchange or to your payee—they have no ability to stop you. So for something like a vault, only you would have to have software for it. Your exchange would not have to implement support for it. And there is software that’s in development for this. And part of what makes CTV a little bit simpler than more general covenants is that it just puts out a list of transactions at the end of the day, because remember, it’s just pre-committed transactions. And so those pre-committed transactions actually already pretty much work with anything that supports a partially signed Bitcoin transaction. So a lot of hardware wallets already support that. So the support story actually should be quite simple compared to other upgrades like Taproot, which require an entire new signing algorithm or a new address output type. None of that is required for Check Template Verify in particular. So that time to [become] live is a lot faster than you might think.

Stephan Livera:

And so also then the congestion control aspect, if you could explain a little bit about how that works?

Jeremy Rubin:

Yeah. So I think one thing that is fun to do when you describe changes to Bitcoin is describing how there are ultimately flaws in how Bitcoin was designed originally. And there are certain things that you can point to where you’d say, Okay yeah, if Satoshi knew about SegWit, SegWit would’ve been in Bitcoin originally, it’s kind of a very straightforward thing. It was misdesigned slightly, but now we’ve fixed it. There are a lot of things that have been like that over the years. Like originally in Bitcoin, when you evaluated the scriptSiG and the scriptPubKey, you just concatenated them together and executed, and that was horrendously insecure, but it was patched and fixed and we improved it. Now for Check Template Verify, it is in a sense fixing one of these fundamental bugs of Bitcoin, which is that the time at which you spend a coin and which you receive a coin are inherently bundled in a transaction right now. So when I choose to suspend a coin, let’s say I want to pay a hundred people. At that exact same time, I also need to create the outputs for those hundred people. That’s a little bit weird. What if all of those outputs, they’re not planning to spend for a year? Why am I paying for block space today? Why am I using this finite time-sensitive resource today? When actually it’s going to be a random process over the next year of when people actually claim those outputs and spend them. Why bother creating the UTXOs if we don’t know when we need them? And so that’s kind of the fundamental bug in how Bitcoin transactions are structured, is that outputs are just a list of outputs rather than a Merkel tree of outputs—where they’re only lazily created. That’s what congestion control is: it’s letting a sender who is creating a lot of outputs choose to defer the actual creation of those UTXOs, and smooth out the difference between the urgency of confirming that funds have been sent—which is very urgent, right? You don’t want to have a unconfirmed transaction in the mempool for a very long time, because you might not actually get paid. So splitting that out between spending, knowing that you can receive, and actually receiving. And so by making those two separate concepts—(1) spending, knowing you can receive, and (2) receiving, that allows the network to process transactions in a lazy and very efficient way so that you create a bimodal—that means there’s two lumps of the graph mempool—where there are things that are trying to confirm as spend, and there are things that are trying to receive, and those receiving transactions are much less urgent because you already know that you can receive tomorrow and the funds are as locked in. So for big institutions like Coinbase or Kraken, who just do tons and tons of volume, one thing you can imagine is that when you go and request a withdrawal, you get put into a batch of everybody who wants to be withdrawn at that time. And if you are withdrawing from one exchange to another exchange, Okay, the other exchange can see and immediately credit your account. If you are withdrawing into a vault and the vault is a time release vault happening over the span of months, then you don’t care about getting that vault created immediately. You can do it sort of very lazily and just expand it when you see fit. So that’s sort of the insight of congestion control, that some of these things are actually not very time-sensitive. The best example of this is Lightning channels. When you open a Lightning channel, you don’t want to use it necessarily until it’s confirmed, otherwise the funds can maybe be double spent. But you don’t really need the output to actually exist. It can just be provably that you could redeem it when you wanted. And so by combining something like congestion control with Lightning channels, you can actually open up tons and tons of payment channels that you can then immediately get liquidity on and then only lazily claim them if there’s ever a reason to close it out.

Stephan Livera:

And so what would it look like in practice, then? So let’s say we were living in a CTV world and the exchange can pay out to me. Let’s say I purchased some coins on the exchange. I withdraw them into my CTV-enabled vault. And let’s say the mempool is very high at that time. It’s very expensive right now. So the exchange uses this technique to sort of lowball that fee and say, Okay, we’re just going put it out there at a lowball fee. And then what’s happening on my side? Do I have a wallet that’s kind of looking and saying, Oh, I can see there’s a waiting transaction out there in the mempool, but they put it in at a low sat per byte. Could I claim that in a few months down the line? I’m like, Oh, actually I need that money now. How do I do it? What would that look like?

Jeremy Rubin:

Yeah. So people—this is something that people like to sort of like freak out about, because they’d be like, Look at all the complexity that’s going to happen! And I think it’s important to zoom out a little bit and remember that if somebody is going to claim that they paid you, they have to be able to provide proof that they paid you. So if you withdraw from Coinbase, ever—I don’t want to pick on them in particular—like legally, they permanently have to keep a record that they paid you, or maybe they get a signature from you that you have accepted the payment. But like, they have to be able to keep those transactions. Otherwise, if you withdraw, you can just sue them and say, Hey, you didn’t pay me. And then they have no defense if they can’t provide those records. So this is something that already exists. That’s my first kind of point. The second point is that what happens today, if you’re not doing any sort of batch payment, and then if somebody pays you and the transaction sticks in the mempool forever because it’s not confirming—Okay, well they have to pay more fees. But block space is finite, so not everybody can get that. What’s the story around that? How do wallets handle that today? So these are just kind of like koans for enlightenment. And the enlightenment is that what we’re doing today already is broken in the way that everybody’s concerned that CTV congestion control might be broken, because these things you already have to do, people just don’t really necessarily recognize it because blocks are empty. As soon as blocks become full over long periods of time, people become very aware of the fact that things fall out of the mempool and they’ve got to revive these transactions and stuff. So the way that I see CTV progressing—and this is more concrete over the next, let’s say, couple years—would be: at first, exchanges will take the opportunity to say that they’re just going to do a two stage transaction. One transaction is just going to lock in that all of the funds are confirmed, and that will pay a high fee, but it’ll pay a high constant amount of fee. And this is incentive-compatible. That means that this is the behavior that would naturally emerge, because when exchanges have a transaction that gets stuck in the mempool, they want to replace-by-fee it. And when you do a replace-by-fee, you have to pay an increase in fee rate, which for a size N transaction means you have to pay N more fee. So having a transaction with a single output means you only have to pay 0-of-1 more fee to fee-bump. So naturally what exchanges will want to do for congestion control is they’ll want a single root transaction with a single output that they’ll bump and bump up until it gets confirmed in a block. That will be the most fee-efficient thing for them to do. And that output will commit to a transaction that pays out the batch of all the users that they want to do. And that will be less time-urgent, right? Because they will say, Okay, well we can prove to you—here’s the transaction. But now our SLA—that’s like a businessy term that just means our service level agreement—like what are you guaranteeing the user that they get? What an exchange might say is, We guarantee that you get one block finality, or two block—like we guarantee that we’re going be paying top of the mempool. Maybe somebody censors us or doesn’t like us, but we guarantee we will always pay top of the mempool for confirmation of receipt of funds. Nothing’s going to be sitting. However, we have one week with which we can take the opportunity to pay a lower fee rate for the full redemption—but we are still on the hook for that. We will still solve that in a centralized manner. And if you’ve got a Lightning channel in there, which is part of that non-interactivity that you can do that—right now you can’t do that—like, everything will ultimately be okay, and you can use it immediately. So that’s like the first step on that congestion control journey. Now one further point would be, what if you have customers who have different SLAs? You have customers who you want to give a one week guarantee, and you have customers who want to do a one month guarantee. And different customers might have different needs that would constrain that. For example, if you’re depositing from one exchange from another, that exchange might say, Look, it’s not sensitive for us—give us the cheapest option, because we know we have the funds. We can account for it, and we manage many, many withdrawals, so we always have enough liquidity. We don’t really care. Consider it just like a little bit colder storage—we can see when those funds are moving, right? So they might want to pay less. The others might wanna pay more. Now, if you have two different groups of users who want to pay different rates, you can’t put those in the same transaction because transactions only pay—and this is building some intuition for what I was saying that it’s a bug in Bitcoin—outputs that have different priorities can’t go in the same transaction unless you want to overpay for half of them, right? So now you could imagine, instead of creating one fan-out, you could say, Okay, well there’s another layer that fans out into 10 different buckets for different service level agreements. So things that are Lightning channels are like maybe really, really not time-sensitive because they’re already created and usable, things that are cross-exchange are a little bit more time-sensitive, but still not very. And then things that are like, Actually, we just need the funds available for some arbitrary thing that’s high priority, maybe, and people are willing to pay for that. Now what’s cool—and this is where we have to go back and ask the question like I said earlier, What’s happening right now? What’s happening right now is if you have a lot of users requesting withdrawals, things are unconfirmed. So already this story is immensely so much better for the user, because they are getting that instant, next block finality experience for a mempool that is completely full and otherwise they would not be able to get confirmation at any reasonable price. And we can talk about why that’s important for decentralization and self-custody as well. Like right now, if you wanted to drain every account on, let’s say, Coinbase, it would take you like weeks or months of transaction time in order to do that. Now, if you’re shutting down a service because like, Oh, the government is doing some order and we’re going to shut out all our accounts before that happens—now you can actually clear all those shutouts immediately. It’s very, very good for users that this is possible. And the longer—and this is like the final, sometime in the future—you’re just going to be receiving arbitrary proofs and it’s maybe going to be the user’s responsibility. Maybe if you’ve got a better SLA with the exchange or a payer, they’re going to expand it for you. But you’ll get these proofs, and you’ll have not that much work to do if you want to get paid, but you’ve got a little bit of transactions to do a log. And if nobody else—if you’re the first person—then ultimately people worry about the overheads. I’ve proven in some models that there’s no overhead from this approach. But you’ll get something, and when you want to spend from that coin, you will have to do some on-chain work, claim the coin and then spend it. Keep in mind, that’s that mempool with different humps. Like, now that you’re trying to do a spend, you want to pay the higher fee rate, whereas everybody who just wants a lazy redemption will just do the work passively when the mempool is low enough. That’s the view for congestion control. I think it’s really, really good for all users of Bitcoin. I think it’s really, really good for businesses that are operating on Bitcoin, that they have more fine-grained control over these things. But it does just seem kind of like nerdy, niche, and nuanced. So everyone’s like, Ah, do we really need this? Blocks are empty. And I’ll give you the strongest argument for that and then I’ll stop, which is Jevons paradox: blocks are empty because everybody knows in the free market somewhere that this problem exists, and relying on Bitcoin for these use cases might be really inefficient. If we make it more efficient, then more people will use it, and then we’ll see blocks get full. So it’s not really a valid argument to say blocks are empty so we don’t really need stuff like this yet, because, Well, blocks are empty because everybody knows they can’t rely on blocks being not full. It’s one of these chicken or egg problems. If we make the block space much more efficient to utilize, more people will use it.

Stephan Livera:

Okay. So the way I see it—and I broadly see the point of that, I think it makes a lot of sense—because it’s one of those things where it might not look like we have a problem until we do. And then all of a sudden we might be in a situation where there are lots of people who literally cannot self-custody, because they either can’t afford the price to get into the next block, and just literally not everyone can fit into the next block. And of course we could say, Look, exchanges nowadays, they support batching. So maybe that would be a little bit better than let’s say if this were to happen in 2017, at the time when exchanges didn’t support batching and didn’t have SegWit. Whereas nowadays you could sort of argue, Okay, SegWit plus batching plus maybe a little bit of impact from Lightning, and that might be enough for today. But who knows. If we were to hit 10X in users or some crazy—and crazier things have happened—then at that point it would be quite difficult for people, especially for people who aren’t rich enough to be able to pay the high fee. So of course, if you’re a Bitcoin baller, you can pay and you’re fine, but this idea could be argued as, It’s actually improving accessibility in a self-sovereign way. And so I guess that’s part of why I was reading about this and thinking, Oh, okay, that could be interesting from that perspective, because in that view, if more and more people can self-custody, well then that in some sense makes the overall system more robust because more and more people can now self-custody. And now it’s harder to go out there and individually control those people instead of going to the one choke point, the chokehold, or the big exchange or vault aspect. So I can see it from that point of view, but if you could just explain for us what it would look like? I mean, let me say how I’m understanding it. So the idea is you might have some CTV-enabled wallet or software, and maybe it’s watching the mempool and the blockchain and sort of going, Oh okay, fees are high right now. This exchange has broadcast it’s withdrawal, and I can see mine is in there—I’ve got my proof. But the fees are high right now. So I’m going to wait until the fees are low to actually then pull it out into my own wallet. Is that how it would work? Or help me understand that?

Jeremy Rubin:

So the funny thing—and this is why I keep pointing back and saying all the code for this and all of the issues already exist. So what happens today, if let’s say there’s—I don’t know if your listeners will know the term long chain—but it means a stream of transactions. So like A pays to B pays to C pays to D pays to you. And what happens if all of those are unconfirmed sitting in the mempool? What does your wallet do with that? If you see those in the mempool—and I think that that’s where people are a little bit confused—of like, I’m trying to decongest block space, but I’m okay with still broadcasting things, right? Broadcast whatever you want, let users know about it. But this is really just stuff that Bitcoin Core wallet should do. When you see a long chain and you see yourself getting paid by it, you should—and I think you actually do—save all those transactions, because those are things that you need to know if you want to get paid. And it’s very rational that you should save those things. I’m pretty sure we do save those transactions, but it would be weird if you deleted a transaction that was paying you. There’s no good reason to do that. So in a congestion control world, if you imagine that you’re not trying to decongest the broadcast or the mempool, but you’re trying to decongest the block space availability, you would see these transactions—you would save them. And then you can, with certain forms of congestion control, trace up that it’s a congestion controlled transaction and you could credit yourself with the balance. You could say, Okay, I got paid. Then let’s talk about coin selection. When you go to do a transaction, it is your wallet’s job to give you the cheapest transaction possible, right? If for some reason you have a bunch of little coins or you have one Bitcoin and you’re trying to do a big transaction, you should use the big one because it’s going to be cheaper than using all the little ones that you have. So wallets already know about the idea of what is the cost of me using this output. And I think that they should know— one other thing that wallets should do right now is if you see something that’s going unconfirmed for a long time—and it’s not trusted, so you can’t prove to yourself its CTV—you want to Child Pays For Parent that to drive the confirmation. Wallets already should be doing this. So that’s where for a lot of these—and I’m going to sound like a broken record—these are already problems that exist that you will see when mempool gets more full. The difference is, with Check Template Verify, you at least can know that the funds are fully confirmed and can’t be double spent. So the software for that should already exist in Core. And to the extent that it doesn’t—whether or not CTV gets merged—it’s a bug, right? Like, we should fix that. That would better match rational user behavior, that you’d want to track things that are paying you, you’d want to CPFP them, you’d want to save them. And when you’re making a transaction, you’d want to compute, Well, what’s it going to cost for me to do this transaction that CPFPs this thing? What’s the cheapest thing I can CPFP? And this is where congestion control is really cool, is it exerts a passive back pressure. Because you will passively wait for the cheapest thing, and the longer you wait to spend an output, the more chance there is for somebody else to do part of the expansion and pay for some of the transactions you would have to do to get to your individual output. So that’s where it makes wallets very lazy in trying to defer doing the work for somebody else to pay for it who has more urgency. And that’s a back pressure on the entire network, of saying, People will prefer to wait to spend funds because somebody else might have more priority. That’s a very good thing for—it’s not decreasing demand, but it’s increasing willingness to wait for getting that full redemption, because there’s a benefit for waiting.

Stephan Livera:

Yeah. So we can think of it like we’re decomposing, let’s say. As you said, they might be the very high priority people who are like, I want it now and I’m willing to pay for it. And then there’s that kind of medium level people, and then the, I’m very patient—I don’t need it right now. You can take as long as you want because I want to pay the minimum. And so we are trying to decompose those in a way that makes more sense. The high fee paying person is like, Yeah, I’ll pay it now. So if you could just help me understand this part: is it essentially then that instead of actually broadcasting the transaction, exchanges are just going to give you a proof. They’re just going to hand you a proof and say, Hey Jeremy, I know you wanted to withdraw these coins, but actually we’re in a CTV wallet and you’ve told me you’re happy to wait, so here’s a proof instead. And you just trust that until such time as that you actually actually need it. Is that roughly how?

Jeremy Rubin:

Pretty much, yeah. I mean, you don’t have to trust it. You can verify it, right. It’s not really particularly sensitive. You can store it in a Google drive, you can send it to your friends, you can back it up however you want. Now there are some other applications we can talk about too, that take it to the next level, but for the most part, these things are not sensitive whatsoever. It’s just like, Okay, it’s a thing that you have. It’s a receipt. If you think about it, with things like Utreexo—I think you’ve had a show on that—it’s very similar to that. Like you can’t just go to the network and say I have this UTXO, you’ve got to carry the proof that it exists. It actually—you can kind of squint and CTV looks like an in-band version of Utreexo, right? Where you’ve got to keep the proof of how to actually get that redemption. Now there could be situations where the exchange gives you a CTV thing that’s like the proof—it’s like a million long and you’re like, What the heck? So businesses would probably want to put limits on that. They’d say like, Look, we’re not going to give you a proof that’s longer than 32. That would be really long—32 transactions you have to do. But 32—I can’t do the math off the top of my head—but if you have rate X4, that means every time the transaction splits, it splits into groups of four. It’s optimal for some niche math reasons. But you’d be talking about 4^32 people getting paid in a transaction, and that would cause the depth of 32. So that would be way too big. Probably something like 16 or—and sorry I just don’t have the numbers memorized—but I think like 14 transactions of size four outputs each—one input—would be enough to cover a billion users, just to give you some back of the envelope math.

Stephan Livera:

So it could be way less than that, yeah.

Jeremy Rubin:

Yeah. So it would probably be way less than that. And the longer you wait, the shorter the amount of proof you’re responsible for gets. And for every person who does a transaction that’s in your subtree, you lose one of those. So it gets pretty small pretty quickly. The total overheads if you go up a tree end up being linear. So it’s not like—some people are like, Isn’t this exponentially more data? It’s like, No, actually in some uses of it, it’s like 1.2 times more data than if you just did a single batch. And in some applications of—where we talked about priority groups—you can actually prove that it’s actually cheaper for some very niche reasons that are probably out of scope right now, but we can get into it if you have interest. And so it’s not that bad. The other thing that’s interesting, and I’m always gonna point back to: Well, what’s happening today? If you received a batch transaction, it obviously can’t be a billion big, but it really could be a thousand big. So let’s say that you received a batch, it’s a thousand big and it’s not getting confirmed, so then you’ve got to CPFP it—you CPFPing that batch is going to cost you for all the other thousand people, which is really expensive. But if you have 4 times 14 outputs that you’re paying for, that’s very small, right? You’re paying for under a hundred outputs. So it’s like 20 times more efficient for you as the end user. So selfishly, this is 20 times cheaper for you to get into a block than if you had the batch of a thousand directly going.

Stephan Livera:

I see. Yeah. And so I guess in practice nowadays, exchanges might be doing like a batch withdrawal, let’s say a hundred outputs. But in this example, they could chunk that down into those stratified groups of low fee, medium, and high fee people. And I don’t know, maybe there’s even an argument of like, if you are a low fee person, but somehow you got included in a batch with a high fee person, and that high fee person CPFP’ed—does Child Pay For Payment—you get the free ride because he paid more and now you get your coin confirmed sooner because he took on the cost for your little batch or whatever we’re calling it. So that’s an example there.

Jeremy Rubin:

You could even put—and this is an example people worry about—like, What if there’s no incentive? You could even have a change output in every one of these sub-batches that’s owned by the exchange. And the exchange would say, Hey look, don’t worry about this batch getting lost, because I’ll lose money—I have incentive. And that’s actually kind of cool as well that the more people—the bigger the sub-batches, the more data redundancy you have. Like, if you’re four, you’ve got four people who also have an incentive to try and get that thing. So if you had an outage, there’s still probably somebody out there who has that. And if you made it 10, it would be 10 people. Now that’s not perfect, but that’s something that is kind of a cool property of it to think about—other people have incentive.

Stephan Livera:

Yeah. Gotcha. And so one other question I wanted to raise now—and this is also related to Shinobi’s blog post which I’m sure you’ve seen as well—which is like this idea around, I guess it’s a little hypothetical, but let’s talk that out. So what Shinobi, as I understand him, is he was getting at this idea that, imagine if the ecosystem had gone into a CTV world and there were people who maybe got essentially trapped in a way, where they had coins that were locked into a script with, as an example, a very long redemption time, or, like to your risk that you pointed out earlier, that let’s say the government is a counterparty, and that maybe they’re a counterparty that the user doesn’t want. So what’s your view on that? Do you view that as an overly theoretical risk? Or how are you thinking about that?

Jeremy Rubin:

Yeah, so Shinobi has a very particular argument around this. It is coherent. I don’t know if I fully agree with it, but the argument is that covenants are okay as long as you can prove that they terminate. And not just that you can prove that you terminate, maybe that’s too technical, but, that you had to decide all the possible things that could happen with this covenant before you spent to it, provides some form of social safety of how they’ll actually be used. So an example of a covenant that maybe would annoy someone is: let’s say I’m on my deathbed—you can pre-plan for these things too. And I want to bequeath 1 Bitcoin a year to one of my children. I can give it to them, and there’s no way they can get it faster. That might really annoy them, right? Because they’d be like, Oh, I have enough Bitcoin. Let’s say I could do this for their whole expected lifetime. So they’re going to be getting 1 Bitcoin a year for a hundred years or something like that. And they might be really annoyed by that. There’d be no way for them to get out of it. So it is actually kind of a problem, right? You’ve got to be careful when you attend to these things, they can live for a very long time. But where Shinobi makes the argument is going, Well, that kind of thing is okay, because you had to explicitly decide the day that you wanted this thing to end, all of the installments, and you pre-committed to every possible state transition. So you knew exactly what was going to happen—that’s kind of okay. Where Shinobi has a problem is not with Check Template Verify, but with more powerful covenant varieties. You might have something where you say this coin—as long as the government signs off on it permanently—it can be spent however you want. And it’s like, Okay, well now what happens? Well, what’s the cost of receiving this coin to you? It’s actually not that high. You’d be like, Well, the government’s kind of fine—they’re signing off. I don’t mind taking it. And these things could maybe proliferate and become relatively innocuous. This could be something that maybe an exchange is doing. They get an order that says, Hey, you’ve got to make all of your Taproot top-level things also have another government key that requires approval for the transaction. And that could be a thing that happens. That would be bad. So that’s something that I think Shinobi is particularly worried about, that covenants would just cause this to be the case socially, that people are uncareful, and it’s really easy to coerce these covenants on people, because you receive a coin, it’s got a covenant, but, Hey, the transaction seems to be going through okay. And I think the point that he’s making is it is very different from a world where when you construct a covenant, you have to pre-plan every possible thing the coin could do in its future, until it exits the covenant. Those are just very different models. And I think where—there’s an argument that Shinobi is wrong, is that you can kind of do these things with multisig already. At that point it’s like, Well, at least with a multisig, there’s still some human in the loop deciding whether you wanted it to keep on happening. But if it’s just a covenant that’s self-enforcing itself, you can’t even vote that out of office. You’re just stuck with it forever and you’ve got to live with whatever that means. So I think it’s a sound argument overall. I don’t know if I agree with it being something that we should worry about. There are lots of ways to destroy Bitcoin that are problematic. I am sympathetic to the idea that what people do socially has an impact, even if you don’t use it personally. Because if everybody else gets 6102’ed, my coins are probably not valuable anymore. So I’m sympathetic to it. And I think that more broadly, Bitcoin is a big tent, and you have to respect everybody’s opinion when you’re pushing something. And so maybe developers have convinced themselves that covenants are good, but I think most people are still at the point where they’re like, This sounds scary—let’s be very cautious with this. And that’s where I still feel like CTV is a very solid approach to adding covenants insofar as it is a very, very locked down, restricted model of types of things that you can do, that happens to be very useful—that you can do a lot of great things with—but none of these socially dangerous things people might worry about.

Stephan Livera:

So let me try to summarize some of that. So essentially part of Shinobi’s concern, and part of the overall concern, could be that if covenants are done in a certain way, that people could get trapped into certain conditions, whether of their own doing—like that they had written up a condition that was just too restrictive or actually didn’t reflect what they really wanted, or arguably the social aspect of, let’s say, having a government as a counterparty on every transaction or something like that. And then I guess your rejoinder might be something like, That would apply in terms of—it just means you have to write your CTV and write your template and write your contracts and conditions. And that’s where it’s going. And I guess part of your argument is also that that could even happen today. If the government came out and said, Okay, every exchange—all your coins—we want to be at least one of your multisig parties or even the majority quorum holder on your coins. And that could happen today. Is that roughly what you’re saying?

Jeremy Rubin:

Yeah. I think maybe just because it might be hard for the audience to parse, is that Shinobi likes CTV. So his view is kind of that something like CTV is basically near or at the limit of how sophisticated covenants can be without introducing these social issues that he worries about. And maybe there could be some things that are similar, but as soon as you start going to covenants that could be potentially infinite or things that are more dynamic state or can be substituted in, some of these concerns become a little bit more grave and merit more consideration. And his view is basically like, We can get to CTV. There are enough demonstrated benefits of something like that, that it might be worth doing. But going beyond that, he gets very upset when it’s mentioned of like, Oh, well CTV is a good first step in covenants that will build confidence and maturity around. He’s like, No, no, no. It’s not a first step—it is the step. There’s nothing that should come after it!

Stephan Livera:

So it’s more like a concern of going too much beyond what it is, at least as I understand it. And so the other part—I know ANYPREVOUT is not really directly comparable with Check Template Verify, but just for the sake of clarifying for listeners, could you help explain for them how they differ?

Jeremy Rubin:

Yeah. So Check Template Verify and ANYPREVOUT are conceptually very close in that they’re both based on different ways of hashing a transaction. Hashing just means committing to— that’s how you decide which transaction you should do. It’s like, Okay well you proposed this transaction, we’re going add up all these little bits, and we’re going check that the signature covered that, or we’re going to check that that was in the script. So at core, CTV and ANYPREVOUT are both ways of hashing a transaction, committing to what you want to have happen. The difference is that CTV is a direct commitment to that hash in the script, and ANYPREVOUT is being able to do that dynamically with a signature. Now as a quirk of how ANYPREVOUT is structured, it turns out the fields that you cover in the transaction are relatively similar, and that enables you to directly commit to a signature inside of the script at the time you create the output. That’s something that you can’t—I mean, you could do it today, but if you went to validate that, it would cause what’s called a hash cycle, which means you’re trying to sign something that includes itself as the signature, and then you can’t ever really do that computation—and so you can’t validate that signature. But with ANYPREVOUT you can, and that means that you can commit to a particular format of a transaction using ANYPREVOUT, and they do intersect to a degree. I would be very happy if ANYPREVOUT were to be delivered to Bitcoin. And there would be things I could build. There are a couple of cases where they don’t intersect, and they have relatively large differences in terms of the cost of using it. And that’s where, if congestion control is something that’s relatively an important use case, cost actually matters—making all of the congestion control transactions more expensive is a bad thing. So that’s one of the arguments where it’s like, even if they do overlap, the situations where you might use them differ pretty broadly. And there’s also some issues with like, Okay, well how are you picking which key you’re using for this? And is there a single key you can use? You’ve got to generate these signatures. It makes compilation much slower. It just balloons in terms of like—there’s all these different things that go in that they’re sufficiently different—one is higher cost than the other. So I don’t think they’re really actually that competitive. Where they might be competitive is I think that there’s two arguments from either—let’s call them camp—but I think everybody’s friends here. One is that, Well, if CTV is conceptually a subset of what you can do with ANYPREVOUT, from a risk-averse perspective, it actually helps ANYPREVOUT be audited as being safe sooner, because if we can agree that CTV is safe, then ANYPREVOUT has less review surface required. Because we already know these things are doable. So that’s one benefit of having it. And if you’re really risk-averse and you want to sequence things—you want to say this and then that—we can show that the smaller thing is safe, and then we can move to a more sophisticated thing after. That’s one argument. The other argument you could make is you could say, Well, why don’t we just do ANYPREVOUT first, because we’ll get something similar to CTV. And if it’s so popular that we want to optimize it, then we’ll optimize it in the future. Why not just do something that covers both use cases now? And this is where things get dicey, is I think people like to hold these things as very abstract concepts in their head and just go, Oh, this next or that next? It’s like, Well, CTV is very simple. And developers may agree or disagree about the specifics of this. It is basically in a mergeable state today, where if we decided that we wanted it, it could be in a release in the next couple months. You can question me on it. Some developers have dissented—that’s the case. But it basically has the shape of what you would expect a BIP to have before getting merged. It has been reviewed by a lot of different people. It’s been used by a lot of different people. There are tests that are relatively exhaustive. There are test vectors that any implementer could use to verify that they implemented it correctly, if they’re doing it as a third party thing. There are tool chains built on top of it for Rust Bitcoin in Sapio, so it’s in a relatively good state for the things that it’s saying it should do—there’s an open PR. ANYPREVOUT is not in that state right now. And so the notion of like, Oh, well, we should be doing ANYPREVOUT—really the question is like, Okay, well who wants to advocate for it? And this is where the, the issue comes up is that ANYPREVOUT is something that nobody wants in particular. People want Eltoo, right? So people aren’t getting excited about APO as like, This is what I need. They want Eltoo—but nobody actually wants Eltoo. What they want, is they want the Lightning Network to be better, right? So it’s sort of like when you’re debugging a tech support problem, you always have to ask somebody, What are you actually trying to do? Beause they’re going to come to youand they’re going to be like, How do I plug in the VGA cable into my printer? And you’re like, Wait a minute—what are you trying to do? Oh, you’re just trying to do a scan? Here’s how you do the scan. So when you peel back the layers on like, Well, what are you actually trying to do?—the thing people want to do is make Lightning as good as possible. And for BIP118 in particular, we want to do better watchtowers. We want state compaction. And those are kind of like the main things that ANYPREVOUT is bringing. There are other things we want. We want better performance, we want multiparty channels. There are certain things that we want to experiment with, and those are are all good things. The problem with ANYPREVOUT becomes—if it is really the upgrade that is for the Lightning Network, that is to give us the better Lightning Network, we want to thoroughly make sure that when we get APO, it doesn’t need to be subtly different, or there aren’t other things that need to happen at the same time in order for us to actually use it. And that to me is sort of the main holdup for it, because there is such a specific structure of the application that we have to deliver with BIP18, it actually is worth not doing that one prematurely until we’ve fully fleshed out what the Lightning spec upgrade would look like. And it’s not just like FUDing that there are problems. There are real issues that we need to think about to make Lightning work perfectly. Like, how do you get transactions into the mempool? How do you add fee to them? Those are very big questions. What do the PTLCs look like? It was only a couple months ago that AJ realized that just with Taproot, you can get rid of the state storage issue. You can’t solve for watch towers. You can’t solve for the toxic waste problem. But if you want to run a channel, you only need to store a constant amount of data per channel now—you don’t need to store all previous transactions. So we’re still even kind of figuring out what we can do with Taproot to make the best Lightning possible. And there’s still issues in Lightning that we know APO is not going to be solving, and that we still want to figure out around mempool pinning and various attacks and things like that—layered commitments, the exact protocol that will be running. There are developers who have concerns around like, Well, do we even want to get rid of punitive channels? Like, is the punishment actually good in situations where the mempool is really congested? Will people have incentives to just try to cheat constantly? And so all for all these reasons, it just sort of becomes—from my perspective—very much up to the Lightning Network to deliver a coherent, This is a upgrade or set of upgrades that can be used in conjunction and are perfectly designed to give us a much better Lightning Network. That’s sort of the burden that BIP118 and its developers, I think, feel. And Check Template Verify, for what it’s worth, it is not trying to be specifically delivering something for the Lightning Network, even though it does have some applications that really do benefit the Lightning Network. It doesn’t have anybody who’s depending on a particular behavior of it. It’s more like, Here’s a thing that we know how to do. It can do things for congestion control. It can do things for vaults. It can do things for Lightning. It makes all of that a little bit better, but there’s not like a very specific design it has to satisfy. And that’s I think what makes BIP118 more difficult to say, It’s next and it’s ready to go, when there are still these unanswered questions.

Stephan Livera:

Yeah. So hopefully that gives listeners some perspective on the compare and contrast between BIP118 and BIP119, which is Check Template Verify. And so I guess the other question people are probably thinking about is: what kind of risks might CTV introduce into, let’s say, those people who want to run a Bitcoin node? If you could just talk a little bit to the computation requirements, hard drive requirements, networking requirements—are there any changes that people would need to think about there? Would that reduce the accessibility in any way of—again, I’m, I’m not a developer, but I’m just trying to summarize how I understand it—that each Bitcoin node might now have to maintain and retain this proof and then calculate, Oh, okay. How many possible scenarios are there? Would my Bitcoin node be able to run that? And is that accessible for people? So if you could just answer that for people.

Jeremy Rubin:

Yeah. That’s a great question. So I think that the biggest cost is just like, Any change to Bitcoin is a risk—people are, in my view, definitely overfixated on the risks of consensus changes. We want the protocol to be well defined and bug free, but any change to Bitcoin is pretty much as likely as any other change to introduce a critical bug or vulnerability and nobody is paying attention to—well, some people are—but nobody’s paying attention to the same degree about changes in the networking stack as they are about changes to the script interpreter. I don’t know why people don’t care more about what’s happening there, but for some reason it’s just very, very popular to worry about soft forks, even though they’re like the lowest risk because they get a lot more review anyways. So it’s just a weird paradox. That’s one thing that’s like a cost for nodes, and something that people could be worried about. But in terms of—assuming everything’s all fine and dandy—if you’re running a node, the, the main things for Check Template Verify is that the amount of memory to validate a block goes up by I think about 32 bytes per transaction. It’s not the biggest cost. We’ve done bigger costs. Like Taproot was substantially more, and that’s in caching. And if that were a problem, we have some mitigations we can do to make caching use less memory synchronously. So there’s some things we could do if it became a problem. But at that scope, we make changes that use that much more memory all the time, and we don’t worry that much about them—maybe we should—but we don’t worry that much about them because it’s like rounding error amounts, so it’s not a big deal. And you have to do a little bit more hashing as well. So you have to do a little bit more computation. It’s on par with what we’re doing already—it’s a little bit more. And then during validation, if it weren’t implemented correctly—and this again goes into the bug category—there could be things that could take your node offline, something called a quadratic hashing bug. But the way that CTV is designed, and maybe it’s a little bit subtle: it is immune to those things if you use the caches that I talked about previously, and that’s why those are required. And it is subtle, because it is something when people say like, I more powerful covenants, oftentimes those more powerful covenants, there’s no way of implementing them without introducing some of these resource exhaustion attacks. So for example I can give you a very, very simple one: Check Template Verify commits to all the outputs. What if instead, it had an integer that corresponded to a bit mask of which outputs should be selected, right? So now we say, Okay, well we can do up to 32 different outputs in a CTV transaction. And we have an integer that tells us by either being a one or a zero for each index, which output we want to hash. You can’t cache anymore, and now it’s possible to write a small script that causes you to do an N square—that means you have to look at a thing that is N long, N times validation, and that might be for a block that’s constructed by a malicious miner—that might be the entire block. So you might have basically like a megabyte times a megabyte of stuff to do. And that could be way too much computation. And CTV is designed not to have that problem. But even for mildly more sophisticated things, you run into some of these issues. And so to concretely answer your question, CTV should probably be as minimally invasive as possible for any sort of opcode change. It’s actually less of a burden than CheckLockTimeVerify or CheckSequenceVerify work, because those required some more context being available in a different way than CTV does. But overall my point would be, It’s not that much. And if we were to do something more sophisticated, there are a lot more things that we would have to be thinking about in terms of that validation cost. And that’s part of CTV’s design conservatism, is that it’s very easy to prove that it does not introduce any resource issues.

Stephan Livera:

Yeah. Are we seeing any commercial use ideas? Or do you foresee that coming down the line soon? In terms of, as you were saying, things like vaults, congestion control, non-interactive channels, maybe payment pools. Do you see any ideas around that, or commercial use?

Jeremy Rubin:

The two commercial use things I’ve seen people get really excited about are congestion control and vaults, along with non-interactive channels. For vaults, it’s sort of—I’m not gonna name names—but it’s exactly who you’d expect in terms of people who manage a lot of a lot of Bitcoin. That is a no-brainer. And one of the weird things with vaults is, for protocol designers, you always want to say like, Oh, I want something that’s more flexible that, What if I wanted to do this? And what if I wanted to do that? And I wanted to allow vaults that could also do this? For companies that custody Bitcoin, they’re just incredibly pragmatic. Like, right now we’re doing multisig. We would like to have more structure around this. We don’t mind if we don’t have precise controls over variable amounts getting withdrawn different times. We manage lots of Bitcoin through different processes. What we want is a backbone that we can statically audit and prove is correct, and use very robustly. All these other things are kind of like the 5% better version on top the 95% improvement. So for them, I think that’s the perspective I’ve seen for large custodians. And two years ago, actually—and this just goes to show you how long this CTV process has been—Brian Bishop published a open source CTV vault, Python vault program. And Sapio has vaults, and people are toying around with thinking about different types of vault design and ways of composing them and what sort of triggers and things you might want to have. And that’s something that, because CTV is so flexible, it’s not like there’s one way to design vaults around CTV. You can design whatever flow of the funds you want, which is actually very good for institutions that might want to inject different numbers of, of checks or safeguards in. They can pick and choose what parts they want. So that’s one side. The other thing that is popular is congestion control. Congestion control popularity is kind of interesting, because some people get really, really critical of me when I talk about it, because they go, This is the most boring problem you could have picked and nobody cares about it. I don’t get why you’re doing it, except for the people who like congestion control, who get exuberantly excited about it, because it solves some of these really big issues. And the people who get the most excited about it are people who work in the Lightning space, because what do they want to do? They want to open up lots of channels. I think Alex Bosworth tweeted recently. He said, People are talking about how we could make channel opening more efficient. However, we could open up a billion channels if we filled every block for a year with batch channel creations of 50 people doing a pre-signed transaction together. And my response to that was like, Cool story, bro. We can do a single transaction that opens up a billion channels using CTV. And congestion control with back pressure and everything if they have to do a contested close. And so that’s where, for people who are building services that maybe open up lots of channels, CTV really really helps with that. So Muun is an example. Lightning Labs is also another example where they’re going, Huh, if we have CTV, we can create a request to open up a—we didn’t talk about it—but non-interactive channel, create a request to open up a non-interactive channel. Our services can then aggregate these up however we want, and then we can create them all in a single output. That, for them, is just huge. It’s enormous like for example, the stuff happening in El Salvador—a lot of those channels are hosted channels, which means somebody else has it. And part of the reason for that is it’s difficult to open up a lot of channels for a lot of people who have shitty cell service, and that’s something where, Oh, if you can non-interactively—and people get pedantic about what non-interactive means. You still have to communicate. It means that every part of the thing is decoupled and does not have any sort of DoS-ability. Everything’s asynchronous and aggregatable by a third party. That’s what I mean when I say non-interactive. So for these service providers who want to get people having self-sovereign channels, it means that it solves one of these very, very core backbone problems of like, How are we going to get millions of users on board? Do we have to be worrying about what fee rates are on an ongoing basis? It basically just eliminates all those issues. So for congestion control, people who are actually reaching users at scale right now get very excited about it. People who aren’t don’t necessarily get it as much, because it’s just one of these—it’s very nuanced and niche-seeming, and the importance of it is kind of limited. Just to close on that, the main thing that I think makes it clear for anyone is like, Well, what happens if you want to do a transaction paying out a hundred million people, which you might want to do if you’re the United States and you’re going to say, Okay, we started a Bitcoin wealth fund and we’re going to open Lightning Channels once a year to every citizen. How many blocks would you have to fill synchronously to do that? It would be too many. This would let you actually just create those channels without having to worry about the underlying block space. So when you blow up the scale of the problem, you can see that block space becomes a limiter for anything. But if you’re just thinking in terms of like, Well, blocks are still going to be pretty empty, then you don’t see the problem as much. At least in today’s condition.

Stephan Livera:

Yeah. That’s very interesting. And I think that reminds me as well of Rusty’s talk at the Lightning Conference in I believe it was October, 2019. He was saying, In the early days of Bitcoin, people were saying, Oh, look, it’ll be low fee forever. And then now Lightning, okay. But Rusty’s point was that, Look, Lightning may not remain low fee forever as well, because again, the same thing of, What’s the cost of opening and closing channels? What’s the cost of providing all the things that a Lightning routing node operator is doing? So I think in the same way, maybe we’re living in the golden age now where the mempool is easily accessible, and we don’t need advanced techniques. But I guess that’s the argument for CTV or at least to consider it, is that we could start optimizing our use of block space even further with these kinds of techniques, and these kinds of engineering ways of getting more for less, basically. So I think that’s probably a good spot to finish up there. So Jeremy, if you could just give everyone a summary of why should they think about learning more about CTV? I mean, personally I’m not necessarily saying, Yeah, rah-rah, let’s all do CTV. I’m kind of neutral myself, but I find it interesting. And so I guess from your point of view, why should people think about CTV and where should they go to learn more and follow you online?

Jeremy Rubin:

Yeah. So I’m @jeremyrubin on Twitter, you can find me there. There’s a ton of material on utxos.org. And my Advent Calendar, which is fun to read is rubin.io/advent21. So those are great resources to get started. In terms of the case for, Why care, why get excited? I would say there’s two things I would want to leave people with. One is that an ounce of prevention is worth a pound of cure. We know how to do something today. We know how it could be used in the future if we ran into some of these problems in a larger sense. And if we don’t deploy something now—and this isn’t just congestion control. We didn’t really talk about privacy—CTV also has really good privacy benefits, and privacy is something that’s path-dependent. We can’t ever get it back for things we did historically with Bitcoin. It really makes sense to just get something that is available so that when we go to need the tool in a year, two years, three years from now, it’s not, Okay, we now have a problem. Now let’s spend another block size wars debating it out. That to me sounds like a lot of stress. It’s much better to do things that we know to be safe and have a possibility of solving some of the obstacles that we have down the road. To me that seems like good planning, and is worth considering even if these things don’t feel urgent to you today. The other side to it is that everybody thinks that—well, some people have said maybe they don’t—but most people want more people to use Bitcoin. Like there’s some people who are like, Oh no, I don’t want more people. Because my fees are going to go up. But it’s like, Okay, I want Bitcoin be useful. I want more people to use it. And for some of these things like non-interavtive channels and congestion control—combining those concepts—that legitimately is something that has the potential to bring a lot more users to Bitcoin. So if you want Bitcoin to be more useful—this gets into the Jevons paradox—it’s like the more efficient something is to use, the more people who end up using it. And maybe it ends up looking less efficient. Maybe the fees do end up going up because now instead of having—I don’t know how many channels there are—but maybe now we have billions of channels operating and things do get more expensive, but we’re actually serving billions of people rather than a couple million. And so that’s something that I think is also a powerful argument for, Why CTV, why now? And then the maximally selfish thing—if you’re just a pleb and you’re like, Whatever, I don’t care about all these businesses or operators—what’s it going to do for me? The main thing is like, Hey, vaults are really cool. Everybody is concerned about how they’re safeguarding their stack. Vaults and inheritance things are things that can give you a lot more self-sovereign control over what happens with your Bitcoin. And can basically help you get a better night’s sleep. That’s a pretty compelling argument for me, personally. But that’s I think what I would leave folks with, if you want to get excited for it.

Stephan Livera:

Fantastic. Well, listeners, I’ll include the links in the show notes. And Jeremy, thank you for joining me.

Jeremy Rubin:

Thanks for having me.