Given the recent discussion on covenants, you might be curious about what actual covenant use cases look like. Joining me today is Steven Roose to help explain covenant uses and TXHASH as well as various objections: 

• Case for Covenants
• Why TXHASH 
• Scope of changes
• Covenants.info
• Covenant use cases
• Ark
• Commercial viability

Links:

• X: @stevenroose3 
• Site: Covenants.info
• TXHASH ML post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html

Sponsors:

• Swan.com (code LIVERA)
• CoinKite.com (code LIVERA)
• Mempool.space

Stephan Livera links:

• Follow me on X: @stephanlivera
• Subscribe to the podcast
• Subscribe to Substack

Podcast Transcription:

Stephan (00:00.748)
Stephen, welcome to the show.

Steven (00:02.951)
Hi, thanks for having me.

Stephan (00:04.768)
So just for people who don’t know you, just a very quick, just give us a quick background on yourself, who are you, and what are you mainly working on these days?

Steven (00:14.666)
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 covenants and use cases. Yeah, so thinking about covenants, working on liquid before.

Stephan (00:40.876)
Great. And I know you are also the man behind covenants.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 involved with TxHash, aren’t you, as well? 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?

Steven (00:59.338)
Yes, yes, yes. Yeah, so the.

Stephan (01:10.836)
for covenants. Do we need them?

Steven (01:14.034)
Yeah, that’s a good question. I actually listened to Brandon Black’s episode and he had a very good explanation of this. But, covenants are kind of like an addition to the things we can do with coins and the expressions we can use to condition the spending of coins. And in some way, we always had some form of covenants because Checksig, the normal signature scheme we use 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 need to do this kind of schemes where things get a little bit more complicated than just broadcasting a transaction in a signature. And covenants are really powerful in allowing us to create these kinds of constructions, right? So when Lightning was created, 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 a second layer, Covenant’s really help us construct those things in like incentive compatible way and like efficient ways. There’s other use cases that are not second layers that are also like using the expressiveness of script to make coins more secure like vaults. So yeah, my case for Covenant is

It’s just making the scripting language more expressive. And it’s not in any way something bad because you’re restricting your own coins, right? Just as 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 you agree to this restriction.

Stephan (03:01.1)
I see. And so I think similar to the episode with Brandon Black, we were talking about this idea of why would I want to restrict the coins? And 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.

Steven (03:23.404)
Exactly.

Stephan (03:29.696)
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 is not because in their minds, they’re thinking, oh, somebody else is gonna try to restrain my coins.

Steven (03:45.07)
Exactly.

Stephan (03:58.208)
Could you just spell out a little bit about how that works? Like, I guess the way I’m thinking about it, and 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, or maybe there’s some kind of Covenant protocol 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 going to 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’s address in this case, right?

Steven (04:31.643)
Yeah.

Steven (04:36.278)
Yeah, 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 all involve two people, it’s pretty easy to think about what can go wrong, like what are the different options you can have?

But when you try to scale beyond two people and you’re thinking about 10, 100, or 1,000, or even million people trying to have a social contract agreement on the chain, things kind of blow up very fast. And that’s where covenants come in. So yeah, one of the use cases is getting into these larger scale construction where you’re actually trading your money for some kind of share in the construction, 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 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 wallet constructs the address and you know exactly what kind of conditions are in that address. So if someone sends you that money.

you’re fully aware of the scope of what the covenants are actually doing and you want these things because otherwise you would just not use them.

Stephan (06:07.404)
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 CheckTemplateVerify. There’s already Anyprevout. There’s now LNhance, which is a new proposal from Brandon. So I’m curious what your view on the, you know.

Steven (06:31.854)
Okay.

Stephan (06:36.085)
Why create TxHash? Where did it come from? And give us a bit of the context there.

Steven (06:40.878)
Cool, yeah, so TXS 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 deaf mailing list conversation. So, I think most people are familiar with CTV, or at least the name CTV, and TXS is actually, the default mode for TXS is exactly like CTV. So, 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 use cases that CTV cannot. And since it’s been talked about for a while, and sometimes it comes up in conversations like, oh, but if you do TxHash, you can do this. But no one ever actually took the time to do the work and implement TxHash. So what I did is I just went from the bib for CTV, extended it.

