S15 E58: Liam Eagen, Robin Linus & Jonas Nick on Shielded Client Side Validation & Bitcoin Privacy

0:47Vlad CosteaWelcome to the Bitcoin Takeover Podcast. This is Season 15, Episode 58. I can't believe it's been such a long time. And we are live with the creators of private client-side validation, a concept that was first created by someone who might just be Satoshi according to HBO, that was made private according to some recent research in math and cryptography with zero-knowledge proofs. And it's super cool. The story behind this interview is that basically Robin Linus, who is on the show with us, sent me a message and said, are you still upset that Bitcoin is not private?

1:25Check. Check this out. You know, and he sent me this paper, this beautiful paper, which is a collaboration between Jonas Nick, who is on the show, and Robin Linus and also Liam Eagen. The three of them are from Blockstream and ZeroSync and Alpen Labs, which is a very beautiful collaboration between companies. And I'm very proud of this. I'm going to feel like an idiot for about an hour interviewing them. But I think we sort of figured out something for Bitcoin privacy, which previously did not exist. So welcome to the show, guys.

1:59Liam EagenHello.

2:00Robin LinusThank you.

2:04Vlad CosteaOkay. So first of all, I think it's useful to mention that Jonas Nick has been on the show once before, and it's the second time this season that Robin Linus joins. The previous time he spoke about BitVM, so you can check that out. It's Liam's first time, and I guess he also has some interesting stuff. Maybe I can get you solo to talk about Alpen Labs. But my first question for you right now is, what is client-side validation, and how did you make it private?

2:37Liam EagenFor me?

2:38Vlad CosteaOr if you want to pick that up, sure.

2:41Liam EagenSure. So client-side validation, it kind of follows from a simple observation that the blockchain is invented to prevent double spending, but it actually does two things in the case of Bitcoin. It prevents double spending, but it also validates all of the transactions that are published into a global public ledger. And so client-side validation, which Peter Todd wrote about a long time ago, is the idea that rather than putting the transactions on-chain to be validated, we can keep them off-chain and only put commitments to transactions on-chain.

3:30The trouble with that, simply, is that in order to validate a transaction, you have to validate its whole history, all of the transactions that came before it. So that history blows up exponentially over time. And with the power of SNARKs and zero-knowledge proofs, we can compress that history and also kind of get privacy for free. So that's my little spiel about client-side validation and how we made it private.

4:03Vlad CosteaI mean, it sounds simple, but you said we get privacy for free. So it sounds maybe a little bit too good to be true. Is there any trade-off?

4:15Liam EagenSure. There's lots of trade-offs. I mean, previously, before the recent advancements in the SNARKs, it's potentially not even possible. We would have to do a lot of proving on the client side, which is expensive but increasingly feasible. Clients also have to keep more state because it's not on the blockchain, just accessible. The protocol itself has some kind of complicated corner cases that are discussed in the paper, but we can get into it maybe. But yeah, the privacy part, though, I think is pretty straightforward, right? Because the history is never shared, and it's compressed with SNARKs.

5:00And so because the history is kept secret and a few little tweaks, the privacy really does actually come pretty naturally for free in this model.

5:13Jonas NickYeah, I think maybe it makes sense to compare it a little bit with what people call existing client-side validation protocols to really explain the difference. So what me, initially, so Liam, he somehow got this idea of, or at least he proposed this idea to me. Robin wasn't involved at the time. He was doing zkCoins, which is sort of a parallel invention anyway. Liam, he told me about this CSV thing. I was working on some version of Tornado Cash for Simplicity. And Liam convinced me, you should look into client-side validation because it's strictly better than what you're trying to do here.

6:00And by that, I mean Tornado Cash on Liquid or Bitcoin with advanced scripts. And why is it better? I think this idea that you don't have to post transactions to the blockchain in order to build an L1. So this is what to me at the time was really mind-blowing. Peter Todd had already figured this out in 2013, but in 2023, I still wasn't aware of this until I had this realization after talking to Liam that this is actually possible. So in existing client-side validation protocols, like Taproot Assets and RGB, you still post essentially Bitcoin transactions to the Bitcoin blockchain, which has some downsides.

7:01For example, Bitcoin transactions by themselves are large. There's some overhead and also, well, they reveal a lot of information or reveal a transaction graph. So the fundamental idea of client-side validation is that you can send the transaction directly to the receiver, but as Liam said, you can compute what is sometimes called a commitment. In our case, we call it a nullifier. You can compute this piece of data. Let's maybe stick with commitment from now on. Compute this commitment from the transaction and then just post this commitment to the blockchain.

7:40And this commitment is sufficient to prevent double spending, but this only prevents double spending. The receiver still needs to verify the transaction. And Liam already mentioned, you need not only to verify the single transaction that you get from the sender, you need to verify essentially a whole graph, a whole tree of transactions, because you not only care about whether this one transaction that you're receiving is valid, but also the previous transaction that the sender was spending is valid. So in order to do that, you need to verify this tree of transactions, which potentially grows very large, very quickly.

8:24And then the advantage over regular Bitcoin transactions, where we also verify all transactions, is not particularly large. So this is where the SNARKs come in or recursive SNARKs or our techniques. In our case, we build on proof carrying data, but that's sort of not really relevant.

8:51Vlad CosteaRight. So to summarize in a way that the average Bitcoin pleb will understand, you guys are adding more states to Bitcoin. State?

9:02Robin LinusActually less state.

9:04Vlad CosteaNo, I'm just joking. There should be no state involved. But once again, we're going to get in arguments with the BitcoinOS people. I think that's our intent, right?

9:15Robin LinusI think the perspective, it's important to know like the protocol increases the on-chain throughput to about like 100 transactions per second, then it gives you perfect privacy, obfuscating both the transaction amounts and the graphs. I think that's the best high level description of why it's interesting.

9:35Jonas NickYes, but maybe one big elephant in the room is that when we're talking about Shielded CSV, it's sort of a system that is entirely separate from Bitcoin. So it's built on Bitcoin's blockchain. It gets the double-spend security from Bitcoin, but it's a separate system. So somehow you need to connect the Bitcoin world and Shielded CSV. You need to be able to send coins from the Bitcoin main chain into the Shielded CSV system and back. If you really want to add privacy to Bitcoin, which is our goal here, so you need to have actually some sort of bridge between the two systems. For example, a BitVM-based bridge that would potentially make this possible.

10:29Vlad CosteaSo does it work sort of like a sidechain where you peg your coins and you're going to get them on this second layer where you have 100 transactions per second, zero-knowledge proofs?

10:43Jonas NickYes, except that it's not a separate chain. But yeah, it has a similar notion of peg-ins and peg-outs, if you want to call it that.

10:52Liam EagenIt's a bit more like a roll-up sidechain, but yeah.

10:57Robin LinusIt's a way to use the main chain space more Efficiently.

11:02Vlad CosteaIt sounds very cool. And I did read part of your paper. I'm not going to pretend I understood everything, but I have to ask you, how will the average user make use of this? How will they interact? Is there any wallet that you envision that will have this feature or do you want to build it from scratch?

11:23Robin LinusWallet is like a last consideration. I think, first of all, we would have to implement the protocol.

11:33But yeah, it would be like the long term vision should be, of course, to have at some point nice wallets that make it very easy for end users to send Bitcoins around so that they don't have to think about if it's like they don't have to think about privacy or whatever. It's just a handle for them under the hood and mostly transparent for them. And it should all be like well integrated with the Lightning Network such that when you're on a Shielded CSV, you can pay anyone within the Bitcoin ecosystem as long as they are connected to the Lightning Network.

12:08And yeah, the Lightning Network would be like something like the central settlement layer also to other L2s.

12:16Vlad CosteaIt's funny you mentioned the Lightning Network because it seems like the past year has been pretty pessimistic when it comes to it. Some people have given up on building on it. Others are arguing that it should be more centralized. There's e-cash that's being built on top of custodial Lightning. And it seems like it's moving away from the narrative through which it was first presented. Yeah.

12:44Robin LinusI think it's pretty clear that Lightning doesn't work for end users as well as people had wished it. That has been shown quite clearly, I think. It has not been adapted the way that people hoped it. But as a settlement layer between different layers such as you mentioned, e-cash or Shielded CSV or rollups or sidechains. I think like as a central settlement layer, it can work really well. It just doesn't work very well for end users. That's why there are all these custodial solutions.

13:21Vlad CosteaI mean, that was one of the first use cases that was presented for the Lightning Network. That it can be this platform for atomic swaps, right, where you can swap between coins. It's blockchain agnostic. At the time, people thought they could do this with Litecoin, Bitcoin, maybe also Monero and get rid of centralized exchanges. That never really happened. But it's good that you're bringing back this use case of using Lightning as the settlement layer between different layers or networks.

13:54Robin LinusSo that there's problems like there's that free option problem which make these atomic swaps quite problematic in practice. And I think that the original use case was mostly payments. That was what people promised. That Lightning would be great for payments, but it turned out that it is not for end users. But I think as that central, as that settlement layer with like more user friendly layers on the periphery, that that could work really well.

14:27Vlad CosteaI did interview one of the lead developers of Decred and he told me that their blockchain, which is one of the oldest altcoins that is still alive, has implemented Lightning Network in a way that's almost 100% efficient. So it doesn't have failed transactions. But if Bitcoin was to do that, we would need like a couple of soft forks to enable that.

