Sigbash: Covenant-Like Policies on Bitcoin Without a Soft Fork

We're looking at the wrong place for demand for covenants when we say, "Oh, there's no real demand for covenants." Nobody-- well, I don't think there's much demand for covenants per se, because you have to start explaining to most people outside of the Bitcoin ecosystem what covenants mean. But if you explain what they enable, things like vaults, things like spending limits, things like address blacklists to make sure that your coins don't get sent off to the Lazarus group, there's pretty high demand for that.

Hi everyone, and welcome back to Stephan Livera podcast. Today we are chatting with Afshin, who many of you may also know online from Bitcoin Twitter or Bitcoin X as Arbedout. Now, Afshin has been doing some work on what's called SigBash, and I guess it's this promise of could we have covenant-like conditions without actually bringing in a soft fork to Bitcoin? And would this allow us to do things like have spending limits or amount limits or address whitelists or time delays? and perhaps in increase certain levels of privacy in the ecosystem, and so Ashin has been working on Bitcoin engineering for a while, he's been around, and, yeah, I'm excited to chat. Ashin, welcome to the show.

Thanks for having me, Stefan.

So let's start with the big picture. What was the problem that you were really trying to solve when you started building SigBash? And maybe just give us a bit of your overview on the current state of Bitcoin self-custody, Bitcoin security.

Sure. So the problem in general Saw was, I became really excited about all the different things we can do with Bitcoin multisig. There are all these sorts of different constructions we have, things like way back in the day federated sidechains from, Blockstream. There's Lightning, of course, which is the canonical two of two multisig with hash lock time contracts. There's all the new things you can do with ARC and there are all the different two of three multisig constructions powering things like AnchorWatch, Unchained, lending and insurance, vaults, that type of thing. I think that's all very interesting, but I noticed a problem as I was setting up my own vaults, which is that when you want to invite someone into your multisig swarm, you're basically sharing your entire transaction history with them as well as your account balance by design. and I was wondering if there's any way we could sort of address that problem. And I went down a bit of a rabbit hole trying to solve it for the past, gosh, two and a half years now, and the current version of SigBash is what I came up with.

Basic idea was, the premise is based on an academic paper that came out about two years ago, titled Concurrently Secure Blind Schnorr Signatures, I think I'm remembering that right off the top of my head. And the gist of it is, instead of sharing your transaction data with another person in your multisig or another signer, can you provide them with a zero-knowledge proof that convinces them to give you, give you your, their signature share? And I think we managed to crack it. There were all sorts of problems with the initial academic- Dynamic paper, things like, well, you might be hiding your transaction details, but you're still sharing your policy details. So that was one issue we had to solve. Then there's, well, okay, you are able to hide your transaction details, but the signer can track you after the fact, and we managed to solve that as well.

And so just for listeners who are following along, make sure everyone's following along, what we're talking about when you say policy, what we're talking about there, I presume, is things like rate limiting or spending limits or Address whitelisting or this kind of thing where you are allowing a greater level or fine-grained level or fine-tuned level of control in the transaction that we are signing. Right, in Bitcoin, we have inputs and outputs, and I guess- Can you elaborate a bit on that, that additional level of control that's permitted or permissible under this new SigBash approach?