to make it into TX hash and implemented it for core. We’re still discussing some of the nitty-gritty aspects of how the implementation should be. But yeah, it’s basically a super version of CTV that allows for more things. And also it opens the way to be used together with CheckStick from Stack, where it can emulate or it can very efficiently do things like APO.

for lighting symmetry, like together, DXHash used together with the signature is basically a SIG hash. So some developers might be familiar with SIG hash single, SIG has all, where you can choose which of the outputs you want to include in your signature. And with DXHash, 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.

Stephan (08:41.728)
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

Steven (08:54.478)
Exactly.

Stephan (09:12.208)
sign only this part of the transaction, but leave that other part unsigned, and then maybe in a collaborative context, maybe a coin join 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 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 the previous

Steven (09:25.81)
Exactly. Exactly, exactly.

Steven (09:40.044)
Yes, yes.

Stephan (09:42.004)
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 you can think of TX hash 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 kind of what’s going on here?

Steven (10:03.938)
Mm-hmm. Yes. Yes, exactly that. Exactly, exactly. So yeah, so with the SIG hash, like when you send money to an address, you basically say, 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 SIG hash all, you basically signed 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 CKSH flash called CKSH single where you say, I only care about one output that is the same output on the same index as my input and all the rest, I don’t care. So you can use the signature in any other transaction where the same output is actually the same. And with the XS you can actually choose any of these combinations. You can say, I need these two outputs, these three outputs or I only care about the inputs or I only care about the outputs. And APO.

With APO, you say, I care about 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 of a series of transaction that could be potential states of your channel, for example. And with the Xhash, you can also do APO because you can just say, I select all the outputs, but I don’t select the inputs. It’s just like a more general work. Yeah, exactly.

Stephan (11:19.809)
like a generalized form 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 checksig from stack and what’s the interaction here between TxHash and checksig from stack.

Steven (11:40.67)
Okay, so that’s a good question. Because what’s funny about Bitcoin is it has an opcode that verifies the signature. But 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 check stick, but it only takes a public key, it 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 how to construct a message or how to combine elements from the transaction, create a message and then the private key has to sign this message and the message represents the signature, the transaction. And what CheckStick from Stack is, is basically allowing you to provide the 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 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 100k for a bitcoin and then when the oracle signs this you can use checkstick from stack to actually verify did this oracle sign the message that the current price is 100k. So you can actually specify the message of the signature.

And if you combine this with dx hash, then you can actually use dx hash to pick manually, like we did with the, like I did in the explanation of the SIG hash, 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 SIG hash ideas, if that makes sense.

Stephan (13:28.248)
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 template verifies is one of the simplest possible changes that you could have. Let’s say TX hash 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.

that they don’t want to enable. What’s your thought on that idea of accidentally enabling something that people don’t want?

Steven (13:59.935)
Yeah.

Steven (14:08.118)
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 accepted is that you cannot force anyone to opt into a covenant So like you cannot do the whole government surveillance thing 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 it just never goes into the covenant but there are like some

some concerns about external effects, because if Covenant can enable some kind of incentive games, then everyone’s coins are actually affected, right? If, yeah, yeah. So those are the current, yeah. Yeah, those are the current kind of concerns that people talk about, I think mostly. Like MEV is one of those, but I haven’t actually heard any like concrete examples of how MEV could really like affect Bitcoin that much.

Stephan (14:44.7)
Like, yeah, there could be some kind of negative externality of the particular covenant, yeah.

Steven (15:06.942)
I think most of the fears of MEV come from Ethereum, where MEV 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. Yeah, 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 cannot 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.

Stephan (15:53.228)
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 TX hash on that sort of scope or spectrum of how big the change is to Bitcoin?

Steven (16:36.554)
Yeah, I think conceptually, the scope is pretty limited. It’s like you can…

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 of CTV and the one beauty about CTV is the simplicity, right? So the code for CTV is like 30 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 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 minor or any validator to hash a whole bunch of data and 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 more along 500 lines of code instead of 30 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 nowhere near the scope of SegWit or Taproot or something big like that. But it’s also, it’s arguably a lot bigger than CTV.

Stephan (17:54.16)
Okay. And in comparison with just APO, what would you, how would you compare Tx hash with just APO?