14:51Jonas NickIt sounds like something an altcoin dev would say. But speaking of, speaking of Lightning, so that is something that is currently, so we have a bunch of open problems in the Shielded CSV space. 100% compatibility with Lightning is one of the open problems that we're looking into. What we do support right now is atomic swaps between the Bitcoin mainchain and Shielded or atomic swaps sort of between Lightning and Shielded. But that still requires shielded transactions. And since Shielded transactions or commitments use the Bitcoin blockchain, you still need to wait these 10 expected 10 minutes for confirmations to have your transactions confirmed for these types of swaps or instant transactions that are compatible with Lightning that are trust minimized. They are not. They're currently an open question. Right.

15:56Vlad CosteaSo you made fun of Altcoin developers, but I got to ask you, how does this Shielded client-side validation layer compare with Zcash or Monero in terms of privacy?

16:07Jonas NickYeah. So I think one of the motivations actually was to with Shielded CSV was to actually show, OK, there is an alternative approach to private cryptocurrencies that seems to be better in many dimensions at least. And it essentially has the same privacy. There are some very minor, I think, differences, but essentially has the same privacy. But there are no big zero-knowledge proofs on the blockchain. Only the receiver needs to verify zero-knowledge proofs and needs to receive these zero-knowledge proofs. The blockchain is entirely unaffected by large proofs.

16:51Liam EagenYeah, I think it's worth maybe going over. So currently Monero uses ring signatures, which have a small anonymity set, or relatively small, for each transaction. And Zcash uses kind of like the nullifier scheme of Zerocoin with Halo 2. And so it uses a proof system with no trusted setup, and it has perfect privacy over the whole chain. The Shielded CSV has the same kind of privacy. That is, you learn no information about the transaction given the proof. But to Jonas's point, yeah, you keep the proofs themselves off chain.

17:32And one interesting consequence of that is that you are able to use more proof systems feasibly, right? So if you put the proofs on chain, you probably can't use something like a STARK, say, for a transaction proof because it would be too large, be tens of kilobytes. Whereas in the Shielded CSV world, that's fine, right? I mean, it's larger, but sharing it peer-to-peer, it's a negligible additional cost.

18:07Vlad CosteaYeah, at this point, I have to remind everyone, as in the listeners, that this show is sponsored by SideShift.ai. And SideShift, basically, if you get paid in stablecoins, and that's an ugly reality of this industry that a lot of companies choose to pay you in stablecoins. And maybe you don't want to hold on to that and you want to swap it instantly for Bitcoin or for whatever else you want. You even find meme coins if you want to speculate on that one. But anyway, you can swap CBDC wannabes for free market money on SideShift.ai.

18:41Check that out. And thank you, SideShift, for sponsoring. And I also have to mention that you said something about STARKs and StarkWare was nice enough to sponsor the show, except that they are advocating still for OP_CAT to be enabled on Bitcoin. They believe that they can build the system that they already have on Ethereum for extended scalability and privacy and bring that to Bitcoin. And OP_CAT would facilitate this transition of their system. And I was going to ask you, what do you think about STARKs and StarkWare's approach to doing STARKs?

19:23Liam EagenWell, I think STARKs are pretty cool. I don't know.

19:28Vlad CosteaSo they come to Bitcoin because I've heard, for example, when I interviewed Orkun from Citrea, he told me that, you know, his system is better, basically.

19:38Liam EagenOh, interesting. OK, well, I didn't watch that, so I won't. I mean, I'm not sure what he said, but I think that, yeah, so the OP_CAT stuff is often cast in contrast to the BitVM approach. You know, I'm from Robin originally, and I think that's also what Citrea is probably talking about. And the OP_CAT would give you things like covenants and would allow you to have a kind of proper SNARK or STARK verifier on chain. But that does have significant on-chain costs. So in practice, maybe people would still use a kind of hybrid optimistic approach.

20:22I don't know. I think there's probably more kind of hybrid approaches that are underexplored at the moment, but the proof of concept STARK on Bitcoin with OP_CAT is really cool, in my opinion.

20:41Vlad CosteaWhen I interviewed Peter Todd, who might be Satoshi according to HBO, he said that STARKs are basically an argument against activating OP_CAT on Bitcoin, because he doesn't believe that bringing that to Bitcoin is a net positive. He thinks that it can bring some MEV situations and possibly some shitcoinery.

21:08Liam EagenYeah, I mean, that's definitely a risk worth considering. But I mean, in terms of building a bridge, it's necessary to verify SNARKs, basically. So whether you use BitVM or whether you use OP_CAT and a STARK or whether you use some other thing, it's not an argument, I think, so much against STARKs per se as it is against the concept of the bridge in and of itself or like a roll up or something like that. I don't know if other people have thoughts about this.

21:40Robin LinusI have a bit different opinions. First of all, I would not frame CAT as a covenant proposal. It is true that CAT can emulate covenants in a very clunky and expensive and weird way. But I think if you really want covenants, then we should discuss covenants proposals such as TXHASH or introspection opcodes as we have them on Liquid, because they are much cheaper in terms of fees and much easier to work with for developers. Therefore, also much more secure for users. And yeah, I think that's a way better approach.

22:24The other thing is if we want STARKs, I guess we need CAT for that. And it might be an argument to activate CAT if we want STARKs, but I think then we should actually talk about STARKs and not about covenants. I think it's quite dishonest to say CAT is a great covenants proposal because it's certainly not. And the other thing is, of course, that the scope of CAT is quite large. Like it has only 10 lines of code or something and people keep saying, yeah, it's very easy to review these 10 lines of code.

22:57But that's actually quite a silly metric because the number of lines of code doesn't say anything really about what the opcode does. And the thing with CAT is that it enables everything in at least some clunky way. And it's hard to reason what it can do and what it cannot do. And the fact that it is pushed by fraudsters like Eric Wall and Udi, who have been known to be involved in pretty much all of the biggest scams in recent history, like FTX and all that shit.

23:32It's what they want to do with it after they have been attacking the chain with their spam attacks. And it's quite a complicated topic, I would say, with CAT. But I am definitely open to debate how to activate some kind of proof system on Bitcoin, because I think that is necessary for the future, for sure. Proof systems are the future, for sure.

24:00Vlad CosteaI did see recently, I think it was yesterday, that someone posted that they can create OP_CAT without the OP_CAT soft fork. Did you guys read that?

24:09Robin LinusIsn't it like some version of what Jeremy Rubin did with like this?

24:14Liam EagenIs it the Bitcoin PIPEs paper? Yeah. I have not read it yet, but I started reading it. Nope.

24:24Robin LinusI think it's like that.

24:27Liam EagenYeah, it's a functional encryption thing or something like that.

24:31Vlad CosteaYeah. It was someone with a Russian name. I wish I saved the link so I could talk about it here. But to me it was interesting that people are finding workarounds. In the absence of consensus on what we should do next, people are just searching for ways to do it without any sort of soft fork. But unfortunately, it's not the most efficient way most of the times. It's just a workaround. It's not necessarily the best way to do it. It's not the most block space efficient way. And there's also, I'm not sure if you guys looked into BitcoinOS by the guys from Sovryn, Edan Yago.

25:16Robin LinusI mean, I know it, but I haven't talked very deeply into it.

25:19Vlad CosteaI had him on my show and he said that he basically figured out how to do everything without soft forks and Bitcoin can stay the same forever.

25:29Liam EagenIs it not a BitVM thing? I'm not sure.

25:33Vlad CosteaIt is a BitVM thing, but it's not quite BitVM. I think it's BitVMX or something. By the way, why are there so many versions of BitVM, Robin?

25:45Robin LinusIt's a hype topic. You can make money with it, with the hype.

25:56Vlad CosteaWell, you're a PhD student now at Stanford.

26:00Robin LinusYeah.

26:05Jonas NickI mean, BitVM is definitely a real breakthrough because now we can build these bridges. Otherwise, Shield would be much less interesting if we didn't have BitVM. So, I don't know how practical BitVM will be. It seems like a lot of people think that it will be practical and betting a lot of money on it. So, Shielded CSV sort of depends on it unless you actually want to do these, you are adding a soft fork to Bitcoin. Because then there are potentials for actually not having like a BitVM based bridge, but rather verifying the bridge contract directly on chain, not optimistically, whatever.

26:50I don't know how realistic that is, but it's at least possible and would have maybe some better security even than BitVM. But we see how that plays out with BitVM. Yeah.

27:07Vlad CosteaSo, I got to ask you guys coming back to the topic of shielded client-side validation or SCSV or whatever you want to call it.

27:17Jonas NickCSV, Comma separated value or check sequence verified.

27:23Vlad CosteaWhy do you bother with this when you can just build a swap to Monero and enable basically Bitcoin to be swapped instantly for Monero and have more privacy or Zcash or whatever? So, why would you want to build this complex feature on Bitcoin, which most users probably will not figure out, or at least not initially, when you have other blockchains to fulfill these features? And I think Alexey Zamyatin is the champion of this approach. He basically said, why bother building something different on Bitcoin when you have Ethereum for smart contracts and you make a bridge and you can use the smart contracting features with BTC? And that's the way in which he chose to do his BOB project. So, why not do the same with Monero and Zcash?

28:16Robin LinusPeople want to use Bitcoin, no? Obviously, the market is quite clear that this is the most valuable asset and over time it just gets more obvious. I mean, Bitcoin should be used as a currency and I think what we are doing here is trying to make it more usable as a currency by increasing throughput and improving the privacy.

28:42Vlad CosteaWell, but you have a bunch of guys who get on stage probably even today in Amsterdam. I guess by virtue of being here, it just means that you guys were not invited to speak in Amsterdam, which is a shame, I guess. Shame on you a little bit, Bailey.