Sure. So let's talk about what's permissible right now on chain. So we're sort of limited without a software by what we can do with Bitcoin Script. We can do things like lock coins for a certain amount of time. And we can lock coins based on the number of signatures, and that's pretty much it. If we want any more complicated instructions that, we're gonna need a software to enable some form of covenants. So there are different approaches to try to get around that roadblock, the, the issue of having to coordinate software. There's, see, Robin Lin has his work on BinoHash, there's what the Alkinet team is doing with Pipes, and Both of those models are, they work on-chain, even though there's no soft fork required to, get them working. You're-- they've, they've, they've been able to find a way to actually enforce spending conditions on-chain. SigBash is a different flow. It's off-chain. The commitment is between you and the signer. So you're really sort of trusting the signer to- Abide by their promise, but the signer doesn't actually know what promise they're abiding by. You can define these complicated policies, the signer only sees a compact 32 byte hash, and when signing time comes, you submit a policy proof to them, convincing them that your policy matches up to the original specified hash. Now, what that policy can be is, because we're not limited by script, it can be as complex as you would like, it can be as simple as just sign after this date. It can be complex as if this then that, if this signature then that amount, if this other signature then these whitelist or blacklist or whatever. digging under the hood, the way it works is the policies are all encoded in this thing I'm calling a poet, a policy operand expression tree. It's a Boolean abstract syntax tree. This might get pretty technical, so bear with me. The idea is, I hit on, is, well, if we include all the different logical operators, all the logical gates that we have from Boolean algebra, things like and, or, XOR, not, if and only if, and if we include all the properties in a The PSBT file, a partially signed Bitcoin transaction, then we don't have to worry about complicated covenant designs or anything like that. We can say with authority that we have the ability to define arbitrary spending policies, because we have every logical way to address them, and we have every property in the PSBT. What that means is that no matter how arbitrary your policy, how complex it is, we have the ability to define it and condense it into a single thirty-two byte hash. And when you want to actually prove that you've passed the policy, all you have to do is submit a zero-knowledge proof that one leaf in that hash has-- the conditions have been met.

And so, as I'm understanding from you, this means, let's say we set up a SigBash Set up together or you or let's say you set up a SigBash setup, what we're talking about here is the co-signer is gonna look at, the, the zero knowledge proof to say the transaction you have signed and the, the zero knowledge proof you've made, I guess, it, it satisfies the initial policy, that we init- that you initially constructed upfront and therefore allow or don't allow. Is that, have I got it right there? Yeah. Oh, I just, in terms of what can be specifically allowed or not. So, I guess things like transaction amounts, transaction destination, like the address destination, I guess many of these things can be encoded using- Boolean logic in a poet, right?

Yeah, that's correct. We really want to avoid the, the oracle problem, the idea that the signer is somehow has some knowledge of the source of truth that the, that the person asking for the transaction being signed doesn't. So All of the things that we can address, things like amounts and inputs and outputs, they have to be in the PSBT. They have to be in the transaction file that we both agree is the source of truth. That's the only limit that we have. So we can do amount, input amounts, output amounts, address whitelists, address blacklists, you can do RBF status, anything that you can reference in a PSBT file.

I, I guess the other aspect of it is oblivious signing. So can you just tell us or explain for us what is oblivious signing?

So one of the nice things about coming up with your own sign-on technology is you get to name things yourself. The first version of SigBash used Blinded xpubs, and the idea behind blinded xpubs is, well, I'll give you an xpub, a master xpub, and you'll derive a random child xpub, and I won't know anything about that xpub until you come to sign it. And one of the many problems with that model, first off, you have privacy until you actually need a transaction signed, which isn't a very useful construction. The other problem was that when I was trying to explain it to people, because it has the word blinded in the name, everyone would ask, "Well, so this is blind signing?" and we assumed it had something to do with blind signing, and it's not blind signing at all. What I wanted to convey with Oblivious Signing, I borrowed the name sort of from technologies like Oblivious HDP and Oblivious DNS, where the idea is the server is satisfying a request without actually knowing anything about the request. This is the same idea. It's a combination of blind signing on the server, but gated by a zero-knowledge proof. So it's not full blind signing in that the signer isn't just willy-nilly handing out signatures. The signer has to be satisfied that the policy has been actually matched before providing signature share.

And as I understand this, there's some zero knowledge proofs going on here, and so the user has to-- it's not just a one time setup thing, it's an every transaction thing. And then, I guess what you're-- as I understand, you tell me if I'm getting this correct, every time you go to sign, your phone or your computer is having to create a zero knowledge proof and then show that to the co-signer, and the co-signer, let's say it's a SigBash co-signing server, in as an example. That server is checking, is this valid with what we initially agreed up front or no? And then that's kind of where the zero knowledge, and the Wasm part comes in. Can you just elaborate a bit on that for us? Sure,