Steven (18:02.482)
I think APO is more along the lines of CTV. Yeah, 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 scope. But what bothers me most about APO and CTV is like, APO is like, we have lightning symmetry in mind, right? People have been talking about L2 for a long time. Actually, APO has changed names a few times along the years. Yeah.

Stephan (18:05.223)
Okay.

Stephan (18:28.668)
Right, it used to be called C cache no input and now it’s called APO and yeah.

Steven (18:32.978)
And then CTV also has changed names. I think it was called security bag or something like that. 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 if we want to like totally think about something new? We cannot really imagine what things we will need. And then if we always have to go and

Stephan (18:36.297)
secure the bag, yeah.

Steven (19:01.678)
create a new, not any prev out, but any output value or something, you know, new stick hash flag just for specific operations, then we just have to keep doing soft works. And 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.

Stephan (19:30.604)
Right, yeah, okay. So, yeah, I think 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 Covenants and your website, covenants.info. So just tell us a little bit of the background there, covenants.info, what are you hoping to achieve there?

Steven (19:52.502)
Yeah, actually, 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 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.

And what we noticed was two things. One is that many of the developers are not really too excited about Covenant. Because many, I think it’s two main reasons. Some of them think it will never happen anyway, so I don’t really have to think about this. And just some of them think I don’t need it for the thing that I’m working on, so I’m not very interested in working on this. And the second thing we realized is that actually no one really has the total scope of all the different proposals, all the different use cases, how they work together. So we were trying to, for the panel,

create a table of the different proposals, the different use cases that we know, which proposals enable which use cases. And even like we were with very experienced developers, some of us were like, I’m not really sure if this really works well, whatever, so then we’re like, okay, so this is not really knowledge that is out there very easily. So then that table that I used for the conference was actually 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 BIP or the implementation or some website that explains the use case, just so you have a central place where you can go from to explore Covenant.

Stephan (21:32.588)
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?

Steven (21:54.922)
Yeah, transaction templating, I think, is the most intuitive or the most straightforward use case. It’s basically replacing the need for presigning transactions, right? So when you do off-chain protocols, both in Lightning or other off-chain protocols, 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 fulfill signatures because you have to do something with conditions. And then you have to…

Stephan (22:21.628)
Right, so there’s a lot of presigning required, right?

Steven (22:23.326)
Yeah, so you pre-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 lots of the needs for these pre-signed transactions so that you can use conditions in the existing script instead of needing to create a transaction yourself and then put a signature on it, which takes a lot more bytes when it’s broadcast, than if you could just say,

Okay, the transaction spent that spent this needs to be this template. Instead of that you say, this will be the transaction and we will sign it. And then the transaction will be bigger and you need to keep the signature, because if you lose the signature, you also lose access 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 useful for many.

many protocols. And it’s basically replacing pre-signed transactions.

Stephan (23:22.841)
Okay, great.

Great. And so that can really simplify certain protocols and maybe make them feasible where previously they were not. 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 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?

Steven (23:33.582)
Exactly.

Steven (23:55.094)
Mm-hmm. If you allow me to go back one more remark on the template thing, so there’s one significant difference because when you presign a transaction, the transaction can always be re-signed, right? And it’s impossible to prove that a key does no longer exist. So it’s impossible to prove that you cannot have an alternative presigned transaction or an alternative signed transaction that can actually replace yours, while if you use a Covenant, you have a 100% guarantee, like okay, the transaction that spends this actually will be this one. And that is…

Stephan (23:55.344)
enabling this.

Stephan (24:00.297)
Yeah, sure.

Steven (24:24.962)
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 will still be there, some risk factors. But we can go to…

Stephan (24:36.444)
Right, so let me 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 presigning, or in some cases, maybe some level of trust that the person has deleted the key. So in a Covenant’s world, where let’s say we had CTV or TX hash or something, we could then, or OpVault in this case, we could have it without the presigning 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 the world we’re in now. And maybe 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.

Steven (25:11.726)
Exactly.

Steven (25:23.55)
Exactly. Yeah, exactly. If you have a really big vault, let’s 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 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 covenant because you say this needs to happen. And if it doesn’t happen, it’s just not consensus value.

Stephan (25:52.488)
Right, 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 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’s 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?

Steven (26:23.122)
To a certain extent, I think. But I think they’re also like, both for CTV and for presigning, 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. We need some other changes to the Bitcoin mempool policy, like fee anchors and stuff like that. That I don’t think, CTV doesn’t solve that for presigns.