28:57Robin LinusI'm just here in California, so I didn't have time to go to Amsterdam. I didn't want to fly that much.

29:02Vlad CosteaAnyway, there are a bunch of people on the stage of Amsterdam who will say you should never spend your Bitcoin. You just buy and you hodl and it doesn't matter if you have no privacy. All you have to do is just vote for Donald Trump because he says that he's going to allow you to self-custody and he will not do another Emergency Act 6102 or whatever that one was called to confiscate your Bitcoin. And that's all. You just hodl. You can even keep it on exchanges if Trump wins because he says he's a good guy, right?

29:35Robin LinusI totally feel your cynicism. I absolutely agree. I'm not at all a fan of Donald Trump. I'm just in general not a fan of politicians, so I do understand that it's a bit weird that the Bitcoin community is simping so hard for politicians. And I think we should get back to the original cypherpunk's values, which in particular meant that we create a money that is just open for everyone and a kind of money that just cannot exclude anyone from the economy. And I think Bitcoin is the best shot that we have.

30:13Monero is interesting, but Bitcoin is certainly the bigger brand. It has more developers behind it, I think. And it's more stable as an asset, like as a currency as well. And I think we have to improve this because it's our best shot.

30:35Vlad CosteaWell, I very much agree with that. It's just that I don't see consensus in this regard. And I'm surprised that you guys got any funding at all to proceed with your Shielded Client-side validation project. I'm actually curious if there's going to be funding for putting that into practice. Probably.

30:56Robin LinusThe good thing is it doesn't really need any consensus changes, right? So you don't need to be in consensus if this is a good thing or something like that. We don't have to ask Michael Saylor for permission, right?

31:09Vlad CosteaBut he will tell users to stay away because they're gonna whatever, taint their Bitcoin. By the way, is there any such concept as taint once a coin has been on this protocol for shielded client not shielded? Oh, it is shielded client-side validation. Once Bitcoin is sent to an exchange, is there anything that can go wrong?

31:33Jonas NickI mean, the only thing that the exchange sees is that they receive a valid coin, but they don't know where it comes from or what the history of that coin is. I mean, they could reject it just because it's a shielded coin that they can always do. But it doesn't have the regular concept of taint.

31:55Vlad CosteaYeah, so basically, of course, we're about Litecoin right now.

31:58Robin LinusWhen you're bridging, right?

32:02Jonas NickWhat exactly? When you're moving coins out of the shielded system, that could be visible depending on how you do it. If you maybe swap it correctly, then it's maybe not visible, but it could be visible. But that's also the reason why just swapping into Monero doesn't really work. You can swap into Monero, but then you have to hold Monero also because if you swap into Monero and then immediately swap back, that's also visible on chain because it can correlate amounts and whatever. So I don't see this as a great solution.

32:38Most people, I don't think, want to hold Monero just to get privacy. At least, I don't know, I would want to just concern myself with Bitcoin. That's already complicated enough and build protocols on top of that.

32:57Vlad CosteaSo there could potentially be this concept of taint by virtue of not having a clear history. So if exchanges have this KYC/AML policy that pushes them to always ask for origin, they can freeze any funds incoming from the shielded client-side validation layer and then ask for more information about where the coins have been and stuff like that.

33:28Jonas NickYeah, but that is the same as them receiving Lightning transactions and then asking for KYC. I think they can do this once and someone will complain and maybe then no one will ever send shielded coins to them because they cannot distinguish, they either have to request KYC for all shielded coins or for none of them because all of them look the same to them. Maybe they have different values. They could ask for larger values. That, of course, is visible to the receiver.

34:02Robin LinusAlso, to some degree, it's a matter of adoption, actually. If we imagine a world where the protocol is highly adopted and most people are using this shielded transaction instead of standard transactions, then you won't be really able to blame anyone for using that protocol in any way. So if we get it into the market quickly enough and if it can spread quickly enough, then I think that would protect most people from these kinds of surveillance from governments.

34:39Liam EagenThe fact that it's scalable and private is a nice virtuous property in that regard because you can use it as a scaling solution and you sort of contribute to the anonymity set in a pro-social way. It's not more expensive to be private. It's actually cheaper.

35:03Vlad CosteaSo once you do get on this layer, are there any transaction fees to pay? And if yes, then where do the fees go?

35:14Robin LinusThe fees go to publishers. Publishers batch shielded transactions and these publishers, they pay fees to inscribe blobs of data into the blockchain and they pay them to the miners. So the users who want their commitments to be inscribed in those blobs, they have to pay the publishers.

35:39Vlad CosteaSo even though you have 100 transactions per second and all of these features, blobs do have to get inscribed into the base layer. Yes. And it can potentially be more expensive than the average on-chain transaction just because it has privacy and there can be a premium on it?

36:00Jonas NickIt's always cheaper because the commitment is always 64 bytes or in Bitcoin tech parlance, 64 weight units. And the regular and average transaction is I think 450 weight units. And that's where you get the about 10x speed up from. So regardless how large the shielded transaction is, the commitment you need to inscribe into the chain is 64 bytes.

36:34Vlad CosteaSo let's say that you do get 100 transactions per second on this layer. And then you're going to get until the next Bitcoin block. No, you're going to have 6000 transactions per minute. And let's say 60,000 per 10 minutes. And this amount of data, 60,000 transactions is only going to wait 40 bytes on the base layer, assuming that it reaches full capacity?

37:09Robin LinusNo, no, that would be a full block then. Like for these 100 transactions per second, you would need to have a full block full of shielded transactions.

37:18Vlad CosteaOh, bummer. I guess that would be cool, though, if you could only have this one blob of just a few bytes to account for a bunch of transactions.

37:37Robin LinusThat's also another nice feature that if you have a block full of shielded transactions, then you can process way more transactions. But it's way less verification for the full nodes than in comparison to like a block that is full of regular Bitcoin transactions. Also, it doesn't bloat the UTXO set. So it's very good for the base layer. Like it's much lighter on the base layer, even though it has way more throughput and way more privacy.

38:07Vlad CosteaSo in popular terminology, it's sort of like a block size increase and the privacy addition, but without any soft fork and without any other change to the base layer. It's something that exists outside of the average consensus. Not every node has to run it, only those that get directly engaged in it. And I have to ask you, what happens if your node, for some reason, while you're in the middle of receiving a transaction, it goes offline?

38:42Robin LinusDoesn't matter. It receives the coin when it gets back online.

38:45Vlad CosteaSo it's not like lightning.

38:48Robin LinusNo. There is a component that you have to transmit data. Like if I send you a coin, then I have to send you the coin proof, the history proof. But I can finalize the transaction without you. So I can just send you money and then make that commitment on chain. And then I put that coin on some server or whatever. And then I go offline and a week later you come online and then you look at that server and then you find that coin and then you receive it. And if that server just deletes it, then I can resend you the coin.

39:25Vlad CosteaIt sounds a bit like what they're doing right now in Grin or Mimblewimble protocols, where if you don't come online in 24 hours, the transaction gets canceled.

39:36Jonas NickIt's a bit different to Mimblewimble as far as I understand Mimblewimble, because in Mimblewimble, you need to really sender and receiver. They have some sort of back and forth communication. So both need to be sort of online in some sense at the same time. Whereas in Shielded, it's just unidirectional. So we call it's a one way anonymous communication channel. You need some way to communicate to the receiver, but it just needs to be one way. And ideally it's anonymous, because if you just upload it to the server and someone just retrieves it from the server, then you're leaking a lot of information to the server.

40:18So that is something that if you want to actually implement that you want to prevent.

40:23Vlad CosteaYeah, I just remembered something. And this is sort of a way to sidetrack from the main conversation. But I got something very cool in the mail today. And it's the new Cryptosteel metal plates device. And they're not sponsoring the show anymore. It's just that this is sealed. They came up with a new concept. And they launched it today in Amsterdam. It's called Seed12. It's very tiny. It's more affordable. They managed to make it modular. So that the expenses for everything are lower. They look like boxes of nails.

41:01I'm not sure if it's visible. I like the design. And you should check that out. It's on cryptosteel.com. They are the innovators of metal plate backups. This is pretty cool. Honestly, it's very tiny. You can hold this in your hand. And I think if you use promo code BTCTKVR, you can still get 10% off your order. I'm not sure about that. But anyway, I got to talk about an actual sponsor of the show. And that's LayerTwo Labs. And Paul Sztorc is a big fan of the show.

41:32He actually listens. He's trying to push drivechains. Right now he gave up on the BIP. And he is trying to convince miners to activate it with a simple majority. And he calls that a Core Untouched Soft Fork. And the philosophy behind that is not just to increase the throughput of Bitcoin, but to bring basically every feature on a sidechain. And I'm actually curious what you guys think about this.

42:00Robin LinusPaolo is one of the most funny Bitcoiners out there. I think it's very entertaining to say something about that idea.

42:12I like the idea in general. In general, I think we should explore different ways to enable bridges. BitVM is one approach, but it's mostly like a clunky workaround to hack it into Bitcoin. And BIP 300 is like a more clean approach, even though it has all kinds of trade offs. And some people are angry at these trade offs. And they think they could mess up miner incentives. And there is definitely some truth to that critique. And I can understand people who are against it because of that.