that's broad strokes, that's all correct. So, a couple of things, you don't actually have to do anything on your side. It's all transparent to the user. The zero knowledge proof is constructed in your browser in WebAssembly. The reason it's done WebAssembly is that the zero knowledge proof math is actually extraordinarily complex. It's not something you can do in JavaScript or TypeScript without, you know, causing your laptop to burst into flames. So you really have a couple of options. Either we write a native app, and now suddenly everyone has to download iOS and Apple apps and Android and get it working on their machine. And my experience has been that adds sort of two layers of difficulty for users, where now they have this whole separate app they have to manage as part of their signing flow. WebAssembly allows us to just have this incredibly complex logic that just happens in the background in your browser Tab that you don't know anything about. Every time you want a transaction signed, yes, you have to generate a zero knowledge proof and the server has to verify it. But under the hood, you don't see any of that happening. You're just uploading a PSBT file to be signed. The WASM hat parses it, checks for transaction suitability, make sure it matches the policy, submits the zk proof on your behalf, and you get a signed transaction back.

And so just on the PSBT side of it, I guess as you're saying, this is all just valid with Bitcoin hardware wallets today, And this already no changes needed, correct?

That's correct. That was actually an explicit design goal. The one limitation is you have to support Taproot. That's pretty much all we're asking. Got it. Okay. Under the hood, we're using mUZIK2, but you don't know anything about that. What's actually-- This is the neat trick about how we don't actually know anything about your key. One side of a key is generated in your browser, the other side is derived from our server key. They're aggregated into a third key via mUZIK2 We don't know anything about it, all we know is our signature share. So come signing time, you just have this, this xPub that looks like any other Taproot key, you add it to your multisig worm, and when you want your PSBT signed, you submit that PSBT to us, and we add our signature to it.

Just one other point, coming back to the oblivious signing concept, just to spell that out a little bit. I mean, you tell me, but my presumption is you're also trying to help avoid future, let's say, regulatory Clamp down or capture risks on a certain individuals who are, let's say, they are running a SigBash co-signing server, because now they can legitimately say, "Hey, yes, Mr. Regulator, I actually don't know what I'm signing." Rather than, we're in a world where if increasing kind of K-KYC sanctions, AML, BSA, kind of noose is tightening, they may start clamping down on what exactly a partner or service provider can sign for their

customers, right? I don't wanna speak for anyone else, I'm not a lawyer, and I don't want to offer anything that sounds like legal advice, but my personal opinion is, if you can see the transaction contents and you see the amounts and destinations, you're a little bit closer to- To a fiduciary than you need to be. And for a lot of business models, that might be fine, you know, maybe you want to have that level of control and awareness of your transactions. But I think if you see all the transaction data, there are a lot of use cases that are sort of closed off. It's much easier, both not just from a regulatory perspective, but from a privacy perspective, if you're completely arm's length and know nothing about it, it sort of demotes the signer from being judge, jury, executor, executioner, and fiduciary to just a not You know, just stamping a transaction saying, "Yep, this looks right to me."

And even setting aside the regulator, the state concern, there's also just a general privacy concern because if you are running a centralized co-signing server, that can itself become something that people wanna hack and find out, "Hey, what are these customers? How many coins do they have? Where are they sending the coins?" I mean, obviously, this is a big thing on the news, in Bitcoin and crypto circles, we're seeing, we're hearing about, you know, these kidnappings and things like And all around the world, that even just setting aside the regulator part of it, just the privacy aspect of it might be interesting, in a practical sense, and then I guess ideologically, maybe you could argue there's a bit more of a cyberpunk ethos to this technology and use of Bitcoin this way, in theory.

Absolutely, that's, that was also an explicit design goal. If, again, it's one thing if you and your counterparty are sharing each other's financial details with each other, you know, because you're in a relationship together, but if you've got another person in your multisig form who's just serving as sort of backup keyholder, why are you sharing all your details with them? The concern, especially with, you know, the typical five dollar wrench attack, is you've got someone else in your quorum, you're just shooting off your transaction graph to them, they're storing it in their database, doing nothing else with it, and then eventually someone compromises them, they find out your details, and they go tracking you down.

