In this episode, Stephan sits down with Arbedout to explore one of the most debated technical topics in Bitcoin today: covenants, vaults, and the future of Bitcoin custody infrastructure.
They discuss why many people may be misunderstanding where the real demand for covenants comes from, and how covenant-related features could improve Bitcoin self-custody through vaults, spending limits, recovery mechanisms, and more secure long-term storage setups.
The conversation also explores Bitcoin adoption, conviction, long-term store of value dynamics, and the psychological challenges of holding Bitcoin through volatility.
Timestamp:
(00:00) – The privacy problem with co-signing today
(03:25) – What does Sigbash allow us to do?
(08:15) – What is Oblivious Signing?
(12:20) – Privacy, Regulation, and Reducing Multisig Honeypot Risks
(15:10) – What does Sigbash use look like in practice? Inheritance, Vaults, and Multisig
(19:50) – Can the server grief the user?
(21:10) – Mobile Wallets, Assisted Self-Custody, and NeoBank Possibilities
(25:50) – Sigbash project and product
(28:29) – Sigbash vs PIPES vs BinoHash Explained
(33:01) – Covenant Demand, Bitcoin Security, and the Future of Self-Custody
(36:33) – Closing Thoughts
Links:
Stephan Livera links:
- Follow me on X: @stephanlivera
- Subscribe to the podcast
- Subscribe to Substack
Transcript:
Stephan Livera (00:00.431)
Hi everyone and welcome back to Stephan Livera podcast. Today we are chatting with Afsheen who many of you may also know online from Bitcoin Twitter or Bitcoin X as Arbdout. Now Afsheen 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 increase certain levels of privacy in the ecosystem. so Afsheen has been working on Bitcoin engineering for a while. He’s been around and yeah, I’m excited to chat. Afsheen, welcome to the show.
@arbed_out (00:46.382)
Thanks for having me, Stephan.
Stephan Livera (00:49.221)
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.
@arbed_out (00:51.566)
All right.
@arbed_out (01:04.11)
Sure. So the problem in general I was trying to solve 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, course, which is the canonical two-of-two multisig with hashed lock time contracts. There’s all the new things you can do with ARK, and there are all the different two-of-three multisig constructions powered
powering things like Anchor Watch, 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 Quorum, 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. The basic idea was the premise is based on an academic paper that came out about two years ago.
titled concurrently secure blind and snore 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 multi-sig quorum, another signer, can you provide them with a zero-knowledge proof that convinces them to give you their signature share? And I think we managed to crack it. There were all sorts of problems with the initial academic 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.
Stephan Livera (03:00.107)
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 additional level of control that’s permitted or permissible under this new Sigbash approach?
@arbed_out (03:36.216)
Sure, so let’s talk about what’s permissible right now on-chain. So we’re sort of limited without a soft fork 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 to that, we’re going to need a soft fork to enable some form of covenants.
So there are different approaches to try to get around that roadblock. The issue of having to coordinate a soft fork. There’s, see, Robin Lines’ work on BinoHash. There’s what the Allocanit team is doing with pipes. both of those models are, they work on-chain, even though there’s no soft fork required to get them working.
they’ve been able to find a way to actually enforce the spending conditions on-chain. Sigbash is a different flush. 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, or it can be complex as if this, then that, if this signature, then that amount, if this other signature, then these white lists, or black lists, or whatever.
Digging under the hood, the way it works is the policies are all encoded in this thing I’m calling the poet, a policy operand expression tree. It’s a Boolean abstract syntax tree. This might get pretty technical, so bear with me.
@arbed_out (05:38.686)
The idea 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 PSBT file, a partially signed big-twine 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 PSP tier. So 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 this single 32-byte hash.
Stephan Livera (06:09.378)
I say.
@arbed_out (06:19.631)
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, the conditions have been met.
Stephan Livera (06:32.73)
Okay, got it. And so, as I’m understanding from you, this means, let’s say we set up a Sigbash setup together, or let’s say you set up a Sigbash setup, what we’re talking about here is the cosigner is going to look at the zero-knowledge proof to say the transaction you have signed and the zero-knowledge proof you’ve made, I guess it satisfies the initial policy.
that you initially constructed upfront and therefore allow or don’t allow. Is that, have I got it right there?
Okay, and then, yeah.
@arbed_out (07:08.92)
That’s correct. one important note is, go ahead. One important note is the signer is actually now.
Stephan Livera (07:13.688)
Yeah, 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?
@arbed_out (07:31.916)
Yeah, that’s correct. We really want to avoid the oracle problem, the idea that the signer is somehow has some knowledge of the source of truth 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 PSPT. 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 PSPT file.
Stephan Livera (08:14.522)
got it and I guess the other aspect of it is oblivious signing so can you just tell us or explain for us what is oblivious signing
@arbed_out (08:27.244)
So one of the nice things about coming up with your own spin-off 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 is not 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. 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-htp 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 zero knowledge proof.
So it’s not full blind signing and that the signer is not just willy-nilly handing out signatures. The signer has to be satisfied that the policy has been actually matched before providing signature share.
Stephan Livera (09:42.768)
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 cosigner. And the cosigner, let’s say it’s a Sigbash cosigning server, as an example,
that server is checking is this valid with what we initially agreed upfront 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?
@arbed_out (10:25.912)
Sure, 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 in WebAssembly is that the zero-knowledge proof math is actually extraordinarily complex. It’s not something you can do in JavaScript or TypeScript without 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 zillion-odge 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 PSPT file to be signed. The Wasm parses it, checks for transaction suitability, makes sure it matches the policy, submits the ZKP proof on your behalf, and you get a signed transaction back.
Stephan Livera (11:38.881)
And so just on the PSPT side of it, I guess as you’re saying, this is all just valid with Bitcoin hardware wallets today. Like your cold card can sign this already no changes needed, correct?
@arbed_out (11:51.554)
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. Under the hood, we’re using Music2, but you don’t know anything about that. 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 Music2 on WebAssembly, and that’s yours. We don’t know anything about it. All we know is our signature share.
Stephan Livera (11:57.669)
Got it, okay, yeah.
@arbed_out (12:21.162)
So come signing time, you just have this xpub that looks like any other taproot key. You add it to your multi-step quorum. And when you want your PSPT signed, you submit that PSPT to us, and we add our signature to it.
Stephan Livera (12:35.802)
And just one other point coming back to the oblivious signing concept just to spell that out a little bit. I presume 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
where in a world where if increasing kind of KYC sanctions, AML, BSA, kind of nuisances tightening, they may start clamping down on what exactly a partner or service provider can sign for their customers, right?
@arbed_out (13:23.212)
I don’t want to 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 a fiduciary than you need to be. And for a lot of business models, that might be fine. 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 for being judge, jury, executioner, fiduciary to just a node republic, know? Just stamping a transaction saying, yep, this looks right to me.
Stephan Livera (14:15.767)
And even setting aside the regulator, the state concern, there’s also just the general privacy concern because if you are running a centralized cosigning server, that can itself become something that people want to 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, hearing about these kidnappings and things like, and attacks on Bitcoin holders in France and all around the world. Even just setting aside the regulator part of it, just
the privacy aspect of it might be interesting in a practical sense. then I guess ideologically, maybe you could argue there’s a bit more of a cypherpunk ethos to this technology and use of Bitcoin this way in theory.
@arbed_out (15:00.192)
Absolutely, that was also an explicit design goal.
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 Quorum who’s just serving as sort of backup key holder, why are you sharing all of your details with them? The concern, especially with, you know, the typical $5 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 their database, doing nothing else with it. And then eventually,
someone compromises them, find out your details, and they go tracking you down.
Stephan Livera (15:39.42)
Yeah, so that could be interesting. Let’s talk a little bit about what this might look like in practice. 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 gives them more kind of security under the hood with policy limits or is it more like you have a two or 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?
@arbed_out (16:26.52)
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, their children, and then the third person is an attorney. And the parents want to 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 air. 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 basically, you’ve introduced this trusted third party into your inheritance protocol.
With Sigbash, you can get rid of that attorney completely if you want. You can set up a key that only signs transactions after a certain date for certain amounts to the trust address. And you can hand that to your heir as well and say, if I’m gone, here’s your key, which you signed by discretion, and here’s the server key. 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 drag through the courts if they misbehave. Just know that in case of emergency, break glass, and this is your way to do it.
Stephan Livera (17:51.142)
Got it. And just, guess, 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. that error in that scenario is also SOL, right?
@arbed_out (17:57.836)
Yeah, that’s the one thing, dude.
@arbed_out (18:06.86)
Yeah, that’s the one catch. There is a liveness requirement. You’re asking the signer to exist. But 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. 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.
Stephan Livera (18:33.797)
Yeah. And so do you envision a world where Sigbash cosiners are run by, let’s say the CoinBases and BitGoes of the world or the unchained capitals of the world?
@arbed_out (18:46.678)
Yeah, I do. think anyone who’s running an existing multisig corn 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 $5 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…
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 dumb computers that are just doing the job of signing transactions and humming along in the background. So yeah, I could see BitGo, Coinbase, anyone who’s actually using existing multi-sig signer setup just switching over to this seamlessly.
Stephan Livera (19:36.944)
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 e-scrow, maybe some of these lending, the collateralization companies as well, on the loan side, not just the vault side. I guess all of these might potentially want to do some kind of Sigbash, like assuming adoption, right?
@arbed_out (20:01.174)
Yeah, these are all things we’re actively exploring. It’s actually pretty interesting because you can make the case for an insurance company, for example, that this probably lowers your risk premium because you have absolute certainty that 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.
Stephan Livera (20:25.061)
Now in terms of guess griefing, can the server just not sign the thing that you want? I mean it comes back to what you were saying about the liveness requirement, in terms of understanding the security model, the threat model, is it just that you need to, if, put it this way, can you still have some kind of unilateral exit if the Sigbash co-signing server does not sign when you need it?
@arbed_out (20:50.902)
So you need to design that into your multisig quorum just as you would before. Obviously, the server can go offline. It can’t do so intelligently. It can’t know anything about your transaction and say, I don’t like this address. I’ve decided I’m not going to sign it. these amounts are above my predefined limits. I’m not interested in signing it. 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 binno hash, whether it’s pipes, whether it’s something else. So the idea is you have a perfect world I would have nested music to. 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 assurance in the background, the fallback is some sort of covenant.
Stephan Livera (21:46.298)
Yeah. Now we were, we kind of started some of this thread a few steps back about use cases. So we spoke about the multi-sig like a two of three or maybe a three or five use case where one of the signers or multiple signers are actually a SIG bash 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 want to self custody is because they’re worried.
that they would rather offload that work to a professional. Maybe in the future there’s a possibility where you have 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 this is a few years back, but Blockstream Green had a two of two signing thing where 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 and where The the code sig bash co-signing server is helping them. What would that look like?
@arbed_out (22:55.916)
Well, under the hood.
for the user experience it would look exactly the same as a normal custodial wallet. 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 music to key, the signature share. 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 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. Other than that, it looks like just a normal wallet.
Stephan Livera (23:54.396)
I see. in practice, it could be that people might, you know, onboard to a service and I mean, I’m just kind of 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 wallet 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 0.1 BTC per day or whatever number makes sense, 0.01 or whatever. And then that would be a way to sort of rate limit or stop, you know, $5 wrench 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?
@arbed_out (24:56.118)
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 seat 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. And insofar as first,
I’m presuming that all the other custodial solutions, 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. I could definitely see.
Stephan Livera (25:47.44)
Yeah.
Now, to be fair, in that scenario, you would still have to really think about redundancy and backups, right? So let’s say the Neo Bank, the Bitcoin Neo Bank with a Sigbash co-signing server, they still got to wonder what happens if my user loses his phone or something like that, right? Or maybe 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.
@arbed_out (26:14.156)
Yeah, so we have different ways of dealing with that. We back up user key material using pass keys. So hopefully it can be as simple as keeping track of your pass key. 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. We can make it a lot easier on you,
Stephan Livera (26:37.019)
Gotcha. So I guess just to understand, like you put out your research and your code on this SIG bash, are you also going to set up a service on this? Like is it going to be a for-profit company as well? Or is it you’re just putting out the research and the development? Like what’s the plan there?
@arbed_out (26:55.118)
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 want to make sure that we’re not relying on custodial solutions or giving up our privacy just because 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.
Stephan Livera (26:57.691)
Ha
@arbed_out (27:19.266)
There’s two pieces of this. There’s the web app. You can go to sigabash.com right now. I’m going to try to keep that for free, running as long as I can as a public service to Bitcoiners. If you are clued enough to be setting up your own multi-sig quorums 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, contracts. They want an SDK to integrate with. 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.
Stephan Livera (27:51.951)
like SLAs and things, yeah.
Stephan Livera (28:04.316)
Interesting. so I guess the idea is, yeah, so coming back to what you were saying, is like covenants without covenants on chain, as opcodes specifically. I mean, there’s a lot of debate and discussion about some of these ideas. What are those? don’t know, CTV or template hash or TX hash, whatever. So, oh, one other thing. Can you explain the difference between SIG bash pipes and binno hash or binno hash? Just for people to…
@arbed_out (28:33.592)
Sure, I think we touched on it earlier, but the basic idea is BinoHash and Pypes are an attempt to get around the lack of a Covenant opcode by doing all sorts of interesting tricks. think Pypes is actually probably, BinoHash seems more like a mad science experiment. Pypes is actually, they’re getting towards something that’s more production, but it’s all the same thing, trying to enforce Covenant restrictions on Chan.
Stephan Livera (28:34.181)
Understand?
@arbed_out (28:58.442)
Sigbash is off-chain, so the difference is the model. It’s on-chain, enforced 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 preferred 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 of careers, 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.
Stephan Livera (29:35.992)
Okay, yeah. So I’m just trying to, yeah, because it’s like, to be honest, I still haven’t really got my head around, like, of Sigbash versus Pipes versus BinoHash, but I guess…
@arbed_out (29:44.846)
Do you want to talk through a policy and we can actually lay out a concrete example because it might be useful for people watching now. Sure. OK. So let’s go back to the inheritance protocol. We’ve got a two of three. There’s a parent, a child, and a third key. And the third key is Sigbash enforcing, let’s say,
Stephan Livera (29:51.322)
Yeah, maybe you can talk us through an example there.
@arbed_out (30:11.82)
You can only spend after this date and you can only send coins to this approved address where the address is for trust disbursement. All right, on chain that ideally in a perfect world we can actually use nested music too to make that all look like one key. And that’s our key path spend in Taproot.
The script path spend would be pipes saying, OK, well, you can only spend, it’s the same conditions defined, but it’s actually defined in script and enforced by consensus. Not defined in script, but the way pipes is doing it with, because script would require an opcode.
Stephan Livera (30:46.022)
This witness encryption idea. Yeah. as I was trying to research a bit, I guess the simple way I’m understanding it then is Sigbash is like a policy cosigner. You’re committing to certain spending rules off chain and you prove it in zero knowledge and the server is then signing it like blindly, 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…
@arbed_out (31:03.043)
Yep.
Stephan Livera (31:15.13)
maybe has other practicality concerns, but it’s not a server that you are relying to be online and honest.
@arbed_out (31:22.69)
Correct, you’re relying more on consensus to take care of things.
Stephan Livera (31:27.024)
Yeah, I see. Yeah, so it’s a kind of a, yeah, interesting, 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, 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, well, no, actually at a very high level, the big security guys in the industry, they really would make use of some of these things, whether it’s kind of like an OpVault or something like that. Like I think nowadays, James O’Bee sees it more like OpCCV is kind of like a successor to OpVault.
And people kind of play around with other ideas of like CTV or TX hash or what kind of volts 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?
@arbed_out (32:39.298)
I think we’re looking at the wrong place for demand for covenants when we say, 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 Pypes, things like BinoHash to prove out all the different things you can build 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, because everyone who wants to build things with covenants seems to have different goals, because 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 I think to the extent that 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 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 because they’re not available.
Stephan Livera (34:13.702)
I see, yeah. 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, what can Covenants do for Arc and Spark and 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, where can we do something on vaults? Where can we maybe make…
And their concern might be more like, hey, how do we stop all these people trusting custodians and get them to use self-custody? And this would help that. 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 that maybe covenants could assist.
@arbed_out (35:01.998)
wow, I haven’t even gone down that rabbit hole. You’ve given me some homework to do when I get out of here.
Stephan Livera (35:07.804)
Well, 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 reasons so some people have made covenant arguments on that basis There is P2Pool v2 as well. So I didn’t have said with Junglee on that. But anyway, it’s just it’s one of the ideas
@arbed_out (35:25.197)
Mm.
Stephan Livera (35:37.968)
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 want to get more information on Sigbash?
@arbed_out (35:47.182)
Sure, go to http://www.signbash.com. Set up a key. Like I said, the individual web app version is completely free. Play around with it. Try and sign up first if you’re not comfortable. Otherwise, feel free to go for a mainnet key. Set up a sign-in policy as complex as you would like. We’ve got a cute little clod front end if you want to just type it in natural language and have it spit out a policy that you can import into any wall that supports Taproot. Give it a go and let us know what you think.
Stephan Livera (36:12.934)
Fantastic. yeah, let’s just check it out. I think it’s interesting to see, you know, this new research. mean, some people like to say, hey, Bitcoin is dead, nothing’s happening. But there is research. There’s, know, there’s Sigbash, there’s pipes, there’s Bino hash, and there’s, you know, there is work going on. So it’s, you know, it’s time for people who want to 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.
@arbed_out (36:39.0)
thanks for having me,