Note: Per socratic village rules, names of all attendees (other than the advertised speakers') have beem anonymized and audio will not be published to preserve anonimity of the question askers.
Shaun Apps 0:00
I'll kick things off a bit introduction, both Andrew and Jeremy will present. And then we will go through some questions and we'll go to questions from from the audience after that. So that's kind of the the format for this.
So, covenants, this term has both historical context when it comes to religion and law. Many of us might be familiar with covenants within the bounds of property law constraining or bounding the use of land for example, by covenant, but how many people here have heard of covenants as it relates to Bitcoin? Okay, good amount of people. So at a high level, a higher level, covenants provide the Bitcoin script introspection, such that you can constrain how a output will be spent by some predefined bounds. I'm not really sure how far back exactly covenants go into bitcoin talk more. But there is this seminal Bitcoin talk post by Greg Maxwell. Kind of introducing the concept of covenants, and providing a few amusing examples. For example, a smash point covenant where spending the coin that covenant has to provide proof of an attack on an alternative cryptocurrency or even something like adult coin covenant, where the data provided would be someone's date of birth, and it would constrain that recipient of that to be older than 18. So, of course, these are just kind of amusing and silly and fun examples of the of the covenants concept, and this is just kind of a post in jest. However, there are some very exciting use cases for covenants, which we will get into today. So we have Andrew Poelstra, and Jeremy Rubin, Andrews going to be approaching covenants from the perspective of check sig from stack also known as CSFs. And Jeremy will be presenting on check template verify, referred to by CTV. So with covenants, there's no one singular way of doing them in Bitcoin. There's there's different ideas, different proposals, they each have their own trade off and use cases. So we will get into that. Andrew, do you want to go ahead and get started?
Andrew Poelstra 2:53
So as Shaun says, I'm kind of representing the check sig from Stack School of covenants. I seem to represent a more general viewpoint. So to build on this idea of covenants, which by the way, I think does originate with Bitcoin talks thread... I'm not aware of any older discussion...
Jeremy Rubin 3:20
earliest I know!
Andrew Poelstra 3:24
There are kind of two different categories of covenants that I'm going to call the crypto covenants and non recursive covenants. And I think that's probably also the terminology that was used in this post. So what a recursive first, what a covenant is, is just a way to constrain where the coins are gone, right. So normally, a script can using Bitcoin script, you can determine under what conditions can a coin move, but once those conditions are met, they can go wherever. And a covenant lets you constrain that further and do all sorts of silly stuff like this. And there's a distinction to be made between non recursive covenants and recursive ones, where non recursive covenants, let you constrain where the coins are going. And then you can maybe constrain it to be in another covenant, which further constraints and so on. But you've got to kind of like map out the entire future of these coins, you only go so many hops to get to, but you've got to write out all of your constraints all on the first shot. Whereas recursive covenants are ones where you can constrain the coins basically, to go back into a covenant of essentially the same shape of where they came from. And thereby creating sort of finite state machines that the coins can move between like either they just stay in one place and then like some constants change or they can go to like different states or they can come back around and you can create covenants the coins don't escape from in this way. And this even the way that I worded that right and at that point, don't escape from these is kind of reflects the the danger inherent in this and reflects the fear that people have had over the years about enabling recruiting. covenants. And so there are there have been a number of covenant proposals over the years. One of which is Jeremy's op CTV, which was previously op secure the bag, I think I've had a few names over his lifetime and it's gone through a few iterations... op CTV is designed deliberately to avoid recursive covenants to avoid this, the entire like specter of these these horrible jokey but in some ways, not joking things. Whereas the other kind of well known covenant proposal was out there is a very general one based on these two new opcodes to their clinical check sig from stack and CAT. And there's there's a more efficient variant of this where you basically add opcodes to the you directly at all, because they can look at the transaction, the spending the coins, and then you can pull that onto your stack and your script execution and then constrain them directly. So you're sort of directly looking at the transaction that you're spending, putting arbitrary constraints on those. And in particular, if you put constraints on the outputs of the transaction, that spending your coin, that's how you get these recursive covenants that just kind of permanently encumber the coins.
there's kind of a trade off, there's kind of a trade off between these these two approaches, where if you are trying to do something that avoids recursive covenants first and we talked about avoiding or critical in the past, because it is frightening history of covenants in Bitcoin, it's surprising that there aren't covenants in Bitcoin, actually. Because it turns out that just the nature of script is that it does have to look at the transaction, right? So Bitcoin script has this check sig opcode, which lets you check a signature on the check a signature on the transaction. And the signature data, of course has to be accessible to the script. So the checks opcode can access it. But mathematically, the way a digital signature works, that is inherently tied to the transaction data itself. And so some clever mathematical tricks, you can kind of like force a signature to go backwards and then get a hash of the transaction onto your stack, and then then start reasoning about it. And in fact, it is possible using Bitcoin's, check SIG operators, to say, this coin can only move if you provide a signature, that's just all zeros. That's a valid signature. There's some metadata in there, but effectively all zeros as a couple of ones and twos at that specific places. And you don't contain the public. So normally, you say like, I need a signature on that transaction with the public key here, you say, I need a signature with some public key on this transaction, which has this exact form. And so you do that. And in order to satisfy the transaction, you're forced to provide a hotkey for what's the signature or validate, and that pub key turns out will algebraically be a sort of weird mixed up hash of the transaction. And you could, therefore constraining what that hash has to be in your scripts, and thereby get covenants. And the reason this doesn't work is that all the different sig hashes in Bitcoin, except for one, actually cover the public key that has been signed. So there's a circularity if you try to do this. But if we had like sighash anyprevout like, which is a popular proposal for Bitcoin, then you would get this form of covenant. And the point of the story is not to propose that as a serious covenant thing, the point is to demonstrate that, like, it's very hard to avoid having recursive covenants. So my position to the extent that this I mean, this is not a debate, but my position here is basically, we ought to have a very general kind of deliberately designed method of doing recursive covenants versus either trying to do something narrow, which may be, which first off is maybe like, you don't get as much flexibility. If you do the narrow covenant proposal, the still have to go through all the consensus changes and stuff, you get less of the benefit, but also because like, probably you actually do get recursive covenants. I bet you do, it's very hard to avoid it. I guess. That's me.
Jeremy Rubin 9:17
Yeah. So I think most of that I would concur with up until maybe the conclusion. Drama makes perfect TV of course, but there's really not that much drama I think Andrew and I maybe aren't completely dead center in the Bitcoin community on this, but we both think covenants are a good thing for Bitcoin, where my perspective has diverged and what led to check template verify which I'll explain in a second what exactly that's doing was really more from pragmatism in an engineering perspective, which is getting this perfect primitive that gives us safe and expressive recursive covenants is pretty difficult. There are [also] people in the community who are opposed to that kind of thing. And so what I tried to do in coming up with check template verify was find that narrow, narrow band of protocol design, that would be acceptable to even the most anti covenant person. And that is kind of what check template verify is targeted at is like, what's the most limited thing that can actually solve some really interesting problems. And I think this is sometimes people get confused about it, it's not because I think the only thing we should ever do is this limited form. But it's because I want something that is a part of Bitcoin's gradual process of creating upgrades for Bitcoin. And rather than change the whole world all at once, maybe what we can do is we can get a simple primitive that introduces the ability to do lots of interesting things, we can grow around the tooling and infrastructure around building covenants based on that. And over time, as we learn more about what types of things people are trying to accomplish with covenants, we're gonna be able to make something that is really sufficiently generic and usable for a wide variety of other use cases without introducing vulnerabilities, or having to ingest a whole bunch of engineering work all at once to design the covenants framework for developer infrastructure and tooling, and user interfaces, things like that.
So for check template verify, in particular, it's actually really close to what Andrew described as, "this complicated thing that you can do with the keys", it's actually simpler, all it is, is you pick the exact transaction that you want, at the time that you're spending to someone. So if, if I, for example, said that I am going to spend to this address, and I want this address to send coins to 100 of my friends, that is an example of something that you could do a check template verify. And what you're committing to in that address is the exact transaction that it's going to expand into later. Why might you want to do something like the one that I just told you, this is sort of one of the primal use cases for check template verify is congestion control. And the reason why I sort of in my engineering process, the way that I think about these things is, I want to pick a specific single use case that I want check template, verify to absolutely nail and give a solid story for why you would want to use this, maybe a small set, and then design something that is going to satisfy that need, and then go back and see if there are other things that we can do. But I want to know that check template, verify as a solution has good product market fit for this final user story. And so this example that I gave of where I split the transaction from a spending side to expanding side is really good. For example, if the mempool is really expensive, if you want to get a confirmation, you can get your transaction confirmed with just a single output by all your 100 friends can fully verify that they will with the expansion of that covenant receive their payment in the future. So that can be really good. For example, for an exchange, that idea can also get expanded into much more sophisticated forms by leveraging some other things check template verify can also do to create like lightning channels without interaction. And I think that that generally, as you start going to the depths of like what you can do with this very simple covenant. There's even a kind of compiler that I wrote for to do, its does check template verify based smart contracts. And that can be used to make all sorts of really wonderful covenant based things. And the compiler itself is generic to future types of covenants that might be defined. So if somebody comes along and says, Well, I've invented a new form of covenant, we have a chance to basically develop tooling that can be used in the future when we have expanded types of covenants. So that's sort of the perspective that I have is like from where we are now, I don't know how long it would take for us to get this grand vision of like sufficiently general covenants, Andrew might claim like, well, you just need checks sig from stack, but those covenants actually like are really, really large in size of the expansion of the long chain is really expensive. The technical verify ends up being because of its simplicity. And this ahead of time compiling notion that we have to know where you want to send it, it ends up having a really low chain footprint. And so it's very difficult for even mildly more sophisticated covenants to beat a check template verify based covenant in terms of on chain efficiency. So it's kind of a little bit like, somebody asked for a bridge. And there's a river that we want to cross to have covenants and what I did with technical verifies, like I cut down a tree and I just plopped it over the river so you can walk across this. And my feeling is like a lot of developers are like well no, we want to like carve a ornate bridge and it's gonna take time and I'm like, well, here's something that we can get across the river today with and maybe we can then use that to build [the more beautiful bridge] more efficiently, for the future we can build from both sides at the same time or whatever.
J 14:57
I just very quickly no recording please or videos. We should have had signs posted, but you can transcribe, but no photos or videos, please.
Shaun Apps 15:05
Just a reminder, as we ask questions, the audience is free to respond to those questions as well. Could you guys talk more about what's like the specific parts of a transaction that like, have these foot guns when you're when you're designing and covenants like what are the parts that have like the most careful consideration where things could potentially go wrong?
Jeremy Rubin 15:27
Well, I think basically all of it, if you mess up any detail of a transaction, you're kind of screwed. So one of the things that's kind of forgotten in check template verify, for example, is if you send the wrong amount of money to a covenant, this is also a problem for any covenant, if you make a covenant that expects to have available to one Bitcoin, and you send one bitcoin minus one Satoshi, that whole covenant might not be able to execute in the way that you expected. So that is one area that is a massive issue for anybody working on covenants. Another big problem is, and I have a, somewhat of a solution for it, but it's not that popular yet. And the community is paying fees. If you have a covenant, you've restricted the coin to only be spent in very specific ways. How are you going to assess the fees. And then if you have to pay more fees than you expected, then maybe you're going to drain the amount of money the covenant expects too far, and then it's not going to execute correctly. So paying fees is also an area where it's really tricky. My general proposal for solving that, which is maybe a little bit out of scope of this is that we should build a way that fee paying can can just be completely separate from transaction flows of execution, where you're covenant and whatever other smart contract code, maybe a lightning channel just executes as like the transaction graph you want and fee paying happens as like an external consideration to that.
Andrew Poelstra 16:48
Regarding specifically the fee issue, I don't think we should get him higher than in the details of that. But I think there's maybe a way using child pays for parents that would be less dramatically different from how transactions are structured. But definitely original question about was the most dangerous part of the transaction. I think what what your some parts are less dangerous, right? I think the outputs you're constraining with your covenant. That's a dangerous part. Because you can either this, Jeremy suggested you could constrain your output to be something that's impossible, right? Like it has to have a certain value that you just cannot get, when your transaction is structured the way that the covenant requires it to be. You could also make it impossible to spend in ways where your output to be then spent, would require you construct a script that violates some limit that it will be too big. Or would otherwise step outside of the balance of scripting, maybe you have to add two numbers, but they wind up being larger than 32 bits or, or something like that, under some weird state that your covenant can get you into, you can just find, surprisingly, that your coins are unspendable. But that even if you can see it coming, that covenant is kind of forcing you to, to drive that way. The outputs the most dangerous, versus there's some other parts of the transaction that you could restrict was covenants, you could say like the lock time has to be a certain minimum height. And even if you screw that up, well, then you have to wait until the minimum height has been achieved. I mean, I guess if you screw it up such that it's like years or decades in the future, that's, not much consolation, but at least in principle recoverable. Or if you require the transaction version number be something weird and non standard well, so those will still be accepted by the blockchain, you're then going to have to go to a miner directly because transactions at that version number won't propagate. But it will confirm. So it's stuff like that with a lot of... same with sequence numbers for your inputs, they may constrain your place by fee behavior, or whatever. But it's really the outputs, right. And that's when we talk about covenants, we really are talking about constraining outputs, even though in my mind is a more general constraint in the shape of the transaction. Ultimately, to get cool applications and also dangerous applications, you have to constrain the outputs.
Jeremy Rubin 19:10
I'll just add that that the my interpretation that outputs also includes inputs to the transaction, there are some really surprising results that you can get where if you have a transaction that has two inputs, you can have both of them constraining at the same outputs get created. And so you could have two inputs, and they're both saying create an output with one Bitcoin and they're both satisfied by the same output. And then you lose half the value in two different covenants. So there can be some sort of surprising interactions between how covenants can work and that's why at least for the time being my path, with check template verify is like lock it down as much as possible. So we can build things that we know kind of work and then the more surprising, harder to get right things we can get all the sophistication right on that over time.
Shaun Apps 19:53
Jeremy mentioned one of the use cases for congestion control, because you guys talk about your these proposed With regards to how covenants would affect layer two solutions, like the Lightning Network, what? What's to be gained from these proposals? How can it kind of like improve things? And what can it do
Jeremy Rubin 20:18
Yeah, so layer two with covenants is like, amazing, right? Right now Layer Two?... Whatever... layer two covenants?.. Awesome. There are a lot of problems in building layer twos. And don't get me wrong, I think layer twos are a good solution for a wide number of problems. And that spans lightning, side chains, whatever. The way that I like to think of it is Bitcoin and like the blockchain is executing as like your CPU, and layer two is executing inside your operating system. And this has given you new capabilities at the base layer, and your operating system can really take advantage of these new instructions in ways that are really great. So one example that I like in the Lightning Network is creating channels, it's kind of hard because you have to have both people online. So if you want to get a channel, out of Coinbase, what you'd have to do is you'd have to like withdraw your funds from Coinbase first, and then you'd have to make a channel with somebody, what if you could just say, Coinbase, please make a channel for me, and then go offline, and Coinbase, sends you a channel later. And there's no trust assumption with Coinbase, that would actually be like pretty impactful for getting more liquidity on board. That's one area that congestion control is also really relevant for layer twos, where let's say you wanted to create 10,000 channels all at once... Well, right now, you have to consume a lot of block space to do that with check template verify, or other covenants, you can defer that chain load. And you can do it lazily. Whenever you need to close the channels, if you're opening a channel, and you don't expect to close it, that could be like a year later that you're actually closing it. So that could be really impactful for onboarding more. And then also for exiting. In the case of certain side chains, you might have to like pay out a large number of users, I think Stacks had something where in their consensus protocol, they expected to pay a certain number of users and they couldn't get their transaction confirmed. And it was they have kind of a consensus fault. As a result, with check template verify your layer two side chain can be agnostic to the under underlying mempool weather. And you can just always pay very high fee for your single output transaction, and lazily let people get their things out. It also helps a lot with -- going faster but we can dive into any of these -- but with custodial issues, and that's for layer twos or for individuals. Blockstream, which is a fabulous company had a bug a while back in their liquid Federation, where you deposited funds into their liquid custodial service. And the funds were supposed to move every couple of weeks in order to keep the time locks fresh. And if you had covenants, you would eliminate that need to move the funds. And now because they have this constraint, there was a service that was supposed to be running in liquid that made sure that the coins were moving frequently enough that the time locks guaranteed that this failover condition wasn't happening. And that service wasn't running correctly, Andrew can probably explain it... but that maybe out of scope for this [session]. And that guarantee was violated covenants would fix things like that we've expressed a little bit more logic about actions that have to happen constructively rather than automatically guaranteeing the flow of things. And also those types of deposits. You could have actions where the funds automatically maybe even returned to the depositor instead of just failing over to a different signer. So there's a lot of really exciting things that covenants would brings to layer twos, but I think we should all be excited about it.
Andrew Poelstra 23:49
Yeah, that's a really good answer. And just specifically about that, but the issue was, the coins have to move every two weeks and the timer was set at two weeks, which is not correct. You can't react instantly on the Bitcoin network, right? You can't create transactions and expect them to be confirmed within the next block, or they would have to be but you'd have to like spawn a new block at the time Once the timer came up, so we've just changed the logic to sweep the coins a bit earlier than that I think we do like 300 blocks early or something. But this is a really good illustration of where covenants would help right because it's kind of like ad hoc, A is is annoying and expensive have to sweep all these coins all the time. But B, when you're dealing with signature than time locks and trying to hoping that miners will accept your stuff in a timely manner. That's also a very frustrating because it leads to... you can't guarantee that it's going to work and this leads to kind of embarrassing bugs like this, that that I noticed by by people on telegram and so to build on on the first half of what Jeremy was saying where you could in principle have coins that are just like sitting there waiting for coinbase to kinda like do their part of opening up a payment channel. You can you can generalize that right. In a lot of cases, you don't care that it's Coinbase, you can say like, anyone who has enough channel capacity and who was able to connect to where I'm actually trying to send coins to, anybody can just come pick us up and open a payment channel. And you can offload a lot of the normally online interactive stuff that you'd be doing with like peers, you have authenticated connections to, you can sort of formalize what your requirements those periods are, drop some code on the blockchain, and then just like wait for somebody to pick it up, basically. Yeah, so I'm glad that you had such a cool answer. I think of covenants as actually not so much about layer two, I think about vaults and custody and stuff. But that's such a really cool set of applications that I don't usually think about.
Shaun Apps 25:51
Wanna field some questions from from the audience,
J 25:53
does anybody want to speak to like layer two and covenants remember you guys can answer questions, ask them anything you want. It's interactive.
Question Asker 26:02
I'd love to hear more about what you're thoughts are about the vault applications...
Andrew Poelstra 26:08
sure. I have knowledge and made people somebody asked about vaults. And what do I think about vaults basically? What do I think? I think the vaults are necessary for major Bitcoin adoption, quite bluntly. So what vaults are is they're a covenant construction, where you can constraints coins, such as they cannot be directly moved to any particular destination, where they're kind of sitting in this covenant script. And if you want to move them somewhere, then you have to create a new transaction, which defines the destination, move the coins to a staging area, and then after like three days or something, the covenant logic will then allow the coins to be moved to that destination. And during this three day kind of waiting period, anybody with the appropriate key can basically reset the timer or reset, or they can change the destination if they want. And in doing so they reset the timer. So the idea here is that if your keys like somehow get out of your control, somebody steals your keys or something, they can't run off with your bitcoins, they can try and then move the coins to this three day timer. And then you can keep resetting the timer on them. And then the two of us have like a fee war. And if if your attackers goal is to just like deny you access to your coins, they can do that as long as they're willing to stay online and continually spend money to sustain this attack, but they can't get the coins and run off of them, which which, by itself should discourage the kind of the kind of expensive attacks that would be required to extract key material in one. And related to vaults are, even if you have control of your own keys, you may want to limit how quickly the funds can move. Because maybe these keys are like shared with maybe maybe they're just constrained by external legal thing, maybe the company coins and your your charter doesn't allow you to spend too many of them at once. Or maybe you have some cold keys that you have in, in deep storage without some hot keys, muggers might take and you want those hotkeys to only be able to move coins so frequently and stuff and you can use the same bolt construction basically, to say that the coins can only move after a certain amount of time and in a certain quantity. And my feeling is that Bitcoin not supporting this, or more generally, in Bitcoin, if you authorize the coins to move, that any amount of them can move to any destination, right? So it's just like really binary is this like, either the coins don't move at all, or it's a free for all. And that really scares me as an individual trying to custody Bitcoin than if I were like, like, like State Street or somebody trying to custody a tremendous amount of coins, then that would really frighten me. So I think this is like a necessary, I think it's necessary for Bitcoin to gain serious adoption, really. And I hopefully we get there.
Jeremy Rubin 29:00
Yeah, I would just add on to that. I like vaults.. check template verify can do a slightly different variant of them, but also meaningful. One of the properties that I think is most relevant is for the type of all that I'm doing. It has a failover where it's basically a lukewarm wallet, where you have your hot wallet, which you can just spend however you want discretionarily you have your cold wallet, which is like really difficult to access, like you went to three different deserts and like burried, your metal plates with your seed, and you got to get two of them to like recover, it can take it's buried under concrete, and it's got like radiation or something, whatever. We're talking about that the other day... So you have this really difficult thing and imagine you're like, Okay, I'm gonna withdraw and I'm gonna put my funds onto that two or three, you're never going to get those coins, right. That's like an emergency procedure. And you can model your backup procedure. As you're like leaking entropy every time you access it every time you Do you do your little procedure and somebody can be watching and being like, oh, like now I know where Andrew keeps his thing. Also, the other side of that, the more difficult it is to do, the less regularly you want to do it. And so your desert might become three different drawers in your desk... it might get degraded to that level, but you might be willing to pay a one time cost for the setup. You might casually, whenever I'm visiting a new city take a GPS and bury something somewhere and just have a key stash randomly. And what you can do with this lukewarm wallet concept is you can set it up such that your funds have an annuity where let's say you have 10 Bitcoin on it, once a month, you have the option to withdraw one bitcoin out of this contract for the last time you withdrew. So you've got this stream of liquidity that you can get out of your, of your vault. But if you ever get hacked, you have the ability to emergencies subvert it back to that deep cold storage. And so what this is doing is it's separating the concern of your backup from "I want my funds to be safe and secure", "spendable", and also, "I want to be able to recover them in emergency". And by separating those out nicely. I think that that can really help a large amount of users adopt higher security cold storage backups.
Shaun Apps 31:21
Part of the discussion around covenants I see is the reintroduction of an opcode. That was disabled license by Satoshi in late 2010, referred to as OP_CAT. Did you guys talk about how that would affect these covenant proposals? What are the things that are gained from that? Like how does that kind of play into these covenants
Andrew Poelstra 31:44
op cat is my favorite opcode... what op cat does, cat is short for concatenate. And what op_cat lets you do basically is you have two two objects on the on the stack in your script, interpreter environment, and you just stick them together. Now you have one element that is the first thing after the other. And in the context of Bitcoin were kind of like execution is verification, you can also run this backwards, right? You can if you have some big object, you can split it into two, by by asking the user spending time to provide the two pieces and you kept them together and check equality basically, you can always, always invert every operation this way. And with cat by itself, you can break apart signatures. So algebraically a ECDSA signature or snore signature it there's two different pieces, it's kind of a numeric part that we often call S and a part that's kind of like a public key that we call R. And without op cat, if you're trying to do like, funny covenant checks, like sneak covenants into the protocol, by by finding algebraic backdoors, then it's difficult, it's difficult to constrain your signature if you can't break the signature part unconstrained S independently of R because they're, they're structurally just very different things and R is much harder to constraint. So in taproot where we have Schnorr signatures, using op cat, and the Schnorr signature verification opcode, it turns out that it is possible to get a form of non recursive covenant where you literally get a transaction hash, not even like a funny mangled transaction hash, but it a literal SHA2 hash of all the transaction data onto the stack. And the way -- I don't want to get too algebraic, but this is this is pretty cool so i will -- the way the signature signing equation works is that you have the S value equals k plus your hash times x, where k is a sort of ephemeral secret key, and x is the real secret key. So using covenants and CAT, you can restrict k to be equal to one, and x to be equal to one. So now that equation reduces just s equals equals one. And so what you can do, and you can't really do arithmetic on big numbers in Bitcoin, but with CAT, you can by breaking big numbers into small ones. So what you do is you take a signature, you've constrained it, so that your S value has to equal the hash of your transaction plus one, you can use CAT to pull the lowest order couple bytes off of that S value, and then you subtract one from it using ordinary opcodes and then use cat to put it back. And now you have a SHA2 of all the transaction data. And now you then request of the user put the explicit transaction data onto the stack, you use the SHA two opcode to compress that and check equality between the one that you stole from the signature and the one of the users created with explicit data. Now you use OP_CAT to pull apart that blob that you just hashed into the constituent transaction parts, and now you can constrain them. So now you have covenants and all you need is cat.
Jeremy Rubin 34:58
If it makes anyone feel any better, I like half-followed that you have to read the blog post to really work through it. The way that I described CAT is that it's kind of like the scrawny 80 pound kid who gets picked first for basketball because he or she can sink three pointers like every time you're like... where does that athletic talent come from? Cat also makes Bitcoin weirdly quantum secure, you can get Lamport signatures in.. Did you know that one?
Andrew Poelstra 35:21
I forgot that one...
Jeremy Rubin 35:23
. So there's, there's like all these like random things, if you have CAT, if you can also get like a check sig from Stack variant with that. And there's just like, a myriad of things. And I think that that's also a good example of where Andrew saying earlier, probably we're going to accept to like get recursive covenants at some point, because cat is this so low power thing that introduces, crazy amounts of complexity to Bitcoin. The power comes from the most surprising places.
Question Asker 35:51
How do you split with CAT?
Jeremy Rubin 35:53
Split? you turn it into a verify opcode that verifies that the concatenation of two things you pass into the witness, are the split of that thing.
Question Asker 36:03
That's gonna be huge signature data?
Jeremy Rubin 36:05
Well, yeah, it's more about the theoretical possibility. And then it's sort of some code golf to get it down in size.
Question Asker 36:23
Why did Satoshi disable CAT?
Andrew Poelstra 36:27
So in the original implementation of cat had a memory blow up issue where it didn't constrain the size of its output. So you could push like the zero byte or something, and then use OP DUPs to duplicate it, and cat put them together and use to dup Cat dup cat dup cat dup... [Andrew motions hands expanding] right, and then very quickly, my hands will be in on other planets. So that that was why it was disabled. If you were only op cat that were broken... and only in this way, I think probably could have just like, fixed it properly. So they go, it would just be a soft fork right to say that go from now on, you're not allowed to count things that are too big. It was part of a larger project to audit all the opcodes. And there was like a dozen of them disabled that all had individually small issues, that reflected a need to step back and reassess. So Satoshi decided to just unilaterally disable them all. And at the time, I think no one was really thinking about the difference between the soft-fork and the hard-fork, the difficulty of adding things versus removing them. Also the language around it was like we could read, they're disabled, we could re enable them in the future. But I mean, really, they were just removed. Right? Now they just had names in the codebase. That that was the reason for CAT, the memory blowup.
Question Asker 37:44
I could ask, maybe very novice question. Can you help me visualize where the code for calculating the program lives?
Jeremy Rubin 38:01
It depends on covenant proposal. For a generalized one, the covenant code would live inside of the script, basically. And then you would also have some logic about for the creator of the Script had for how to create satisfactions of that, how to produce witnesses and transactions that meet those requirements. And that code might be more complicated than the verification code that's inside the script itself. For check template verify, In particular, it's the extreme version of that, where all you know is transaction hashes. And you haven't have all of your logic for how to treat those and when to broadcast them and other things you might do as a separate representation that you're maintaining yourself.
Question Answerer 38:51
Very simply in the same place where you'd to see a multisig script, there'll be an equivalent sort of script that has various constraints on it, which are more advanced
Question Asker 39:03
But how would a new transaction be triggered?
Jeremy Rubin 39:07
All of the logic for like driving it forward has to be like, user generated, it doesn't happen just like like they're not self executing. Somebody would have like, they quickly if like, somebody submitted a transaction, but there's no code in Bitcoin for saying, by consensus, this transaction has to emit another transaction at this time.
Unknown Speaker 39:29
The recursive covenants, I guess that's a little more complicated. The Questions would be, that same script transfers along with...?
Andrew Poelstra 39:44
Yep, exactly. The user have to take action to move the coins, but the only action they're allowed to take is a movement of the coins to a copy another copy of the original script, basically. Yep. So the covenant display for the covenant will constrain your actions but The user, or somebody, has to take a positive action.
Question Asker 40:05
Could there be multiple scripts that satisfy the same covenant?
Andrew Poelstra 40:11
So that it could there could be the short answer is yes, yeah. So you could define a covenant covenants don't have to be constrained. So from narrowly, you can say, as a coin, they're allowed to move to like any number of specific scripts, you can say the coins have to move to like any script, as long as a start to some specific condition. But then after that, it can be a free for all. You have a lot of I mean, again, depending on the exact covenant construction, but in principle, you have complete computational freedom here.
Question Asker 40:42
Bring it up to the application layer, a little bit... I know the research going into the idea of coin pools. Or say, I have coins, I dumped them into what would be a trustless escrow along with a hundred other people that utxo progresses block by block as people spend funds. Maybe then also, there's somebody who's like running this submarine swap server and can get funds up on the Lightning Network. They're just like, the architecture green wallet uses Right now without covenants. I think like one of the downsides of that is the transaction graphs can kinda explode? I'm just curious for your thoughts on how that's going etc.
Jeremy Rubin 41:33
Yeah, so they're possible. There's also some other covenant opcodes that have been introduced kind of recently ones called TLUV (TapleafUpdateVerify). I think coinpools are a really good opportunity, they kind of necessitate some sort of reputation layer, which I think lightning also has some of this concern as well, where you don't really want to be in a coin pool of people whose phones are always off, right? So you need to know that whenever you ask for a transaction and the transaction satisfies your higher order business logic of like, "well, this person is requesting to send money, that's one of their balances", you just by default sign it, you do want that liveness guarantee for the participants. But those actually would keep the transaction graph small, because people would share utxos... The different proposals for it just have different trade offs. And I think, I think people should largely ignore transactions and only think in bytes. Because sometimes you'll you're like, Oh, well, like this way of doing it has fewer transactions, which I think is what people feel like TLUV, they're like, this only has exactly N transactions, whereas CTV would have, like 1.2 N. And it's worse! But it's like, well... if you count the bytes, CTV is like six times smaller. So for some of these things it can just be surprising when you do the the transaction counting v.s. byte counting smaller transactions versus larger, fewer ones.
Question Asker 42:57
Without liveness applied to everyone on the coin pool be possible to have a quorum where some folks have to be live?
Jeremy Rubin 43:09
Yeah, whatever guarantees you want. So you could imagine that you have a pool where everybody has a buddy, and you say, I trust that my buddy or someone else is going to be honest. And then you could do like a half threshold on it [note: e.g. AND(OR(Key(A),Key(B)), OR(Key(C),Key(D)), OR(Key(E), Key(F))), any group of N/2 buddies]. And then that would let you do some more kind of sophisticated stuff, they wouldn't be able, they'll be able to like steal your funds, though. In the CTV. world, the way that I think about it is that as soon as you have a fault, you want to split your pool in half. So if your pool has a liveness fault, you split it, and then if there's one person who's offline, then half the pool is back online, and then the other half has to split again. And then you can do the math, with two transactions, now we've got 75% of the pool back online. And then with another one, you get people back online pretty quickly. And then that unfortunate person who was in the tree very close to the offline person has to do O(log(N)) transactions to exit, which is still not that bad. O(log(N)) is pretty small.
Question Asker 44:11
For context, the reason why I ask. As we're seeing Lightning Network grow, a lot of the scaling that we're seeing is multiple users to one node, but where multiple users don't have keys on chain, right? Multiple users of one channel it's not ideal and nobody's really happy with it. But it the really interesting thing greenwallet does is they have multiple users that have keysvon chain and it's still one node or the node is doing is just doing submarine swaps from off chain or on chain. Scaling that model and making it to where they can do many users and it's not a requirement [unitelligible] for being distributed among the pool in this example is Very interesting idea.
Jeremy Rubin 45:03
Yeah! The other thing I wanted to add to thinking about this in terms of lightning, it's a benefit of like CTV over like the TLUV style without adding anyprevout into the mix a CTV based coinpool will be compatible having nested channels and so all of these things you can only have to you'd only have to do an update when you have to like rebalance liquidity or make an external payment. Otherwise, you can just be doing everything in your leaf nodes as lightning payments and I think that that's like a pretty powerful composition of primitives where you can create a channel with a bunch of people and then only have to update it occasionally
Shaun Apps 45:40
Time for one more question.
Question Asker 45:43
Question for Andrew: Do you see the downside of CTV just being basically brings to bear the review process of something that's too limited or you actually see some more problematic failure modes?
Andrew Poelstra 46:00
No, it is basically just that it's essentially just that it's too limited in my view, was it was a slightly related point that if we if we find in the future that there is a cool application for more general covenants, because we have like 90% of the functionality already in CTV, it would be a harder sell, then to come back and do it again for an extension. And then also in some cases, there's a possibility that like CTV could somehow be incompatible with with something that otherwise would be a future proposal or there could be efficiency or some sort of interaction there that will be complicated to reason about... but yeah, essentially it is just like... if we're going to get into stuff in the Bitcoin, I would prefer to get the most general things that we could. I suspect that our disagreement is really what is the most general thing that we could, right? I think Jeremy has expressed skepticism that that we could actually get all my stuff into bitcoin even proposed it properly.
Jeremy Rubin 47:02
Yeah, just from the community's perspective, there have been people who like Shinobi who stated publicly that he will not accept anything more complicated than CTV. I don't agree with that as like a like a position that I think is, good, but he has his reasoning and the community is a Harsh Mistress so I don't know if we can actually get everybody on board with something, but I like to try and even for CTV it's hard to get people to "get activated"... So if you do want to be...
Audience 47:35
Groans and laughs about "get activated".
Jeremy Rubin 47:38
So there's utxos.org/signals for people who have reviewed it sufficiently and feel like they could get behind getting the community towards a merge and release and then activation. That's going okay, but it's it's not a snap of a finger, it's like a multi year effort to get everybody feeling like they've reviewed it enough and it is getting enough of a use case they care about over the line.
Shaun Apps 48:03
We'll go ahead and wrap up thank you guys both for for doing this!