Let's talk a little bit about What this might look like in practice. So, you know, we've spoken a bit about in theory the technical aspects of it, but can you walk us through some examples of a setup that was not previously possible without, you know, without SigBash? And that is now possible with SigBash, like as an example, are we talking, user can have a mobile key and actually he can have a, it's actually under the hood, it's actually a two of two SigBash, and it, it gives them more kind of security under the hood with policy limits, or is it more like you have a two of three where maybe the third signer is actually a SigBash co-signer, and it's you and your business partner or something? Like, can you talk us through some examples just to make it tangible for us?

Sure. So let's go through two of them. You've given two great examples, and I'll go through the sort of pros and cons of each, let's say. So a typical example is, the existing sort of inheritance protocol where you've got a two of three where there's the ancestor, the parents, the heirs, the children, and then the third person is an attorney, and the parents wanna pass their coins on to the children, right? That all works great, but you're depending on a couple of things with the attorney in this scenario. You're depending on them following the law, you're depending on them not colluding with the heir. And you're depending on them not doing anything that you wouldn't want them to do, that's specified in whatever trust agreement you've set up with them. You're basically, you've introduced this trusted third party into your inheritance protocol. With SigBash, you can get rid, rid of that attorney completely if you want. You can set up a key that only signs transactions after a certain date or certain amounts to the trust address, and you can hand that to your heirs as well and say, "If I'm gone, here's your key, which you sign right as threshin', and here's the I don't have to be involved in this at all. There doesn't have to be some trusted third party that you have to direct the course of things to have. Just know that in case of emergency break glass and this is your way to do it.

Got it. And just, I guess, a little proviso there is that the SigBash server is still operating, right? That it is maybe a provider or someone somewhere is still running that SigBash co-signing server, otherwise, that, that, that in that scenario is also

SOL, right? Yeah, that's the one thing. Yeah signer to exist. So because the signer doesn't know anything about the transaction and doesn't know anything about the policy, there's no way for it to collude with your error or to misbehave. So as long as we're online. So how do you deal with that incentive problem? Well, that's the only way the server gets paid. Now, the-- you require, you don't set up a contract or anything like that. You make sure that the server has an incentive, just like a miner, to collect its fee.

Yeah. And so do you envision a world where SigBash

It goes, of the world or the unchained capitals of the world.

Yeah, I do. I think anyone who's running an existing multisig coin setup that requires a third key should be asking themselves, "Well, why am I collecting all this data now? Why do I have this sort of..." These, gigabytes and gigabytes of basically a honeypot, a five dollar wrench attack waiting to happen, when I could be signing things this way. there's a lot of interesting things you can do with two or three multisigs, but they all sort of require, require user discretion. and we've become accustomed to it being that way. It doesn't have to be that way. We don't have to be asking these third parties for permission. We can just treat them as sort of, you know Dumb computers that are just doing the job of signing transactions in the, humming along in the background. So yeah, I could see BICO, Coinbase, anyone who's actually using an existing multisig signer setup just switching over to this seamlessly.

Yeah, and then maybe there's like an insurance use case, like, I don't know, like an anchor watch kind of thing, like other, or even, maybe escrow, maybe some of these lending, the collateralization, companies as well for the lo-- on the loan side, not just the vault side. I guess all of these might potentially wanna do some kind of sigbhash, like if, assuming adoption, right?

Yeah, these are all things we're actively exploring. It's actually pretty interesting because you can make the case for an insurance Probably lowers your risk premium because you have absolute certainty that you're not even-- you're not worried about the key being compromised because even if it is, you can only sign transactions that match the predefined policy. You can make the case that it drops lending rates for the same reason. So there's actually a value add there for both those business models.

Now in terms of, I guess griefing, can the server just not sign the thing that you want? Right? I mean, it comes back to what you were saying about the liveness requirement, but in terms of understanding the, the, the security Is it just that you need to, like, put it this way, can you still have some kind of unilateral exit if the, if the co-signing, if the SigBash co-signing server doesn't sign when you need it?