Stephan (26:45.514)
Right.

Steven (26:50.082)
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. So, but for both presigning 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 policy.

Stephan (26:57.969)
Interesting. Yeah. Okay.

Stephan (27:09.668)
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, V3 transactions, ephemeral anchors, and then 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 TX hash argument, which is that these protocols would allow the participants to add new fees, which might be useful in a…

Steven (27:18.571)
Yeah.

Steven (27:37.006)
Exactly.

Stephan (27:38.856)
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 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 would not be able to.

Steven (27:53.62)
Exactly.

Steven (27:57.374)
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 page for parents, um, using some kind of fee anchor. Yeah.

Stephan (28:09.34)
Right. So you have to have an extra anchor output, right? That’s like in Lightning where they have anchor outputs to help you like be able to bump, but then there’s a trade off of extra fees because you’re paying more, 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, et cetera, the efficiency conversation.

Steven (28:16.362)
Exactly.

Steven (28:24.43)
Exactly, exactly.

Yeah. So with DXHash, you can just append the fee into the same transaction because the Covenant only covers 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.

Stephan (28:42.176)
God, I think I’m slowly following you. Although this conversation is 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 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?

Steven (29:05.418)
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? And lightning is used a lot, but L2 is just a very, it’s a way simpler way of reasoning about like how your lightning implementation needs to like handle data and transaction constructions and stuff like that. So I think everyone agrees that a, and lightning symmetry enabled lightning would just be better.

But there is, the type of component needed to enable this is not very advanced. I mean, what I’m saying is many of the proposals can 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, TX hash, plus the checkStickFromStack, all, or even without checkStickFromStack, can all somehow enable.

lightning symmetry.

Stephan (30:06.108)
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 just our general process for setting up and operating in a lightning environment. Now, we’ve also got vaults. Now, there is a specific opcode related to vaults, and my understanding is it…

Steven (30:11.422)
Exactly.

Stephan (30:35.392)
can operate on its own, but it’s maybe best to be paired with OpVault plus CheckTemplateVerify, or in this case, it could similarly, like you said, TxHash. So do you wanna just explain a little bit around the vault and what you’re seeing the impact or the use would be there?

Steven (30:53.214)
Yeah, so Lightning Symmetry is like a use case that everyone talks about for covenants, but it’s like more abstract because lightning already exists and just optimize the 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 Bitcoin want something like want their setup to be very secure. And a vault basically allows you to

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 those keys are stolen or 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 vaults, you can actually give some kind of backup clause in the worst case scenario where someone steals some or more of your keys, even with multisig.

If several of the keys are stolen with multisig, you can still lose some of 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 fuck up in any way, you have some backup clause to just recover your money and make sure that the thief cannot take the money. And I think everyone agrees that we want the vaults. And so the opcode opvault 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 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 really want to comment too much on the upvault itself. Personally, I’m from the philosophy that we should create opcodes that

that do small primitives, and then use cases can be built by combining the primitives, right? Just like we use CheckState again. Yeah, yeah. But there is a really good argument to be made if we want to use Taproot, and we want to do something that up-fold does, we need actually a whole bunch of up-codes. So I somehow get the argument that up-folds.

Stephan (32:55.336)
Right, I see. You’d rather not have it like a purpose-built opcode for a one use case thing.

Steven (33:12.018)
It does a very simple thing like add a timeout phase, took some coins to make an unvault phase possible. And if you wanna build this using like a set of more generalized opcodes, you would need several of them. You would need both cat, something like tweak add, you need a covenant like TX hash, you need probably something like opsegment to go around the op success.

loophole otherwise, so it gets a bit complicated, and up-vault is basically, okay, here, I want to build a vault around these coins with this up-code. So I can see both the arguments 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 yeah, it can be up-vault, it can be TX hash plus, some other things.

Stephan (34:08.444)
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?

Steven (34:24.138)
Yeah, cool, like payment pools, I actually really like them because they’re one of the new things, right? Like Lightning exists, faults to some extent can exist with pre-sum transactions, but payment pools are something like quite new, maybe not as an idea, but as like something that might be practical 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 their balances 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 we don’t have to do anything on the chain.

But also anyone can make payments to external parties by taking some money out of the pool, making an unchanged 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 10 people sharing the same UTXO,

