{ "episodeId": "SLP541", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "stephan_livera": { "name": "Stephan Livera", "role": "guest", "tag": "STEPHAN" } }, "segments": [ { "speaker": "stephan", "time": "00:01", "start": 0.52, "text": "Hi, welcome to Stephan Livera podcast, a show brought to you by Swann dot com. So today we're continuing the conversation about covenants on Bitcoin, and we're talking about TXHASH. Now joining me is Stephen Roost to explain some of these Covenant use cases, such as transaction templating, LN symmetry, vaults, and more. I will just recommend for those of you who haven't seen the earlier episode with Brandon Black, make sure you watch that one just to give yourself some context, as this one does get a little bit more into the detail. Now, on to my show with Stephen." }, { "speaker": "stephan", "time": "00:45", "start": 44.83, "text": "Stephen, welcome to the show. Hi, thanks for having me. So, just for people who don't know you, just a very-- just give us a quick background on yourself. Who are you and what are you mainly working on these days?" }, { "speaker": "stephan_livera", "time": "00:56", "start": 55.84, "text": "Yeah, so I've been a Bitcoin developer in the background for a long time, I think since 2012. joined Blockstream about five or six years ago. been working in the Liquid team, working in the backend of Liquid, and in the last year I've been on sabbatical and I've been thinking a lot about," }, { "speaker": "stephan_livera", "time": "01:16", "start": 76.5, "text": "Covenant's working on, Liquid" }, { "speaker": "stephan", "time": "01:18", "start": 78.14, "text": "before. Great. And I know y-you are also the, the man behind Covenant dot info, so this is a really great site for people who are interested to get some, just basic explanations about what Covenants are, and I know you're also, you're also involved with TXHASH, aren't you as well?" }, { "speaker": "stephan_livera", "time": "01:36", "start": 96.09, "text": "Yes, yes, yes." }, { "speaker": "stephan", "time": "01:38", "start": 97.69, "text": "Okay, so this is another proposal, right? So I guess let's sort of step it back and just kind of keep it in simple terms for people. So in simple terms, what's your case for Covenant? Do we need them?" }, { "speaker": "stephan_livera", "time": "01:49", "start": 109.44, "text": "Yeah, that's a good question. I actually listened to Brandon Black's episode and he had a very, very good explanation of this, but Covenants are kind of like an addition to the things we can do with coins and the expres- the expressions we can use to, condition the spending of coins. And in some way, we always had some form of covenants because check sig, the normal signature scheme we use in, in Bitcoin is also kind of like a covenant, just a very like specific and limited one. And so I think when we're trying to scale Bitcoin up to different layers, we, we need to do this kind of schemes where things get a little bit more complicated than just broadcasting a transaction and a signature. And covenants are really powerful, in allowing us to- To create these kind of constructions, right? So when, when Lightning was created," }, { "speaker": "stephan_livera", "time": "02:39", "start": 158.72, "text": "we got this like payment network second layer that has like lots of powerful features and some softworks were needed. Some of them are actually also very small covenants, and now that we're like looking, trying to look beyond Lightning, trying to construct other kinds of constructions to go off, second layer, covenants really help us, construct those things in like incentive compatible way and like efficient Ways, there's other use cases that aren't second layers that are also like using the expressiveness of script to make coins more secure, like vaults so yeah, my, my case for, for covenants is it's just making the scripting language more expressive and it's not, it's not in any way something bad because you're, you're restricting your own coins, right? Just as you, you can restrict your coins with a multi-sig, a single sig, you're just restricting them in a different way, but they're your own coins, so, so you, you agree to this," }, { "speaker": "stephan", "time": "03:35", "start": 215.06, "text": "restriction. I see. And so I think similar to, you know, the episode with Brandon Black, we were talking about this idea of why would I wanna restrict the coins? And, you know, I think the same kind of explanation I was trying to get at as well is this idea that by restricting our own coins in a certain way, we can be a part of certain protocols that would otherwise not be possible. So for example, Lightning using relative time-locking and multi-signature is a way of restricting the way we use our coins that allows us to- Achieve more things. So for example, I use Lightning quite regularly. It saves me in terms of on-chain fees because I might only have to do a few on-chain transactions, but I can do dozens, if not more than that, off-chain every month, as an example. and so- When, I think one other area that people might be a little bit hesitant about covenant, covenants is not, because in their minds they're thinking, \"Oh, somebody else is gonna try to restrain my coins.\" Could you just spell out a little bit about how that works? Like, I guess the way I'm thinking about it, and you, you correct me if I'm wrong, but the way I'm thinking about it is I might have some kind of covenant-aware wallet, and I could generate either like a standard address, a single-signature address, or a standard multi-signature address, or That I'm opting into, and I'm generating like a covenant address, and then I could give that to you, and you can make a payment, and I can sort of trustlessly know that the coins are gonna come to me because that's maybe how this particular covenant works, right? It's the idea is the user is the one generating the covenant address in this case, right?" }, { "speaker": "stephan_livera", "time": "05:11", "start": 310.73, "text": "Yeah, and you're, and you're going down a very specific path, but if you look at, for example, Lightning, right? In Lightning, we're all comfortable with Lightning, and in Lightning, you are creating channels, there are two parties, and you're not just putting money in an address, you're putting money in some kind of agreement, some kind of contract, right? And it's two people, and you can, intuitively understand when your contract clauses only involve two people, it's pretty easy to think about what can go wrong, like what can-- what are the different" }, { "speaker": "stephan_livera", "time": "05:40", "start": 340.15, "text": "And you're try-- you're thinking about ten, hundred, or thousand, or even million people trying to do, trying to have a social, like a contract agreement on the chain, things kind of blow up very fast, and that's where covenants come in. so like, yeah, one of the use cases is getting into these larger scale construction where you're actually- Trading your money for like some kind of share in the construction, like, like your balance in a channel, but instead of with two people, it's with more people. But yeah, if you want to use the covenants for like personal wallet use cases, like vaults where, where covenants can help you do like, inheritance planning or, more complex, waterfall systems for signatures where if you lose some keys, you can use other keys, stuff like that. there, yeah, like your, your wallet constructs the address and you know exactly what kind of conditions are in that address, so if someone sent you that money, you're fully aware of the, the scope of what the covenants are actually doing, and you want these things because otherwise you would just not use them." }, { "speaker": "stephan", "time": "06:42", "start": 401.9, "text": "Right, okay. And so let's get into a little bit of the TXHASH aspect. So TXHASH is a proposed opcode, as I understand. and can you spell out some of the context on why you're creating this new TXHASH proposal? Because there's already other ideas out there, right? There's already Check Template Verify, there's already AnyPreVote, there's now LN Hand, which is a new proposal from Brandon. So I'm curious what your view on, the, you know, why, why create TXHASH? where did it come from? And, you know, give us a bit of the context there." }, { "speaker": "stephan_livera", "time": "07:15", "start": 435.32, "text": "Cool, yeah. So the extension is not a new idea. it's been around, I think, a year or two on the mailing list. It was originally, put out by Russell O'Connor, in some, mail, dev mailing list conversation, So, like, I think most, most people are familiar with CTV or at least the name CTV, and TXHASH is actually like the default mode for TXHASH is exactly like CTV. So, like, TXS is basically CTV, but it gives you a little bit more fine-grained control over what parts of the transaction you want to template in your CTV. so this idea has been around in the mailing list because it opens up, several other, like, use cases that CTV can't And since it's been talked about like for a while, and sometimes it, it, it, it comes up in conversations like, \"Oh, but if you do the hash, you can do this,\" but no one ever actually took, took the time to do the work and implement this, TXHASH. So what I did is I just went from the Bib for CTV, extended it to, to make it into TXHASH and implemented it for Core. it's still, we're still like discussing some of the like nitty gritty aspects of how the implementation should be But, yeah, it's basically a super, a super, version of, CTV that, that allows for more things. And also it opens, it opens the way to use, to be used together with CheckSig from Stack, where it can emulate or it can very efficiently do things like APO, for Lightning symmetry, like together, TXHASH used together with a sig signature is basically a seck hash. So some, some developers might be familiar with, TXHASH Single, TXHASH All, where you can, you can choose which of the outputs you want to include in your signature, and with TXHASH you can basically choose Anything in the transaction you want to include in your signature, so certain specific inputs, specific outputs, and you can just pick them manually and then sign and then, restrict your signature upon those conditions." }, { "speaker": "stephan", "time": "09:16", "start": 556.17, "text": "Got it. Okay. So my, again, my, poor man's understanding of the sig hash flags is, it's like this idea that when you sign a transaction, it's sort of saying, \"This is what the signature covers.\" And so either you do like sig hash all to say, \"I'm signing the entire thing,\" and if any part of that transaction- Changes, it's no longer valid because it doesn't match my signature. But you have other sig hash flags, like, you know, particular, you know, sig hash flags, and you can use those to sort of sign only, you know, this part of the transaction but leave that other part unsigned, and then maybe in a collaborative context, maybe a coinjoin or some other context, somebody else can have their signature that applies in. And so I guess that's maybe the context of where the sig hash flags come in. And so APO is a proposal Proposed is like a proposed new sig hash flag. It's this idea that allows you to, again, my poor man's understanding, it allows you to rebind out, you know, the, the previous, you know, output so that in the lightning context, it allows us to kind of make the scripting a bit cleaner and our backups a bit better and this kind of thing. And so I guess we-- you can think of TXHASH sort of like that, but in a more advanced form where maybe it gives you a bit more, let's say, power in terms of what you can select or not select. Is that-- Is that kind of what's going on here?" }, { "speaker": "stephan_livera", "time": "10:39", "start": 639.31, "text": "Exactly, exactly. So yeah, so with the SigHash, like when you send money to an address, you basically say this, this key, this public key, has power over this money. And then when you sign with this public key, you can choose actually what needs to be true for the signature to be valid. You can say, with SigHash All, you basically sign the whole transaction. You say, this signature is valid, but the transaction in which your signature appears needs to be exactly this transaction with all these outputs and all these inputs. And there's also another SigHash Flash called SigHash Single, where And all the rest, I don't care. So you can use this signature in any other transaction where the same output is actually the same. And with the access, you can, you can actually choose any of these combinations. You can say, \"I need these two outputs, these three outputs, or I, I only care about the inputs, or I only care about the outputs.\" And APO, with APO, you say, \"I care about the outputs, but I don't care about where the money comes from.\" And this is useful because you can then plug in your transaction in any And with the XHASH, you can also do APO, because you can just say, \"I, I select all the outputs, but I don't select the inputs.\" it's just like a more general, like a generalized form" }, { "speaker": "stephan", "time": "11:51", "start": 711.02, "text": "of check template verify and of APO, let's say. and then if you could-- So I guess that's kind of like TXHASH sort of simplified. If you could give us like a simple version of what is CheckSigFromStack and what's the, what's, what's the interaction here be-- between TXHASH and CheckSigFrom" }, { "speaker": "stephan_livera", "time": "12:10", "start": 730.27, "text": "Okay, so that's a good question. because what's funny about Bitcoin is it has an opcode that verifies the signature. But ever-- anyone who ever learned about digital signatures knows that there's a private key, there's a public key, and there's a message, and you always sign a message, right? So then you can verify using the public key whether the private key signed the message. And in Bitcoin, we have this opcode CHECKSIG, but it only takes a public key, doesn't take a message. But it's implied in the operation that the message, of course, is the transaction because you're validating the transaction. So the protocol, the Bitcoin consensus protocol, knows what-- how to construct a message, so how to combine elements from the transaction, create a message, and then the se-- the private key has to sign this message, and the message represents the signature. the, the transaction. And what checksick from stack is, is basically allowing you to provide a message on the stack and not have this implied message which is derived from the transaction. So you can verify any signature on any message that anyone has created. So for example, very, very, intuitive example of this is if you want to do a price oracle, you could say, \"We want a signature from the oracle on the message that says the current price is one, is, hundred K for a Bitcoin,\" and then it would- When the oracle signs this, you can use Trixie from Stack to actually verify did this oracle sign the message that the current price is hundred K. So you can actually specify the message on the signature. And if you combine this with TXHASH Then you can actually use the xhash to pick manually, like we did with the-- like I did in explanation of the sighash, pick elements from the transaction, put it in a hash, and then use this hash as the message together with checksig from Stack to actually emulate a normal checksig, but with many different, sighash ideas, if that makes sense." }, { "speaker": "stephan", "time": "13:56", "start": 835.96, "text": "Okay. And so it, it sort of opens the door more in terms of what's possible. Now, I guess there may be some people who have a concern about that because maybe they're worried, okay, Check Temple Verify is, is one of the simplest possible changes that you could have. Let's say TXHASH is maybe you're sort of opening the door a little bit more, and maybe for some people, maybe they have a concern about MEV or enabling something, some drive chain or some kind of thing that they don't want to enable. What's your thought on that idea of accidentally enabling something that people don't want?" }, { "speaker": "stephan_livera", "time": "14:35", "start": 874.68, "text": "these are difficult questions. I think there's one thing that's very important to keep in mind, but I think even the people who are actively speaking against governance already accept it, is that you can't force anyone to opt into a covenant. So like, you can't do the whole Government surveillance thing where they, where they spy on all the coins or they control all the coins. No, because you choose where your money goes, and if you don't put it in a covenant, you, you, it just never goes into the covenant. But there are like some, some concerns about external effects because if covenants can enable some kind of incentive games, then everyone's coins are actually, like, yeah, there could be some kind of negative" }, { "speaker": "stephan", "time": "15:11", "start": 910.91, "text": "externality of the, of the particular covenant, yeah. Yeah." }, { "speaker": "stephan_livera", "time": "15:15", "start": 914.99, "text": "Yeah, those are the current kind of concerns that people talk about," }, { "speaker": "stephan_livera", "time": "15:20", "start": 919.89, "text": "But I haven't actually heard any like concrete examples of how MUV could really like affect Bitcoin that much. I think most of the fears of MUV come from Ethereum, where MUV is really big, especially because they have on-chain market making and stuff like that. I don't think Bitcoin is suitable to do on-chain market making and trading. I think all of that will be off-chain, and then there will be different, incentive games that don't affect the chain necessarily. I don't really understand any of the concrete examples people have brought. For MEV, actually I haven't seen any concrete examples, just like, oh, maybe we will enable MEV. And it's true, like it's hard to prove you don't enable certain things, right? You, you can't think of everything. but for now, I haven't heard any like scary examples or things that are actual feasible dangers, That covenants can enable." }, { "speaker": "stephan", "time": "16:09", "start": 968.93, "text": "I see, yeah. Okay, and I guess that's where people have to consider the different scope of the changes, right? So I think this comes back to, as you probably recall from the episode with Brandon, we were talking, and Brandon was mentioning the relative size of some of these changes in Bitcoin's history. So obviously SegWit and Taproot were huge changes. They were like really big changes to how Bitcoin works. Smaller changes, things like, CSV, CLTV, these were much smaller changes. Where would you place TXHASH on that sort of scope or spectrum of? How big the change is to Bitcoin?" }, { "speaker": "stephan_livera", "time": "16:51", "start": 1011.26, "text": "Yeah, I think, I think conceptually, like the scope is pretty limited. It's like you, you pick some stuff from the transaction, you hash it together, you put it on the stack. But like I said, TXHASH is like a generalized form, form of CTV, and the one beauty about CTV is the simplicity, right? So the code for CTV is like thirty lines of code or something like that, very small. It's very easy to think about and reason about, like the implications, especially code-wise and, technical- Technical baggage-wise that it could have. TXHASH, because we want to like avoid potentially like, denial of service scenarios where a bad user could actually cause a miner or any validator to hash a whole bunch of data and like spend a lot of time, using a transaction, we need to use some kind of caching strategy, and the code becomes a lot more complex, than CTV. So even though conceptually it's not so hard to reason about, the code is like more along like five, five hundred lines of code instead of like thirty lines of code So then there's more surface for bugs, there's more technical baggage that we have to keep, keeping with us. But it's, it's nowhere near the, the scope of SegWit or, or Taproot or something, big like that. But it's also, it's arguably a lot bigger than, CTV" }, { "speaker": "stephan", "time": "18:06", "start": 1085.96, "text": "Okay. and in comparison with just APO, what would you-- how would you compare TXHASH with just APO?" }, { "speaker": "stephan_livera", "time": "18:13", "start": 1093.38, "text": "I think APO is more along the lines of CTV, yeah. It's a, it's a single hash mode, so it's like, \"Oh, we're picking these exact things.\" So it's like, it's also very limited in, in, in, in scope. But what, what bothers me most about A- APO and CTV is like, APO is like, we have, we have lightning symmetry in mind, right? People have been" }, { "speaker": "stephan_livera", "time": "18:35", "start": 1115.22, "text": "Changed for, changed, changed names a few times along the years. It used to be called TXHASH No Input and now it's called APO and yeah. And then CDV also has changed names. I think it was called Secure the Bag or something like that. Secure the bag, yeah. Yeah. So like, these are things that do like for one very specific thing, but like, if we want to like encourage innovation and like thinking about new, like, yeah, like Lightning's great and we can improve Lightning with these specific things, but what, what if we want to like totally think" }, { "speaker": "stephan_livera", "time": "19:06", "start": 1145.78, "text": "Imagine what things we will need. And then if we always have to go and create a new, not any prevout, but any output value or something, you know, new TXHASH flag just for specific, operations Then, then we just have to keep doing soft forks, and what, what is, what TXHash is nice, for is that it basically enables many, many things. Most of them will probably never be used in any practical applications, but some of the combinations can be used, and some of the combinations we can now not even imagine can actually be useful, might actually be useful for certain people in certain use cases." }, { "speaker": "stephan", "time": "19:39", "start": 1179.38, "text": "Yeah. Okay. So, yeah, I think that, that can kind of cover the, let's say, the TX hash as contrasted with, you know, APO, CTV, and so on. Let's now talk just a little more generally about Covenant and your website, covenant.info. So, just tell us a little bit of the background there, covenant.info. What are you hoping to achieve there?" }, { "speaker": "stephan_livera", "time": "19:59", "start": 1198.57, "text": "Yeah, actually, it's, it's, it's an interesting story. We were at the conference in the Azores, and we wanted to do like a quick, like, it's an unconference in the Azores, so it's like we don't really plan talks or workshops, it's more like everyone that comes can, can propose at the event itself, like, \"Oh, I wanna talk about this,\" \"Let's do a panel about this.\" And we wanted to obviously do some panel about covenants because many of us are very excited about covenants" }, { "speaker": "stephan_livera", "time": "20:30", "start": 1229.65, "text": "I think it's, I think it's two main reasons. Some of them think, \"Oh, it won't ever happen anyway, so I don't really have to think about this.\" And just some of them think, \"I, I don't need it for my, for the thing that I'm working on, so I, I'm not very interested in, in working on this.\" and the second thing we realized is that actually no one really has a total scope of like all the different proposals, all the different use cases, how they work together. So we were trying to, for the" }, { "speaker": "stephan_livera", "time": "20:59", "start": 1258.65, "text": "Enable which use cases, and even like we were with very experienced developers, some of us were like, \"Oh, I'm not really sure if this really works well, whatever.\" So, so then we were like, \"Okay, so this isn't really knowledge that is out there very easily.\" So then, that table that I used for the conference was actually the, the beginning of the table that I have, the summary table that I have on the website, and then I elaborated a little bit on every use case and every proposal and kind of put them all in the same place. there's not a lot of text for all the proposals, but there is always links to the original Bib or the implementation or, some website that explains the use case, just so, so you have a central place where you can go from, to explore covenants." }, { "speaker": "stephan", "time": "21:39", "start": 1298.62, "text": "Great, okay. So let's talk through some of these Covenant use cases. I think that's another area where maybe people have heard of Covenants, but maybe they haven't really had some of the use cases clearly explained, so now might be a good time to go through and do that. So one of the ones that we have listed here is transaction templating. So what's transaction templating?" }, { "speaker": "stephan_livera", "time": "22:00", "start": 1320.24, "text": "Yeah, transaction templating, I think, is the most intuitive or the most straightforward use case. It's, it's basically replacing the need for pre-signing transactions, right? So when, when you do off-chain protocols, both in Lightning or other off-chain protocols, you, you want some transactions to already exist off the chain that you could potentially, broadcast to the network and then they come on chain. And to do that, you need to usually like fulfill signatures because you have to do something with conditions, right? So there's a lot of pre-signing required, right? Yeah, so You sign the transaction so that it's valid, and then you keep it in memory, so that at some point you could broadcast it, and what transaction templating mostly does is remove mo- lots of the needs for these pre-signed transactions so that you can use conditions in the, in the existing script instead of needing to create a transaction yourself and then put a signature on it, which is, which takes a lot more bytes when it's broadcast. Then if you could just say, okay, the transaction split that spent this needs to be this template, instead of it you say, \"Oh, this will be the transaction, and we will sign it,\" and then, and then the transaction will be bigger, and you need to keep the signature because if you lose the signature, you also lose, You, you lose access to, to this, to this, to this clause in your exit. So this is useful for vaults, this is useful for ARC, it's very useful, it's useful for this old use case called congestion trees, yeah, it's, it's, it's useful for many, for many protocols. And it's basically replacing" }, { "speaker": "stephan", "time": "23:29", "start": 1409.13, "text": "pre-signed transactions. Great. So that can really simplify certain protocols and maybe make them feasible where previously they weren't. so let's talk about, the next one which I can see here is, L2, or also known as LN symmetry. So I think you've listed that there. That, I guess, most people might have-- people might have heard of that. That's like this idea of an upgraded version of the Lightning Network. Do you wanna just elaborate a little bit on any thoughts you have there about where? Covenants are enabling this." }, { "speaker": "stephan_livera", "time": "24:00", "start": 1440.43, "text": "If, if you allow me to go back one more remark on the, on the template thing. So there's one significant difference because when you pre-sign a transaction, the transaction can always be repri-resigned, right? And it's impossible to prove that a key doesn't no longer exist. So it's impossible to prove that you can't have an alternative pre-signed transaction or an alternative signed transaction that can actually replace yours, while if you use a covenant, you have a hundred percent guarantee, like, okay, the transaction that spends this actually will be this one. And is very useful in concepts like, multisig vaults and stuff like that, that actually is not just more efficient, but it's actually removing trust that otherwise would still be there, some risk factors. Right. Let me" }, { "speaker": "stephan", "time": "24:41", "start": 1480.67, "text": "just spell that out then. So I guess what you're saying there is currently to do some of these use cases, it requires a lot of pre-signing, or in some cases maybe some level of trust that the person has deleted the key. So in a covenant world where, let's say, we had CTV or TXHASH or something We could then, or OpVault in this case, we could have it without the pre-signing transaction, so it's easier to set up, therefore easier UX, and maybe even better security as well, because you're not having to trust that the other guy has deleted his key, because that's currently where-- that's currently the, the world we're in now, and maybe that, that, those two requirements can often be a deal breaker in terms of making it feasible or practical to even do that vault as an example. Exactly." }, { "speaker": "stephan_livera", "time": "25:28", "start": 1527.82, "text": "Yeah, exactly. If you have a really big vault, like something like Coinbase with like thousands of Bitcoin, and you want to create some kind of covenant where only this transaction can spend this, you can pre-sign it, but like there's a really Big surface for an attacker to infiltrate these com- these computers and make sure they can steal the keys, and if they steal the keys, they can just break the covenant because then the keys have access to the money. And with the covenant, nothing can break the co-covenant because you say, \"This needs to happen,\" and if it doesn't happen, it's just not consensus valid. Right," }, { "speaker": "stephan", "time": "25:56", "start": 1556.13, "text": "I see. I'm also curious that, well, I mean, if you were at, the Azores, I know some of the Revolt, Liana guys have-- they're, they're trying with some of these concepts, but the other aspect is that you might need to cycle the coins, let's say once a year, something like that. And my understanding is maybe in a Covenant world you can change some of that or maybe you have less of this kind of recycling the coins every year requirement. Is that also true?" }, { "speaker": "stephan_livera", "time": "26:26", "start": 1586.49, "text": "to a certain extent, I think, but I think they're also like both for CTV and for pre-signing To do, to have efficient ways to make sure that you can pay for the fee, even in a year from now or two years from now, when the fee might be significantly higher, you, we need some other changes to the Bitcoin mempool policy like, fee anchors and stuff like that. That I don't think CityV doesn't solve that for, for mul- for pre-signed TXHash could somehow solve that because with TXHash you can fix certain outputs and then allow an external party to add fees at the moment you're spending this." }, { "speaker": "stephan", "time": "27:01", "start": 1621.28, "text": "Interesting, yeah." }, { "speaker": "stephan_livera", "time": "27:02", "start": 1622.26, "text": "So, but for both pre-signing, like, like Revolt was trying right now, or for CTV, you would need something like fee anchors so that you can pay the fee at the moment of spending and not at the moment of creating the" }, { "speaker": "stephan", "time": "27:12", "start": 1632.01, "text": "policy. I see. And I know this is another area where people are sort of debating a little bit back and forth on what's the right way with, you know, V" }, { "speaker": "stephan", "time": "27:23", "start": 1643.14, "text": "How do you bring fees if you can't pre-kind of plan what those fees are? And I understand that's another argument for the, let's say, the TXHASH argument, which is that these protocols would allow The participants to add new fees, which might be useful in a very variable fee rate market, like let's say the block space market is very low right now, but in a year's time it's very high, and one of us needs to close the tran- the channel or get out of the protocol somehow. In the TX hash context, you can bring some extra fee, whereas in, let's say, a CTV context, you wouldn't be able to." }, { "speaker": "stephan_livera", "time": "28:01", "start": 1680.73, "text": "Yeah, so in CTV, it would, it would practically only work with a fee anchor. So then you need to make your, your covenant transaction, like your transaction that's, that's encumbered by CTV, and then add extra fees using child pays for parents. Right. using some kind of fee anchor. So you have to have an extra" }, { "speaker": "stephan", "time": "28:15", "start": 1694.52, "text": "anchor output, right? That's like in Lightning, where they have anchor outputs to You're, you're paying more, you're, you have a bigger size transaction in terms of bytes. And so because of those extra bytes, you're paying more for that. And, you know, yeah, etcetera. So with TXHASH, you can" }, { "speaker": "stephan_livera", "time": "28:33", "start": 1712.69, "text": "just append the fee into the same transaction because the covenant only covers The, the encumbered input and some outputs, and then you can just add an extra input, add an extra output, and then pay for the fees that way." }, { "speaker": "stephan", "time": "28:45", "start": 1725.3, "text": "Got it. I think I'm slowly following you. although this conversation's probably not for the beginners, but it's okay. I think this episode will just be more for the, let's say, intermediate and advanced people who wanna learn a bit more about it. And so, yeah, now let's, let's talk a little bit about Lightning symmetry. So, do you have anything to add there in terms of Lightning symmetry, or do you wanna just, skip over that and go to other use cases?" }, { "speaker": "stephan_livera", "time": "29:09", "start": 1748.74, "text": "No, we can talk about Lightning Symmetry, but I think Lightning Symmetry is one of the oldest ideas where that still like are very actively discussed that need covenants, right? Lightning's is used a lot, but, L2 is just a very, it's a very simpler way of reasoning about like how your Lightning implementation needs to like handle data and constr- and transaction constructions and stuff like that. So I think everyone agrees that a and, and Lightning symmetry enabled Lightning would just be better, but there is," }, { "speaker": "stephan_livera", "time": "29:41", "start": 1781.32, "text": "The type of covenant needed to enable this is, is not very advanced. I mean, what I'm saying is many of the proposals can't actually enable this. So from a use case point of view, I think everyone agrees eventually Lightning will have to enable Lightning symmetry to be like practical, but yeah, APO, TXHASH, plus the CheckSig from Stack, all, or even without CheckSig from Stack, can all somehow enable Lightning symmetry." }, { "speaker": "stephan", "time": "30:09", "start": 1809.41, "text": "Back to the show in a moment. The lead sponsor of this show is Swann dot com. Over at Swann dot com, you can buy Bitcoin and learn about Bitcoin. Using the Swann dot com website or the Swann Bitcoin application on iPhone or Android, you can easily get started. So you can fund your account with ACH or wire, and you can purchase Bitcoin either doing an- An initial lump sum or setting up an automated recurring savings plan. So these are two great ways that people get started. Oftentimes, people start with an, a lump sum and then they go on to an automated savings plan with Swan. Also remember, you can withdraw your coins for free. Swan wants you to withdraw Bitcoin into your own self custody, into your own Bitcoin wallet. So there's also a range of services available over at Swan. So for example, if you are a high net worth investor or an individual, you can go to Swan swanprivate dot com and sign up there for concierge guidance. You can have somebody who you can call, you can get additional guidance and, additional services such as tax loss harvesting and have support for corporate, retirement or trust accounts. There's a range of service-- services available over at Swan. If you wanna get started stacking, go to swan dot com slash livera and you'll get ten dollars of Bitcoin dropped into your account when you start stacking with Swan. This show also brought to you by Mempool. Mempool.space, the leading Bitcoin and blockchain visualizer. If you are looking to send a Bitcoin transaction, make sure you check Mempool.space because this allows you to target the fee of your transaction and make sure that it is appropriate to get it confirmed in the timeframe that you would like it to get confirmed in. Mempool.space also has a transaction history visualizer, so you can search old transactions. You can take the TXID, the transaction ID, and paste that into Mempool.space, and you can search transactions. It's a really cool- feature, it helps you understand when your transactions have been confirmed or not, as well as looking at other informative, aspects of that transaction, such as whether it was multisig or not, or whether it had replaced by fee, flagged on or off. There's all kinds of information you can learn by using mempool dot space. They also have mempool goggles, which is a really cool tool that you can use to basically hover over and see what kinds of transactions are coming through the mempool, whether they are multisig or single signature. Or inscriptions or something else, it's a really cool way to learn a bit about Bitcoin. Now, remember, they've also got a transaction accelerator program coming out soon, so make sure you go and sign up for the waitlist if you're interested in that waitlist. The website is mempool dot space slash accelerator. Now, finally, when it comes to securing our coins, we need hardware to secure larger amounts of Bitcoin. So I'm a big fan of using the Coldcard from coinkite dot com. The Coldcard is a very reliable device, it's ultra secure, it has multi- able secure elements. It has support for all the latest and greatest in terms of Bitcoin on-chain aspects. It is able to be used in different modes. You can directly plug it into your computer, or you can use it with an SD card, or you can even use it with NFC if you wish. And so that gives you a lot of functionality, a lot of features that you can use to help tune your particular security setup, whether you wanna be in single signature, whether you wanna have a passphrase, whether you wanna do seed XOR, whether you wanna- Do things like have bip eighty five, which allows you to have one master seed or parent seed and different child seeds for different wallets, or maybe you wanna retain a backup for somebody who's a loved one of yours. You could even use the bip eighty five feature to generate a child seed for that other person. And so this way, if you've got the kind of person in your life who is very prone to losing their seed words, you can regenerate that for them in this case. Also, over at Coinkite, you can find a range of different accessories Accessories, whether that is metal seed plates to stamp in your twelve or twenty-four words, or whether that is other devices such as the TapSigner or the SatsCard, which is kind of like the new version of the OpenDime, or the BlockClock, which is a great, clock that allows you to see the price of Bitcoin or see the block height of Bitcoin and various details. You can go and find out more over at Coinkite dot com, use code Livera for a discount on your cold cards. And now back to the show. Right, which is coming back to What we were saying before, this is this idea of being able to rebind the previous output so that we can simplify our backups and our, just our general process for setting up, and operating in a lightning environment." }, { "speaker": "stephan", "time": "34:49", "start": 2088.74, "text": "Now, you've al- we've also got vaults. Now there is a specific op code related to vaults, and my understanding is it can operate on its own, but it's maybe best to be paired with op vault plus check template verify, or in this case, it could similarly, like you said, TX hash. So do you wanna just explain a little bit around the vaults, and what you're seeing the, the impact or the use would be there?" }, { "speaker": "stephan_livera", "time": "35:15", "start": 2115.47, "text": "Yeah. So lightning SIM tree is like a use case that everyone talks about for covenants, but it's like more abstract because lightning already exists and just optimizes stuff. I think vault is like the prime, okay, if we have covenants, we can build vaults, right? And vaults are something that everyone kind of agrees is like really useful because it's just a way more secure way to deal with coins, and especially larger custodians, but even people that have their entire savings in, in Bitcoin want something like want their setup to be very secure, and a, a vault basically Prevent your coins to be lost when some keys are stolen, right? So you always need to have keys when you deal with your Bitcoin because you need to spend and if some-- if those keys are stolen or con-confiscated in any way, either your computer is hacked, someone steals your backup, someone guesses your passwords, stuff like that, then your coins are just gone. And with Vault, you can, you can actually give some kind of backup clause in the worst case scenario where someone steals Some or, or more of your keys, even with multisig, if, if several of the keys are, are, are, are stolen with multisig, you can still lose some of your, you can still lose your, lose your coins. And vaults are just a way to add an extra layer of security. If your keys are confiscated in any way or you, you fuck up in any way, you have some backup clause to just recover your money and make sure that the, that, that, that the thief cannot, take the money. And I think everyone agrees, that, that we want a vault. And so the opcode of vault is basically something that works together with CTV, like you say, to enable this. it's a very use case specific opcode. it's basically an opcode that, that formulates The conditions of the backup clause that you can use when someone confiscates your keys, and to recover the money, during some unvault phase when the money is being spent. I don't, I don't really want to comment too much on the op vault itself. Personally, I'm from the philosophy that we should create opcodes that, that do Small primitives, and then use cases can be, can be built by combining the primitives, right? Just like we use xPub and" }, { "speaker": "stephan", "time": "37:19", "start": 2239.33, "text": "like a purpose-built opcode for a one-use case thing." }, { "speaker": "stephan_livera", "time": "37:23", "start": 2242.73, "text": "But there is a really good argument to be made if we want to use Taproot and we want to do something that OpVault does, we need actually a whole bunch of opcodes. So I somehow get the argument that OpVault It does a very simple thing, like add, like a timeout phase, took some coins to, to make an unvote phase possible. And if you wanna build this using, like, a set of like more generalized opcodes, you would need like several of them. You would need both CAT, something like tweak add, you need a covenant like, like, like, TXHASH, you need probably something like op segment to go around the op success, Loophole other, otherwise, so it's like it's, it gets a bit complicated, and OpVault is basically, okay, here I want to build a vault around these coins with this op code. So I can see both the arguments be-f, in favor and against. I haven't looked at the specific implementation, but I've read the Bib. Yeah, I mean, I think everyone agrees vaults are useful, so we need to find a way to get them, and like, yeah, it can be a vault, it can be- TXS plus some other things." }, { "speaker": "stephan", "time": "38:31", "start": 2310.68, "text": "Yeah. Okay, fair enough. let's move on to the next use case here, which is payment pools. So can you just explain what's a payment pool, also known as join pool or coin pool? what is this? How would it be useful for us from a covenant context?" }, { "speaker": "stephan_livera", "time": "38:46", "start": 2326.42, "text": "Yeah, cool. Like payment pools, I actually really like them, because they're one of the new things, right? Like, Lightning exists, falls to some extent can be, can exist with pre-sent transactions, but payment pools are something like quite new Maybe not as an idea, but as like something that might be practical in the, in the near future. And what a payment pool is, instead of like every individual having their own set of UTXOs and spending them, a bunch of people can come together and say, okay, like we will put all our money in the same one UTXO, and then using the, the script conditions in this UTXO, they can both, all of them Exit and get their own coins back without needing cooperation of anyone else, but they can also collaboratively reshuffle the, their balances within the, within the pool, right? So in some way you can think about this as a multi-party lightning channel, like where many people are in the same channel, and I can send money to any of these people and, And we don't have to like, we don't have to do anything on the, on the chain. But also anyone can make payments to external parties, by taking some money out of the pool, making a non-chain, a non-chain transaction, but then the change again is the new pool, where all the leftover money goes in the exact same state. And like in theory, not even sure about that. Like the reason why covenants are needed to make these pools is because, as you can imagine, if you have ten people doing, sharing the same UTxO, this, all these ten people need to like cosign all kinds of stuff. And a, a covenant can r-remove or reduce, eliminate a lot of the interactivity that is needed so that people can actually unilaterally take certain actions in, in, in the pool, like taking, share of the Their money out or something like that without needing everyone to be online, right? Because if you're, if you're ten people, let's say, let's not, let's even consider everyone's our friends, but what if just one person just loses their computer, like some water falls on it or whatever, then they can't co-sign and then what happens? The pool is stuck. No, you want, you want the pool to be able to continue without this person. So you, you need some kind of non-interactive way to kick this person out, get, give him his money back, and" }, { "speaker": "stephan", "time": "40:59", "start": 2459.11, "text": "So I'm curious then, in terms of the way people are talking about it or thinking about it, is this designed for higher value use cases or could it, like, because imagine, like, imagine we're moving into a world where fees are high, would this realistically only be for- Larger entities who want to do some kind of joined or payment pool together and then, because every payment here is on chain, right? And if, you know, let's say we're in the context of, you know, high on-chain fees. well, payments within the pool" }, { "speaker": "stephan_livera", "time": "41:29", "start": 2488.97, "text": "aren't on chain, but yeah, you're right. Like actual payments are on chain because you only transact so much with your friends, you know? I mean, you always have to buy something external, yeah." }, { "speaker": "stephan", "time": "41:39", "start": 2498.87, "text": "So I could-- I mean, as an example, you could imagine, let's say Kraken and Coinbase and BitGo and whatever want to all go into a payment pool together, for them it would make sense, because now in between each other there might be lots of inter-exchange flows anyway, and so they can take a lot of their volume off the chain per se, and when they need to make payouts, they can still do payouts out of that." }, { "speaker": "stephan_livera", "time": "42:04", "start": 2524.38, "text": "Yeah, exactly. So it makes a lot of sense for like, maybe not necessarily people, but parties that already transact on a regular basis with each other, right? and in that case, it makes sense that they set up a pool to just save on, on chain fees. So like the example you give, exchanges between each other, I think most of the international or continental banking systems also have systems like that where they, they tally up the, the debt they owe and then in the end of the day, or in the end of the day, at the end of the day, they just that would make a lot of sense. the fact that it's all fairly secure, like most, most layer two solutions have some kind of incentive games, like Lightning has with the revocation, all that stuff, but the payment pool is like, it's very simple, like everything is really Secure on, on, on the chain. Everyone has a one transaction, their direct exit. So, so for like really high amounts, I think the pools make a lot of sense, for people that transact on a daily basis. you can never say never because you can never imagine what people will build, but maybe someone will build an im- an implementation where a family can set up a pool so they can all share their, their savings in a safe way But yeah, I think the first, the first use cases where the pools are more interesting are, are, large custodians or holders of large amount of coins that actually have to do on-chain" }, { "speaker": "stephan", "time": "43:24", "start": 2603.82, "text": "transactions. Right. And as you said, crucially, it's best, or there's more fee savings if they would normally be transacting with each other a lot. And so I guess that would be an important point also, because then you're getting a big sav- even bigger savings. although, I mean, you could just say, \"Look, today, some of them just use Lightning Even something like Liquid or, you know, things like this. So, I mean, there's all kinds of different options that they could use. Obviously, they have to kind of decide what's actually useful for them. Now, related, and I know you're also, I guess you're involved with Ark, or I'm not sure how closely you are with the team. yeah, yeah. Yeah, so, yeah, so do-- let's, let's talk a little bit about ARC. I know it has some similarities with payment pools, but it's obviously like another whole thing. So I guess we don't need to go and do like a whole ARC podcast, but if you could sort of just light-- just touch on the covenant elements of ARC and maybe the TXHASH elements of ARC." }, { "speaker": "stephan_livera", "time": "44:21", "start": 2660.99, "text": "Yeah, okay. Yeah, so recently I kind of did some kind of very short summary about the difference between ARC and payment pools, I think, because for me a payment pool is a bunch of people who And reshuffle the money, right? So they can reshuffle internally and they can all exit and then continue the pool. And Ark is very different in that sense that in Ark, still some people share UTXO, but only in a fixed set way. You can't reshuffle anything in, in, in internally. So like You get this like bunch of money is divided among some people and then it, it stays like that. The only thing they can do is they can just give up their part and let's say like, okay, I'm out. And then usually in, in an, in the Ark protocol, when you go, when you go out, you exchange this share for a share in the next, construction like this, right? So Ark is like a series of Fixed situation pools where people can only exit and not reshuffle, and then you can do, efficient payment protocols there. So for ARC, the covenant needs there are are way simpler than for pools, because if you want to have unilateral exit from pools but continue the pool from there, you need to- You can imagine this, you need to keep state, right? Because in the pool, you have this, this state like you have one Bitcoin, you have two, you have three, and if one person goes out, the re- the remainder of the state needs to live on, o- on the chain, right? So you need to keep state, which is more complex. But in, in ARC, the whole situation is laid out from the beginning, so it's kind of like a pre-committed, set of transactions, and all you do is eliminating some branches, but, but the rest doesn't live on. You eliminate the branches by kind of send, by kind of Making a transaction that spends your potential output, right? So that, so that if you try to cheat and get your money back, even though you were out, someone else can take it before you, you can take it. So, so for ARC, it's a lot simpler because everything is already set in stone the moment the, like, the ARC transaction is, is made, and all you need to do is add off-chain transactions so you can safely exit, more like, kind of like a revocation transaction in, in Lightning, where you say, \"Like, okay, this old state is no longer Take my money. The same with ARC, you say I'm out of this tree, I'm out of this like construction, and if I try to still take my money, someone else can take it from me." }, { "speaker": "stephan_livera", "time": "46:41", "start": 2800.59, "text": "yeah, so that's ARC. So what, what you would need for ARC, Covenant-wise, is more something like, a CTV or TXHASH simply without, without the check sig from stack feature or without like the, the vault and the, the script tweaking features, that you need for more complex things, because everything is already set in stone, I see." }, { "speaker": "stephan", "time": "47:01", "start": 2821.43, "text": "Oh, okay. I was actually under the impression you needed, check sig from stack also for ARC. So you don't?" }, { "speaker": "stephan_livera", "time": "47:08", "start": 2827.66, "text": "No, there's many optimizations we can make. Okay, gotcha. Yeah, so it's either we can make or" }, { "speaker": "stephan", "time": "47:12", "start": 2832.12, "text": "TXHASH that enables ARC. Exactly, exactly. Okay." }, { "speaker": "stephan_livera", "time": "47:16", "start": 2835.83, "text": "Actually, I really like, there's a version of ARC Possible without, covenants that has a little bit of, of trade-offs, but I think they're very fair, but yeah, with a very simple covenant like CDV or TXHASH, we can, we can build a really good version of ARC. There's many optimizations, especially around, liquidity recycling and especially around paying fees for exits, where some things like CheckSig from Stack, become useful for us. Yeah." }, { "speaker": "stephan", "time": "47:44", "start": 2864.19, "text": "Now, listeners, you can go and check my earlier episode with Barak about where we sort of walk through ARC a little bit. But I think one big criticism that I've heard, and while we're on the topic, we may as well touch on this with you, the big criticism most people have is that there's a very high capital cost for ASPs, so arc service providers. Can you explain your thoughts on this? Like, is that a problem or you think it's like a low level issue and it's not a showstopper?" }, { "speaker": "stephan_livera", "time": "48:11", "start": 2890.88, "text": "well, I could go in, in a lot of detail. I think it's not a showstopper at all because there's a very good way where you can make the liquidity need optional for the user and it can be offset for a slight like, A slight trust model change, and as a second argument, you can charge fees, relative to the amount of liquidity that is needed for a certain arc transaction, and then users are incentivized to make the transactions that require less liquidity. But I think both ways, the fact that needing the liquidity is kind of optional in, in the first place, and the fact that you can incentivize users to like help the ASP by, by spending the arc coins, the VTXOs that require less liquidity to be spent, Makes the liquidity problem not so insane that people talk about. People talk about, oh, the SP needs certain multiples of all the money that's in the ARC in liquidity, but that's certainly not the case. but yeah, we will only know When we built it and, and people started using it." }, { "speaker": "stephan", "time": "49:15", "start": 2954.65, "text": "Okay. Fair enough. Okay. I, I don't think I have any further kind of criticism on that. let's talk about the congestion control idea, because I think this is an interesting one for CTV or TXHASH. what is congestion control? Can you just walk us through just basically how, how would it work? What does it look like?" }, { "speaker": "stephan_livera", "time": "49:37", "start": 2976.74, "text": "Yeah, so the, the plain and simple idea is, let's say you want to pay a hundred people some money and the fees today are really high, right? And you don't wanna do that because you don't wanna make a hundred transactions or you don't want to make one transaction with a hundred outputs because, it's very expensive. But you want to give these hundred people a certain guarantee, like, hey, you have this money. Like, I actually sent it to you, it's, it's yours now, but you just, you just- You just need to do some more work to, to, to have it, and you can do that work when the fees are lower. So, so that's like, congestion control. So you can basically commit to a number of payments in a very small transaction, and then later on, the idea is that later on when the fees would be lower, these payments can actually be unlocked in certain ways. And the original congestion control idea came from, Jeremy Rubin, when he was making a case for CTV, because you could make such a payout scheme using, again, pre-signed transactions, where you pre-sign a whole bunch of transactions that eventually pay to people, but of course, these people don't Don't trust this pre-signed, this pre-signed, bunch of transactions because, like we said, anyone who has the keys can actually pre-sign other transactions and then they will be double-spent. So with CTV, you can do this very simple idea where like You say, \"Hey, I'm gonna give you guys all these transactions later, and you commit using CTV to all these transactions existing, and no one else can change because the, the commitment to all these transactions is in some kind of hash in the original output that you create.\" So you can create a single output on the chain, give this output to all these people, and then they know that they can get their coins by broadcasting some other transactions the moment that the fees are more cheap." }, { "speaker": "stephan", "time": "51:15", "start": 3075.06, "text": "Interesting. And so my understanding here is this could be really handy in an exchange payout scenario, right? Like exchanges need to pay out to, to customers, like withdrawal scenario. Is that right or no?" }, { "speaker": "stephan_livera", "time": "51:30", "start": 3089.71, "text": "yeah, personally I'm not the most convinced of the actual use because, I mean, the, the drawback of doing this construction is that you have the, the total amount of fees or total amount of bytes you put on the blockchain is higher, right? So this construction works well if the fees are really swinging very high and one time you have to pay like two hundred sat per vbyte and then maybe next week you can pay five sat per vbyte. We've seen this happen maybe over really long terms where suddenly, like, I don't know, someone is, having a new use case and suddenly the chain is used a lot, like with the inscription stuff and, and so on, but I'm not sure if in the long term, in a more stable eco-ecosystem, this is gonna be, a really big issue. But yeah, you never know. Like for, for an, for an exchange to say, \"Currently the fees are high, you guys want your money? Here is some kind of congestion control commitment, and here is how you guys can actually get your money.\" First of all, as a user, you're gonna have to pay fees to get your money, which otherwise you wouldn't. So they need to like agree with all this. of course, then you get a little bit more instead of paying the fees at the moment, maybe the users will, will be happy with that, but still the total amount of bytes, like, imagine the fees don't go down? Then the total amount of fees you're gonna pay is will be a lot higher than if you would just have paid, right away. but yeah, I mean, these constructions work well when fees are high and you know they're gonna go down, which of course will, will-- those situations will arise. but I hope on the long term that the fee market can stabilize a little bit more than it has" }, { "speaker": "stephan", "time": "53:03", "start": 3183.13, "text": "over the last few years. I see. And I mean, look, there will be some people like, like Pierre Rochard who believes that it is just always going to" }, { "speaker": "stephan", "time": "53:14", "start": 3194.04, "text": "volatile, then maybe the congestion control case actually makes more sense. Yeah, yeah. but if you believe it's gonna, let's say, eventually stabilize out at some particular level, then maybe not. Maybe it's not so useful. interesting though. Okay, so Yeah, and I mean, and here's the other point, right? It comes to UX, is right? 'Cause it's one thing to have like the cryptography and the Bitcoin on-chain and all this other stuff, but it's another level of how many real-world actual users, like man on the street who's using Bitcoin Are gonna be comfortable with that level of UX, right? Because imagine the UX of like, \"Oh, I, I, I, the exchange has given me-- it's kind of like, I've got this thing saying the exchange has given me the money, it's not here yet, but I can get it later.\" How many people are gonna be comfortable with that?" }, { "speaker": "stephan_livera", "time": "54:01", "start": 3240.52, "text": "Yeah, that's true. You could imagine maybe some like, maybe advanced users" }, { "speaker": "stephan", "time": "54:05", "start": 3244.66, "text": "for sure, but I don't know, average users." }, { "speaker": "stephan_livera", "time": "54:08", "start": 3248.06, "text": "Yeah, you can imagine some wallet that knows about this, the existence of this construction, and you can already sign away, oh, that's not really secure. Like you could try to give your share in one of those congestion control trees to someone else and already sign it to him, and then he needs to claim it, but then he also needs to accept the fact like, oh, he doesn't really give me coins, he gives me potential coins where I need to first May, like, yeah. First of all, you would need users to use the same wallet like you that actually understands that this exists. They need to be comfortable with then actually paying the fees before they get the money. It's" }, { "speaker": "stephan", "time": "54:43", "start": 3282.94, "text": "like, it cascades a little" }, { "speaker": "stephan_livera", "time": "54:53", "start": 3293.19, "text": "bit. Yeah Instead you have this like fixed structure that, that you get into and then you can exit. So ARC is exactly, this structure is exactly a congestion control tree. The only thing that we add on top is that At some point, the tree just expires and then it can just vanish. And the idea is that by the time it vanishes, everyone will have spent their leaves and cycled their leaves to be part of something else, and then you can just forget about the whole tree and spend it. So So then, then the congestion control tree becomes just a safeguard, like, \"Hey, if the ASP disappears, I can exit. I will have to pay some fees, but I can exit. But if the ASP doesn't disappear, we don't have to do all this work, we don't have to pay all these fees, we can just forget about it and then continue in another, tree like such. So the, the idea generally is definitely a useful concept that can be used in, for example, in payment pools, certain actual payment pools, you can also use these kind of trees to pay" }, { "speaker": "stephan_livera", "time": "55:54", "start": 3353.6, "text": "Then when the money shuffles around or if everyone is collaborative, you don't have to do it. So you only use these congestion control trees as exit mechanisms out of other protocols. And that sense, I think it's, it's a very useful concept, but just to To lower your total fee paid or to like push the fees on future users, I don't personally see it as a very valuable use case." }, { "speaker": "stephan", "time": "56:14", "start": 3374.17, "text": "I see. Okay. So, yeah, so I guess the way you're explaining it is maybe it's not that useful for an exchange payout case, but it's useful in other contexts, is, I guess, the point you're trying to make. Okay. Fair enough. and so I guess when we're talking about some of these covenant use cases, the big challenge a lot of people have is, hey, what about commercial viability? What about proving out this real demand? do you have any thoughts on that idea? How can commercial viability and real demand be proved out here?" }, { "speaker": "stephan_livera", "time": "56:48", "start": 3407.84, "text": "Yeah, that's a very difficult thing. there's different arguments, on both sides. Some of them I understand, some of them I kinda don't agree with. Yeah, I mean, it is true you can theorize a lot, but you need to build stuff to prove that it's possible. But I, I think you can actually- Talk about practical things to a very far extent without having to build them, right? Like building the Lightning Network, for example, before, like, before all this software existed Like, I mean, generally just building a Lightning network, for example, is, is, it's a lot of work. It took people two years to actually build a first version, and to then say like, \"Oh, we're not gonna change anything in Bitcoin, just prove us first that it would work, but we don't give you any guarantee that it will actually exist,\" people aren't gonna build for two years on some use case that they might not even ever use, because if, if those primitives wouldn't have existed, Lightning wouldn't have been like at all as useful as it is now." }, { "speaker": "stephan_livera", "time": "57:43", "start": 3463.19, "text": "I don't really like the argument like, \"Oh, build everything first and then we'll talk about the use cases.\" I think there's a lot of value in, in talking about, \"Okay, with this construction, we could do this.\" And I think many people in the space are able to actually imagine like how things would work concretely and say, like, \"Okay, yeah, it is true, with this we could do this, without having to see someone actually build it, right?\" Of course, proving demand is way higher, like, \"Oh, it's way harder.\" Like," }, { "speaker": "stephan_livera", "time": "58:15", "start": 3494.87, "text": "and there it's even harder because even if you built already an implementation of a use case using a non-exist, not yet existing feature, you can still not prove demand. You can't say like, \"Oh, now people are using this.\" What you could do is build something on, for example, Liquid, where, where Liquid already has covenants and, and very powerful, covenant, constructions. But then you still have the problem, like maybe some users would use a certain product if it was on Bitcoin, but they wouldn't use it If it's on Liquid, because they have other objections, you can build use cases on Signet, but Signet money has no value at all, and then it's like, okay, like, yeah, it exists on Signet, but how can you prove people want it? Like, if, if like twenty people come try it on Signet, how many people would try it on Mainnet? I think it's really hard, a-but I think there's still some use cases where it's very obvious that there is like demand for them. I think vaults would be the biggest one, like, we have We have large amounts of Bitcoin getting stolen every year still, like since the beginning of Bitcoin, many amounts of Bitcoin have been stolen, and just false would have, would have been able to avoid many of those, and at the point now where We have like a handful of really big holders, like it's obvious that they need something, to secure their, their coins. So I think for some use cases Like vaults, like Lightning's symmetry in some way, because everyone uses Lightning, everyone knows, like, \"Oh, it's annoying that I need to backup my channels. If you could just, like, make the watchtowers more efficient, then we don't need to backup our channels every time we make a transaction.\" Stuff like that, where you actually know, okay, people will, will use this once it's there. But for others, you can't really know, like, maybe the payment pools will just be like a handful of users, and you won't make a product that can actually make" }, { "speaker": "stephan", "time": "01:00:04", "start": 3604.93, "text": "Yeah, I see. I think I can understand the hesitation from some people where maybe they s- they might think of it like, \"Well, hey, we already have Lightning now, I just don't want any future changes that could break things.\" And that's why there's-- there should maybe in their, from their point of view, they would say, \"No, there should be a higher bar, right?\" It's not a personal attack on you or other people, but they're saying, \"No, like there just needs to be a higher bar.\" Because, you know, now Bitcoin is so much bigger now than it was, you know, in twenty fifteen and sixteen, something like that, right? I, I think one other area That is interesting to talk about related to this is, when it comes to like multi-party and sharing UTXOs, it It's a, you know, there's like people have to build code for this, and also the users need to be able to collaborate in a way that makes sense for them too. So I'm curious if you have any thoughts on, I guess, crossing that bridge also, like the users being able to have to collaborate on these things, to make-- In what way collaborate? Yeah, like whether it's, payment pools or if it's like a, an ARC thing. I guess in the ARC context, it's more like you'd be a, a service user, right? You Some kind of arc wallet, and you have your ASP who's kind of dealing with the stuff in the background for you, maybe in an LN symmetry context or people are talking about like multi-party lightning channels, then maybe there's more Coordination involved, maybe that's at a more technical level, the users might not have to do as much, but maybe that's also-- I guess what I'm trying to get to here is Some people, at least the criticism that I'm seeing, maybe some people are saying, \"Oh, some of this stuff around sharing UTXOs, it seems hand-wavy.\" In their, in their eyes, it seems, quote unquote, hand-wavy, and it's not, spelled out in terms of what real world impact it's gonna have to scale Bitcoin, as an example." }, { "speaker": "stephan_livera", "time": "01:02:12", "start": 3732.46, "text": "I think, I think for like usage as from users, I think it will be a lot like one use case gets built out, it's, it's a product, it's like an app, and people will install this app. And this goes against some people's philosophy like, okay, we need protocols, we don't need apps, we need protocols. But even with like, like we have this great thing, it's called multisig descriptors. All these kind of, like Bip thirty-nine, Bip, Bip thirty-two, all these kind of protocols that allow actually wallets to supposedly interoperate, while this is all true, what you often see still is that if someone sets up a multisig with a few people, they will on, like in many cases, use the same wallet, all of them, because then it just works out of the box, right? If you use one wallet, you use the other, you use the other, then you need to be fiddling with your derivation paths, with your, with your, description And it just works better. And while it's of course important that all these other wallets can do that, because this one wallet can't just stop existing or something like that, it's gonna be easier and especially the first, the first time many users are gonna be exposed with this, it's just they're gonna use the same app, they're gonna use the same product. And I think with the, with the covenant use cases like ARK, like payment pools, like vaults, it can be very similar. Like Some app will say, \"Okay, we're, we're building a vault, we're building ARG, and people are gonna use this app because that's the first or only app that, that has this usage.\" But as long as this is built on like Bitcoin script, open things, some, some standards, they standardize certain things, then other people Can also write apps and maybe compete or provide backups or provide more advanced like, controls for certain users. I, I, I think it has to go that way, and I think like that, if you have an app it's also way easier to like, I don't know, push the first use case on users, right? Like, hey, with this app, you can do these things that you can't do with other apps. And Of course, like it's not with this app you can do that, it's more like with this protocol you can do that, but the app, people more have like this feeling of, \"Aha, this app gives me this,\" and that's important, and at some point there will be another app, and then maybe there will be like a more, diverse Ecosystem of different apps doing kind of similar things, but I think using an app to like push these new features on users and like make them aware that they exist and how to use them, is useful. Yeah. And of course, when a new product or a new protocol has like a business model, it's gonna be a lot easier to create the app and, and, raise money and build the, the, the whole infrastructure. If you have some protocols that are actually hard to monetize, these use cases might have a harder time. Actually getting adopted. These are, this is an unfortunate side effect, but I, I think it's how it's gonna be. Yeah." }, { "speaker": "stephan", "time": "01:04:59", "start": 3899.46, "text": "yeah. When it comes to upgrading Bitcoin or making protocol changes, one other criticism people have is around Technical debt, this idea that you might still have to maintain this thing in the future. Do you have any thoughts on that, in relation to covenants and TXHASH?" }, { "speaker": "stephan_livera", "time": "01:05:19", "start": 3919.12, "text": "yeah, I, I certainly have. like technical debt is very important, right? And Segwit and Taproot have been like, change the world changes where like everything changes, like your whole thinking model, a lot of the consensus like sub-uh, protocols change and that's why personally I'm, I'm a big fan of like opcodes in general, like an opcode is just an opcode. It's like a feature in script, and we try to make these opcodes have a really small scope. Like they do something if you invoke the opcode, but they don't change anything else. Like if you don't use the opcodes, if you don't like interact with this opcode at all It doesn't change. So like, in the, in the code that executes all the opcode, you have like this blob of code that is like this one opcode. Of course, it, it might branch into some other pieces of code, but I think scoping the technical depth to this one opcodes, is very useful. I think it's important to note, for example, that eliminating an opcode is a very easy software, so if some opcode eventually turns out to be dangerous or bad, it can be disabled. Of course, you don't want to confiscate people's funds But, opcodes have been disabled in, in the past. So as long as we build using opcodes and not-- and try to limit the scope of the opcode to just the context of the opcode, so like you're executing this opcode, you get introspection into the transaction, this, the script, but nothing more, I think, I think it's a very sane way of doing upgrades instead of I don't know, trying to rethink everything, right? Big wholesale" }, { "speaker": "stephan", "time": "01:06:47", "start": 4007.23, "text": "changes, okay. Yeah, yeah. Now, like one of the wholesale changes" }, { "speaker": "stephan_livera", "time": "01:06:50", "start": 4010.71, "text": "people talk about a lot, so sorry to interrupt, is like, simplicity, right? So simplicity would be like, oh, ditch, ditch whole Bitcoin script, replace it with an entirely different language that is very expressive, very safe. Like, I'm obviously a big fan of simplicity, but it's not something That is anywhere remotely similar to upcodes, right? With an upcode, it's like, okay, we add this tiny thing to the language that already exists, it can do this kind of things, and then all the rest just keeps existing and you can combine the upcodes. With Taproot, you change everything So TXHASH, while as an opcode, it's a lot more, it touches a few more things. It doesn't really touch, touch them, but it has more technical depth than CTV. It's still, it's still just an opcode that puts a hash on the stack, you know, or compares a hash with another hash. So The actual scope of how it affects consensus in general is very small, the same with opcodes like CTV, Vault, Optix, Jaxx from Stack, like all these opcodes are very small in, in what they do. Okay." }, { "speaker": "stephan", "time": "01:07:52", "start": 4072.12, "text": "And when it comes to comparing some of the different proposals, right? So this is another area where people are watching some of the discussion and they see almost like these technical wizards who are battling it out about like this particular, you know, people who want CTV or this- There's other people who say, \"No, CTV isn't powerful enough\" or, e-e, et cetera. So if you could just compare for people, is TXHash, i-is it something that you would see as coming after we first have CTV and APO or, or something like that? Or do you see it as like You would actually like to see people be just going straight to TXHash. Do you have any thoughts around that?" }, { "speaker": "stephan_livera", "time": "01:08:32", "start": 4112.89, "text": "yeah, I mean, maybe I can, I can tell a tiny story about how actually I started, I decided to start doing TXHash because, like, I got involved in ARK, I got very interested in ARK and like, okay, ARK needs CTV, was the original story, like, oh, we need CTV, and ARK can work very well with CTV, so I was like, okay, CTV is great, we need CTV, and Notably was, Josie, the Bitcoin Core developer Josie. Yeah. Josie, back. And he was like, \"Yeah, we don't, we don't want CTV, because CTV, it's so limited, it can almost do nothing.\" And I was like, \"Well, it's not true, it can do everything, it can do ARC, it can do many things.\" And then he was like, \"Well, show me.\" And I was like, \"Well, actually, at the time, the month before, I had built some use case, some small" }, { "speaker": "stephan_livera", "time": "01:09:24", "start": 4164.17, "text": "CTV, and I, and I started like coding and I was like, \"Oh, actually, there's some side effects of CTV I didn't really imagine around like fees, and you need to like build a whole more, like a little bit more infrastructure to like accommodate the fact that CTV is so limiting.\" And while usually you can accommodate those things, you need to just think a little bit more further about it and it's like, \"Ah, yeah, actually, he's right. I think something like TXHASH would just have eliminated all this extra thinking I had to do.\" and then I came back to him and I was like, \"Damn, I think I have to, I have to, I have to give you your right, and I think, I think something like TXHASH is actually a lot better than CTV, because it gives you like this more flexibility to not have to think about what, what beyond, and especially fees.\"" }, { "speaker": "stephan", "time": "01:10:02", "start": 4202.43, "text": "Yeah. quick question on that. So for the purposes of ARC, is TXHASH better than CTV?" }, { "speaker": "stephan_livera", "time": "01:10:10", "start": 4210.41, "text": "yeah, I mean, I think definitely even though if we would like, so yeah, there's, there's multiple different ways, right? Arc using CTV is very intuitive in the construction. If you would, you, you can like, like I said, TX hash, if you don't do anything fancy, is exactly the same like CTV. So if you have the X hash, we can do exactly the same simple naive implementation of the arc If you try to optimize the arc and like make it easier to do the fee thing, like you can't do with CTV, then, then you optimize a lot, the-- well, not a lot, but you optimize quite some, the, the arc construction, but you need to do some extra thinking because TXIDs will change, so you need to be a little bit more wary of the construction itself. And I think, if I'm right, you would have to combine it in some way with, CheckSig from Stack to, to create something like a, a PO. So I think just the xHash doesn't allow us to do much more for ARC if we would combine it with something like a signature scheme like CheckSig from Stack, Then, then you can optimize a lot of the, the fee problems that we have. But I think it's fair to say that with CTV, we can do a lot of things with, for Arg. for TXHash, we can optimize, but I think we would, we would prefer to have TXHash with Checksec from Stack to do a little bit more around these" }, { "speaker": "stephan", "time": "01:11:33", "start": 4293.97, "text": "optimizations. So they would be likely bundled together if it were to be sort of put forward, like TXHash plus Checksec from Stack?" }, { "speaker": "stephan_livera", "time": "01:11:42", "start": 4302.22, "text": "I think so. yeah, there's certain use cases, for example, right now that the XHash supports that actually don't make sense in its current form. They only make sense if you would combine it with XEC from Stack. But that's, I don't know, that's how I think upcodes work together. It's like, yeah, you, you shouldn't say this upcode does this use case. It's like, this upcode does a thing, and how you use the thing, you can, you can You can plan these things to be something in, to be useful in the future. You can, you can have use cases in, in your mind right now. but yeah, definitely. I think if we would get- Enthusiasm around activating TXHash, most of that enthusiasm will also, involve see, check sig from stack, very easily." }, { "speaker": "stephan", "time": "01:12:24", "start": 4344.76, "text": "Okay, great. Alright, well, as we wrap up then, any closing thoughts for people and where can people find out more about, your work?" }, { "speaker": "stephan_livera", "time": "01:12:33", "start": 4353.84, "text": "Yeah, so like you said, Covenant's dot info is, the website that I made that summarizes lots of the different covenant proposals and use cases. yeah, personally, you can find me on Rose dot io, but, I'm not very active on Twitter. I try, like, many people, many developers say, like, \"Ah, everything is decided on Twitter. It's where all the discussion happens, it's where all the magic happens.\" I don't really like Twitter, but I try to go on Twitter sometimes to participate. I've had some good and interesting questions and remarks on TXHASH, on Twitter. But yeah, I prefer we just talk on the Delving Bitcoin, forum or over email or over chat. I'm also on IRC. but yeah, I, I really I realize lots of it is happening on Twitter, so you can find me there as well." }, { "speaker": "stephan", "time": "01:13:19", "start": 4399.6, "text": "Great. Okay. Well, thanks very much for joining me and helping explain some Covenant use cases and, chat again sometime soon." }, { "speaker": "stephan_livera", "time": "01:13:27", "start": 4407.25, "text": "Cool, yeah, thanks for having me. See ya!" } ] }