{ "episodeId": "SLP776", "speakers": { "stephan": { "name": "Stephan Livera", "role": "host", "tag": "STEPHAN" }, "misha_komarov": { "name": "Misha Komarov", "role": "guest", "tag": "MISHA" } }, "segments": [ { "speaker": "stephan", "time": "00:00", "start": 0.0, "text": "Hi, everyone. Welcome back to Stephan Livera Podcast. Joining me on the show today is Misha Komarov from Allocinit. Misha is a co-founder there, and, we'll be chatting a bit about Bitcoin PIPEs v2 and, you know, what that potentially enables for Bitcoin. So first off, welcome to the show, Misha." }, { "speaker": "misha_komarov", "time": "00:16", "start": 16.0, "text": "Hey, thanks for inviting me." }, { "speaker": "stephan", "time": "00:18", "start": 18.0, "text": "So, Misha, let's start with, you know, I guess, just quick background on yourself. Just, you know, just take a minute and tell people who don't know you. Okay, so, hey, I'm" }, { "speaker": "misha_komarov", "time": "00:27", "start": 27.0, "text": "Misha. I mean, actually, kind of have been around for a while when I learned all that kind of stuff. Like, there was such a thing, like, kind of a lot, just all over crypto, honestly. Like, quite, quite, you know, started from doing things around Bitcoin when it was like 2013, it was the BitMessage, if you do remember saying. It's like I kind of helped with the CPP implementation. It's kind of still Somewhere around the internet, if you can find it, it's probably my code out there. This is all, whatever, just, you know, doing the implementation. A ton of stuff just all over crypto, around Ethereum, like, John co-founded back in the day, like, =nil; Foundation there was such a thing, like a proof system research thing around Bitcoin, around, around Ethereum, helped effectively to bootstrap, Lido, like it's a liquid staking thing. And, you know, but honestly, after we had all of these, all of this, proof system research around Ethereum, there was always, you know, kind of a question on my mind, if we can make it helpful for, for, for Bitcoin, because, like, nobody really was looking at it, honestly. So, that's, that's how we, that's how we came to,, like, what, what, what came to." }, { "speaker": "stephan", "time": "01:31", "start": 91.0, "text": "Yeah. And so, talk to us a little bit about, you know, the approach you're taking with Bitcoin PIPEs and now the more recent version, PIPEs v2. Yeah. As I understand, you're trying to Do things that were, would otherwise require, you know, typical covenants kinds of things in Bitcoin. Talk to us a little bit about that." }, { "speaker": "misha_komarov", "time": "01:53", "start": 113.0, "text": "Okay, let's talk about that, right? So, what's the never-ending conversation in Bitcoin? New opcodes. It's a conversation which we've, which we've had since like, since, since I do remember, like since, since I came around like in 2013, I, I hear a conversation about, oh, let's add this opcode, let's disable that opcode. Let's, like, it's a never-ending conversation. And, for certain upgrades, for certain improvements, it of course kind of makes sense to like, you know, get, get maybe a little bit upgraded somewhere here and there for security purposes, for example, or like for bug fixing or whatever. Like we had early on with like, you know, like this early Satoshi, Satoshi era supply, supply bonds, or like we're having, you know, kind of potentially, like it's kind of a little bit of fun around quantum thing, right? Okay, not a fun, but still, it's, you know, we'd better to, we'd better to come up with a way to like protect against that. And But there are always those conversations around kind of Bitcoin which involve things which are nice to have. Like, let, let, like, which are just not crucial for the existence of the Bitcoin itself. Things like, hey, let's add CTV, like the opcode CTV. Like, let's, let's add CSFS. Let's add, I mean, we have the recent whole drama about OP_CAT. There's a bunch of other proposals, like we had a proposal about OP_VAULT. We had a proposal like a bunch of other different kind of ways to induce covenants, etc. And, there was always this kind of never-ending conversation. And, as I said, kind of because of all of this, like, you know, it's, how do you, like, like, because it's just not so important to upgrade Bitcoin for the sake of things which are nice to have. Like, it's just too big right now. It's, it's like, don't touch it, right? Don't risk, don't risk, don't risk the whole thing for the sake of things which are nice to have. So the question was always like, okay, how do we actually give people what they want? Cuz like, it's a never-ending thing without us actually touching Bitcoin. And this is where, kind of, as I said, the, the, the whole kind of proof system research we've accumulated just all over, all over the industry, I would say, came to the rescue. It turns out, like in 2024, it turned out that we actually can emulate certain type of opcodes without touching Bitcoin itself, like the behavior of certain type of opcodes without touching Bitcoin itself. And it turns out that some of these opcodes actually allow us to induce certain type of covenants without touching Bitcoin itself. And sure, there are things like DLCs, there are things like whatever, like something else, right? But like, all of those kind of like pre-sign, pre-sign transaction tricks, etc. But like, all of those are either custodial, either they are You know, they're, they're inducing a lot of trust assumptions. Either they're not flexible enough, so you can't really kind of, you know, induce various behavior, like just any kind of behavior. So, and that's why effectively we kind of came up and that's why I published back in October 2024 the paper called Bitcoin PIPEs. It was this idea that you could effectively via Witness Encryption or Functional Encryption, depending on what works first, right? There was this idea that you could effectively, well, kind of induce these and enforce these covenant, these covenant-like behavior outside of Bitcoin L1, like outside of kind of the protocol itself, for Bitcoin L1, but outside of the protocol itself cryptographically. Like the way it worked is that effectively the way it worked and the way it seemed seemed to work back in the day, and it still is this way, is that it's supposed for certain, whatever, like one out of n trust assumption can be, like a secret can be to generate a secret key which nobody, which nobody has and effectively form a ciphertext. And then once a person, once a user wants, wants to effectively induce covenant line behavior, they can prove some type of computation, like generate a ZKP of that computation, right? And then verify, yes, a zero-knowledge proof effectively, and then push it through the verifier of the PIPE, through the decryptor of the PIPE, through the effectively the witness, or through the Witness Encryption scheme to get the key. Okay. So let's just stop there" }, { "speaker": "stephan", "time": "06:01", "start": 361.0, "text": "So let's just stop there for a second. So let's just talk to us a little bit about, you know, Witness Encryption, right? So people might know Bitcoin transactions have an input, have inputs and outputs, and we might think of, okay, when I sign my Bitcoin transaction in the SegWit or Taproot context, the signature is going in the Witness. I guess that people might understand that. So maybe you can take it from there. What is Witness Encryption? Like how is Pipes working to do that? Okay. So let's talk about that. Obviously, yes," }, { "speaker": "misha_komarov", "time": "06:27", "start": 387.0, "text": "as I said, as you said, there is a notion of like Witness in Bitcoin itself. It's true. But like, it's all about where Bitcoin itself got this notion, right? So like Witness Encryption actually is a thing which originated just kind of from academic cryptography back in 2013, if I remember. Kind of, it was introduced by Sanjam Garg. Like, and Effectively, the idea in there is, is that you can decrypt some ciphertext. You can decrypt something out of the ciphertext only if you have a proof or even, or only if you have performed some type of computation. So like, without this, without actually performing some type of computation, you cannot decrypt anything. So, that's effectively the trick with, which were," }, { "speaker": "stephan", "time": "07:12", "start": 432.0, "text": "yeah. And so I guess another way, so again, I'm, the way I'm understanding it is like, typically in Bitcoin, when, you know, I sign, when I sign my transaction, I send some Bitcoin. It's like we are unlocking the coin from its prior, you know, and we are relocking it to the new owner. And in this context, what we're talking about is like we're kind of locking it in a special way that only by satisfying certain conditions, right? Like the ZKP, that's how we unlock it. Like, so instead of like normal Bitcoin, like single sig, one of one, or multi sig, two of three, or whatever, we're using a special kind of lock and unlock. That's what this is, right? Like in simple terms. Exactly, exactly," }, { "speaker": "misha_komarov", "time": "07:51", "start": 471.0, "text": "exactly, exactly. And the trick is, if you, and the trick is like, how do you actually verify this kind of on-chain, right? So you would be able to rely on it within, within the transaction or within whatever you want to do with your Bitcoin, is that the thing is, if you never had this key from the ciphertext, which you have kind of, you know, unlocked effectively, which you have, you know, sort of decrypted with certain proof of certain computation, if you never, if like, if you never have done the computation correctly, you would have never had this key. If you never had this key, you would have never been able to sign a transaction to indicate the fact that you've got a computation correctly on Bitcoin at one, like directly just on Bitcoin. So..." }, { "speaker": "stephan", "time": "08:31", "start": 511.0, "text": "Yeah. And so then what you're getting at is this idea that if we use this ZKP and this Witness Encryption, we can start locking Bitcoin in ways that are not currently kind of technically supported by the opcodes that we already have in Bitcoin today. And this is where you can start Thinking it like you can do other functions. So do you want to talk to us a little bit about what some of those other functions might be? Okay, let's talk about that, right? So" }, { "speaker": "misha_komarov", "time": "09:00", "start": 540.0, "text": "effectively, effectively, like, that's kind of the, we're coming to like the distinction of like the PIPEs v1 and PIPEs v2. Like PIPEs v1 were published back in October 2024, and PIPEs v2 is something we published around maybe February this year, maybe March this year, right? So the difference between them is exactly in which type of functions and which type of, which type of functionalities we're able to decrypt. Upon, so, PIPEs v1, since it was kind of like a concept based on Functional Encryption, allowed effectively to not just, to not just decrypt, to not just decrypt upon certain computation, but also to perform this certain computation over a ciphertext and, and output decrypt a result of this computation, which allow to induce, as we call them, kind of, you know, as we call them, like post-covenants. I'll talk about this a little bit later, right? And with, and, and like, but again, because it's Functional Encryption, it's like, it's pretty, you know, pretty, pretty, pretty, pretty novel, like we're still yet to like achieve all of that just in general academically, but it's all about, sure, how can we make this like actually work in practice? And that's where PIPEs v2 come into, come to the rescue. But PIPEs v2 come with like a little bit of a, a little bit of a reduction in like the direct covenant emulation functionality, is that they allow, because of being Witness Encryption, it simply decrypts the ciphertext, it simply decrypts the key. It doesn't perform the computation over the key later." }, { "speaker": "misha_komarov", "time": "10:30", "start": 630.0, "text": "So you cannot really kind of sign with this key. You can simply kind of decrypt key and like let the user sign. This way, you can do pre-covenants. Pre-covenants is actually like good examples of pre-covenants are OP_VAULT. It's a pre-covenant. You can either withdraw from a vault, either cannot, right? Another like another interesting opcode which is the proposal for which is circulating around is CSFS. Like that's basically CheckSigFromStack, like either the signature is valid, either not, and you can make the user to like push it to push it to Bitcoin together with a verification transaction as well, right, afterwards. So, or any kind of binary covenants, like any kind of binary predicates. So if you can, for example, put, well, yeah, put like put CTV indirectly, for example, into some kind of predicate, into some kind of lambda, which results into zero or one. You can verify this on Bitcoin. You can effectively be like, okay, like this piece of Bitcoin script, which contains CTV, is valid. So it's like, think about it as, if we were able to emulate check CTV." }, { "speaker": "stephan", "time": "11:39", "start": 699.0, "text": "Okay. And then, talk to us a bit about some of the trade-offs of this, because, I mean, there are all kinds of different approaches people have taken to this. As I read from the paper and some of the other kind of surrounding work, it looked like, and I understand this number is moving over time, but this ciphertext is like, or at least was, like 300 terabytes. And the cost to do the transaction was also quite high. But maybe the trade-off of that is like, maybe this would be, this would make sense for like a big name custodian or some kind of professional use case to use it in that way. Can you give us an update on that? Like, what is the latest state of technology there on the size of that ciphertext, what it will cost to do these transactions? Okay, so" }, { "speaker": "misha_komarov", "time": "12:21", "start": 741.0, "text": "what's going on there? Effectively, true, separate exercise is one of the largest kind of pace of this mechanism, like all, like everything comes as a trade-off, everything comes like, you know, there is no free cheese as they say, or like whatever. So it's true, at some point, I guess the primary kind of issue with all of these Functional Encryption, Witness Encryption, and everything, is that they're simply just too large, right? And the whole kind of, the whole point of why we're going around and like talking about this is that we, we think that there is a way, and like we're kind of demonstrating this with a paper over paper over paper, to make these ciphertexts or to make the computation necessary to perform this kind of, you know, to perform these kind of, you know, encryption schemes, like Witness Encryption in particular. And the little bit In a, in a way which is a little bit, well, down to earth, more down to earth way, right? So that's the thing. So indeed, in the paper we published back in February or like March, was it like the AADP Witness Encryption at that point, we had the ciphertext, like we, at fir, we, we, for the first time had like a particular ciphertext size estimation. And indeed, it was 300 terabytes or something. Like, it is large. It is definitely not for like everyday user, not for, not for everyday kind of transaction signing. And, the number kind of over time goes down, like for example, we're like, we're on the verge of like publishing the updated ADP Witness Encryption Scheme, which hopefully gets the ciphertext down to like double digit, double digit terabytes, maybe a single digit terabytes. And even that, it's still like, not like really something you would do on your phone. Like, so the question is all about, what is this, what is this helpful for? What is this useful for, right? Like, for example, an OP vault, like a pre-covenant, OP vault, yeah, like it's vault. It's maybe, maybe, maybe, maybe vaults, like the OP vault, for example. Like, it's a pre-covenant, yes, indeed, you can either withdraw, either deposit from the vault effectively. From your vault, it might be a shared OP vault. Like, it might be an OP, it might be a vault between different users, right? And, the question is all about You know, and like, and, and like, the question is all about if this vault because of pipes, like, is it, is it like ever practical to use it? Well, once you, like, once you, for example, deposit your Bitcoin into the vault or whatever, or you kind of decide to store it there or something, yes, if you want to withdraw it, like, you would need to sign for text. If you're doing something with your Bitcoin inside your vault, which, for example, could be a vault for a meta protocol, like, that is like a ton of uses, ton of use cases for Bitcoin vaults, right? Especially for non-custodial Bitcoin vaults, which pipes kind of allow us to do. It might be not kind of involving this in, like, just every transaction. You might be, it might be fine. Like, for example, when you only, like, for example, when you're using pipes, only for the sake of, I don't know, getting your Bitcoin back, like, being able to get your Bitcoin back out of the vault, out of some protocol or something like this. If things went south within the protocol. So like you always want that guarantee. You always want to get guarantee that whatever happens. It's like a unilateral exit" }, { "speaker": "stephan", "time": "15:28", "start": 928.0, "text": "sort of thing situation. So you're saying this would be like the unhappy path and in the happy path you're just going to stay inside the that vault construct or whatever the pipes enabled kind of L2 or construct." }, { "speaker": "misha_komarov", "time": "15:41", "start": 941.0, "text": "I hope, I mean like people, people can do, people probably will introduce some kind of sidechains or L2s on top of like on top of these, on top, on top of like pipes based, some kind of pipes based bridge of course. But like we're trying to kind of just focus on introducing vaults on the Bitcoin L1 itself and we're thinking that there might be a whole new family effectively of meta protocols enabled by this. Because meta protocols were, were kind of boring at a time and everybody was thinking that they're just spam. Why? Because there was no Bitcoin inside. So if you have Bitcoin inside, there might be fun again. And we're hoping there will be a whole new family of like Bitcoin meta protocols which actually use Bitcoin inside," }, { "speaker": "stephan", "time": "16:19", "start": 979.0, "text": "because now we have" }, { "speaker": "misha_komarov", "time": "16:20", "start": 980.0, "text": "non-custodial" }, { "speaker": "stephan", "time": "16:21", "start": 981.0, "text": "bulls for." }, { "speaker": "stephan", "time": "16:23", "start": 983.0, "text": "I'm just now thinking, I'm sure you're, you're kind of watching the space and all these different ideas that are going around. I know there was an idea by, a developer known as arbedout. It's called Sigbash, and this is like a, a cosigner, a Sigbash cosigner is this idea, and that was kind of his idea of like kind of doing covenants without covenants on L1 Bitcoin, and now that does have a cosigner, and that is also using ZKP and Wasm and some other pieces. How does Pipes contrast with that? I guess the point would be this is not having a cosigner. This is just like on L1, no cosigner. That's the main difference?" }, { "speaker": "misha_komarov", "time": "16:59", "start": 1019.0, "text": "Yes, that's I think, I think, I think that's primary pitch. Like the private, the private, like the private, the primary difference is that once the ciphertext creation is done, like on the PIPEs side, and the ciphertext is yours, nothing can stop you from getting your Bitcoin back or deposited in there, whatever. It's like completely self-custodial. It's like there is no cosigner, there is no like, you know, somebody being the liquidity requirements. There are no like requirements for like having whatever liquidity from somebody or like some tree size or whatever, you know?" }, { "speaker": "stephan", "time": "17:28", "start": 1048.0, "text": "Crucially, there's not a global state here. Like it's just whoever wants to opt into that system, they already can do it right now. That's the point you're making. There's not like, it's not like there's one lightning network and everyone needs to kind of speak the same lightning protocol or something like that. It's more like individuals in Bitcoin today can just already use this with the trade-offs, as you said, the let's say double digit terabytes of ciphertext storage is kind of the main trade-off it sounds like. And maybe that setup process. So do you want to talk to us a little bit about that? Is that like a, I've, I've heard the term DKG. Is it like a distributed key generation kind of setup, something like that? Or how does it work?" }, { "speaker": "misha_komarov", "time": "18:05", "start": 1085.0, "text": "Yeah. So, we actually have like a large internal discussion about how to, how to, how to actually use this in the, in the best way, right? Because there are the ways, as you said, just to do kind of a DKG when somebody like ends up having some, as they call it, like toxic waste or whatever, and you can make sure that they As far as the with the vault, that's stuff, stuff, stuff. So that's also a way, like that's also a way forward, true, but that is a little bit of a nuance that we actually need to be able to make sure that the ciphertext you're getting, that the user needs to be able to make sure that the ciphertext they're getting actually belongs and actually corresponds like the private key inside of it, which you should never know until you want to decrypt, until you want to decrypt it, that it actually corresponds to the circuit and to the public key, which the vault effectively states that it belongs to. Like, it's, you know. So, when you're deposited into, into the vault, you want to be sure that this is the ciphertext, you're going to be able to decrypt the key to this person. The person," }, { "speaker": "stephan", "time": "19:04", "start": 1144.0, "text": "the user is not getting scammed by giving the wrong, by being given the wrong ciphertext that doesn't correspond to what he actually is using, right? And then, because of the size we're talking about, it kind of makes it hard to do it over the internet remotely, right? Like, I guess theoretically, are we saying people, the signers are going to have to get together in person to kind of network locally to, to do the setup? Or talk to me about how that would work. Yes, it's like, because of the size, indeed," }, { "speaker": "misha_komarov", "time": "19:31", "start": 1171.0, "text": "it's probably going to be required for, for, for, for these people to be, well, you know, kind of. Right, so get together and have like a LAN party, like in the old days, and kind of set up their process that way. Probably in data centers, probably in something like this. Maybe same data center, maybe different data centers with just good connectivity between them or whatever. So, yeah, let's, the MPC, MPC is going to be communication heavy in there. It's true." }, { "speaker": "stephan", "time": "19:55", "start": 1195.0, "text": "And then, so talk to us a bit about, okay, so let's say you've set that up, and is it a 1-of-n model or how, what's the model there? Ideally, it's 1-of-n," }, { "speaker": "misha_komarov", "time": "20:05", "start": 1205.0, "text": "yes. Like, it's like the more we push towards 1-of-n, the more communication complexity becomes. But like, you know, the pair, the most paired or regime you could" }, { "speaker": "stephan", "time": "20:14", "start": 1214.0, "text": "get out of this is 1-of-n. Right. And I guess just for listeners, can you explain what is a 1-of-n trust model? It means that if during the setup, at least one" }, { "speaker": "misha_komarov", "time": "20:23", "start": 1223.0, "text": "party behaved honestly, then everything else is kind of honest, that everything else is okay, even if everybody else cheated. So, basically that. So, in case, in case you're being like completely paranoid, which is, you know, we kind of imply that our users are completely paranoid, you're welcome to like, you know, participate or like to become a participant in these kind of MPC setups, just to be sure that your ciphertext was created honestly and there is no like caveat or nobody kind of decided to generate it for the wrong server or somebody else. But yeah, in" }, { "speaker": "stephan", "time": "20:54", "start": 1254.0, "text": "general, it, it works this way. Yeah. And so, as we've mentioned, like the, there are certain trade-offs of this. Who do you see as the main users? Is it like a big vault custodians or who, who would you see as the main user of this? Yeah. Okay. So let's talk about" }, { "speaker": "misha_komarov", "time": "21:11", "start": 1271.0, "text": "that, right? So actually, like, if we're talking about, if we're talking about, like, us, for example, finally being able to induce non-custodial vaults of Bitcoin, like, there is, like, a ton of uses, there is a ton of use cases you can come up with, right? You can use these vaults, for example, for inducing, for inducing, I don't know, shared, shared pool collateral lending on Bitcoin. For example, if people want to collateralize, collateralize. So Bitcoin right now, it happens the way that there's some kind of DLC or something else, you know, and there's a trusted party always involved, and you're like, you, you negotiate your rates or whatever, it always kind of ends up being a little bit funky in there. It's not bad. It's just, it's just the way it is right now. And, if you, for example, had these kind of non-custodial vaults, you would be able to, you would be able to induce shared pool collateral, like for like a shared pool, like shared pool of Bitcoin or like shared pool of dollars, if like somebody wants to, like, do it separately to make or whatever. And this would effectively allow to lower the rates and like, like, and get rid of these, all of these trust assumptions with like the counterparty when you're trying to Like your Bitcoin. So that's one of the, that's one, that's one of the things which, which, which could be cool. Or another thing, again, like it's, it's also another kind of cool application of this, right? Is one could induce some kind of pools. For example, like Shielded pools, right? Like there could be, you know, there could be some, whatever, like private transfers pool, like the Zcash style, right? But that's just one of the use cases. So like when you have vaults, especially non-custodial" }, { "speaker": "stephan", "time": "22:38", "start": 1358.0, "text": "vault, there is like a ton of use cases one can do. Gotcha. Yeah, so let's get to the sure Bitcoin after this. One more question on vaults. I just want to understand the type of vault that could be done, right? Because I guess people have different ideas of what a vault is. So when I'm thinking about like Revault, right? Like WizardSiding and Kevin and those guys, they had this idea, I think that was maybe a bit of a pre-signed idea or anyway, sorry, I'm skipping around a bit. But I guess in your concept of a vault, are we talking here about this idea of you have like when you try to spend out of this, there's like an emer- you have like a Watchtower, and then if it's getting spent and it's not you, you have like an emergency backup transaction to your second key set. Like, is that the kind of vault you're talking about? Or what kind of vault do you mean? Yeah, okay." }, { "speaker": "misha_komarov", "time": "23:24", "start": 1404.0, "text": "Yeah, let's talk about that, right? So what you have described is effectively a description of, of this kind of, you know, already almost canonical OP_VAULT PIP. And it is effectively what we started from. Like we started thinking about, okay, well, what can, what, what kind of OP codes we can kind of emulate with this, and it turns out that OP_VAULT can be emulated with this, and then we were like, okay, are there any more, are there any kind of more interesting vaults we can induce by this than, than effectively what OP_VAULT did kind of describe. And it turns out we can. Like, for example, we can extend this to be a shared vault. Like it could be a vault for multiple users. Like, so multiple users could kind of deposit, pool their Bitcoin for various reasons, and then kind of get their Bitcoin back without being afraid that somebody's going to screw" }, { "speaker": "stephan", "time": "24:06", "start": 1446.0, "text": "them over. And so would the vault have some kind of accounting of who contributed in what, or is it more, are we talking more like, you know, it's a foundation or a business and it's just a shared pool, it's a shared pot of Bitcoin in the vault?" }, { "speaker": "misha_komarov", "time": "24:18", "start": 1458.0, "text": "Well, I'm thinking, like, I'm, I'm actually thinking about this right now as more like a, as, as more of a, as more of a primitive, because, for example, one could use, one could use this kind of shared pool vault for building, as you said, yourself, like a bridge on top of it. Like, somebody will come up with a bridge based on this shared pool, right? Like, somewhere else. And so then, in that way, you're kind of," }, { "speaker": "stephan", "time": "24:41", "start": 1481.0, "text": "you're trying to almost, I guess, there's different problems that are in, like, Bitcoin and, in kind of crypto land, and one of them is, like, bridging in and out. And because of all these bridge hacks, I guess you're trying to say, can you, like, obviate a bridge or have it in a different, have a bridge in a, with different trust assumptions? Is that, is that right, or how are you seeing it? Well, I mean, again, as I said, the bridge" }, { "speaker": "misha_komarov", "time": "25:02", "start": 1502.0, "text": "is just one of the examples of what you can do on top of the shared, shared, shared, like shared, shared vault effectively, right? And yes, if somebody comes up with a bridge construction on top of it, that's going to be a bridge which, you know, with, with, with a trust assumptions that a multisig or a set of operators or like anything like this. Indeed, I mean, as I said, there is like, you know, kind of a bunch of other use cases one can do on top of shared pool vaults, and there are some of them you do not need a bridge. For example, as I said, if you want to collateralize your Bitcoin, for example, with this shared, shared, shared user vault. It's just" }, { "speaker": "stephan", "time": "25:33", "start": 1533.0, "text": "like borrowing against your Bitcoin kind of thing, that kind of setup. Yeah. And especially for larger amounts, then maybe it is worthwhile or whatever. Yeah. Interesting. Okay. And then how would you encode, like, so let's say, let's go to that idea of the, the loan. How would you encode, you know, the different conditions, right? Like if it's a liquidation kind of loan or if it's a, you know, how would you encode who gets what in what condition? Like, how would that work?" }, { "speaker": "misha_komarov", "time": "25:57", "start": 1557.0, "text": "Yeah. I mean, it's like, let's, you know, it's It's, it's, it's a little bit of like, you know, like, like a draft of a design or like we don't really have this kind of design on the paper or whatever, but like we can spit ball about it if you want to. Yeah, okay. But I guess just loosely" }, { "speaker": "stephan", "time": "26:10", "start": 1570.0, "text": "speaking then maybe you would say it's like going to be enforced, let's say at the policy level, not on-chain per se, in terms of loan conditions?" }, { "speaker": "misha_komarov", "time": "26:18", "start": 1578.0, "text": "At the decryption policy level, you could be effective like if somebody can prove that whatever the exchange trades somewhere here, somewhere there, whatever changed below the certain threshold, anybody can decrypt, anybody can decrypt this or like certain additional bodies can decrypt this, like effectively cause an A liquidation quote-unquote event. So. I see." }, { "speaker": "stephan", "time": "26:35", "start": 1595.0, "text": "Okay. Yeah. All right. And let's talk a bit about the, the shielded Bitcoin idea. Now, I think this has to be distinguished because there's like various ideas going around. There's shielded CSV, which is, I think Robin Linus, Jonas Nick, and Liam Eagen, right? Yes. Exactly. So that's like, that's kind of a related but different idea. So do you want to just explain shielded Bitcoin and how that's different from shielded CSV, which people may have heard of? Yeah, okay, let's" }, { "speaker": "misha_komarov", "time": "27:00", "start": 1620.0, "text": "talk about that. So, like, Shielded CSVs primarily is like, I mean, it kind of like, the differentiation is within its name. Like, it's CSVs. What does that mean? It means client-side validation. So, all the client, like, we've seen a bunch of client-side validation protocol, validation protocols on Bitcoin over the years. Like, we've seen RGB, we've seen, like, you know, like, all these early, what was like, oh, god damn it, Mastercoin, some of this stuff, or something else. There was, like, a bunch of protocols which effectively used some kind of client-side validation. And Shielded CSVs effectively is the, is a continuation of that client-side idea that, you know, a user or, like, somebody else can have a separate state, like, outside of Bitcoin, and node with a separate state, which would effectively just parse Bitcoin and validate if certain transactions are correct or not, which simply are using Bitcoin as, like, as they say, for the, for the data, just storing data, transaction data, right? And they got to decide themselves if these transactions are valid or not. And that is a separate state. Like, it's a separate state on like the user side. You got to have your own separate state. You got to run your effectively Shielded CSVs node and you got to make sure that you never lose that state. It's more like, you know, I don't know, like a side chain or like an L2 or maybe something like this, you know, of some sort, I would say. Does it work? Absolutely. Like, it's suitable for payments. Like, it's good for just kind of, you know, high frequency," }, { "speaker": "misha_komarov", "time": "28:31", "start": 1711.0, "text": "small private payments. Like, for example, if you're trying to buy coffee at Starbucks anonymously and like you want nobody to know you or whatever, or something like this. Because it effectively stores all the state of chain, and it only stores commitments of that state, effectively, you know, kind of just Merkle roots, right, of that state on, on Bitcoin L1, just to be able to attest that somebody has that state. But you still got to have that state. It's for payments. Shielded Bitcoin, on our side, is more like, it is more like the, is more like an attempt to bolt on, to like introduce this kind of shielded pool right on top of Bitcoin L1, and store all the state on Bitcoin itself. So effectively, instead of like, you know, just some side, side chain, side state, like somebody sending each other, like, but synchronizing nodes of this side state, you know, sending all of these kind of commitments, etc. You could simply send shielded notes within Bitcoin transactions on Bitcoin itself, and to be able to restore whatever happened with your, with the, with your kind of shielded Bitcoin anytime from Bitcoin itself. So, it's kind of like that." }, { "speaker": "stephan", "time": "29:41", "start": 1781.0, "text": "Yeah, and then would every transaction done inside the Shielded Pool of this, let's say Shielded Bitcoin, Shielded Pool, the point is those transactions don't have to hit L1 Bitcoin, right? They stay off-chain, is that right? No, no, no, they, they, they, they need to, they need to hit the Bitcoin L1, like. So every transaction would still have to hit L1 to do that, okay. So then, I mean, people are going to have more of the concern around the scalability, but maybe this is like a thing that people would just be willing to pay. How, how, how are you seeing that? Is it just like every transaction needs to go, the private ones in this context would have to all still go on-chain? Yeah, I mean, again," }, { "speaker": "misha_komarov", "time": "30:20", "start": 1820.0, "text": "like as I said, like we're kind of not targeting, we're like, we're like, we kind of don't have this target to, to make this a solution for like scalability. As I said, like we're not targeting like small payments or whatever, cuz like people just don't do small time payments for Bitcoin anymore. It's just kind of, yeah. I mean, people do like" }, { "speaker": "stephan", "time": "30:38", "start": 1838.0, "text": "Lightning stuff for that, cuz it's off-chain to that, right? Yes, yes. Spark and Arbitrum, all these things, right? Yeah." }, { "speaker": "misha_komarov", "time": "30:44", "start": 1844.0, "text": "They do it off-chain, indeed, indeed. But like, they're not trying to do it with Bitcoin alone itself. So, we're thinking that, well, this is a, this is a, this is a design which could be kind of used for not payments, but like the large bulk transfer, large bulk transfers. Settlements. And I mean, maybe it makes sense for" }, { "speaker": "stephan", "time": "31:03", "start": 1863.0, "text": "like, you know, exchange to exchange kind of transfers or something" }, { "speaker": "misha_komarov", "time": "31:06", "start": 1866.0, "text": "like this. Yes, yes, or treasuries. People who store their treasuries in Bitcoin, for example, and don't want anybody to know the structure of the treasury. Yeah. Or something like that." }, { "speaker": "stephan", "time": "31:15", "start": 1875.0, "text": "I mean, it's interesting because like, when people look at They try to watch on chain what's going on with, you know, MSTR or whatever, any big treasury companies and try to look at maybe not MSTR but some of the others. Oh, hey, there's some coins moving. Are they going to sell? Like this kind of thing. Exactly." }, { "speaker": "misha_komarov", "time": "31:30", "start": 1890.0, "text": "Exactly. So that's for" }, { "speaker": "stephan", "time": "31:32", "start": 1892.0, "text": "that. That's, that's, that's to be able to kind of, you know. I see. And so help me understand this then. So like in other contexts, it's typically like as an example, if I think about liquid, right? As an example, people peg in coins into liquid and they can trade around inside of liquid and then they can peg out of liquid. You know, now of course, there was recently the liquid hack, but theoretically it should be that, you know, approved by the, what is it, 11 of, 12, I think it's 11 or 15 and there's like certain rules about how you peg out, things like that. But in this context, we're saying instead of having like a federation, you just have, you just have this pipes Shielded Bitcoin concept and you, you can peg in or go into the shielded pool that way and then come out of it. Yeah." }, { "speaker": "misha_komarov", "time": "32:17", "start": 1937.0, "text": "You can, you can, yeah, exactly. You can do it yourself. You can effectively, you can effectively, you know, get the ciphertext, deposit it into, like deposit your Bitcoin into the public key of like which corresponds to like the ciphertext you have right now. Then you can get the proof of the fact that you have deposited Bitcoin in it. you can get it through, for example, I don't know, index or something like this, like this kind of shielded Bitcoin thing, right? And you would get out of like as an output of this, you know, kind of getting through the indexer, you would get as an output this shield, like encrypted note, which would effectively be your note kind of attesting the fact that you have your Bitcoin shielded now. And in case you want it back, you can just get this shielded note, you can put it through the verifier, through the decryptor of the PIPE, through the, through the, through the decryptor of the Witness Encryption and get your keys back. It's, it's completely self-custodial." }, { "speaker": "stephan", "time": "33:06", "start": 1986.0, "text": "Okay, and that would be like exiting the system or pegging out per se. And so I guess the difference is I'm understanding you then, it's like you could have something like a federation or something like a system, but there's not a bridge operator. Is that right? Yes, yes, because why?" }, { "speaker": "misha_komarov", "time": "33:25", "start": 2005.0, "text": "If you can do it just all by yourself, why, why do you need a bridge operator? I mean, sure, you can probably use services of some people if you don't want to mess like with all of these ciphertexts, etc. You can use services of people who will help you decrypt like a large bulk of the ciphertexts and then kind of finish the computation yourself just to make life easier for yourself. Sure, if you don't want to mess with ciphertexts at all, you can buy maybe use services of somebody who would be willing to like do an atomic swap between Bitcoin and shielded Bitcoin. Yes, absolutely. But like if you trust them, if you don't trust them, just do it all yourself. Like don't, don't," }, { "speaker": "stephan", "time": "33:59", "start": 2039.0, "text": "don't. And so do you see this, I mean, coming back to this is kind of for larger Operators or larger people, right? This is not necessarily for like people to do on their mobile phone, right? That's not really the context. Yeah, yeah. I don't think that people are going to be doing this on," }, { "speaker": "misha_komarov", "time": "34:14", "start": 2054.0, "text": "on, on their phones. Like, I mean, as I said, like for example, if somebody wants to, if somebody like hides, it's like trying to, well, not to hide, but kind of, trying to not, not to give up, not to give, not to give out too much information about their treasury charter, for example, right? They could just kind of do that. So it could make sense then" }, { "speaker": "stephan", "time": "34:30", "start": 2070.0, "text": "for like, I guess, capital markets, operations in Bitcoin, like Bitcoin capital markets kinds of operations where they don't want to dox what they're doing on chain. Yes, exactly, exactly. And so then people can deposit into the construct, let's say, or like how, and I guess that's the other thing I'm trying to understand. Is it kind of like you could have one, as you said, like one big shared pool, so that could be like Ten companies worth of Bitcoin are kind of in that pool, but in different amounts, and then you would have a shielded note that allows you to, let's say, trade around inside of that. Like, so as an example, maybe exchanges or Bitcoin financial service providers are also, like in this context, could they also be part of that, and then you're trading around inside of that pool without doxing how many coins you've got or what you're doing? That's the idea? Yeah, I mean, okay, first of all, let's" }, { "speaker": "misha_komarov", "time": "35:22", "start": 2122.0, "text": "be, let's be, like, you know, careful with the word doxing, because, like, you know, there are, there are mechanisms and the design of, like, you know, people who are thinking about, of, like, the shield of Bitcoin, which do allow. Okay. Is that similar to like a viewing key" }, { "speaker": "stephan", "time": "35:36", "start": 2136.0, "text": "kind of concept? Like I know some of, like, some of these, like, they have like, an idea where it's normally hidden, but there's a viewing key which you can show for compliance reasons, that kind of thing." }, { "speaker": "misha_komarov", "time": "35:45", "start": 2145.0, "text": "Yes, yes, yes, yes, yes, yes. The same kind of idea, yeah. Yeah, it's not about like doxing or non-doxing. It's like selective, it's like selective disclosure, let's say. Yes, yes, yes, yes, yes. If you want to, if you're required to. So, and speaking of like your previous question about if there are like, you know, kind of different participants and every, every single one of them, they have their own kind of shielded notes for their own kind of, you know, amounts. Like, once the transfer is happening, like it's kind of the same, it's kind of the same as like people do on Zcash, right? And because it's basically kind of the fork of like that old, old design, which kind of evolved over years as a separate system, back to Bitcoin, right? So pretty much in a similar way as those people do, like in here, once you have your encrypted note, you're like able to, if you're sending it to somebody, you're like, you're, you're sending it, like, you're sending a note with a certain amount inside of it. You have, you have a different one in like a different UTXO, which is kind of your change. Then you submit a nullifier to like the previous node, so you could indicate that this, this, this node was already spent. And then you kind of end up owning different nodes with like different amounts in it. And once you want to peg out, you just got to go around and find this ciphertext which has enough of Bitcoin locked inside of it, so you could effectively decrypt your Bitcoin from it." }, { "speaker": "stephan", "time": "36:57", "start": 2217.0, "text": "Okay. And then, like, I guess, can you give us an idea what this looks like on chain? Like, let's say you'll, maybe just walk through an example, like you deposit some Bitcoin, you trade around inside the shielded pool, the shielded note, and then you withdraw. What does it look like on chain?" }, { "speaker": "misha_komarov", "time": "37:14", "start": 2234.0, "text": "okay, let's talk about that. The deposit on-chain is effectively a transaction, just a single regular Bitcoin transaction, into, like, into effectively a public key which corresponds, which you know, and you have verified that it corresponds to the ciphertext you have on your hands. So it's just a single transaction, like regular transaction. The transfer, like the Shielded Transfer on-chain, is effectively, is effectively a... A Bitcoin transaction with about 700 V, vbytes in like the upper term or whatever, like of an encrypt, like of an encrypt, of an encrypted ciphertext in there. So it's like three or maybe four times larger than the average Bitcoin transaction, so it's kind of not that much. Like it's, yeah. So that's, that's, that, that's the, that's the, that's the on-chain footprint for the transfer. The on-chain footprint for the withdrawal is, well, I mean, once you found the ciphertext, which has enough of Bitcoin like locked, locked inside of it, so you can get your Bitcoin back, it's again, just a withdrawal, like just a single transaction of withdrawal. There is a little bit of a caveat though, that for some people, or like for certain purposes, like kind of, you know, just all of this All of this vague, well, like, all of this, not like vague, all of this, like, kind of large pool of different ciphertext, which do have different amounts, amounts of Bitcoin locked behind them, might be required to be kind of, you know, just rebalanced for the sake of convenience, or like somebody might come in, like, put up some kind of market fix or whatever, who would be, who would be kind of, you know, willing to" }, { "speaker": "misha_komarov", "time": "38:44", "start": 2324.0, "text": "kind of get from people, you know, deposits or like ciphertext, which have more Bitcoin behind it, and give them, like, back, for example, three or four, like, some amount of, like, ciphertext, which have less amount of Bitcoin behind them, like denominations, right? This is like, just a, like a, like a, like a," }, { "speaker": "misha_komarov", "time": "39:03", "start": 2343.0, "text": "like a pool maintenance, a pool maintenance operation. So, there might be something like this happening as well, but like" }, { "speaker": "stephan", "time": "39:09", "start": 2349.0, "text": "We'll see. Okay. But at that point, because these ciphertexts are quite large, that's going to be technically more challenging. Of course, this, what we're talking about here is for like professionals, right? This is not just like everyday guy on the street. And that's completely optional. That's completely optional. They can just opt out and not to do it. Just on the security side of it, like what's the overall kind of security of it? Like how do you, how do you make sure it's safe? Like obviously right now there's been all these hacks, so it's kind of, it's top of mind for everybody, right? Whether it's like the liquid stuff or the Coldcard stuff or whatever. How do you make sure it's safe? Yeah." }, { "speaker": "misha_komarov", "time": "39:42", "start": 2382.0, "text": "Okay. Let's talk about that. So there are actually, well, maybe there is like maybe one point which, you know, going on security, which is worth kind of highlighting kind of explicitly, is that, well, Witness Encryption itself is like no matter, well, okay, it's, it's actually pretty, it's actually pretty level, right? Like Witness Encryption is only 15 years old. At this point, different, there were different proposals, different schemes, different approaches on how to actually induce that practically, and, there was a recent paper which induces it from well-known assumptions. So, like, we're, like, you know, the industry is getting there, like, we're academically getting closer and closer to just having it induced from, like, standard assumptions. And, effectively, like, on our side with the description scheme is, like, kind of, again, it's pretty novel. So, we are kind of already running for maybe half a year, maybe a bit more, you know, these kind of theoretical challenges for people willing to crack it, you know, just kind of take and be able to take an attempt, and, we're happy to, like, give them one of the rewards or, like, guarantees or whatever. If they're able to, like, crack it, we have certain submissions because we, you know, have certain patches, certain fixes, and so, like, the usual security work, you know? And, closer to the end of the year, we will be actually going out with the implementation. Like the, of the, of the Witness Encryption, and like the PIPEs themselves will be closer, closer to like having something, you know, just the code out there, not just papers. And, we hope that we're going to be able to run, on-chain challenges, like so people will be able to just Go and like try out the implementation, not just papers, not just theoretical tasks, not just, hey, like there is some caveat in here, like a theoretical construction, right? But so they would be able to take the code, take a crack at it, and if they're able to like break it, they, they, they can, they can get the Bitcoin will lock behind that. So we will have that on-chain challenges running for quite some time as well. And yeah, like I want to encourage everybody who's listening to this, if you think you're like savvy in theoretical cryptography, please take a crack at it. Like we are very happy to hear from you. If you think you are very savvy in cybersecurity and like code analysis and all that stuff, fuzzing and everything, please take a crack, please take a, take a, you know, do your take on the implementation closer to the end of the year. We're happy to hear from you if you're able to like, if you're able to attack this somehow. Sorry. Okay," }, { "speaker": "stephan", "time": "42:12", "start": 2532.0, "text": "Okay, great. So summarizing, yeah, we've spoken about PIPEs v2, this concept of, Witness Encryption, doing like vaults and, Shielded Bitcoin. Any other closing thoughts for people just as a final takeaway?" }, { "speaker": "misha_komarov", "time": "42:25", "start": 2545.0, "text": "Well, I hope, I hope we will be able to convince people that there, that there is a way to do more than, to do more with their Bitcoin without, trusting a lot of people. So at some point, we'll get there. Okay," }, { "speaker": "stephan", "time": "42:41", "start": 2561.0, "text": "Okay, great. Well, Misha from Allocinit, thank you for joining me today." }, { "speaker": "misha_komarov", "time": "42:45", "start": 2565.0, "text": "Yeah, thanks. Thanks for having me." } ] }