42:51On the other hand, I think these trade offs are okay because I don't really see how it would endanger the main layer. I see that the second layer or the sidechain security depends a lot on the main chain miners, but not necessarily that the main chain would be endangered in some way. So in that sense, it would be just a matter of the users deciding if they want to trust that the miners don't steal from the sidechain. And if they trust that, then it's kind of okay, I think.

43:26But the particular activation thing, I think it's a plausible way. But I also feel like it has a lot of potential for drama. And we'll see what happens. As always drama.

43:47Jonas NickI think that the Bitcoin community needs to make sure that any soft fork is not too chaotic, because it's just too much value at stake. So I would rather first see rough consensus. And I know that's very hard to build, or even impossible, maybe in some cases. But I think chaotic attempts at soft forks, they don't help anyone.

44:19Vlad CosteaI mean, technically, it's not chaotic, because this is how Bitcoin works. If the miners run a software in a large majority, then there's nothing you can do about it other than hard fork.

44:33Robin LinusThat's true.

44:36Jonas NickIt can still be chaotic, though. I mean, you need to make sure that the miners actually are all enforcing the rules, etc. And what if there's, well, there can't be a longer chain that does not that does not follow the rules. If, if most miners follow the rules. Yeah.

45:00Vlad CosteaInteresting. You guys are developers. I'm pretty sure you're not big fans of this political side of Bitcoin. But to me, it's interesting, because we have had narratives. Jonas, you mentioned something about rough consensus. And I think that term gets mentioned a lot without a clear definition. I don't think anyone knows exactly what rough consensus means. And they're gonna say it's all about economic nodes expressing their views. And then you ask yourself, well, who's an economic node and who isn't? And who gets to vote for this or express their opinion?

45:38And who doesn't? And what's the timeframe that is ideal for this? And for this reason, it's why we don't have a covenant soft fork. We don't have BIP 300. And a bunch of other proposals get buried before they even get a chance to be discussed. And it's a bit of a shame, because honestly, I do want builders to come to Bitcoin. And I do want this to be the chain that includes everything to make everything else redundant.

46:10Jonas NickYeah, I think how to actually do soft forks, there's no consensus, rough consensus, on even how to actually do soft forks. It's hard. It's an unsolved problem. It's undefined. Some people have proposals. But most I've seen, they just don't make sense.

46:27Robin LinusSorry. It's also a very delicate problem. Because like on the one hand, we want Bitcoin to be stable. If it's not stable, and if it's not very hard to change it, then it's kind of worthless. If it would be easy to change Bitcoin, and if it would be like if everybody could get in their software, then Bitcoin would be pretty useless, because it would be very easy to attack it or like to weaken it in ways that might be devastating. So we want Bitcoin to be hard and we want that process to be very rigorous and very slow also.

47:04But yeah, that's the other thing that we need innovation. It's not likely that Bitcoin will always be the best chain while all the other chains are innovating much faster. So it's hard to find the sweet spot there, I feel.

47:24Vlad CosteaThere's also something to be said about incentives, because right now the fees are still very low. And there are chains like Tron that actually right now have much higher fees for sending USDT or whatever. So the fact that the miners have invested so much money into their rigs, and they don't have the profitability that they expected after the halving. I do remember the fees were about $200 at the time, and the miners were having a good time. They were collecting a lot of fees. Now they get like 30 cents per transaction.

47:58It's not really what would support the Bitcoin economy in a couple of halvings. So if we don't get a healthy amount of subsidies for miners, then we can expect them to experiment with soft forks like drivechains just for the sake of creating side chains from which they can collect more fees. For them, it's just an attempt to get more revenue. And we do have to understand their incentives when we discussed. Of course, there is someone on Twitter right now who's going to say, you know, Bitcoin is over secured, maybe that these mining companies should go bankrupt.

48:36We're just going to mine from our laptops at home. I don't know what to say to that, if it's reliable or not.

48:48Jonas NickBut there are also other types of soft forks that might become more relevant in the future. I mean, this is extremely off topic. But anyway, which is, I mean, besides governance, there's also this question of post-quantum. So we will probably see post-quantum proposals in the next years. And there's also big question how we should deal with those. Because many people are starting to think, well, maybe Bitcoin needs to, at least Bitcoin right now needs to have a plan with respect to post-quantum. And then we will eventually have to do soft forks.

49:26And then which one? So this will be a similar question to functionality, hopefully not as politicized, but could well be and still, it's unclear how to even do those kinds of soft forks.

49:39Robin LinusAnother interesting dimension in particular in regards to Shielded CSV is that it might make sense if that protocol catches on, that we also think about increasing the block size at some point. Because since it is so much cheaper to validate CSV transactions, essentially, you just have to hash them. You don't need to verify any signatures or whatever. So it's very cheap for the main chain nodes to verify them. Then that means it's cheap to verify them. And the second thing is they don't blow the UTXO set, which is also a major scalability bottleneck.

50:25Since that is given, we could think about increasing the block size such that we can process more Shielded CSV transactions without decreasing the decentralization too much, since the verification is not much more expensive. The bottleneck would become the network then, of course. But I think at some point we can assume that networks are just way faster than the time where we introduced the 4MB limit.

50:56Vlad CosteaIs anyone else on the call in favor of increasing the block size any time in the future?

51:05Jonas NickI mean, I think that the whole client-side validation model definitely allows us to look at this question in a different way. Because now that transaction validation is not part of the consensus rules, it doesn't matter as much anymore whether you can... When you receive a block, you don't need to verify transactions. So if transaction verification takes a bit longer, then you don't care as much anymore as maybe right now. So for example, miners, of course, in order to be efficient, they need to be quickly verifying the block.

51:44But if transaction verification is not part of it, then transaction verification can take a while. But there are other questions. It's a huge topic. How do you do the initial block download? That would still be a problem because transactions are large. Then the Shielded nodes, they still have some sort of transaction validation, which is extremely compressed now that there's only 64 bytes of commitment in the blockchain. A lot of transactions can be in the blockchain. They need to verify all of them, at least build their sort of UTXO set.

52:20We haven't talked about it, but we have a similar concept to a UTXO set. It's more like a spent transaction output set. We call it nullifier accumulator. But whatever. Nodes need to keep up with that if they speak the Shielded protocol. So I think it's a big question, but definitely an interesting one because it changes, I think, how we look at blockchains in general.

52:44Robin LinusShielded CSV nodes, it's not time critical for them to verify the blocks. It's much more time critical for Bitcoin miners to verify the blocks. There's a big difference there, I would say.

52:55It wouldn't matter for them if it takes a minute or so to validate the block.

53:03Vlad CosteaSo Robin, what would the ideal block size would be for you? 16 megabytes, 32?

53:11Robin LinusYeah, I asked God and God told me the perfect block size is, of course, 32 megabytes. I have no idea. It's up to debate.

53:20Vlad CosteaI did interview Amaury, who has been the lead developer of Bitcoin Cash for a while, and he told me that the bottleneck should be at 32 megabytes. And it's just that maybe that you can build faster engines, but you still have to rely on roads and there have to be some limits. This is the way that he described it. And said that 32 megabytes is a pretty good limit.

53:48Jonas NickYeah, I think last time this question came up, the environment was very different. So I would rather see actual simulations and data before forming an opinion on that.

54:03Vlad CosteaBut how are you going to present that? Because it's very funny. People have been indoctrinated into believing that just because Bitcoin rejected the block size increase in 2017, we agreed to never increase the block size. And I don't think people who rejected it at the time did it because they were against in principle of increasing the block size, but they were not in agreement with the terms of doing it. They were not fans of the New York agreement. They did not to do it at the time under pressure.

54:34They believed it's healthy for a fee market to build up and for real demand to exist. And now that we have more stuff coming to Bitcoin and the fees are going to go high, of course, we're going to have another debate about this. And it can't just be a no offense, Jonas, about this. It can't just be just use liquid or just use custodial lightning. I guess users deserve something much better than this and a way which is truly trust minimized and does not rely on Fedimints or whatever.

55:11I'm going to get you guys so canceled after this interview. I'm not joking. This is, you know, controversial. You're not going to get any more funding after this.

55:25Jonas NickYeah, I mean, I'm not sure what to answer to this. I don't I mean, right now, it doesn't seem like there's huge pressure to increase. The block size fees are low most of the time, but maybe that can change in the future and it could also change very quickly. So, for example, like the example I have in my mind is always, sorry, post-quantum again, because then the signatures and the potential the signatures will be much larger than they are today. So if we had some sort of software with a fixed four megabyte block limit, then maybe we will only be able to fit one transaction per second into the Bitcoin blockchain.

56:10And that might change how people use Bitcoin. So in that world, and maybe it makes sense to increase the block size, but I don't know, I wouldn't want to commit to any single proposal right now. But I think the whole Bitcoin ossification thing doesn't make sense to me. It's just this would require predicting the future, for example, with respect to post-quantum and other cryptography. And that's just not possible.

56:44Vlad CosteaYeah, I did read some stuff about Lamport signatures being quantum resistant. And there was another type that was being presented two weeks ago in Frankfurt by a guy from Rootstock. I don't recall exactly the signature scheme.

57:00Robin LinusLattice-based signatures, maybe?

57:02Vlad CosteaProbably. Can you say it again?

57:08Robin LinusLattice?

57:09Vlad CosteaIt wasn't lattice.

57:12Jonas NickWinternitz?

57:13Vlad CosteaYeah.

57:16Robin LinusThey're just a form of Lamport signatures, essentially. It's mostly like an improvement.

57:22Vlad CosteaSo how do we get that? What's the best way?