All these 10 people need to like co-sign all kinds of stuff. And a covenant can remove or reduce, eliminate a lot of the interactivity that is needed. So that people can actually unilaterally take certain actions in the pool, like taking a share of their money out or something like that, without needing everyone to be online. Right, because if you’re 10 people, let’s say, let’s even consider everyone’s our friends, but if just one person just loses their computer, like some water falls on it or whatever, then…

they cannot call sign and then what happens, the pool is stuck. Now you want the pool to be able to continue without this person. So you need some kind of non-interactive way to kick this person out, give him his money back, and then let the pool continue. And that’s where covenants are needed to create the pools.

Stephan (36:36.916)
I see. And 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 joint 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.

Right, go on.

Steven (37:08.626)
Well, payments within the pool are not on chain, but yeah, you’re right. Like actual payments are on chain because you only transact so much with your friends, you know what I mean? You always have to buy something external. Yeah. So like, yeah, if.

Stephan (37:17.616)
Exactly. But I could imagine, 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.

Steven (37:25.249)
Exactly.

Steven (37:45.066)
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 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 tell you up the debt they owe. And then in the end of the day or in the end of some day, they just settle it. Yeah. And if you can use pools for something like that,

Stephan (38:10.128)
Right, and they just net it off at the end of the day, yeah.

Steven (38:15.25)
That would make a lot of sense. The fact that it’s all very secure, like most layer two solutions have some kind of incentive games, like Lightning has with the revocation, all that stuff. But the payment pool is very simple. Everything is really secure on the chain. Everyone has a one transaction, they’re direct exit. So for 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 implementation where a family can set up a pool so they can all share their savings in a safe way. But yeah, I think the first use cases where the pools are more interesting are large custodians or holders of large amount of coins that actually have to do on-chain transactions.

Stephan (39:05.732)
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, even bigger savings. Although, I mean, you could just say, look, today, some of them just use lightning channels, and they just use lightning between each other, or 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…

Steven (39:14.144)
Exactly.

Stephan (39:33.236)
decide what’s actually useful for them. Now related, and I know you’re also, I guess you’re involved with Arc or I’m not sure how closely you are with the team. Yeah. Yeah, so 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 touch on the Covenant elements of Arc and maybe the TX hash elements of Arc.

Steven (39:42.495)
Uh, yeah, yeah. Yeah, go on, go on.

Steven (40:04.178)
Yeah, OK. 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 own the money collaboratively, and they can reshuffle the money. So they can reshuffle internally, and they can all exit and then continue the pool. And ARC is very different in that sense that in ARC, still some people share UTXO, but only in a fixed set way. You cannot reshuffle anything internally. So like,

You get this like, measure money is divided among some people and then it stays like that. The only thing they can do is they can just give up their parts and they’ll say like, okay, I’m out. And then usually in the ARC protocol, when you go out, you exchange this share for a share in the next construction like this, right? So ARC 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 or 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 state, like you have one Bitcoin, you have two, you have three. And if one person goes out, the remainder of the state needs to live on, on the chain, right? So you need to keep state, which is more complex. But in ARK, 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 the rest doesn’t live on. You eliminate the branches by kind of making a transaction that spends your potential output, so that if you try to cheat and get your money back, even though you were out, someone else can take it before you can take it. So for ARK, it’s a lot simpler, because everything is already set in stone the moment the ARK transaction 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 Lightning where you say like, okay, this old state is no longer valid. I signed some transaction. And if I try to revert the state, you can take my money. The same with ARC. You say, I’m out of this tree. I’m out of this construction. And if I try to still take my money, someone else can take it from me. Yeah, so that’s ARC. So what you would need for ARC, covenant-wise, is more something like a CTV or a DX hash.

Steven (42:29.31)
simply without the CheckStickFromStack feature or without the Vault and the script tweaking features that you need for more complex things. Because everything is already set in stone every time the construction is made.

Stephan (42:43.248)
I see. Oh, okay. I was actually under the impression you needed check seek from stack also for Arc. So you don’t. Okay, so it’s either CTV… Okay, gotcha. So it’s either CTV or TX hash that enables Arc, just on their own. Okay.