So you need to design that into your multisig worm just as you would before. obviously the, the server can go offline. It can't do so intelligently. It can't know anything about your transaction and say, "Oh, I don't like this address, I've decided I'm not gonna sign it," or "Oh, I don't, It can fail, because that's the same thing as having a service outage. My ideal scenario is a combination of this as the happy path of signing, and then the backup would be some form of covenants, whether it's a covenant soft fork, whether it's zero hash, whether it's types, whether it's something else. So the idea is you have, in a perfect world, I would have, nested music too, so you have a bunch of different keys all looking as one key signing happily, as long as everyone behaves, that's just Fine, and then you have the insurance in the background, the fallback is some sort of covenant.

Now, we were, we kind of started some of this thread a few steps back about use cases. So we spoke about the multisig, like a two of three or maybe a three of five use case where one of the signers or multiple signers are actually a SigBash co-signer. What about, let's say, the mobile wallet replacement? So is that also a possibility? One of the arguments I have heard from people is this notion of, the reason some people don't wanna self-custody is because they're worried that they, they would rather, you know, offload that work to a professional. Maybe in the future there's a possibility where you have like a phone wallet, but it also has a SigBash co-signer kind of supporting you in some way. Now maybe there's a parallel to, I know the, maybe this is a few years back But Blockstream Green had like a two of two, sorry, a, a two of two signing, thing where like Blockstream as a server would help the user, this kind of thing. So could you maybe imagine for us or spell out what that might look like if the user is-- We're just talking about like a typical mobile hot wallet use case, where The sigbhash co-signing server is helping them. What would that look like?

Well, under the hood, for the user experience, it would look exactly the same as a normal custodial wallet. The only difference is it's sort of between, I can't Say that it's non-custodial, but I also can't say it's custodial either, because custodial to me means the server has enough key information to actually move funds or take them away from you in some way. We don't, we don't actually see your side of the use of two key, the signature share, we can't do any signing on your behalf, but again, we can go offline so we can deprive you of funds that way. Under the hood, it's just a key. It's a key that you can't export the seed to, and that's an important trade-off to be aware of. But in return, what you get from that is you're not, you don't have any seed material on your phone. You have the confidence that the server is actually handling the keys in the background and that you won't have any transactions sent on your behalf that don't match policies that you've already defined and agreed to.

So in practice, it could be that People might, you know, onboard to a service and, I mean, I'm just kinda spitballing, here's an idea, right? Like maybe the Neo banks, the Bitcoin Neo banks of the future, instead of having a custodial account, would have a SigBash based wallet for that user, and he could have like one of the keys, and whether it's, I don't know, Strike or River or whoever else Could actually be a SigBash co-signing server. And so then that user now holds one of the two keys and Strike or River or whoever holds the other key. And then maybe they would have like policy limits of, okay, you can't spend more than zero point one BTC per day or whatever number makes sense, point o one or whatever, and then That would be a way to sort of rate limit or stop, you know, five dollar rent attacks and still, while still having accessibility, I guess in theory, to being able to spend your coins. Would that make sense or no? What do you think about that?

You know, it wasn't a design goal when I was first setting this up because I'm personally focused on self custody. I'm a big cold card maxi, and I believe in holding your seed phrase at home. But as I spoke more and more to users, I'm noticing just how many people rely on custodial solutions. I would say this is strictly better than a purely custodial solution in, insofar as first, I'm presuming that all the other custodial solutions, they actually are aware of your keys and are holding all the key material they need to move funds on your behalf, so you've given up your privacy completely to them. You've given them the ability to transfer funds if they decide to misbehave, to rug pull you. I have a little bit of caution recommending This because, you know, not your keys, not your coins, but I'll immediately back that up with, it's, they're not our keys either. We just have one piece of the signature share, so they're not our coins either, at least.

Now,

to

be fair, in that scenario, you would still have to really think about redundancy and backups, right? So let's say the NeoBank, the Bitcoin NeoBank with a co-sign, with a SigBash co-signing server, they still gotta wonder what happens if my user loses his phone or something like that, right? Or maybe they would have, they would have to then do like Google Drive or Apple iCloud backup, and, you know, now we're in another whole world of like, what's happening with the user part of that key?

Yeah, so we have different ways of dealing