57:31Robin LinusDisable the key spend path of Taproot transactions. That's the hard part, I think. The rest is relatively easy if you had something like Cat or something. I mean, it's also not that hard to disable the key spend path. It's just a bit weird to hack it in there. So currently the thing is, when we're talking about updates, we're mostly talking about new tapleaf versions. So that we have new script versions in Taproot transactions. And these Taproot transactions, they all rely on that Taproot tweak. So the script is essentially hidden in a public key.

58:20And the issue with that is that if we had quantum computers, then people could just attack that public key and bypass that script completely. And therefore we would need some kind of mechanism that says, hey, for this transaction, not this transaction, for this output, the key spend path is completely deactivated. So even if you know the key you cannot spend from it, you can only spend from the script. And then in that script, there could be some quantum resistance signature scheme.

58:58Vlad CosteaHow imminent do you think quantum computing breaking elliptic curve signatures is? Or when you think this can happen?

59:10Robin LinusLiam is the cryptographer here.

59:13Liam EagenBut I'm not a quantum computer expert. What was Scott Aaronson's most recent prediction? Does anybody remember? I think it was pretty soon or something like that, right?

59:26Jonas NickI mean, the point was of his post, I think, that in the past he said, you need to eventually deal with this. Whereas now he says, you need to have a plan. And that is the problem right now in the Bitcoin world. We don't really have a plan. And not only the plan is the problem, but also the plan would be simple, but a plan that actually works. And just increasing signature size by 20-fold, 30-fold doesn't solve a problem. And there are many additional problems that we would need to consider.

1:00:07For example, what happens to all the existing coins that are not post-quantum and stuff like that. So this is a huge deal.

1:00:19Vlad CosteaYeah, it's going to be interesting to see what happens because obviously the low hanging fruits or the easiest target for someone who develops a powerful enough quantum computer is to steal from Satoshi's supposed coins, right? Because those haven't moved in years. And that's how you show the rest of the network that you have been able to move them. And that can be very interesting if it happens. And if a post-quantum future requires you to move your coins to another type of addresses or whatever, then all the lost coins will be stolen by these quantum computer users, right?

1:01:02Jonas NickOr you sort of soft-fork out the spending, but that could be considered stealing.

1:01:11Vlad CosteaOh, spicy. So which one is more like stealing? Intervening to revert someone who supposedly stole, which is... Which you don't know.

1:01:20Jonas NickYou don't know if it was a quantum computer or not, right?

1:01:23Vlad CosteaExactly. There's a lot of deniability. So I guess there will be some coins that will be stolen and we'll never know.

1:01:33Robin LinusIronically, Satoshi's keys, I think they're mostly in pay-to-public-key outputs. So you could steal them. But a bit later on, most transactions were to pay-to-public-key-hash outputs. And you cannot break these with quantum computers. Because you would need to figure out the public key from the hash. And that is pretty much impossible. A quantum computer doesn't help you do that. So the old addresses would be safe. But as soon as you spend them, you would have to reveal the public key. And then if the quantum computer is fast enough, they could double spend your transaction and pay the output to themselves.

1:02:20Liam EagenYou could construct a protocol where you prove knowledge of the preimage of the hash and a signature without revealing it. I mean, there's like a snarky kind of post-quantum solution to the pay-to-public-key-hash outputs.

1:02:38Vlad CosteaI guess if IBM or some other quantum computer giant is listening to this, they could think of something. But everyone I've interviewed and asked them about quantum computing, and I did have Stepan Snigirev, who is the creator of Specter wallet. And I think he went back to academia to study quantum computing after giving up on Specter. And there was also a guy from Poland, Marek Narozniak. And he also spoke about quantum computing. And they all said that we're at least 10 years away from this. So it should not be a concern yet.

1:03:20Jonas NickBut 10 years in Bitcoin time is like nothing, right?

1:03:26Vlad CosteaI don't know about that. People like Peter Todd will tell you, and once again, he might or may not be Satoshi, according to HBO. But he will say that, you know, all of these qubits mean nothing unless they are put into practice and they have an actual application for something. Because these are just theoretical, but they're not necessarily practical. And constructing a quantum computer that is tailored for this particular use case to break this type of cryptography is a lot more complex than it sounds. It doesn't require just raw power.

1:04:04Robin LinusYeah, I'm also not very bullish on quantum computers. I'm not super familiar with the field, so I have to judge it from my outside perspective. But one data point that I found quite telling was that when Google announced quantum supremacy, they made like that huge announcement that they finally computed some function, I don't know, exponentially faster than how you can compute it on a classical computer. And it turned out it was just like, they were computing some kind of random number or something, some esoteric function that has hardly any use in practice.

1:04:43And Google Research, usually they have these groundbreaking results, right? They build a Go computer, and then they're like, maybe we can beat the world champ. And then they beat them devastatingly. And then a year later, they build another system that beats the old system 100 to zero. So usually they have these really strong groundbreaking results. And then here on the quantum computer side, they come up with like this hand wavy, hype driven things that don't have much substance. And I mean, it's of course not a killer argument.

1:05:20Somebody could come up with some solution that is way better than what the Google people did. But it just feels like it's much harder than other things where we progress actually over time. We haven't progressed much in quantum computers since decades, I think.

1:05:39Jonas NickYeah, to that point, if you go to Wikipedia and look for some quantum records, so the largest number that would ever factored in prime factors was 21. 21 is three times seven, is what the computer computed, which is not very impressive.

1:06:01Robin LinusAnd that was already a while ago, no? That was quite a while ago, yeah.

1:06:07Vlad CosteaYou have a question in the chat from Post Capone. He says, if we would need more than 50% of hash to subscribe to and enforce the shielding protocol, what makes it usefully distinct from a soft fork?

1:06:23Robin LinusYou don't need anybody to agree on it. It's just a regular Bitcoin transaction. It's just like inscribing into the blockchain. It's essentially like inscriptions from that perspective.

1:06:40Vlad CosteaI also need to talk about the last ad that I will be presenting in this episode, which is for Hodling.ch. They are basically experts in self-custody. And if you're part of a company that's going to add Bitcoin to its balance sheet, or maybe that you're a whale and you're concerned that somebody might come to your door because you used Ledger and your address, your home address got leaked in some document. Then you should go to these guys and they're going to teach you exactly how you should do your self-custody setup, if you should use hardware wallets, if you should use a multisig, how you should distribute this, how many backups you should have, where you should spread them around the world.

1:07:25And of course, you benefit from that Swiss privacy, which is well known and has some benefits of its own. So go to Hodling.ch if you need any of this. And if you lost your coins and maybe that you have 20 out of 24 words or maybe nine out of 12, they can still brute force and recover the coins for you. You pay a fee for this, of course. But also, if you have the word scrambled and you don't know exactly what's the right order to recover your funds, they can also help you with that.

1:07:57So check out Hodling.ch. They're some very nice guys who will be on the show. I did record an interview with them.

1:08:08Robin LinusThey're from Switzerland?

1:08:10Vlad CosteaYeah. No shout-outs.

1:08:13Robin LinusPromoting their projects. People like stuff from Switzerland.

1:08:17Vlad CosteaYeah, there's a lot of cool stuff coming from there, including the Ethereum Foundation. So on the topic of quantum computing and this looming threat that we have right now in Bitcoin, or maybe we may never have, who knows? But what is the safest way to store your coins long term? Because I know that there are a bunch of guys who locked their coins for 20 years or something. And then there are others who do very complex multisigs and it requires a lot of work for them to recover the necessary threshold of keys to spend the coins. So which of these setups do you think is safer for the average person who doesn't want to spend their Bitcoin and just wants to hold for a very long time?

1:09:11Robin LinusComplexity is the enemy of security, that's for sure.

1:09:19Vlad CosteaSo you think 12 words is just good enough?

1:09:24Robin LinusNo, I wouldn't say so. Probably some multisig setup would be good, but not some complicated thing. I would rather go for something straightforward.

1:09:34Liam EagenAnd if your public key is never published, then you're not vulnerable to quantum computer attacks.

1:09:45That's the only one element, but it's context for why we're talking about very long term security.

1:09:54Jonas NickIt also seems like a lot of this depends on what your actual threat model is, which is different from everyone. Like some people are extremely, for example, their threat model includes that the hardware wallet manufacturer that they're using is malicious and that then requires using multisig or not using hardware wallet or stuff like that. So this is, I think, very individual.

1:10:24Vlad CosteaI was just curious what you guys recommend because people like Luke Dashjr were like, oh, don't use hardware wallets. Just download Bitcoin Core, sync your node, backup your wallet.dat file somewhere safe and you're good to go. Use a passphrase also. But he got wrecked. He got pwned by his own setup. And it's delicate.

1:10:52Robin LinusHe had just been on some hot server, no? He had a bunch of Bitcoins on an internet-connected server.

1:11:04Vlad CosteaI don't think he was very specific about what happened, but he did tag FBI. And there was a conference in Atlanta that was raided basically because of him. And they had to ask about all the attendees and email addresses because he believed that someone from that room might have been responsible for hacking him. So very not nice.

1:11:27Jonas NickThey just gave them our email addresses. At least that's what the organizer said.

1:11:38Vlad CosteaBut for the record, it was not TABConf because I did meet Michael Tidwell. And he told me, don't ever say that it was TABConf because it was not.

1:11:47Robin LinusI just thought it was TABConf, actually.

1:11:49Vlad CosteaYeah, me too. And he's very angry that people believe that.

1:11:55Jonas NickIt was an event right before TABConf.