Steven (42:50.226)
No, there’s many optimizations we can make. Yeah, yeah, there’s many optimization. Exactly, exactly, exactly. Actually, I really like, there’s a version of ARC possible without covenants that has a little bit of trade-offs, but I think they’re very fair. But yeah, with a very simple covenant like CTV or DX hash, 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 check-sticks from Stagg become useful for us.

Stephan (43:26.192)
Yeah. Now listeners, you can go and check my earlier episode with Barack 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 might 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?

Steven (43:52.53)
Um, well, I could go 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 slide, like, um, 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 ARK 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 the first place and the fact that you can incentivize users to like help the ASP by spending the ARK coins, the VTXOs that require less liquidity to be spent, makes the liquidity problem not so insane as people talk about.

People talk about, oh, the ASP 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 people start using it.

Stephan (44:57.252)
Okay, fair enough. Okay, 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 TX-ASH. What is congestion control? Can you just walk us through just basically how would it work? What does it look like?

Steven (45:19.298)
Yeah, so the plain and simple idea is, let’s say you want to pay 100 people some money and the fees today are really high, right? And you don’t want to do that because you don’t want to make 100 transactions or you don’t want to make one transaction with 100 outputs because it’s very expensive. But you want to give these 100 people a certain guarantee, like, hey, you have this money. Like, I actually sent it to you, it’s yours now, but you just need to do some more work to have it and you can do that work when the fees are lower. So that’s like a 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 trust 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 you say, hey, I’m going to 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 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.

Stephan (46:57.648)
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 the customers, like withdrawal scenario. Is that right or no?

Steven (47:11.486)
Um, yeah, personally, I’m not the most convinced of the actual use because I mean, the drawback of doing this construction is that you have 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 200 sets per V byte and then maybe next week you can pay five sets per V byte.

We’ve seen this happen maybe over really long terms, where suddenly, 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 so, but I’m not sure if in the long term, in a more stable ecosystem, this is gonna be a really big issue. But yeah, you never know. Like 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 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 be happy with that. But still, the total amount of buy, it’s like, imagine the fees don’t go down. Then the total amount of fees you’re gonna pay 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, those situations will arise. But I hope in the long term that the fee market can stabilize a little bit more than it has over the last few years.

Stephan (48:47.136)
I see. And I mean, there will be some people like Pierre Richard, who believes that it is just always going to be volatile, that there will be times where it’s, you know, and if you think it’s going to always be volatile, then maybe the congestion control case actually makes more sense. But if you believe it’s going to, let’s say, eventually stabilize out at some particular level, then maybe not. Maybe it’s not so useful. Interesting, though. OK, so.

Steven (48:55.115)
Yeah.

Steven (48:59.403)
Yeah, yeah.

Stephan (49:17.791)
Yeah, and

Stephan (49:40.66)
How many people are going to be comfortable with that?

Steven (49:40.926)
Yeah. Yeah, that’s true. You could imagine maybe some like… because…

Stephan (49:46.248)
Maybe advanced users for sure, but I don’t know, average users?

Steven (49:50.61)
Yeah, you can imagine some wallet that knows about this, the existence of this construction and you can already sign away. 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 broadcast some stuff and pay some fees. 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 them actually paying the fees before they get the money. It’s like, it cascades a little bit.

Stephan (50:23.644)
Yeah, maybe it’s just too many steps to actually be practical, you know. So best to kind of focus, I guess, on the, and you know, maybe my understanding is wrong here. Maybe there’s somebody else out there who can explain it in a better way. You know, maybe, maybe that’s, that’s where it is at.

Steven (50:27.327)
Yeah.

Steven (50:36.778)
I mean, I mean, the concept of this tree is actually the basis of Arc as well. Right. In, in Arc, like I said, 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 cycle their leaves to be part of something else, and then you can just forget about the whole tree and spend it. So.

Stephan (51:02.91)
into the new set.

Steven (51:06.41)
So 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 idea generally is definitely a useful concept that can be used in, for example, in payment pools, certain extra payment pools, you can also use these kind of trees to pay out people in a more efficient way.

But 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 in that sense, I think it’s a very useful concept. But just to lower your total fee paid, or to push the fees on future users, I don’t personally see it as a very valuable use case.

Stephan (51:56.576)
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?

Steven (52:30.39)
Yeah, that’s a very difficult thing. There’s different arguments on both sides. Some of them I understand, some of them I kind of 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 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 all the softwares existed,