Be as simple as keeping track of your passkey. We have an offline recovery kit, so you can print out a nice little QR code and scan it if you need to. But ultimately, yeah, it's all just a different set of trade-offs. We can't really get rid of the idea completely of someone being responsible for key material.

So, I guess just to understand, like, you put out, you know, your research and your code on this SigBash, are you also going to set up a, a service on this? Like, is it gonna be a for-profit company as well,

The plan

there. So I guess this is a product announcement, huh? so I went back and forth with talking to different people and trying to understand. My main goal was honestly to make sure it got used, to make sure that, I think it's incredibly useful and I wanna make sure that we're not relying on custodial solutions or giving up our privacy just 'cause it's convenient. So what I've settled on now, and I sort of have hinted at this before, but this is me committing to it. There's two pieces of this. There's the web app. You can I'm gonna try to keep that for free, running as long as I can as a public service to Bitcoiners. If you are cleant enough to be setting up your own multisig forms and setting up your own policy, go ahead. There's no charge, there's no upsell, there's no nothing. It's my gift to the community. What I've found is that there are all sorts of businesses, Bitcoin businesses, who are interested in this technology, who need guarantees, thing, contracts, like SLAs and things they can deal with. So it can't be-- So the business side of it will be the SDK and integrating with businesses and individuals get the free web app. It's all the same technology under the hood.

Interesting.

And so,

I guess the idea is, yeah, so coming back to what you were saying, this is like covenants without covenants on chain. You know, as opcodes specifically, I mean, there's a lot of, you know, debate and discussion about some of these ideas whether it's, I don't know, CTV or template hash or TX hash, whatever. One other thing, can you explain the difference between SigBash? Pipes and binohash or binohash, just for people to understand.

I think we touched on it earlier, but the basic idea is binohash and pipes are an attempt to get around the lack of a covenant opcode by doing all sorts of interesting tricks. I think pipes is actually probably, binohash seems more like a mad science experiment, pipes is actually, they're getting towards something that's more in production, but it's all the same thing, trying to enforce covenant restrictions on-chain. Sigbash is off-chain. So the difference is the model. It's on-chain and forced by consensus and everyone running their nodes versus off-chain and just sort of an agreement between you and the signer. That's why I prefer SigBash in the happy path and then pipes or Covenant opcode as the fallback, enforcing and making sure the signer doesn't misbehave. Theoretically, there's nothing stopping the signer from misbehaving, but because it's powered by zero-knowledge proofs, the only really way you can misbehave is either by flipping a coin or by going offline. You can't actually look at a transaction and decide, "Well, now I've decided to be a bad actor."

Okay, yeah. So I'm just trying to, yeah, 'cause it's like, I, to be honest, I still haven't really got my head around the kind of sigbhash versus pipes versus bin hash, but

I guess- But I want to talk to you on policy, and we can actually lay out a concrete example, 'cause it might be useful for- Yeah, maybe, maybe

you can talk us through an example there.

Sure. Okay, so let's say,

There's a parent, a child, and a third key, and the third key is SigBash enforcing, let's say, you can only spend after this date, and you can only send coins to this approved address, where the address is for trust disbursement. Alright, on-chain, that, ideally, in a perfect world, we can actually use NestedMuse2 to make that all look like one key, and that's our, our, key path spend in Taproot. Script path spend would be pipes. Saying, okay, well, you can only spend-- it's the same conditions defined, but it's actually defined in script and enforced by consensus. It's not defined in script, but the way Pipes is doing it with, because script would require-- This

witness encryption idea, yeah. So as I, I was, you know, trying to research a bit, so I guess the simple-- I guess the simple way I'm understanding then is SigBash is like a policy co-signer, you're committing to certain spending rules off-chain and you prove it in zero-knowledge, and the,

Or that's the oblivious signing part. And in pipes, it's like this idea of witness encryption locking a private key behind a cryptographic condition, but it's like very expensive and kind of Maybe has other practicality concerns, but it's not a server that you are relying to be online and honest.

Correct. You're relying more on consensus to, to take care of things.