1:12:00Robin LinusDon't flame TABConf. TABConf is awesome. One of the best Bitcoin conferences. It's actually next week. Yeah, we'll be there.

1:12:09Jonas NickI'm there and Robin is there. Come to TABConf.

1:12:13Robin LinusIt's awesome. They don't sponsor this show. Really awesome.

1:12:18Vlad CosteaThey can what?

1:12:20Robin LinusI said they don't sponsor this show yet, but they are really awesome.

1:12:23Vlad CosteaYou think TABConf should sponsor? I should reach out to them.

1:12:30Robin LinusI think they're not making much profit, so I don't think they should be a sponsor.

1:12:35Vlad CosteaSo how come you guys don't have this? So instead of this being a podcast, how come it's not a presentation in Amsterdam?

1:12:46Robin LinusFor me, it was just too much trouble.

1:12:48Liam EagenI didn't want to go to Amsterdam.

1:12:53Jonas NickToo many events in October.

1:12:57Vlad CosteaOh, that should be something I should write down, because I want to do a conference next year on Halloween in Dracula's castle. Maybe. Potentially. I'm still thinking about it.

1:13:07Robin LinusSounds awesome. Yeah.

1:13:09Vlad CosteaThat's what everyone says, but then they say, oh, you know, I want to go to TABConf, and I want to go to Amsterdam, and three events in one month is too much. So, yeah. Anyway, you guys are invited. It goes without saying.

1:13:26Robin LinusAwesome.

1:13:26Vlad CosteaHypothetically, if it happens. Fingers crossed. I've got to figure out some stuff. So I should ask you at least one final question about shielded client-side validation. First of all, if you're going to receive the funding to do all the coding and make it happen, how long do you think it's going to take?

1:13:53Jonas NickI think there's a difference between proof of concept and actually doing this mainnet, so that has to be considered. And in the way we specify the protocol, there are a lot of gaps, and they are there intentionally, in particular because this whole space of zero-knowledge proofs is moving so quickly. You can use whatever scheme works best for you at the time. So, for example, we don't even give you a hash function. We just tell you the properties that a hash function should have, and then you can select the hash function that best works for you.

1:14:36So this is some initial research that you actually have to do before you can even start implementing the protocol. And then the next step is, in this recursive zero-knowledge scheme, if you know which one you want to use, you need to find an implementation if you don't want to implement it yourself. So that's another issue. And then you need to implement the protocol and the logic with the publishers, the networking, etc. So I think it's quite a big project, to be honest, if you want to go beyond the proof of concept stage for sure.

1:15:19Vlad CosteaSo, two years?

1:15:24Robin LinusI think we can be a bit more optimistic, at least with the prototype. I think it should be doable to do it within a year or something. And maybe even a reckless mainnet prototype. The good thing here is that we don't need consensus from anyone. And it is not easy to change the protocol in hindsight, but I guess it would be possible to have some early experimentations on the main chain, even though the protocol is not completely perfect yet.

1:16:01Vlad CosteaI do remember interviewing Burak last year, and I think I was the first podcaster to get him to talk about Ark. The next day, Stephan Livera basically interviewed him, and that one went viral for some reason, and I'm still angry about it, and I have to mention it out loud. But Burak was super optimistic. He was saying, you know, I think it was May that I interviewed him, and he said that by October he's going to have a pilot and it's going to be ready. And then it seems like he kept shifting the goals and said, you know, we're going to build it on Liquid first, and we're going to wait to see if there's any covenant soft fork that we're going to get.

1:16:42And I'm not even sure what's the state of it right now. But what I'm saying is that there is always this optimistic ETA that people set, and they say, yeah, we can do this in this amount of time, and then there's something else that happens. But in your case, you don't require anyone's permission or any software to be added. It's only a matter of actually getting funding for it and coding it for a certain amount of time. But my other question for you is, what if you make it happen, it's as beautiful and as functional as you want it to be, but it's not going to be used just like with Liquid?

1:17:26Robin LinusThat's life.

1:17:27Jonas NickWell, that's a good question. Yeah, that's life, probably.

1:17:31Vlad CosteaNo, because it's really painful when you have these ideals which are very much in line with what Bitcoin is about. And then you have this ideology and millions of users who adhere to it, who believe that you should only use Bitcoin in the most orthodox way or not use it at all and rely on custodians. So if we're going to go down that path and privacy is going to get frowned upon and something like zero-knowledge proofs is going to get labeled by people like I'm not going to mention any names, but you know who they are.

1:18:06They're going to say it's shitcoin tech and you should not bring that to Bitcoin. And that will remove a lot of users who potentially could be interested in the features, but socially, they don't want to tell others that they're using this. And to them only, I think there is some sort of orthodoxy involved and only a few protocols like Lightning and possibly Ark and maybe also Liquid are pure enough and part of the social consensus that this is the correct way to use Bitcoin. Maybe that this is going to be too eccentric, too avant-garde, or they're going to say it's too shitcoin. But it doesn't have any token in the middle, right?

1:18:48Jonas NickSo, I mean, for me, it's hard to estimate what other people want to do. So I personally, I just build stuff for myself and stuff I want to see and stuff I want to do and hopefully people pick it up. That would be great. But because if I'm the only person on Shielded CSV in the end, that would not be very anonymous. But I definitely think, for me, it's fine to just work on whatever I'm interested in. But there is actually this other client-side validation protocol, which is way more scalable than Shielded, which is not private.

1:19:29It's called Intmax2, and there the data you need to write to the chain is just 5 bytes instead of 64. So you get another 10x scalability bump, 1000 transactions on chain per second, but it doesn't have the same privacy as Shielded. But maybe users are more interested than that. I don't know. But I'm not that interested.

1:19:56Vlad CosteaI mean, it does have scalability. Is that coded? Is it available for anyone to use?

1:20:07Robin LinusOn Ethereum?

1:20:09Jonas NickYeah, I'm not sure how far that has been implemented.

1:20:14Vlad CosteaThere's also RGB, right? On Bitcoin. And that one, I'm not even sure how many developers work on that. But conceptually, it's pretty good.

1:20:26Jonas NickRGB still uses Bitcoin transactions in order to make RGB transactions, at least right now, but they might have plans to switch to a different system.

1:20:37Robin LinusYou can really picture Shielded CSV as like RGB on steroids. I think it's very much inspired by RGB. It's essentially the idea of RGB and combining it with SNARKs.

1:20:48Vlad CosteaYeah, but the purpose is entirely different because RGB was meant to, I think, in the way that it was built, ultimately, was to put USDT on it to help Tether scale on Bitcoin. And that one never caught on. And then they, I guess they decided they could also do NFTs, which was in 2021 at the peak of the NFT craze. And they said, you know, we can actually do this in a much more scalable way and don't put so much data on the blockchain. It didn't get traction.

1:21:23I don't think it was an interesting pitch for what Bitcoin is and what the mission of the project is. They were trying to appeal to the Counterparty and Omni traders. And yeah, for some reason, it never really caught on. And in the case of your Shielded client-side validation, it's about privacy. You cannot, I don't think you can bring Tether to this or that you can do NFTs on it because it has the Shielded quality. It has privacy.

1:21:59Robin LinusTether would be possible.

1:22:04Jonas NickYeah, at least in theory, you can essentially bring or represent any asset on Shielded.

1:22:11Liam EagenThere's no technical obstructions.

1:22:18Vlad CosteaOK, so is there any revenue model for this? Because VCs, when they hear about this, they're going to be like, so how do I make money off of it? Can you actually be sort of a coordinator for this and earn fees?

1:22:37Robin LinusVCs are annoying me to find some kind of company doing something, BitVM or zkCoins or Shielded CSV or whatever. But I think these business models usually don't make any sense. If you think about making any substantial amount of revenue from just transaction fees, you would have to process billions and billions of transactions until that works out. And I just don't think that this is really realistic. And I don't want to do any bullshit business model that I don't believe in. I think that just creates all kinds of bad side effects.

1:23:20Vlad CosteaI do remember in Lightning, it was promoted for a while that you can run your node and you can open channels with others. And if you manage liquidity well enough, you're going to route and make money off of routing. And Alex Bosworth tweeted that he made more than one Bitcoin from routing fees and then everyone wanted to follow his footsteps and be the next Alex Bosworth. And of course, it did not work that way. But right now, I'm not sure if there's any Litecoin, sorry, any Lightning company that is profitable.

1:23:56And that's pretty concerning. The fees on Phoenix wallet are much higher right now than they are on the base layer. And they're still not profitable.

1:24:11Jonas NickYeah, so there are a few things where you could take a small fee. I mean, not what you typically want maybe as a VC. There is this publisher thing. So the publishers, they receive commitments that are supposed to go into the chain, they aggregate them, and then they actually pay the Bitcoin fee to get into the chain. And for that, they receive a fee in the Shielded CSV protocol. But anyone can become a publisher, at least in the normal Shielded CSV protocol. So it's essentially a race to the bottom.

1:24:48There's very little profit that you could gain that way because it's so easy to become a publisher. The other thing I could think of is additional infrastructure like the servers that we talked about. If the receiver is not online, you need to have some clever way where to actually send this coin such that it can be retrieved later. That would be another thing. Maybe BitVM operators, they are also supposed to get a small fee, right, to provide liquidity. But I guess it will be quite small as well because they're a pretty tough competition. Yeah, so that's all I can think of right now.