I mean, generally, just building a Lightning network, for example, is a lot of work. It took people two years to actually build their first version. And to then say, like, oh, we’re not going to 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 are not going to build for two years on some use case that they might not even ever use. Because if those primitives would not have existed, Lightning would not have been at all as useful as it is now. It might not even have catched on at all. So

I don’t really like the argument like, oh, build everything first and then we’ll talk about the use case. I think there’s a lot of value in talking about, okay, with this construction, we could do this. And I think many people in the space are able to actually imagine how things would work concretely and say, 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 harder. You can prove that things are possible, but you never know if actually people want to do it.

Um, and there it’s even harder because even if you build already an implementation of a use case using a non-existent not yet existing feature, you can still not prove the man’s. You cannot say like, Oh, now people are using this. What you could do is build something on, for example, liquid where liquid already has covenants and very powerful, uh, covenant, uh, 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 a liquid because they have other objections. You can build use cases on Cygnet, but Cygnet money has no value at all. And then it’s like, okay, like, yeah, it exists on Cygnet, but how can you prove people want it? Like if like 20 people come try it on Cygnet, how many people would try it on Mainnet? I think it’s really hard, but I think there’s still some use cases where it’s very obvious that there is a lot of demand for them. I think vaults would be the biggest one, like.

Steven (54:53.939)
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 JustFaults 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 coins. So I think for some use cases…

like vaults, like lightning symmetry in some way because everyone uses lightning, everyone knows like, oh, it’s annoying that I need to back up my channels. If we could just like make the watch towers more efficient and we don’t need to back up our channels every time you make a transaction, stuff like that, where you actually know, okay, people 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 they can actually make money. Maybe no one will use ARK, maybe no one will use congestion control. Like you cannot know those things.

Stephan (55:47.516)
Yeah, I see. I think I can understand the hesitation from some people where maybe they say, 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 there 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 in 2015 and 16, something like that. 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, 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, let’s, yeah, like whether it’s payment pools or if it’s like an ARC thing, I guess in the ARC context, it’s more like you would be a service user, right? You’re just using some kind of ARC wallet and you have your ASP who’s kind of dealing with the stuff in the background for you.

Steven (56:54.382)
In what way collaborate?

Steven (57:05.099)
Yeah.

Stephan (57:13.34)
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 eyes.

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.

Steven (57:50.221)
Yeah.

Steven (57:55.854)
I think for usage from users, I think it will be a lot like, one use case gets built out, 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, we have this great thing, it’s called multisig descriptors, all this kind of like, BIP-39, BIP-32.

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, 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 descriptors.

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 just stop existing or something like that, it’s going to be easier. And especially the first, the first time many users are going to be exposed with this, it’s just, they’re going to use the same app. They’re going to use the same product. And I think with the, with the covenant use cases like ARG, like payment pools, like vaults, it can be very similar. Like some app will say, okay, we’re building a vault, we’re building ARG and people are going to 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 standards, they standardize certain things, then other people can also write apps and maybe compete or provide backups or provide more advanced controls for certain users. 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 cannot do with other apps. And of course, like it’s not with this app you can do it. It’s more like with this protocol you can do that. But the app, people more have like this feeling of, ah, 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 this new features on users and like make them aware that they exist and how to use them is useful.

Steven (01:00:16.95)
And of course, when a new product or a new protocol has like a business model, it’s going to be a lot easier to create the app and raise money and build 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 think it’s how it’s going to be. Um, yeah.

Stephan (01:00:42.824)
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 Covenant and TxHash?

Steven (01:01:01.162)
Um, yeah, I certainly have, um, like technical debt is very important, right? And SegWit and Taproot have been like changed the world changes where like everything changes like a whole thinking model, a lot of the consensus, like sub uh, protocols change. Um, 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 upcodes, if you don’t like interact with this upcode at all, it doesn’t change. So like in the code that executes all the upcodes, you have like this blob of code that is like this one upcode. Of course it might branch into some other pieces of code, but I think scoping the technical depth to this one upcodes is very useful. I think it’s important to note, for example, that eliminating an upcode is a very easy soft fork. So if some upcode 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 the past. So as long as we build using opcodes 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, the script, but nothing more, I think it’s a very sane way of doing upgrades instead of…