I see. Yeah, I guess, research, directions that we're seeing. And then I guess, as you were saying, the idea might be You know, one of the arguments we've heard, like just over the years, is people have said, "Oh, maybe we don't need covenants because there's not that much market demand for it." So I guess maybe SigBash is a way to prove out some more market demand for this kind of thing. And I've seen different arguments back and forth because some people will say, "Hey, covenants don't really, you know, they're not helping that much or, you know, they're not that desired." And then on the other side, we're seeing people who say The guys in the industry, they really would make use of some of these things, whether it's kind of like an Op Vault or something like that, like, I think nowadays James Ob sees it more like Op, CTV is kind of like a successor to Op Vault, and people kind of play around with other ideas of like CTV or TX hash or what kind of vaults could be enabled there. but I guess let me put that into a question for you. Do you see SigBash as proving out commercial demand for? Further covenants in Bitcoin.

I think we're looking at the wrong place for demand for covenants when we say, "Oh, there's no real demand for covenants." Nobody, well, I don't think there's much demand for covenants per se, because you have to start explaining to most people outside of the Bitcoin ecosystem what covenants mean. But if you explain what they enable, things like vaults, things like spending limits, things like address blacklists to make sure that your coins don't get sent off to the Lazarus group, there's pretty high demand for that I'm hoping that we can use things like SigBash, things like Pipes, things like NanoHash to prove out all the different things you can build with vaults, sorry, with covenants, and the ways we can actually provide benefits to users. I think part of the deadlock on covenants is not necessarily the idea that there's no demand for them, but what the demand space looks like, what the sort of opportunities are available, 'cause everyone who wants to build things with covenants seems to have different goals, 'cause there's so many different things you can do with them. You can build all these sort of interesting layer two constructions that you couldn't before, but you can also build all sorts of interesting cold storage solutions that you couldn't build before. And I think there's a tension in the design space between all these different proposals. So Sigbash helps break that deadlock. I'm looking forward to seeing what different things people can build on top of it. I'll be announcing different companies that are actually working on the SDK now. Right now, I could say that there are all sorts of different use cases. There's not one, one thing that people settle on. There's all sorts of different things that hopefully people would like to do with covenants, but can't now 'cause they're not available.

And so, yeah, as you said, there are different- Camps or different, users who are trying to do different things, right? Like, 'cause there'll be those who are really focused on the off-chain scaling, and then they're looking at, "Oh, what can Covenant do for Ark and Spark and, you know, other, you know, time out trees and other ideas on that side?" And then you've got the people who are more focused on the self-custody component, and they're more like, "About, hey, what, where can we do something on Vault? Where can we maybe make..." And they, their concern And then maybe even another area is just like mining decentralization. Like some of the people are saying, "Well, if you had covenants, then maybe you could get more decentralization at the pool level with payouts, and maybe that's like another whole area." I haven't even gone down that rabbit hole. You give me some homework to do when I get out of here. Well, I, yeah, I think it's like a small thing of like, one of the reasons why p2pool, was, p2pool v1 was a bit hard to do because there was a, there's a max in the number of, I think Coinbase,

Outputs. And so I think that was like one of the re-- and so some people have made covenant arguments on that basis. there is P2Pool v2 as well, so I did an episode with Jongli on that, but anyway, that-- I, it's just, it's one of the ideas. Yeah, okay. So I think we've covered kind of the key points, just to kind of give people a quick overview. Where can people go if they wanna get more information on SigBash?

Sure, go to www.sigbash.com, set up a key. Like I said, the individual web app version is completely free, play around with it, try on Signet first if you're not comfortable, otherwise, feel free to go for a mainnet key. Set up a signing policy as complex as you would like. We've got a cute little Claude front end if you wanna just type in natural language and have it spit out a policy that you can import into any wallet that supports Taproot. Give it a go and let us know what you think.

Fantastic. Well, yeah, listeners, check it Research, I mean, some people like to say, "Hey, Bitcoin is dead, nothing's happening," but there is research. There's, you know, there's SigBash, there's Pipes, there's this, but BeNoHash, and there's, you know, there is work going on. so it's, you know, that it's time for people who wanna try to improve either self-custody or security to take a look. So, yeah, thanks for joining me, and I hope to chat again soon.

All right, thanks for having me