1:25:35Robin LinusIn general, in these markets where you have a low barrier of entry, you have a very strong competition and it's like a very hard or tough race to the bottom. I don't know if it's necessary to have a business model. Maybe it's possible to just do it with research grants. That would be ideal, I think. That would be like the most pure version of incentivizing it.

1:26:01Vlad CosteaYou said that Shielded CSV does not require any software or any change to the way that Bitcoin works. But is there any software proposal that could make Shielded CSV much better than it currently is?

1:26:18Robin LinusYeah, anything that enables better bridges.

1:26:22Vlad CosteaAs in? Which are the proposals?

1:26:29Robin LinusI would like to see TXHASH, I would like to see introspection opcodes, I would like to see multiplication.

1:26:38Jonas NickI like the great Script Restoration. So that's essentially restoring the script opcodes that were in Satoshi's original implementation like CAT and MUL and add some more. I like this Great Script Restoration because you can do a lot of things with it. But it's not too hard to get consensus. For some reason it seems like it's easier to get consensus on it because it was already there and it's pretty simple. So that's what I like about it.

1:27:22Robin LinusBig int arithmetic is also part of it.

1:27:24Jonas NickRight, right. You can have arbitrary size integers, it's all variable length. There are no negative numbers anymore, no negative zero. So it's just a good improvement to the scripting system overall.

1:27:40Liam EagenYeah, I think all of that is good. Anything that gets us closer to SNARK verification would make bridges a lot simpler and a lot more secure. So whether it's big int arithmetic or not big integer multiplication or CAT or Great Script Restoration, all of that would be great.

1:28:03Vlad CosteaIt's funny how none of you mentioned CTV. It's almost as if you don't like it or something. Even though some people agree that it's the least harmful to put it this way.

1:28:15Robin LinusIt's the least useful. That's why it got rejected in 2022, I think. I mean, of course, that was also the way Jeremy pushed it. Some people didn't like it at all. But the strongest technical arguments I heard against it is that it's actually too limited and that we should rather think about more sophisticated covenant proposals such as TXHASH and introspection opcodes as we have them on Liquid. Does it even really help with bridging? Well, for BitVM, if you have covenants that can commit to inputs, which is impossible with CTV because it only commits to the outputs.

1:28:50If we had a covenant that commits to inputs, you can get rid of that trusted setup. But not with CTV. No, CTV commits only to the outputs and we need some kind of covenant that also can commit to the inputs.

1:29:08Vlad CosteaOkay. So assuming that we do get this sort of soft fork, we get the Great Script Restoration. What's the benefit to shielded client-side validation? Do you get more throughput or do you get much better privacy? What are the benefits?

1:29:26Robin LinusThroughput and privacy, they are different things. I think we haven't said it that clearly. You actually have to think of Shielded CSV as like a different protocol. Actually, it's a token protocol on top of Bitcoin, just like RGB or what do we have, like Counterparty. There are many of these token protocols. BRC-20 is another one that are modulated on top of Bitcoin. And essentially, Shielded CSV is just another token protocol. But the main difference is that it gives you privacy and it increases the throughput to 100 transactions per second.

1:30:01And then the issue is, how do we get Bitcoin into that token protocol? And to get Bitcoin into that token protocol, we need some kind of bridge. And for that bridge, the only option we have right now is, we have two options. One option is, of course, just a regular multisig, which would be a trusted bridge, which is not really that much better than using Fedimint. And the only trust-minimized way we have currently is BitVM. And what we actually would like to have is like a completely trustless bridge that directly verifies some kind of ZKP proof on the main layer. And for that, we need some kind of soft fork, if that makes sense.

1:30:47Vlad CosteaOkay, so I was thinking that the improvements can actually be quantified in more transactions per second or something like that. Yeah. That's not the case.

1:31:00Robin LinusYou cannot really improve the throughput with more soft forks. You would have to increase the block size to increase the throughput.

1:31:08Vlad CosteaInteresting.

1:31:09Jonas NickMaybe. Yeah. There's a roundabout way. Because what may happen is that bridges get more efficient, which leaves more block space for other things, such as shielded throughput. But that's a very, very winded argument.

1:31:27Vlad CosteaDo you believe that the current proposal for shielded client-side validation is final? Or do you envision that maybe in six months or one year, you're going to improve it to a degree that makes, how should I say, makes it pointless to try to put it into practice yet?

1:31:50Jonas NickYeah, I certainly believe that the protocol will evolve still quite a bit. So one example is time locks. We described time locks in the appendix, because we didn't want to put it into the main protocol. Because the easy way to add time locks is to actually increase these 64 bytes by another few bytes. And we didn't like to have that in the main protocol. We wanted the 64 bytes. That's why the time locks got into appendix. We know of a way where you would not have to increase the size of the commitment and still have time locks.

1:32:28But that makes the protocol a little bit more complex. And we just didn't get to implement it yet. So this is just one example of, I think, quite a few that we would still have in mind for things to add. Or similarly, multiple assets. So right now, at least in the main protocol and our specifications that we wrote in Rust, we only support a single asset. But it would also be quite easy to let the protocol support multiple assets and transactions that send multiple assets around. So Bitcoin and Tether, for example.

1:33:07Vlad CosteaSo can I actually mint Vladcoin on this shielded client-side validation layer and trade that for Bitcoin?

1:33:17Jonas NickYes, great idea.

1:33:21Vlad CosteaNever tried before. So that can be a lot of fun. But I guess it's also an argument against it for the average Orthodox Bitcoiner who's going to say, no, you're adding more shitcoins to my holy timechain.

1:33:42I don't know if there's an answer for this, but it's a lot of fun to get you guys to answer questions. And I love that you suck at promoting your own work. It just means that you're honest. I love it.

1:33:58Jonas NickI have another business model in mind, which is also something that maybe connects to something we said earlier. We're using the Bitcoin blockchain as a repository of nullifiers to store commitments. Sorry. Sorry. I didn't want to say nullifier. To store these commitments. But we don't necessarily have to use the blockchain. We could also store it somewhere else, for example, at a federation. So that is a proposal that people already made to us. Why not just send these commitments to the federation and still bridge to Bitcoin? And there are some ways where you can trust minimize this such that if a coin has been confirmed for long enough, they cannot steal from you.

1:34:50That would be somehow done by the bridge. It's all very hand-wavy. But in principle, it seems like that it would also be possible to use a system like that. It has different trade-offs. But the advantage is that you don't have to pay Bitcoin fee to be in a transaction with your 64 bytes and you have instant confirmation. So maybe that would also be a business model. But setting up federations, of course, is extremely hard. Everyone knows it by now.

1:35:21Vlad CosteaYeah. I mean, there's a reason why Liquid and Rootstock did not get too much traction. They're not really trust minimized. I think Rootstock is taking steps towards it. Liquid is just happy to have these federation members. And we do need something much better. And I'm very proud of you guys for coming up with this research paper. Once again, I did read it. It doesn't mean that I understand very well how it works. So I'm happy that I asked you these questions. And I hope that everyone who listened to this got a much better idea about how this can be one of the futures of Bitcoin.

1:36:02And by this, I mean, you know, one of the versions of Bitcoin that we have in the future, not just a feature. And what can I say? I wish you best of luck with this. You're not very good at selling it. You don't seem convinced that you should code it up right now to build it imminently. And it's still a very avant-garde field of cryptography and computer science. There is something new coming all the time. You might build this in a year or two and then you discover that it's obsolete by the time you implement it.

1:36:35But it's fun. And congratulations for caring about privacy. That seems to not be much of a concern for most Bitcoiners these days. But you got to make it fungible somehow, right?

1:36:50Robin LinusI disagree, by the way. I think this idea of client-side validation will probably be the future of blockchains, at least when it comes to payments. I think it's vastly superior to most other approaches. So I think maybe not our protocol in particular, but I think that approach is the best approach that we know for how to scale blockchains. Of course, if you need global state for like AMMs or smart contracts and stuff like that, then it's a different story. But when it's just about processing transactions, I think client-side validation is the best approach that we know so far. So I see a big future for it.

1:37:32Vlad CosteaSo why isn't there more effort in making it happen and implementing client-side validation in more situations?

1:37:42Robin LinusWithout SNARKs, it's not that strong. Without SNARKs, it's essentially a bit of a joke, actually, because the history grows so quickly. But combining CSV with SNARKs, that is the key. That is what gives you the breakthrough. And that has not been possible until recently, actually. Plonky2 is probably the first proof system that is fast enough to enable client-side proving, so that on a regular consumer hardware, you can do that kind of proving. And in general, proof systems have not been developed enough to make it possible. I think it's quite a thing of the last recent years.

1:38:31Vlad CosteaOkay, so how can people keep up with what's happening with this project if anything happens at all in terms of development?

1:38:40Robin LinusFollow me on Instagram. I don't have Instagram.

1:38:45Jonas NickYeah, subscribe.

1:38:48Robin LinusSorry, go ahead.

1:38:50Jonas NickSo we have a GitHub repository. I think our organization is called Shielded CSV, and the project is called Shielded CSV. You can find the paper on ShieldedCSV.org that will redirect you to GitHub. So I think GitHub would be one way, and other than that, maybe follow us on X, and we will post updates there, but also other stuff you might not be interested in. If you're solely interested in Shielded.

1:39:24Robin LinusI'm only on Twitter.

1:39:28Vlad CosteaOh, you guys are not on Nostr. I did notice that. I couldn't find you. I tried to tag you when hyping up this episode today, and I realized, oh, I can't find you.

1:39:41Robin LinusI did a bit of pen testing as well, so I have an account, but I'm not using it really.