I don’t know, try and rethink everything, right? Yeah. Like one of the wholesale changes people talk about a lot, sorry to interrupt, is like simplicity, right? So simplicity would be like, oh, ditch whole Bitcoin scripts, 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 these kind of things.

Stephan (01:02:28.448)
the big wholesale changes, okay. Yeah, now, yeah. Yeah, go on.

Steven (01:02:57.854)
And then all the rest just keeps existing and you can combine the opcodes. So basically you change everything. So TX hash, while as an opcode, it’s a lot more, it touches a few more things. It doesn’t really touch them, but it has more technical depth in CTV. It’s still just an opcode that puts a hash on the stack, 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, OpVault.

Um, up the X, check, stick from stack, like all these up codes are very small in, in what they do.

Stephan (01:03:33.892)
Okay. 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 there’s other people who say, no, CTV is not powerful enough or et cetera. So if you could just compare for people is TX hash, is it something that you would

Steven (01:03:49.74)
Yeah.

Stephan (01:04:00.24)
see as coming after we first have CTV and APO or something like that? Or do you see it as like, you would actually like to see people be just going straight to TX hash? Do you have any thoughts around that?

Steven (01:04:15.422)
Yeah, I mean maybe I can tell you a tiny story about how actually I started, I decided to start doing TX hash 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 I was talking with several people but one of them notably was Josie, the Bitcoin Core developer Josie.

Stephan (01:04:39.688)
Yep, Josie Bake, yeah.

Steven (01:04:40.318)
And he was like, yeah, 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 use case on Liquid using one of the old fashioned covenants where you used cat plus checkstick from stack to like hack a covenant together. And I was like, oh, I recently built a covenant. I will show you how easy it is to build it with CTV. 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. It’s like, ah, yeah, actually he’s right. I think something like DXHash would just have eliminated all this extra thinking I had to do. And then I came back to him and I was like, damn man, I think I have to give you a ride. And I think something like DXHash is actually a lot better than CTV.

Because it gives you like this more flexibility to not have to think about what beyond and especially fees.

Stephan (01:05:44.968)
Yeah, quick question on that. So for the purposes of ARK, is TX hash better than CTV?

Steven (01:05:52.966)
Yeah, I mean, I think definitely even though if we would like, so yeah, there’s multiple different ways, right? Arc using CTV is very intuitive in the construction. If you would, you can, like I said, the X 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 make it easier to do the fee thing, like you cannot do with CTV, then you optimize a lot. Well, not a lot, but you optimize quite some, the ARC construction. But you need to do some extra thinking because DXIDs 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 checks it from stack to…

to create something like APO. So I think just TxHash doesn’t allow us to do much more for Arc. If we would combine it with something like a signature scheme, like CheckSync from Stack, then you can optimize a lot of the fee problems that we have. But I think it’s fair to say that with CTV, we can do a lot of things for Arc. For TxHash, we can optimize, but I think we would prefer to have TxHash with CheckSync from Stack to do a little bit more.

around these optimizations.

Stephan (01:07:16.172)
I see. So they would be likely bundled together if it were to be sort of put forward, like TX-ASH plus check seek from stack.

Steven (01:07:24.754)
I think so. Yeah, there’s certain use cases, for example, right now that the XH supports, that actually don’t make sense in its current form. They only make sense if you would combine it with Checksic from Stack. But that’s, I don’t know, that’s how I think up codes work together. It’s like, yeah, you shouldn’t say this up code does this use cases. Like this up code does a thing. And how you use a thing, you can plan these things to be something to be useful in the future. You can have use cases in your mind right now.

But yeah, definitely. I think if we would get enthusiasm around activating TX hash, most of that enthusiasm will also involve C checkstick from stack very easily.

Stephan (01:08:07.316)
Okay, great. All right, well, as we wrap up then, any closing thoughts for people and where can people find out more about your work?

Steven (01:08:16.382)
Yeah, so like you said, covenants.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 rules.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 realize lots of it is happening on Twitter. So you can find me there as well.

Stephan (01:09:02.196)
Great. OK. Well, thanks very much for joining me and helping explain some Covenant use cases. And chat again sometime soon.

Steven (01:09:09.826)
Cool, yeah, thanks for having me. See ya.

Stephan (01:09:13.568)
Okay, just give it a sec.