1:39:47Liam EagenYeah, same here.

1:39:50Vlad CosteaWhat about you, Liam? You've been the quietest one during this interview. Do you agree with everything that they said?

1:40:00Liam EagenI guess, yeah, I think so. I think that the client-side validated stuff and SNARKs are a really beautiful combination. It's very natural, and I think it is sort of the right way to do transactions. It avoids a lot of really messy problems that other attempts to scale things.

1:40:28So yeah, I'm excited about it. I'm a little sick. That's probably why I seem subdued. But yeah, I also struggle with self-promotion.

1:40:38Robin LinusI don't struggle with Liam promotion. Liam is awesome. He's one of the greatest mathematicians in the Bitcoin field.

1:40:47Jonas NickDefinitely.

1:40:48Vlad CosteaGreat hair, also.

1:40:50Robin LinusGreat hair, yeah, of course.

1:40:51Jonas NickGreat hair, great guy.

1:40:53Robin LinusGreat beard, almost.

1:40:54Liam EagenThank you.

1:40:56Robin LinusYou don't have enough hair to get a softball through.

1:41:00Vlad CosteaOkay, so if someone shows up tomorrow and says, I want you guys to work on this, how much money would you ask them? Like, what's the amount of money that would make you work on this whole time?

1:41:13Jonas NickThat's a question.

1:41:16Liam EagenI don't know that it's a matter of money.

1:41:18Robin LinusYeah, I think so too. I think it's rather a matter of us just starting it, right? It's more...

1:41:26Jonas NickYeah, what is the team I will be working with? It's another question. It's not just the money, because I don't want to work on this by my own engineers.

1:41:36Vlad CosteanChain?

1:41:37Jonas NickYeah.

1:41:39Vlad CosteaOkay. No, seriously, I'm pretty sure that there are a bunch of VCs listening to my show. And if they reach out to you, I'm trying to give them hints.

1:41:53Jonas NickYeah, maybe they have better ideas for how to monetize this. This would be great. Maybe this would even accelerate progress on this.

1:42:02Vlad CosteaWell, they can create their own token, right?

1:42:06Jonas NickYeah, but who wants to sell tokens? If you can have Bitcoin with a bridge, why would you have another token? There's no reason for another token. Maybe they will find a way to introduce it, but I haven't seen a reason, a legit reason, why you would add a token to Shielded for real.

1:42:25Vlad CosteaI don't know, something like reusable tickets for concerts or whatever?

1:42:36Jonas NickHow about that, a governance token, if you need to update how the protocol works? Sounds complicated.

1:42:46Vlad CosteaSounds proof of stake. But once again, Robin, you do like proof of stake. You said that during your episode.

1:42:58Robin LinusNo, I didn't say that. I said something different. I said I like Bitcoin-backed proof of stake because that makes sense to me since it uses an external resource to solve the double spending problem. Classical proof of stake tries to secure itself with itself, which is kind of absurd in my eyes. I mean, it works to some degree, but it's fundamentally different than proof of work. And I really admire the beauty of proof of work consensus. And I don't think that proof of stake is any, like, it's not the same category of things in my head.

1:43:29But I like Bitcoin-backed proof of stake because, as I said, it uses an external resource, which is a different story.

1:43:37Vlad CosteaWell, thank you for the clarification. Is there anything that I haven't asked you about in regards to shielded client-side validation that you wish I asked you, but I haven't because I'm dumb?

1:43:51Robin LinusYeah, can we trade our rare Pepes on that protocol? I know we all have super valuable rare Pepes.

1:44:00I guess you want to see them on the Shielded CSV protocol.

1:44:03Vlad CosteaI don't know. So far, my girlfriend is just drawing these Pepes for people. We're not inscribing them or putting them on anything or tokenizing. It's just people can do whatever they want with them.

1:44:17Robin LinusWell, maybe it catches on and then the first ones will become super valuable. Do they have numbers? Which number is my one?

1:44:25Vlad CosteaOh, yours is like 50, I think.

1:44:28Robin Linus50? So it's way below 100.

1:44:31Vlad CosteaYeah, maybe they should have numbers. Maybe I'm going to ask her because she does save the entire collection. Yeah, that's a good idea.

1:44:41Robin LinusI would love to know if it's a prime number.

1:44:45Vlad CosteaYou all have your own Pepes. I hope you make good use of that. And if you do make good use of that and you put it as profile pictures, I just hope that the VCs are not going to misinterpret that as whatever. I see that. Because I showed a rare Pepe to Phil Zimmermann, and this is just my personal rant, and then he held this 10-minute lecture about American democracy and why it's in danger right now and why Pepe is such an alt-right symbol and there is no redeeming quality to it.

1:45:19And I was like, I mean, I didn't say this to him directly, but wasn't PGP labeled as this technology that the Russians are using to escape sanctions from the Cold War? And it was basically a way to get framed as evil technology. And wasn't Bitcoin just a drug coin like 11 years ago or something? And that was the official narrative about it. You constantly have to reinvent something and give it a different meaning if you wanted to get rid of the stigma. And I think Pepe is a fun meme. It doesn't mean anything political in and of itself.

1:46:00Robin LinusCan trigger people, though.

1:46:02Vlad CosteaIt can. And I think that's the fun part. But if it looks like you and it's just like some sort of avatar, there's nothing offensive about it. Anyway, I love what you guys are doing. I wish I had smarter questions to ask you. You guys should follow Nick. I think it's at. Should I call it Jonas or Nick? I don't think that was ever established.

1:46:31Jonas NickJonas. Jonas.

1:46:32Vlad CosteaBut it's n1ckler on Twitter, N-1-C-K-L-E-R.

1:46:38Jonas NickAlso call me Nick, but that feels to me like I'm back at the army again.

1:46:44Vlad CosteaYou went to the army?

1:46:46Jonas NickYeah, mandatory service. Good times.

1:46:51Vlad CosteaInteresting. And Robin has a much easier at on Twitter. It's Robin underscore Linus. You should definitely follow him because he has interesting ideas. And Liam, he is just Liam Eagen, if I'm not mistaken. If it's E A G E N, you can find it in the title of this episode. So follow these guys. They're super smart. I love their idea. And is there any closing note? What would you tell the listeners to do right now?

1:47:22Jonas NickWell, we already told you how to find us and how to contact us. And now you've heard already a little bit of the, about the protocol. Maybe you want to take a look at the paper. Actually, I think the introduction section is not too complicated. We also have a sort of technical overview that explains to you how that works. So that would certainly be the next step. And if you're interested in diving deeper into the shielded protocol.

1:47:52Vlad CosteaYeah. And if you listened up to this point, publish a comment with an emoji with a shield. That's the way we're going to know that you listened.

1:48:01Robin LinusAnd I would encourage everyone to learn more about Bitcoin, whatever their level is. If they have like a computer science background or not, just learn more about Bitcoin. I think many people in the field are very open to explain everything. And I think we need more people who really know the technical stuff. And this is how to keep the system decentralized. So learn more about Bitcoin.

1:48:26Vlad CosteaIs there any great resource for that? I do remember there was a website that was teaching you opcodes.

1:48:31Robin LinusI even respond to people when they're writing me like private messages on Twitter. When they're asking good questions, I definitely respond. I don't respond when they're saying hello or something. But whenever somebody asks me a good question on Twitter or telegram or whatever, I always respond. Because I learned it that way. Pieter Wuille and Andrew Poelstra and all these people, they were super approachable on IRC. And that's how I learned things. And I feel obligated to give it to the next people.

1:49:09Jonas NickBitcoin Stack Exchange is also a good place. Of course. And the question and answer are public.

1:49:17Robin LinusWhich is mostly Pieter Wuille.

1:49:21Vlad CosteaI tried so hard to get him on the show. And the pitch for him was to get him to comment on the pieterwuillefacts.com facts. There's a website about him with facts about him. They're inspired by the Chuck Norris facts. But it's like Pieter Wuille solves a block with pen and paper and stuff like that.

1:49:43Robin LinusHe compiles the code only to check if the compiler is working correctly and stuff like that. That's a classic.

1:49:51Vlad CosteaIt would be fun to get him to comment on these, but he's not interested. I guess I'm not smart enough to ask him questions.

1:49:58Jonas NickYeah. And you potentially will ask him about a statement on block size increases, etc., right?

1:50:09Vlad CosteaI'm pretty sure he's in favor of it.

1:50:15Liam EagenNo idea.

1:50:17Vlad CosteaLike I've spoken with Thomas Voegtlin, for example, the guy who built Electrum. And he was like, I was never against it. I was just against it under the terms of 2017. Sort of mind blowing to realize that this whole small block, big block dichotomy makes no sense. That's just how to optimize the system best for the current needs for users to make Bitcoin global money. How about that? Sounds so nice.

1:50:48Robin LinusWhat? Make Bitcoin global money, you say?

1:50:52Vlad CosteaYeah, to optimize the system for whatever are the needs to make Bitcoin global money.

1:51:00Robin LinusWell, you don't want to weaken the system, right? You want it to scale without weakening the system. And that's the big challenge, I would say. And I think the best shot that we have currently is Shielded CSV.

1:51:13Vlad CosteaNice.

1:51:14Robin LinusAnd maybe a bigger block at some point.

1:51:15Vlad CosteaI finally got you to shill it. Finally. Okay, guys, thank you very much. Is there anything else to add?

1:51:29Okay, we're done. Thank you again. And I'll see you on the next one. Also, Liam, I'll get you on an interview solo to talk about Alpen Labs.