Transkrip penuh untuk Zero-Knowledge Proofs For Post-Quantum Bitcoin | BENEDIKT BÜNZ

were first getting involved in cryptography in general, or I guess when you went to go, 78 00:04:10,240 --> 00:04:13,520 you did your PhD at Stanford with Dan Benet. Is that right? 79 00:04:13,520 --> 00:04:14,240 That's correct, yes. 80 00:04:14,320 --> 00:04:20,060 Were you already heavily interested in blockchains slash Bitcoin at that time? 81 00:04:20,200 --> 00:04:23,880 Or like why cryptography in the first place? What drew you to cryptography to begin with? 82 00:04:23,880 --> 00:04:34,460 So I think that I'm actually probably the first generation that got into cryptography because I'd been interested in Bitcoin and blockchain. 83 00:04:34,940 --> 00:04:36,760 So it started with an interest in Bitcoin. 84 00:04:36,760 --> 00:04:53,860 Yeah. So for me particularly. So I've been into Bitcoin since 2011. So I was an undergrad, you know, I was like, I think I wrote some newspaper article, which was called like some German newspaper article, which was called like money out of the outlet or something like this. 85 00:04:53,880 --> 00:04:56,780 the Bitcoin price was much lower than it was today. 86 00:04:58,400 --> 00:05:01,120 I think, yeah, I posted about it on Facebook. 87 00:05:01,700 --> 00:05:02,760 You know, that's how old it was. 88 00:05:02,900 --> 00:05:05,800 And I don't think anybody, I think my sister gave me a like, 89 00:05:05,980 --> 00:05:07,160 but that was about it. 90 00:05:07,340 --> 00:05:09,680 Were you interested in monetary policy at that point? 91 00:05:09,680 --> 00:05:11,520 Were you an Austrian economics person? 92 00:05:11,760 --> 00:05:13,000 Like, what drew you to Bitcoin? 93 00:05:13,540 --> 00:05:15,600 I mean, I do think the economics angle. 94 00:05:16,180 --> 00:05:18,460 So I was studying computer science, 95 00:05:18,460 --> 00:05:34,600 But I think just not the Austrian, not the monetary policy point of view, but the fact that you could have money without a central entity, without a central bank, was really, really fascinating to me. 96 00:05:35,060 --> 00:05:38,780 Like that, you know, was very unique. 97 00:05:38,980 --> 00:05:43,420 And like, especially like, how do you set a monetary policy if you don't have a central bank? 98 00:05:43,820 --> 00:05:45,920 Well, I guess you need to just program it, right? 99 00:05:45,920 --> 00:05:49,760 You need to have a programmatic predetermined rule of what it is. 100 00:05:51,180 --> 00:05:54,080 And I thought that was very interesting. 101 00:05:54,340 --> 00:06:06,840 And then I think three years later, I kept my interest, but I don't think I fully understood maybe the basic technical details. 102 00:06:06,1000 --> 00:06:12,900 But then three years later, I did first my master's at Stanford, and there was a class on cryptography. 103 00:06:12,900 --> 00:06:14,620 And I was like, oh, this is cool. 104 00:06:14,680 --> 00:06:15,800 I want to take this class. 105 00:06:15,920 --> 00:06:20,440 in order to learn more about the technical details of how it works. 106

00:06:20,620 --> 00:06:23,840 So you were getting your master's in CS at Stanford, 107 00:06:23,1000 --> 00:06:26,680 and then you kind of stumbled into Dan's class. 108 00:06:26,820 --> 00:06:27,460 Yeah, basically. 109 00:06:27,680 --> 00:06:29,700 I was like, oh, this is cool. 110 00:06:30,360 --> 00:06:32,600 I want to learn more about how blockchains work. 111 00:06:33,460 --> 00:06:36,020 You know, maybe this class will give me the necessary background. 112 00:06:36,020 --> 00:06:39,120 I was more working on AI-related stuff, actually, back then. 113 00:06:40,300 --> 00:06:41,980 Way back in the day, very early for AI. 114 00:06:41,980 --> 00:07:07,700 Yeah, it was basically when the first deep learning classes were also taught at Stanford. Maybe you should have stuck with that, but I think my heart and interest were always like, I took the class and I was like, oh, this is so cool. I love the math behind it. I think it has a very unique, as a field, it has a very unique combination of very deep math, but also real world applicability. 115 00:07:07,700 --> 00:07:13,100 right like obviously blockchains but also the entire internet relies on cryptography and secure 116 00:07:13,100 --> 00:07:18,420 encryption and all of these things and uh yeah it's a very very beautiful combination it's very 117 00:07:18,420 --> 00:07:25,300 like puzzle-like you know uh where you can solve these these puzzles and and sort of it seems you 118 00:07:25,300 --> 00:07:29,020 can do things that seem impossible but then when you understand it it's actually very possible 119 00:07:29,020 --> 00:07:35,080 um so i loved all of that and and then i took the class and after that i i went to uh dan and was 120 00:07:35,080 --> 00:07:42,900 like hey do you have maybe a research project that uh we could work on and together with uh 121 00:07:42,900 --> 00:07:49,600 joe bono who's also a professor at nyu now um we worked on this research project for um it's 122 00:07:49,600 --> 00:07:56,280 actually kind of funny because it was it was 2014-15 and it was just after mount gox had gotten 123 00:07:56,280 --> 00:08:05,820 like bankrupt and uh so the question was basically whether uh you know and there was before mongox 124 00:08:05,820 --> 00:08:10,400 went bankrupt there was always this question like are they solvent are they not solvent right do they 125 00:08:10,400 --> 00:08:15,120 have the money do they have don't have the money it was like for half a year um that was a question 126 00:08:15,120 --> 00:08:23,020 um and turns out they didn't have the money we found out we found out um but you know so people 127 00:08:23,020 --> 00:08:28,980 were already back then asking and discussing like what would be cool is if they could like uh you 128 00:08:28,980 --> 00:08:34,400 know why this is all money it's programmatic it's digital like could they just give a proof that they 129 00:08:34,400 --> 00:08:39,440 have the funds could they give us like a certificate that they have these funds and so we developed 130 00:08:39,440 --> 00:08:47,160 this thing called a proof of solvency which allows an exchange to prove that they have more money than 131 00:08:47,160 --> 00:08:51,180 their customers, like, they have liabilities to their customers. 132 00:08:51,700 --> 00:08:58,640 And the cool thing was that you can do this without revealing, you know, how much each 133 00:08:58,640 --> 00:08:59,960 customer has, right? 134 00:09:00,080 --> 00:09:04,340 And you can even do it without revealing which Bitcoin addresses you control. 135 00:09:05,420 --> 00:09:09,300 All you have to do is do this cryptographic proof. 136 00:09:09,960 --> 00:09:13,020 This is called, like, it's related to, it's a zero-knowledge proof. 137 00:09:13,040 --> 00:09:13,300 Is it? 138 00:09:13,360 --> 00:09:14,580 I was going to say, it is a zero-knowledge proof? 139 00:09:14,580 --> 00:09:16,820 Yeah, it is a very specific zero-knowledge proof. 140 00:09:17,160 --> 00:09:19,680 for basically the statement, I am solvent. 141 00:09:20,500 --> 00:09:22,200 And so we developed it. 142 00:09:23,240 --> 00:09:26,960 Unfortunately, it didn't get kind of the adoption that we were hoping. 143 00:09:27,620 --> 00:09:30,380 Maybe there wasn't enough sort of community pressure for it. 144 00:09:30,540 --> 00:09:36,660 And then sort of when I finished my PhD, you know, it was around the time of FTX. 145 00:09:37,060 --> 00:09:40,640 And, you know, maybe we should have adopted proofs of solvencies. 146 00:09:40,860 --> 00:09:43,820 And I still think we should adopt proofs of solvencies. 147 00:09:43,820 --> 00:09:50,020 and yeah there isn't really a good technical reason why we haven't it's just like social 148 00:09:50,020 --> 00:09:54,880 pressure regulatory and it doesn't involve any like protocol level changes or anything like that 149 00:09:54,880 --> 00:09:59,640 it's just it's just a proof system on top of was it is it for bitcoin specifically or does it not 150 00:09:59,640 --> 00:10:04,760 matter uh you can basically build this so we specifically build it for bitcoin back then 151 00:10:04,760 --> 00:10:11,000 um and i think also like when you read the paper that we wrote back then it's like okay 152 00:10:11,000 --> 00:10:13,300 the proofs were like 153 00:10:13,300 --> 00:10:16,120 I coded it up and the proofs were like 154 00:10:16,120 --> 00:10:18,460 I don't know, 10 gigabytes in size 155 00:10:18,460 --> 00:10:20,460 and you have to download them and it's clunky 156 00:10:20,460 --> 00:10:21,740 and you know, whatever 157 00:10:21,740 --> 00:10:24,280 like today, this would be 158 00:10:24,280 --> 00:10:26,540 you know, it would be 159 00:10:26,540 --> 00:10:28,460 infinite, like there's been so much progress 160 00:10:28,460 --> 00:10:30,420 in zero knowledge proofs and we'll get to 161 00:10:30,420 --> 00:10:32,260 talk about it later probably 162 00:10:32,260 --> 00:10:34,040 but this would be, you know 163 00:10:34,040 --> 00:10:36,140 a 200

kilobyte proof that anyone 164 00:10:36,140 --> 00:10:38,080 can download, check 165 00:10:38,080 --> 00:10:39,880 very easily, like this is 166 00:10:39,880 --> 00:10:44,140 absolutely feasible today with all of the progress that has been made 167 00:10:44,140 --> 00:10:48,060 in zero-knowledge proofs. It's just that, yeah, there isn't 168 00:10:48,060 --> 00:10:52,000 enough, like, I don't know. Demand. There isn't enough 169 00:10:52,000 --> 00:10:55,960 demand. And yeah, of course, it's still a decent engineering effort 170 00:10:55,960 --> 00:10:59,280 to get this rolling. But, I mean, 171 00:11:00,360 --> 00:11:03,940 like, let's be fair. I think that, you know, some exchanges do some sort of proof 172 00:11:03,940 --> 00:11:07,360 of solvency. I think Kraken has done some. Like a proof of reserve. 173 00:11:07,360 --> 00:11:09,020 Yeah, they do a proof of reserves. 174 00:11:09,020 --> 00:11:09,420 You can look at their addresses. 175 00:11:09,700 --> 00:11:10,100 Exactly. 176 00:11:10,240 --> 00:11:11,380 You can look at their addresses. 177 00:11:11,900 --> 00:11:12,780 But yeah. 178 00:11:13,160 --> 00:11:16,300 Interestingly, though, and this will be a tiny, tiny segue. 179 00:11:16,580 --> 00:11:20,380 I just had Alex Leishman, who you met earlier on the show, and we were talking about this 180 00:11:20,380 --> 00:11:20,920 very thing. 181 00:11:20,920 --> 00:11:25,100 And he said the challenge with proof of reserves is that it requires the way that most exchanges 182 00:11:25,100 --> 00:11:29,260 are using it now requires spending from that address to prove that you have control of the 183 00:11:29,260 --> 00:11:32,140 address, which makes it quantum insecure by definition. 184 00:11:33,060 --> 00:11:33,860 So this is not true. 185 00:11:34,040 --> 00:11:35,880 Like, I think that's so this is. 186 00:11:36,040 --> 00:11:37,300 This would be a salt for that. 187 00:11:37,360 --> 00:11:39,440 Yeah, I think you can solve this. 188 00:11:39,560 --> 00:11:42,700 I think that it's like, this is true in the original paper. 189 00:11:43,420 --> 00:11:44,700 So in the original paper that we... 190 00:11:44,700 --> 00:11:46,240 Oh, in your original paper, you had to do the same. 191 00:11:46,340 --> 00:11:47,680 It involves spending also? 192 00:11:49,360 --> 00:11:54,140 It involves revealing your public key, which is equivalent to spending. 193 00:11:54,140 --> 00:11:57,100 Like it involves sort of like, yeah. 194 00:11:57,540 --> 00:12:01,620 So it is, you know, like the original way that we did it. 195 00:12:01,620 --> 00:12:26,360 I do think that today, again, it's a bigger engineering effort, but I think today the way that these proof systems have progressed and very, very recently developed a new one that's even faster, I think you could get by without having to reveal your addresses and remain in quantum secure. 196 00:12:26,360 --> 00:12:28,840 and even the proof can be post-quantum secure. 197 00:12:28,840 --> 00:12:34,380 And so I think that's not quite true anymore. 198 00:12:34,700 --> 00:12:36,480 But this might be a use case. 199 00:12:36,600 --> 00:12:39,920 This was true in 2014, even for proof of solvency. 200 00:12:40,080 --> 00:12:41,920 But you could use proof of solvency 201 00:12:41,920 --> 00:12:43,260 without revealing the public key. 202 00:12:43,380 --> 00:12:45,360 And that could be the use case. 203 00:12:45,520 --> 00:12:47,060 That could be one potential use case 204 00:12:47,060 --> 00:12:49,040 for zero-knowledge proofs in a post-quantum world 205 00:12:49,040 --> 00:12:52,040 as proof of reserves will probably require it 206 00:12:52,040 --> 00:12:53,220 at that point if you... 207 00:12:53,220 --> 00:12:53,560 Absolutely. 208 00:12:54,080 --> 00:13:13,108 I think yeah so this is you know I mean I think one thing that I thought he was going to make a different point which is also that one is true still is that if you want to do a proof of solvency you need to somehow touch your secret keys 209 00:13:14,148 --> 00:13:22,188 And so this is the pushback that we got over 10 years ago, which I would love to talk with Alex again. 210 00:13:22,188 --> 00:13:35,928 And funnily enough, Alex and I actually were, so then like in 2015 or sort of the first, Dan and Joe taught the first Bitcoin class at Stanford. 211 00:13:36,248 --> 00:13:38,728 And Alex and I met there because we were the TAs. 212 00:13:38,888 --> 00:13:39,548 That's right. 213 00:13:39,668 --> 00:13:40,208 That's right. 214 00:13:40,248 --> 00:13:40,888 He mentioned that. 215 00:13:40,888 --> 00:13:55,648 And so the thing is about proof of solvency is you want to prove that you know the secret key for this address, which means you need to touch the secret key, which is a problem if the secret key is in cold storage. 216 00:13:56,228 --> 00:13:56,668 Ah. 217 00:13:56,928 --> 00:13:59,788 So like Bitcoin problems. 218 00:14:00,428 --> 00:14:00,768 Yeah. 219 00:14:00,768 --> 00:14:08,768 I mean, this is, you know, like so if your secret keys are somehow accessible, this is possible. 220 00:14:09,568 --> 00:14:13,008 But, I mean, you know, there, I mean, Alex would be better able to answer. 221 00:14:13,248 --> 00:14:19,668 He literally just came on the show and basically said, you know, he prefers, you know, multi-sigs and cold storage. 222 00:14:19,788 --> 00:14:21,448 Right. Everything is multi-sig cold storage. 223 00:14:21,668 --> 00:14:23,608 Right. So that'll be a major potential tradeoff. 224 00:14:23,608 --> 00:14:25,128 It will be a potential tradeoff. 225 00:14:25,428 --> 00:14:30,728 And, you know, but like there's still like ways around it. 226 00:14:30,848 --> 00:14:32,468 You know, I think it's solvable. 227 00:14:32,708 --> 00:14:33,248 It's solvable. 228 00:14:33,248 --> 00:14:50,108 There's also one really, really inherent problem with proof of solvencies that we cannot fix and no math in the world can fix is that even if an exchange is solvent, like being solvent does not mean

willingness to pay out the money. 229 00:14:50,508 --> 00:14:50,928 Right, right. 230 00:14:51,048 --> 00:14:53,928 They might have all the money in the world if they don't give it to you. 231 00:14:54,848 --> 00:14:56,308 It's not a perfect system. 232 00:14:56,308 --> 00:15:00,828 It can never be, you know, it's never the same as like holding your own coins. 233 00:15:00,948 --> 00:15:02,248 But I think people know that. 234 00:15:02,368 --> 00:15:02,608 Right. 235 00:15:02,608 --> 00:15:16,008 And I think it's still, you know, I think in the cases that we had where there were major issues with solvency, like it would have actually been like it's not these things are not one day things. 236 00:15:16,008 --> 00:15:18,248 They kind of drag out over a bit of time. 237 00:15:18,248 --> 00:15:28,128 So there would have been some warning flags or, you know, you can't like suddenly lend out all of your Bitcoins if you also need to do kind of a solvency proof with them. 238 00:15:28,128 --> 00:15:34,888 And so it becomes, yeah, it becomes an interesting problem. 239 00:15:35,208 --> 00:15:41,608 And I think, yeah, I would love to still see this be deployed more. 240 00:15:41,848 --> 00:15:41,988 But yeah. 241 00:15:42,148 --> 00:15:46,128 So was that the first time that you really were sort of seriously touching zero knowledge proofs? 242 00:15:46,988 --> 00:15:47,588 Yeah, exactly. 243 00:15:47,788 --> 00:15:48,668 And that was the first. 244 00:15:48,808 --> 00:15:56,148 And then I would say, like, I mean, at that time, it feels like you mentioned, you know, the field of cryptography is not focused on Bitcoin very much. 245 00:15:56,148 --> 00:16:12,988 It's focused mostly on these other ecosystems in the past, let's call it 10 to 15 years. To me, as an outsider, as a Bitcoiner who's not as familiar with that world, it feels like the whole world was zero knowledge proofs exclusively for some time. You know, the whole area was just focused on ZQPs. 246 00:16:12,988 --> 00:16:26,848 Could you explain to the Bitcoiners who might not understand why all of the academic kind of cryptography research in blockchains was going into this one thing, this zero-knowledge proving system world? 247 00:16:27,248 --> 00:16:29,528 I mean, it's definitely not all of the academic world. 248 00:16:29,708 --> 00:16:34,908 This is not quite correct, but it is a huge field, and it is especially a field that has… 249 00:16:34,908 --> 00:16:36,128 And for blockchain specifically. 250 00:16:36,128 --> 00:16:37,088 For blockchain specifically. 251 00:16:37,408 --> 00:16:41,048 And so I think to understand that, we need to first understand what these zero-knowledge proofs are. 252 00:16:41,048 --> 00:16:55,688 So a zero knowledge proof is basically it's a cryptographic certificate that I executed, you know, some function, some computation correctly. 253 00:16:56,388 --> 00:16:59,928 OK, so what does this mean? 254 00:17:00,288 --> 00:17:03,608 Well, you know, you can you can give examples in Bitcoin. 255 00:17:03,608 --> 00:17:09,428 So one example is, you know, the cryptographic function checks that, you know, I look at all of my addresses. 256 00:17:09,428 --> 00:17:12,608 I look at all of the balance and then I look at all of my customers. 257 00:17:12,848 --> 00:17:14,428 I look at how much they have. 258 00:17:14,908 --> 00:17:17,308 I sum up those two things and then I compare them. 259 00:17:17,728 --> 00:17:25,068 And I see is the total sum of my assets bigger than the total sum of my liabilities. 260 00:17:25,888 --> 00:17:28,828 So that function would encode a solvency check. 261 00:17:28,828 --> 00:17:39,988 And so what I can do is I can give you a cryptographic certificate that I've executed this function correct. 262 00:17:40,288 --> 00:17:42,168 And let's say it outputs true. 263 00:17:42,648 --> 00:17:45,948 So in the end, it says assets greater liabilities. 264 00:17:47,428 --> 00:17:52,928 The important thing is that we can design these certificates such that they have two properties. 265 00:17:53,528 --> 00:17:57,088 And these properties are really orthogonal and they have different applications. 266 00:17:57,088 --> 00:17:59,988 but you can oftentimes get two of them. 267 00:18:00,528 --> 00:18:04,608 So one of them is that it's so-called zero knowledge. 268 00:18:05,028 --> 00:18:08,588 So zero knowledge means that the certificate itself 269 00:18:08,588 --> 00:18:13,048 reveals no information about the private inputs. 270 00:18:13,608 --> 00:18:18,748 So for example, it doesn't reveal like any of my secret keys, right? 271 00:18:18,948 --> 00:18:23,468 It doesn't even need to reveal any of the addresses that I'm using 272 00:18:23,468 --> 00:18:24,868 or the balances that I'm using. 273 00:18:24,868 --> 00:18:29,668 I don't even need to show you how much money all my customers have in total. 274 00:18:30,428 --> 00:18:35,288 All I'm proving is that the total assets are greater than the liabilities. 275 00:18:35,648 --> 00:18:40,628 So I can prove to you that something is true without revealing why it's true. 276 00:18:41,488 --> 00:18:49,528 And this is true for really anything, you know, like where you can write a computer program for it that checks it. 277 00:18:50,188 --> 00:18:53,908 You can prove that it's true without revealing why it's true. 278 00:18:53,908 --> 00:18:56,548 It's one of these things that seems paradoxical. 279 00:18:57,068 --> 00:19:00,488 I can give you some real-world examples of how this might work, 280 00:19:00,888 --> 00:19:03,728 but it seems paradoxical that this could ever be true. 281 00:19:04,168 --> 00:19:08,688 But magically, like crypto magic, this is true. 282 00:19:09,028 --> 00:19:12,048 And then, amazingly, these things also have a second property. 283 00:19:13,228 --> 00:19:17,908 The second property is that these certificates, these proofs, 284 00:19:18,708 --> 00:19:20,828 they're sometimes also called SNARCs, 285 00:19:21,228 --> 00:19:23,408 succinct

non-interactive arguments of knowledge, 286 00:19:23,908 --> 00:19:26,928 It's just a different word for proof is a snark. 287 00:19:28,128 --> 00:19:31,288 Are ZKB and snark, are those like interchangeable terms 288 00:19:31,288 --> 00:19:33,068 or is snark a type of zero knowledge proof? 289 00:19:34,148 --> 00:19:36,588 Snark is really a type of zero knowledge proof. 290 00:19:37,048 --> 00:19:39,808 It doesn't actually necessarily have to be zero knowledge. 291 00:19:39,928 --> 00:19:41,868 Then it's a ZK snark, okay? 292 00:19:42,388 --> 00:19:43,188 A zero knowledge snark. 293 00:19:43,468 --> 00:19:45,488 But the properties that snark have, 294 00:19:45,608 --> 00:19:46,648 so they have two words in there. 295 00:19:46,728 --> 00:19:50,348 There's the succinct, well, really it's a succinct word. 296 00:19:50,348 --> 00:19:52,868 There's also the non-interactive and argument. 297 00:19:53,908 --> 00:19:57,228 Argument is really just another word for proof for all intents and purposes. 298 00:19:58,168 --> 00:20:00,468 So the S stands for succinct. 299 00:20:00,568 --> 00:20:01,648 So what does succinct mean? 300 00:20:01,648 --> 00:20:06,868 It means that the certificate itself is really, really short. 301 00:20:07,508 --> 00:20:11,688 So we have snarks where the certificate itself is like 200 bytes. 302 00:20:12,368 --> 00:20:12,588 Tiny. 303 00:20:12,828 --> 00:20:13,128 Tiny. 304 00:20:13,428 --> 00:20:19,748 And importantly, you know, whether I'm proving that I'm solvent, let's say I have 10 addresses 305 00:20:19,748 --> 00:20:21,988 or I have a million addresses, 306 00:20:22,788 --> 00:20:24,868 the size of the certificate doesn't change. 307 00:20:25,328 --> 00:20:26,848 It's always the same size. 308 00:20:27,148 --> 00:20:29,428 So no matter, you know, sort of formally we say that 309 00:20:29,428 --> 00:20:32,608 no matter how long my computation is that I'm proving, 310 00:20:33,188 --> 00:20:35,208 the size of the certificate doesn't change 311 00:20:35,208 --> 00:20:39,428 and the time to check it also doesn't change. 312 00:20:39,428 --> 00:20:42,268 So it takes milliseconds, sometimes microseconds 313 00:20:42,268 --> 00:20:44,628 to check that the certificate is valid, 314 00:20:45,128 --> 00:20:49,108 even if the computation itself 315 00:20:49,108 --> 00:20:55,928 took, you know, an hour, a day, a year, a lifetime to do, 316 00:20:56,128 --> 00:20:58,988 the certificate itself is really short. 317 00:20:59,608 --> 00:21:02,268 So why is this important in the blockchain context? 318 00:21:02,888 --> 00:21:07,448 Well, for example, I could, let's say you want to download a block 319 00:21:07,448 --> 00:21:10,288 and the block has like 5,000 transactions. 320 00:21:10,668 --> 00:21:14,968 And I want to know, I want to check that each single one of these transactions is valid. 321 00:21:15,328 --> 00:21:15,788 Right? 322 00:21:15,888 --> 00:21:17,368 And I need to check the signature. 323 00:21:17,368 --> 00:21:19,948 I need

to check something about these UTXOs. 324 00:21:20,108 --> 00:21:22,028 There's some algorithm that checks it. 325 00:21:22,748 --> 00:21:26,948 So instead, I could have my friendly helper called a prover. 326 00:21:27,388 --> 00:21:30,108 And the prover basically does these checks for me. 327 00:21:30,408 --> 00:21:36,528 And then it produces a snark, the certificate, that it did the computation correctly. 328 00:21:37,348 --> 00:21:39,868 The snark is 200 bytes. 329 00:21:40,088 --> 00:21:41,348 Maybe sometimes it's a bit larger. 330 00:21:41,468 --> 00:21:43,108 It's like 100 kilobytes or something. 331 00:21:43,108 --> 00:21:46,028 and you download only the snark 332 00:21:46,028 --> 00:21:49,548 and you sort of the snark takes as one input 333 00:21:49,548 --> 00:21:50,888 basically the block header 334 00:21:50,888 --> 00:21:54,748 and you check basically all you need to download 335 00:21:54,748 --> 00:21:56,388 is the block header and the snark 336 00:21:56,388 --> 00:21:59,128 and suddenly you know that all of the transactions 337 00:21:59,128 --> 00:22:01,648 in the block are valid, all of the signatures are valid 338 00:22:01,648 --> 00:22:03,168 you don't even need to see them 339 00:22:03,168 --> 00:22:05,588 you know that they exist and that they're valid 340 00:22:05,588 --> 00:22:08,968 and suddenly like syncing a block 341 00:22:08,968 --> 00:22:10,428 becomes much much faster 342 00:22:10,428 --> 00:22:13,188 because I only need to download the certificate 343 00:22:13,188 --> 00:22:15,428 and I only need to check that 344 00:22:15,428 --> 00:22:16,828 and it's much, much faster. 345 00:22:17,588 --> 00:22:19,548 But, you know, what I told you is 346 00:22:19,548 --> 00:22:21,388 checking the certificate 347 00:22:21,388 --> 00:22:23,408 or the size of the certificate and checking it, 348 00:22:23,488 --> 00:22:26,668 it's basically independent of how long the computation is. 349 00:22:27,088 --> 00:22:28,468 So why do this for one block? 350 00:22:28,788 --> 00:22:29,948 I could do it for two blocks. 351 00:22:30,468 --> 00:22:31,528 Well, why do it for two blocks? 352 00:22:31,608 --> 00:22:35,008 I could do it for the entire history of Bitcoin, right? 353 00:22:35,008 --> 00:22:37,148 I could just download the current block 354 00:22:37,148 --> 00:22:38,868 and this proof 355 00:22:38,868 --> 00:22:43,628 And I would know that every single transaction in the history of Bitcoin was correct. 356 00:22:43,808 --> 00:22:45,608 And this is the current block header. 357 00:22:46,188 --> 00:22:48,888 And everything about it is correct. 358 00:22:49,568 --> 00:22:52,928 And I don't need to like the syncing becomes, you know, immediate. 359 00:22:54,368 --> 00:22:59,648 So, I mean, basically what you're talking about is like this also has serious implications, not just for privacy, but for scaling. 360 00:22:59,968 --> 00:23:00,188 Right. 361 00:23:00,328 --> 00:23:01,348 And exactly. 362 00:23:01,448 --> 00:23:04,268 Because here there's no private information. 363 00:23:05,028 --> 00:23:05,168 Right. 364 00:23:05,248 --> 00:23:06,808 All of the transactions are public. 365 00:23:07,388 --> 00:23:07,868 In Bitcoin. 366 00:23:07,868 --> 00:23:08,388 In Bitcoin. 367 00:23:08,388 --> 00:23:09,528 They're public, right? 368 00:23:09,628 --> 00:23:13,768 It's not like I'm trying to hide the transactions or the signatures from you. 369 00:23:14,668 --> 00:23:17,168 It's purely about scaling, right? 370 00:23:17,528 --> 00:23:20,508 So I don't need the zero-knowledge property. 371 00:23:20,648 --> 00:23:21,908 I just need the snark property. 372 00:23:22,648 --> 00:23:28,288 There's other applications like maybe the solvency proofs or private transactions on Monero, 373 00:23:29,008 --> 00:23:31,248 where I really care about the privacy property. 374 00:23:32,088 --> 00:23:35,288 The scaling property is nice, but it's not so important, right? 375 00:23:35,888 --> 00:23:37,028 And sometimes I like both. 376 00:23:37,028 --> 00:23:44,068 Would Bulletproofs, for instance, be an example of more of a privacy application example? 377 00:23:44,428 --> 00:23:49,288 Yeah. So Bulletproofs was a zero-knowledge proof that I developed in my PhD. 378 00:23:50,688 --> 00:23:57,248 In collaboration with some pretty heavy hitters. You were working with Greg Maxwell and Peter Willa and the Blockstream team. 379 00:23:57,248 --> 00:24:02,708 So what happened is that sort of Peter and Greg and Andrew, they came to us. 380 00:24:03,608 --> 00:24:04,248 To you and Dan. 381 00:24:04,248 --> 00:24:18,468 Yeah. And they were basically saying, you know, like this was around the time there was something called Mimble Wimble, which was, you know, a new idea for a privacy protocol. 382 00:24:19,068 --> 00:24:30,328 And basically they came to us saying like, OK, you know, there's these cool new tricks around privacy proofs of private transactions, confidential transactions where you don't see the amount, right? 383 00:24:30,328 --> 00:24:39,388 The amount that is being sent is hidden, but it's also relevant for things like Monero, where both the amount that I'm sending is hidden and who's sending it is hidden. 384 00:24:40,208 --> 00:24:47,308 And the challenge, basically, that they had was that kind of the zero-knowledge proofs were too big. 385 00:24:48,488 --> 00:24:50,228 So they were using ZKs. 386 00:24:50,528 --> 00:24:58,328 So confidential transactions developed by Greg Maxwell, the original idea, they wanted to use a zero-knowledge proof, but they were just too big for practical use. 387 00:24:58,328 --> 00:25:00,768 You can't really make it work without zero knowledge proofs. 388 00:25:00,768 --> 00:25:00,948 Okay. 389 00:25:01,108 --> 00:25:01,328 Right? 390 00:25:01,408 --> 00:25:14,108 Because you need to still know, right, when I'm hiding the amount, it's like I need to know that the transaction is valid so that it doesn't create, you know, more. 391 00:25:14,108 --> 00:25:22,068 So let's say

I have one Bitcoin and I'm, you know, sending you some new funds, right? 392 00:25:22,368 --> 00:25:23,828 Or I'm sending two people some funds. 393 00:25:23,928 --> 00:25:27,768 I'm sending you half a Bitcoin and I'm sending Greg another half a Bitcoin. 394 00:25:28,328 --> 00:25:36,688 What's really, really important is that if I had one Bitcoin as input, that the outputs don't sum up to more. 395 00:25:37,768 --> 00:25:45,368 Right. They should not be I shouldn't be sending you one Bitcoin and Greg also one Bitcoin, because then like that's basically like a double spent. 396 00:25:45,888 --> 00:25:48,688 And that's is that where the term range proof comes from? 397 00:25:48,688 --> 00:26:11,216 Yeah it actually what even more it turns out so now we getting into technical details but it turns out even that is not quite enough Because what I could do is I could send you say I have one Bitcoin as input I could send you two Bitcoin And then I have another output that minus one Bitcoin 398 00:26:11,916 --> 00:26:14,376 Right. And if it wasn't clear, you could just check. 399 00:26:14,376 --> 00:26:20,836 And the sums add up. Right. One Bitcoin in two plus minus one, one equals one. 400 00:26:22,476 --> 00:26:26,796 But really, you know, like there shouldn't be a negative Bitcoin. 401 00:26:27,376 --> 00:26:27,536 Right. 402 00:26:28,036 --> 00:26:29,876 That would be really, really bad. 403 00:26:30,756 --> 00:26:33,216 And if it was in the clear, I could check it. 404 00:26:33,836 --> 00:26:37,516 But in the confidential transactions, all of the amounts are basically encrypted. 405 00:26:37,716 --> 00:26:38,056 They're hidden. 406 00:26:38,396 --> 00:26:38,576 Right. 407 00:26:38,616 --> 00:26:41,076 Only the sender and receiver can see how much it is. 408 00:26:41,696 --> 00:26:47,456 And suddenly, if I ignore the minus one Bitcoin, I started with a UTXO, which was worth one Bitcoin. 409 00:26:47,456 --> 00:26:48,896 And now you have two Bitcoin. 410 00:26:49,336 --> 00:26:51,636 So I can create money out of thin air. 411 00:26:51,636 --> 00:26:59,756 So the range proof, the whole idea of the range proof is to basically prevent negative outputs. 412 00:27:00,276 --> 00:27:05,796 It's to say that the sum of the inputs is equal to the sum of the outputs, 413 00:27:05,976 --> 00:27:11,596 and all of the outputs are positive, which is really what you need for these confidential transactions. 414 00:27:11,916 --> 00:27:16,876 So we developed bulletproofs, which was a particularly short zero-knowledge proof 415 00:27:16,876 --> 00:27:21,436 that didn't have something called a trusted setup, 416 00:27:21,576 --> 00:27:23,616 but more importantly, it was very short. 417 00:27:24,236 --> 00:27:26,336 And it was specifically designed 418 00:27:26,336 --> 00:27:29,276 to be good at these range proofs. 419 00:27:29,656 --> 00:27:32,116 And it's now used in Monero. 420 00:27:32,456 --> 00:27:34,076 It's used in Zcash. 421 00:27:34,076 --> 00:27:36,576 It's used in all of these privacy protocols 422 00:27:36,576 --> 00:27:40,496 for basically their privacy, 423 00:27:40,776 --> 00:27:42,416 as their privacy zero knowledge proof. 424 00:27:42,716 --> 00:27:44,496 It's interesting to me, even that, you know, 425 00:27:44,576 --> 00:27:46,356 Greg Maxwell, Peter Willa at this time 426 00:27:46,356 --> 00:27:51,016 were, you know, doing as much research as it sounds like they were on zero knowledge proofs 427 00:27:51,016 --> 00:27:53,336 because zero knowledge proofs on Bitcoin are not really used. 428 00:27:53,436 --> 00:27:55,096 You know, that didn't really go anywhere. 429 00:27:56,136 --> 00:27:59,736 I'm curious, like, what was the conversation like? 430 00:27:59,816 --> 00:28:04,436 I mean, was there any discussion of what was the discussion like about using zero knowledge 431 00:28:04,436 --> 00:28:06,496 proofs on Bitcoin specifically back then? 432 00:28:06,496 --> 00:28:10,016 Yeah, I mean, I think they're like just, you know, technically interested people. 433 00:28:10,316 --> 00:28:14,796 And, you know, I don't think that I mean, I think even Satoshi talked about zero knowledge 434 00:28:14,796 --> 00:28:15,476 proofs. 435 00:28:15,476 --> 00:28:19,656 I think that this is a technology that predates Bitcoin. 436 00:28:20,296 --> 00:28:24,236 I think what sort of comes with Bitcoin, 437 00:28:24,236 --> 00:28:29,096 where there's kind of this funny coincidence of timelines, 438 00:28:29,476 --> 00:28:35,656 is that Bitcoin and blockchains, with their rising popularity, 439 00:28:35,896 --> 00:28:39,616 it just so happens to be, and maybe it's not a pure coincidence, 440 00:28:40,096 --> 00:28:42,376 it's that A, blockchains are the perfect applications 441 00:28:42,376 --> 00:28:49,376 for both the privacy and the scaling aspects of these ZKPs and ZKSNARKs. 442 00:28:50,536 --> 00:28:55,896 But importantly, and they've also, you know, we sort of, 443 00:28:55,976 --> 00:28:57,716 they were like kind of a theoretical idea. 444 00:28:57,956 --> 00:29:00,276 We knew how to theoretically do this. 445 00:29:00,276 --> 00:29:02,996 A little bit like, you know, if you think about AI, 446 00:29:03,736 --> 00:29:09,096 you know, we've had kind of like AI and neural networks, 447 00:29:09,096 --> 00:29:11,576 we've had them for like 20, 30 years, right? 448 00:29:11,576 --> 00:29:16,796 In theory, we knew how to do these things, but they weren't efficient enough to be deployed in practice. 449 00:29:17,576 --> 00:29:26,816 And then there's kind of this liftoff, right, where suddenly the technology gets efficient enough to be deployed in practice. 450 00:29:26,996 --> 00:29:34,936 And this sort of has happened, I would say, since, you know, roughly like 2012, 2014. 451 00:29:35,276 --> 00:29:40,856 Like, you know, these things have gotten like much more and more efficient and there's more libraries and more deployed. 452 00:29:40,856 --> 00:29:45,836 And I think we're still in kind of the exponential

curve of these things getting better and better. 453 00:29:46,856 --> 00:30:00,396 And yeah, and I think sort of, you know, I mean, I think that a lot of people, I don't know if Bitcoin will ever have privacy transactions, but I think a lot of people agree that this is like a flaw in Bitcoin, right? 454 00:30:00,396 --> 00:30:06,876 is that you can see, you know, every address and you can see the amount. 455 00:30:07,036 --> 00:30:11,516 And if I know what your address is, then I know exactly how many bitcoins you're holding. 456 00:30:11,976 --> 00:30:17,936 And I mean, the original paper was called an anonymous P2P cash system. 457 00:30:18,356 --> 00:30:22,896 Like, but it's not really anonymous in any way. 458 00:30:22,996 --> 00:30:23,196 Right. 459 00:30:23,256 --> 00:30:25,936 It's, you know, I know once I know it's pseudonymous. 460 00:30:26,276 --> 00:30:26,436 Right. 461 00:30:26,436 --> 00:30:32,256 Right. Where but once I know your address and if you send me money, I will know your address. 462 00:30:32,556 --> 00:30:38,896 And there's like companies which are specialized on doing analytics and figuring out what your address is. 463 00:30:38,896 --> 00:30:46,476 So so I think a lot of law enforcement actually loves Bitcoin for that because it makes it very easy to trace, you know, where the money is going. 464 00:30:46,556 --> 00:30:50,956 It's all public. It's incredibly difficult to maintain perfect pseudonymity. 465 00:30:51,136 --> 00:30:53,976 It's like almost impossible to maintain perfect pseudonymity. 466 00:30:53,976 --> 00:30:58,476 So like in practice, it's just not really private at all is sort of the general point. 467 00:30:58,936 --> 00:31:02,256 I think that if you want privacy, you need to use a private cryptocurrency. 468 00:31:02,636 --> 00:31:07,856 Like you need to use something like Monero or Zcash or, you know, some alternative protocol. 469 00:31:08,296 --> 00:31:11,676 It's just not. Yeah. That's not what Bitcoin is made for. 470 00:31:12,116 --> 00:31:14,556 The challenge there becomes auditability, right? 471 00:31:14,596 --> 00:31:18,756 I mean, we've just had this issue with Zcash where this inflation bug was discovered. 472 00:31:18,756 --> 00:31:21,256 We don't even know how long, you know, that was there. 473 00:31:21,256 --> 00:31:35,096 I mean, I guess we can infer for a very long time. We don't know if it was ever abused. I mean, is that a fundamental tradeoff that we have to make with privacy protocols in general and using zero knowledge proofs and blockchain systems? 474 00:31:35,096 --> 00:31:59,076 It seems like it. I mean, I think that, you know, you could hide. It definitely seems like that is a fundamental flaw. You know, you can do things. You know, one thing that you could do is you could isolate the problem. You could say, you know, there's kind of a side block. 475 00:31:59,076 --> 00:32:13,676 I think it was at some point there was some discussion about it where, you know, you could opt into this kind of like you basically bridge your like, you know, you could you would call it you would develop it as an L2. 476 00:32:14,096 --> 00:32:23,556 Right. You would say I bridge my Bitcoin to an L2 that L2 uses privacy, private transactions. 477 00:32:23,556 --> 00:32:25,796 and then I can bridge it back. 478 00:32:26,336 --> 00:32:30,116 And the reason why that is important is because if there's a bug, 479 00:32:30,176 --> 00:32:35,196 if there's a flaw in the L2, it will only affect the L2 users. 480 00:32:35,476 --> 00:32:40,876 It will never affect the Bitcoin users. 481 00:32:40,876 --> 00:32:44,556 Meaning like even if there is inflation on the L2, on the L1, 482 00:32:44,676 --> 00:32:46,736 there would never be an issue. 483 00:32:46,736 --> 00:32:50,896 Yeah, you could never withdraw more funds from the L2 than went in. 484 00:32:51,616 --> 00:32:51,716 Right. 485 00:32:51,716 --> 00:32:55,116 Right. So the L1 layer would be integral, essentially. 486 00:32:55,116 --> 00:33:08,056 Yeah. And I think that's, you know, especially for Bitcoin with its properties and sort of this, you know, like stability being, you know, the utmost important design principle. 487 00:33:08,336 --> 00:33:17,056 I think that's the only way that you could ever deploy this is as a sort of standalone thing for people who want to use it. 488 00:33:17,056 --> 00:33:21,536 there is, you know, in all fairness, there's a downside to this. 489 00:33:21,936 --> 00:33:25,256 The downside is that if privacy is opt-in, 490 00:33:25,876 --> 00:33:28,776 and we see this with, like, basically Zcash and Monero, 491 00:33:28,876 --> 00:33:32,356 the main difference at this point is that Zcash is opt-in privacy 492 00:33:32,356 --> 00:33:35,656 and Monero is not, it's default privacy. 493 00:33:36,256 --> 00:33:41,116 If it's opt-in, then fewer and fewer, 494 00:33:41,116 --> 00:33:45,256 like, then if you're using it, you become suspicious just by using it. 495 00:33:45,256 --> 00:33:48,756 So one of the biggest advancement in privacy technologies 496 00:33:48,756 --> 00:33:53,096 that we've had in the last decade is, in my opinion, 497 00:33:53,316 --> 00:33:54,476 is end-to-end encrypted messaging. 498 00:33:55,176 --> 00:33:58,396 So WhatsApp, Signal, iMessage, not Telegram. 499 00:33:58,936 --> 00:33:59,656 Don't use Telegram. 500 00:34:00,716 --> 00:34:02,476 Basically use end-to-end encrypted messaging. 501 00:34:03,476 --> 00:34:05,716 And the beauty of it is that, especially WhatsApp, 502 00:34:06,016 --> 00:34:09,096 is so popular, so globally popular, right? 503 00:34:09,516 --> 00:34:13,856 That you don't suddenly become suspicious by using WhatsApp, right? 504 00:34:13,856 --> 00:34:21,816 But it's kind of assumed to be, you know, your default signal and iMessage as well. 505 00:34:22,696 --> 00:34:26,656 And you basically, with privacy, there's something called kind of the anonymity set. 506 00:34:27,236 --> 00:34:31,016 Your anonymity set for WhatsApp is

a billion people, right? 507 00:34:31,076 --> 00:34:35,196 You're one out of a billion people, like basically every eighth person in the world. 508 00:34:35,336 --> 00:34:38,496 Like impossible to find the needle in that haystack. 509 00:34:38,496 --> 00:34:51,436 Well, and it's, you know, you suddenly don't become suspicious by using, you know, if you're dissident in some country, like, it's like it would almost be less normal to not use WhatsApp, right? 510 00:34:51,936 --> 00:34:58,436 And it would be less normal to, and the beauty is, you know, I mean, Signal is still the gold standard because it's all open source. 511 00:34:58,436 --> 00:35:00,936 but yeah if you use 512 00:35:00,936 --> 00:35:02,336 you know Signal and so on 513 00:35:02,336 --> 00:35:04,496 there's no way you know that 514 00:35:04,496 --> 00:35:06,356 that even the companies behind 515 00:35:06,356 --> 00:35:08,636 them that they can read your messages 516 00:35:08,636 --> 00:35:10,196 and 517 00:35:10,196 --> 00:35:12,536 yeah and the reason 518 00:35:12,536 --> 00:35:14,436 why that's so powerful is this 519 00:35:14,436 --> 00:35:16,596 kind of default first 520 00:35:16,596 --> 00:35:18,556 default privacy and 521 00:35:18,556 --> 00:35:20,616 yeah with a layer 2 approach 522 00:35:20,616 --> 00:35:22,576 I mean we're not close to that but like 523 00:35:22,576 --> 00:35:24,536 with that you would never you know 524 00:35:24,536 --> 00:35:26,556 this is the trade-off right like you wouldn't get this 525 00:35:26,556 --> 00:35:27,616 default behavior 526 00:35:27,616 --> 00:35:35,956 so but yeah that's kind of I think that people would my prediction and I'm not an expert in 527 00:35:35,956 --> 00:35:43,176 kind of the the politics of it but that you know the only way this would ever get 528 00:35:43,176 --> 00:35:52,636 you know popular is really as a as a layer to kind of approach I want to definitely get into 529 00:35:52,636 --> 00:35:56,576 zero knowledge proofs and their applications for post-quantum Bitcoin. 530 00:35:56,736 --> 00:35:59,436 But before we do that, I just want to kind of like close the loop. 531 00:36:00,096 --> 00:36:05,036 Are there ways or applications that, I mean, are there ways that you'd like to see zero 532 00:36:05,036 --> 00:36:09,596 knowledge proofs used for Bitcoin going forward, like outside of PQ? 533 00:36:09,756 --> 00:36:13,856 Like, how would you like to see zero knowledge proofs be used in Bitcoin specifically or for 534 00:36:13,856 --> 00:36:14,776 Bitcoin specifically? 535 00:36:15,616 --> 00:36:21,836 Yeah, I think the, I mean, I think the simplest, one of the main ways that, you know, is sort of 536 00:36:22,636 --> 00:36:26,116 is purely beneficial, like no, I don't know, 537 00:36:26,156 --> 00:36:28,056 at least I don't see any downsides, 538 00:36:28,056 --> 00:36:32,516 is if we, you know, if we produce, 539 00:36:34,596 --> 00:36:36,616 and I think that, you know, 540 00:36:36,836 --> 00:36:39,876 and I'll maybe get

to talk about a new paper 541 00:36:39,876 --> 00:36:44,976 that we're just about to, that we just published. 542 00:36:46,596 --> 00:36:49,776 These proofs have gotten so fast that, you know, 543 00:36:49,776 --> 00:36:55,316 this idea that which long used to be kind of a theoretical idea, but now it's practiced, 544 00:36:55,436 --> 00:37:01,776 that I can prove basically not just the current block is valid, but I can prove that the entire 545 00:37:01,776 --> 00:37:09,296 history of Bitcoin was valid, right? That every single transaction was valid. I think that's real 546 00:37:09,296 --> 00:37:13,316 now. Like, I think, you know, it requires engineering effort. It requires, you know, some 547 00:37:13,316 --> 00:37:16,296 some funding, some people to do this. 548 00:37:16,296 --> 00:37:21,656 But I fundamentally believe if we sit down and try to implement this, we can. 549 00:37:22,236 --> 00:37:26,136 And the benefit for that would just be easier to run a node? 550 00:37:27,056 --> 00:37:30,656 It would be that you can run a Lite client on your phone. 551 00:37:31,596 --> 00:37:34,016 And normally today when I run a Lite client, 552 00:37:34,396 --> 00:37:38,196 I have to connect to some full node and trust that full node. 553 00:37:39,056 --> 00:37:42,096 But here I would run a Lite client that would fully, 554 00:37:42,096 --> 00:37:46,796 like it can't be fooled. It would fully check. It's basically like it's checking every single 555 00:37:46,796 --> 00:37:53,436 transaction. I know exactly what my balance is. I cannot be fooled. I don't have to trust anyone 556 00:37:53,436 --> 00:37:59,336 and it can run on my phone. And like it basically doesn't use it. It hardly uses any computational 557 00:37:59,336 --> 00:38:04,256 resources. Who's holding the data at that point? I mean, is it just like there's some computers 558 00:38:04,256 --> 00:38:09,296 that will have just big, giant nodes that are holding all the data? Yeah. So that's that's, 559 00:38:09,296 --> 00:38:10,896 you know, sort of the architectural difference 560 00:38:10,896 --> 00:38:13,436 is you still need kind of archival nodes 561 00:38:13,436 --> 00:38:16,536 and you do need to maintain, you know, 562 00:38:16,576 --> 00:38:18,216 the one thing that you need to maintain 563 00:38:18,216 --> 00:38:22,276 is your own UTXOs maybe, like that you want to spend. 564 00:38:23,316 --> 00:38:26,356 And like, this isn't, you know, this is an issue. 565 00:38:26,556 --> 00:38:29,216 Like you do need to still trust, 566 00:38:30,116 --> 00:38:31,856 like in Ethereum, they call this problem 567 00:38:31,856 --> 00:38:33,356 the data availability problem. 568 00:38:33,996 --> 00:38:35,536 There's even solutions around that. 569 00:38:35,616 --> 00:38:36,936 How do you make sure that these nodes 570 00:38:36,936 --> 00:38:38,356 are actually storing the data? 571 00:38:39,296 --> 00:38:41,896 there are solutions for that. 572 00:38:41,896 --> 00:38:46,396 But it at least enables a world where, you know, 573 00:38:46,996 --> 00:38:50,016 it's sort of basically there would still be nodes 574 00:38:50,016 --> 00:38:51,296 that run the current software. 575 00:38:52,956 --> 00:38:56,236 But everybody else who's currently not running a node, 576 00:38:57,456 --> 00:39:11,084 like your phones who are like connected to some RPC server they trust some you know exchange for their data right They don have to trust anyone anymore They just can run you know basically a fully validating node 577 00:39:11,084 --> 00:39:16,664 that checks all of the transactions. And yeah. The idea here basically being that you can 578 00:39:16,664 --> 00:39:22,484 effectively check your balances and be sort of running your own mini node. The only trust 579 00:39:22,484 --> 00:39:27,804 associated is you just know that someone is holding the data somewhere. Right. Yeah. 580 00:39:27,804 --> 00:39:30,304 and that that data is correct. 581 00:39:31,064 --> 00:39:32,544 You don't have to trust that it's correct. 582 00:39:32,704 --> 00:39:34,564 You do not have to trust because it's the zero knowledge proof. 583 00:39:34,584 --> 00:39:35,524 It's the zero knowledge proof, right? 584 00:39:35,884 --> 00:39:39,464 Nobody can tell you, right, like this is the important difference. 585 00:39:40,364 --> 00:39:43,784 Right now, someone else is holding the data when I'm running a phone 586 00:39:43,784 --> 00:39:46,124 and I have to trust that it's correct, basically. 587 00:39:47,444 --> 00:39:49,604 Here, someone else can still hold the data 588 00:39:49,604 --> 00:39:52,444 and, you know, maybe I can locally download the data 589 00:39:52,444 --> 00:39:56,344 that I personally care about, like my balance, my UTXLs. 590 00:39:56,344 --> 00:40:00,204 But I do not have to trust anyone that it's correct. 591 00:40:00,944 --> 00:40:06,804 I see. So it would be kind of like the servers that are like dropping into, you know, my river app right now or whatever. 592 00:40:07,124 --> 00:40:13,784 I could literally just have a zero knowledge proof that that 100 percent guaranteed to me that that data was correct, whatever was being pulled. 593 00:40:14,344 --> 00:40:14,684 Exactly. 594 00:40:15,244 --> 00:40:17,964 Any other kind of last minute other ZKP? 595 00:40:18,024 --> 00:40:22,804 Why do you think that zero knowledge proofs haven't, you know, kind of the Bitcoin zero? 596 00:40:22,804 --> 00:40:38,104 Is it just political? Is it just difficult to, like you said, difficult to kind of create these kinds of changes in Bitcoin? Is that basically it? Is there anything deeper than that in terms of like people's concerns about harms with zero knowledge proofs or risks associated with zero knowledge proofs? 597 00:40:38,104 --> 00:40:46,604 So I think that a lot of it, I mean, I think the best comparison that we can do is to other blockchains, 598 00:40:46,844 --> 00:40:52,024 especially Ethereum, sort of as the second larger one. 599 00:40:53,124 --> 00:40:59,504 I mean,

for example, this idea of having, I think two or three things. 600 00:40:59,504 --> 00:41:11,924 So first of all, basically the first, yes, a lot of it is political. 601 00:41:12,224 --> 00:41:17,764 And this idea of, for example, having these fast syncing, like a proof that the entire history is correct. 602 00:41:18,224 --> 00:41:22,324 There are blockchains, something called MENA, that have this deployed. 603 00:41:22,964 --> 00:41:23,984 So it exists. 604 00:41:24,144 --> 00:41:25,404 The technology exists. 605 00:41:25,404 --> 00:41:28,764 it's 606 00:41:28,764 --> 00:41:31,304 of course it's 607 00:41:31,304 --> 00:41:33,644 you know both I think the two hesitations 608 00:41:33,644 --> 00:41:35,524 of it that aren't just 609 00:41:35,524 --> 00:41:37,364 you know political and it's 610 00:41:37,364 --> 00:41:39,124 slow to update are that 611 00:41:39,124 --> 00:41:41,344 the old generation of 612 00:41:41,344 --> 00:41:43,184 zero knowledge proof I think that there's also 613 00:41:43,184 --> 00:41:45,304 you know again people not talking 614 00:41:45,304 --> 00:41:47,224 with each other and there's like this is kind of what 615 00:41:47,224 --> 00:41:49,404 we're trying to fix with this new proposal 616 00:41:49,404 --> 00:41:50,184 I think this is like 617 00:41:50,184 --> 00:41:53,384 the academics have turned out of the 618 00:41:53,384 --> 00:41:55,344 Bitcoin space and the Bitcoin space is kind 619 00:41:55,344 --> 00:42:01,764 of turned off from zero knowledge proofs in like the last, you know, five, six, seven 620 00:42:01,764 --> 00:42:02,284 years maybe. 621 00:42:04,044 --> 00:42:13,124 And I think that the old generation of zero knowledge proofs, they had a bunch of downsides. 622 00:42:13,124 --> 00:42:18,004 So the first kind of, you know, generation of practical zero knowledge proofs, they had 623 00:42:18,004 --> 00:42:19,004 a bunch of downsides. 624 00:42:19,184 --> 00:42:24,864 So for example, the bug that you talked about in Zcash, this was related to something called 625 00:42:24,864 --> 00:42:25,864 a trusted setup. 626 00:42:26,804 --> 00:42:28,384 So this trusted setup, 627 00:42:28,624 --> 00:42:29,324 like in the beginning 628 00:42:29,324 --> 00:42:30,364 of the zero-knowledge proof, 629 00:42:30,544 --> 00:42:31,684 you need to do some setup. 630 00:42:32,064 --> 00:42:34,584 And if some information 631 00:42:34,584 --> 00:42:36,244 from that setup gets leaked, 632 00:42:36,404 --> 00:42:37,624 then, you know, 633 00:42:37,684 --> 00:42:39,164 people can prove statements. 634 00:42:39,284 --> 00:42:40,344 They can prove that one plus one 635 00:42:40,344 --> 00:42:41,184 is equal to three. 636 00:42:41,584 --> 00:42:43,064 And this would be very bad. 637 00:42:43,404 --> 00:42:43,584 Okay. 638 00:42:44,844 --> 00:42:46,904 So the first generation 639 00:42:46,904 --> 00:42:47,644 of zero-knowledge proofs 640 00:42:47,644 --> 00:42:48,744 had these downsides. 641 00:42:51,444 --> 00:42:53,444 Because they had trusted setups? 642 00:42:53,624 --> 00:42:54,464 Because they had trusted setups. 643 00:42:54,464 --> 00:42:58,964 setup is the fundamental downside with with for zero knowledge proofs in the sense that like people 644 00:42:58,964 --> 00:43:05,124 can effectively forge proofs that used to be the downside that that used to be so now we have very 645 00:43:05,124 --> 00:43:10,144 good zero knowledge proofs so bulletproofs for example doesn't have a trusted setup but now the 646 00:43:10,144 --> 00:43:16,464 and the other problem is you know it maybe use some more advanced cryptography that uh like would 647 00:43:16,464 --> 00:43:22,004 have introduced new assumptions into bitcoin but the newest generation of zero knowledge proofs 648 00:43:22,004 --> 00:43:24,704 just uses hash functions. 649 00:43:25,324 --> 00:43:27,464 So you can deploy it using 650 00:43:27,464 --> 00:43:31,624 SHA-256, like something that's already used in Bitcoin. 651 00:43:32,164 --> 00:43:33,884 It doesn't have a trusted setup. 652 00:43:34,344 --> 00:43:36,124 It's become much, much faster. 653 00:43:36,864 --> 00:43:39,824 So this is a huge benefit is like producing these proofs 654 00:43:39,824 --> 00:43:40,764 with the bottleneck. 655 00:43:40,944 --> 00:43:44,164 And that's become much, much faster over the years. 656 00:43:44,444 --> 00:43:46,524 There's a lot of engineering that's gone into it. 657 00:43:46,804 --> 00:43:49,684 Most zero-knowledge proofs that are used today, 658 00:43:49,804 --> 00:43:50,944 that are implemented today, 659 00:43:50,944 --> 00:43:53,104 do still have a trusted setup, though, right? 660 00:43:53,404 --> 00:43:54,424 So I disagree with that. 661 00:43:54,504 --> 00:43:55,804 That's exactly why I'm saying that. 662 00:43:55,924 --> 00:43:56,824 Oh, that's what we're arguing. 663 00:43:56,844 --> 00:43:59,304 This is like the disconnect, right? 664 00:43:59,324 --> 00:44:01,844 I think that Bitcoiners still think about zero-knowledge proofs 665 00:44:01,844 --> 00:44:04,704 as these things with a trusted setup, and that's evil, and this is why we— 666 00:44:04,704 --> 00:44:06,424 But don't, like—isn't, like, what, Groth16? 667 00:44:06,684 --> 00:44:07,624 I'm just, like, thinking of examples. 668 00:44:07,644 --> 00:44:08,464 These are all trusted setups. 669 00:44:08,464 --> 00:44:09,044 Yeah, but it's 2016. 670 00:44:09,844 --> 00:44:10,064 What? 671 00:44:10,344 --> 00:44:11,924 Groth16 means 2016. 672 00:44:12,184 --> 00:44:12,844 Oh, that— 673 00:44:12,844 --> 00:44:13,724 We're in 2026. 674 00:44:13,884 --> 00:44:16,664 But don't most protocols still use these? 675 00:44:16,744 --> 00:44:18,544 They're completely outdated. 676 00:44:18,544 --> 00:44:20,384 Like, no one's even using these trusted setups. 677 00:44:20,384 --> 00:44:22,004 No, I mean, zero-knowledge proofs anymore? 678 00:44:22,024 --> 00:44:23,804 It's a bit more nuanced. 679 00:44:23,924 --> 00:44:24,424 I'm being facetious. 680 00:44:24,804 --> 00:44:28,524

But basically, there is a generation of zero-knowledge proofs, 681 00:44:28,644 --> 00:44:29,664 something like GRAS-16, 682 00:44:30,544 --> 00:44:36,284 that people were very, very focused on proof size 683 00:44:36,284 --> 00:44:38,644 and verifier time. 684 00:44:38,644 --> 00:44:41,104 And if you want the smallest proof size, 685 00:44:42,324 --> 00:44:44,984 GRAS-16 has the smallest proof size. 686 00:44:45,084 --> 00:44:46,644 That's these 200-byte proofs. 687 00:44:46,644 --> 00:44:50,284 and what people sort of realized 688 00:44:50,284 --> 00:44:54,404 I mean, you know, again these things have long and complicated 689 00:44:54,404 --> 00:44:58,444 histories but what people use is that actually what matters 690 00:44:58,444 --> 00:45:02,864 like if it's 200 bytes or even 200 kilobytes 691 00:45:02,864 --> 00:45:06,124 if I'm proving that an entire block is correct 692 00:45:06,124 --> 00:45:10,204 or an entire history of Bitcoin is correct, I don't care if I have to download 693 00:45:10,204 --> 00:45:14,404 200 kilobytes. It's like not really in any way relevant 694 00:45:14,404 --> 00:45:17,464 on my gigabit connection, right? 695 00:45:17,864 --> 00:45:19,924 Like it just doesn't really matter. 696 00:45:20,244 --> 00:45:21,504 For that particular application. 697 00:45:21,584 --> 00:45:22,404 For that particular application. 698 00:45:22,404 --> 00:45:23,524 For some other applications, 699 00:45:23,704 --> 00:45:25,204 it might be more meaningful. 700 00:45:25,204 --> 00:45:26,404 If I have a proof per transactions, 701 00:45:26,584 --> 00:45:27,624 it matters a bit more. 702 00:45:28,344 --> 00:45:30,424 But, you know, this is like... 703 00:45:30,424 --> 00:45:32,144 Like I think this was like a conversation 704 00:45:32,144 --> 00:45:33,344 that I had with Robin Linus 705 00:45:33,344 --> 00:45:35,004 and there was like a lot of concern 706 00:45:35,004 --> 00:45:36,104 about the fact that, you know, 707 00:45:36,164 --> 00:45:38,064 if they stepped up to a non-trusted setup 708 00:45:38,064 --> 00:45:39,844 type of zero knowledge proof for BitVM, 709 00:45:39,944 --> 00:45:41,384 that would like make it, you know... 710 00:45:41,384 --> 00:45:43,224 Yeah, I mean, BitVM is its own beast. 711 00:45:43,224 --> 00:45:46,444 We don't need to go down that rabbit hole. 712 00:45:47,444 --> 00:45:57,144 This is very much in the very Bitcoin-specific, because we don't want to add our upcode. 713 00:45:57,424 --> 00:46:09,584 But yeah, if we basically allow for slightly larger proofs, they're significantly larger, but maybe for many applications, like for solvency proof. 714 00:46:10,264 --> 00:46:11,584 I don't care if it's 200 kilobytes. 715 00:46:11,584 --> 00:46:12,444 That's fine. Who cares? 716 00:46:12,444 --> 00:46:13,224 Who cares, right? 717 00:46:13,764 --> 00:46:14,764 It's 200 kilobytes. 718 00:46:14,904 --> 00:46:17,184 Like my phone, you know, every time I open Instagram, 719 00:46:17,764 --> 00:46:22,784 I'm downloading like many megabytes of AI slop generated images, right? 720 00:46:23,064 --> 00:46:24,744 Like I can download 200 kilobytes. 721 00:46:27,164 --> 00:46:30,724 But these proofs, it turns out they're much faster to generate. 722 00:46:31,604 --> 00:46:33,004 And I can generate them. 723 00:46:33,084 --> 00:46:36,504 I can build them without a trusted setup, just from hash functions. 724 00:46:37,084 --> 00:46:39,904 Like at some point, I don't like the term, 725 00:46:39,904 --> 00:46:42,904 but this is what some people refer to as Starks. 726 00:46:44,164 --> 00:46:47,404 It's in that family, like, I don't like the term. 727 00:46:47,524 --> 00:46:48,184 It's a snark. 728 00:46:48,304 --> 00:46:49,344 It's just a hash-based snark. 729 00:46:49,564 --> 00:46:50,484 It's a hash-based snark. 730 00:46:50,504 --> 00:46:52,644 This is the correct term. 731 00:46:52,904 --> 00:46:53,044 Sure. 732 00:46:53,324 --> 00:46:55,824 And, yeah, these things are much faster. 733 00:46:56,424 --> 00:46:59,304 There's a lot of progress being made on them. 734 00:46:59,444 --> 00:47:04,164 And this is where I would say the major development effort goes. 735 00:47:04,364 --> 00:47:07,884 So just to, like, kind of summarize, this is pretty interesting and important. 736 00:47:07,884 --> 00:47:09,804 I mean, this is a question that I've asked several people. 737 00:47:09,904 --> 00:47:12,204 Like, why have zero knowledge proofs not taken off for Bitcoin? 738 00:47:12,424 --> 00:47:14,804 And this is a unique answer that you're giving me. 739 00:47:14,884 --> 00:47:16,264 So I want to, like, drill into it a little bit. 740 00:47:16,344 --> 00:47:27,344 Your general point of view is that the reason why zero knowledge proofs didn't kind of go too far in the land of Bitcoin is because these sort of older version of zero knowledge proofs back in the day were less efficient. 741 00:47:27,544 --> 00:47:28,044 They were bigger. 742 00:47:28,124 --> 00:47:28,984 They had trusted setups. 743 00:47:28,984 --> 00:47:31,784 They had tradeoffs that Bitcoiners just were unwilling to deal with. 744 00:47:31,964 --> 00:47:33,844 And that is no longer the case. 745 00:47:34,484 --> 00:47:35,464 Yeah, I would say that's true. 746 00:47:35,464 --> 00:47:38,244 So would you say that you're hopeful that zero knowledge proofs? 747 00:47:38,284 --> 00:47:43,624 And again, I think there's a lot of really interesting PQ applications for ZKPs that we're going to get into. 748 00:47:43,864 --> 00:47:52,364 But like generally, broadly speaking, you know, you feel like Bitcoiners just need to kind of open their minds to like this new wave of zero knowledge proofs. 749 00:47:52,404 --> 00:47:57,684 There's a ton of different applications where zero knowledge proofs can be useful for Bitcoin that don't have the tradeoffs they used to. 750 00:47:57,684 --> 00:47:59,764 We need to open our minds. 751 00:47:59,944 --> 00:48:04,004 We need to open our, you know, engineering, our, you know, sort of

research. 752 00:48:04,004 --> 00:48:08,204 And like, it's just not. 753 00:48:08,784 --> 00:48:15,344 And I think the vehicle for it will be the post-quantum transition. 754 00:48:15,844 --> 00:48:19,464 Because there it's like, it's not suddenly a nice to have. 755 00:48:19,644 --> 00:48:22,644 In my opinion, it's a necessity. 756 00:48:23,224 --> 00:48:27,284 All right, guys, taking a quick moment to thank my new sponsors of the show. 757 00:48:27,684 --> 00:48:32,844 First off, the one and only Layer 2 Labs, pushing forward research and development of DriveChains. 758 00:48:33,624 --> 00:48:38,864 Drive chains were first introduced as a soft fork proposal to Bitcoin, a.k.a. BIP300, BIP301. 759 00:48:39,564 --> 00:48:45,704 These BIPs essentially propose a bridging mechanism between Bitcoin and Layer 2s that are incentive-aligned with miners, 760 00:48:45,984 --> 00:48:49,344 and they've gotten a ton of attention over the last couple of years. 761 00:48:49,804 --> 00:48:53,064 If you're curious about how drive chains could work in practice, though, 762 00:48:53,484 --> 00:48:57,784 check out Layer2Labs.com and download their alternative frontend to Bitcoin Core. 763 00:48:58,284 --> 00:49:01,984 It lets you play with drive chains and see how they actually work in real life. 764 00:49:02,844 --> 00:49:14,324 I'd also like to introduce Hashi, an alternative primitive to traditional L2s that allows users to execute a wide range of Bitcoin DeFi activities without having to trust a federated bridge. 765 00:49:14,484 --> 00:49:26,924 With Hashi, Bitcoin is controlled by an MPC wallet that requires a quorum of proof of stake validators on the SUI network to execute Bitcoin transactions based on the validity of smart contracts. 766 00:49:27,624 --> 00:49:35,024 At least a third of the staking power of the SUI validators network is required to execute these MPC mint and redeem transactions, 767 00:49:35,424 --> 00:49:41,104 which is a substantive improvement in trust assumptions relative to other L2s or sidechain bridges. 768 00:49:42,064 --> 00:49:48,004 Hashi's commercial team is also stacked, including a crew of former builders from the crypto division of Meta. 769 00:49:48,584 --> 00:49:53,324 I think we're going to see a suite of super competitive Bitcoin DeFi products built with this protocol, 770 00:49:53,324 --> 00:49:57,644 So definitely check out the HashU page on sui.io if you're curious. 771 00:49:58,684 --> 00:50:01,424 Last but not least, shout out to Bitbox. 772 00:50:01,884 --> 00:50:06,964 Bitbox is one of the easiest and most simple to use Bitcoin hardware while it's on the market right now. 773 00:50:07,144 --> 00:50:18,524 If you have friends or family members that you want to make sure stay safe and use cold storage, but maybe they're not the most Bitcoin native people in the world, I highly recommend checking out Bitbox. 774 00:50:18,524 --> 00:50:26,584 They're completely open source, no compromises on security, but they're also

super easy to use, really intuitive UX. 775 00:50:27,144 --> 00:50:32,724 Plus, you can use them with concierge multi-sig services like Unchained, which I'm personally a big fan of. 776 00:50:33,144 --> 00:50:39,644 If you want to check out their hardware wallets, go to bitbox.swiss and use code BitcoinRails to get a discount. 777 00:50:40,204 --> 00:50:41,424 All right, back to the show. 778 00:50:41,764 --> 00:50:45,804 And potentially zero-knowledge proofs specifically could be a necessity. 779 00:50:45,804 --> 00:50:54,844 I think the post-quantum transition will be incredibly painful if we don't also embrace zero-knowledge proofs. 780 00:50:55,044 --> 00:50:57,644 Okay. Tell me why. That is very interesting. 781 00:50:57,784 --> 00:51:03,164 Because no one's really spoken about zero-knowledge proofs for quantum until I heard from you guys the work that you guys were doing. 782 00:51:03,284 --> 00:51:05,944 I mean, we're all talking about hash-based signatures and, you know. 783 00:51:06,004 --> 00:51:06,144 Yeah. 784 00:51:06,144 --> 00:51:08,004 No one's talking about zero-knowledge proofs for quantum. 785 00:51:08,004 --> 00:51:09,584 Because it's sort of the second step. 786 00:51:09,584 --> 00:51:20,404 And I think that like the only, you know, like the only thing that makes sense, like for Bitcoin is hash based signatures. 787 00:51:20,904 --> 00:51:21,984 You think that. 788 00:51:22,284 --> 00:51:23,384 Let's just pause there. 789 00:51:23,524 --> 00:51:26,924 You think that hash based signatures are the signature scheme we should go with. 790 00:51:26,984 --> 00:51:28,064 This is not overcomplicating. 791 00:51:28,644 --> 00:51:30,624 People like people love to overcome. 792 00:51:30,664 --> 00:51:33,584 Dan came on my show and plugged for lattice based signatures. 793 00:51:33,584 --> 00:51:33,804 Yeah. 794 00:51:33,904 --> 00:51:37,104 I mean, lattice based signatures are like in many ways they're better. 795 00:51:37,104 --> 00:51:41,104 But like, I just don't see a world where Bitcoin will accept that. 796 00:51:41,104 --> 00:51:42,104 Really? 797 00:51:42,104 --> 00:51:44,104 Like, it's Bitcoin is so conservative. 798 00:51:44,104 --> 00:51:46,104 Like technically, it's so, so conservative. 799 00:51:46,104 --> 00:51:51,104 Like we can't agree on like, you know, it takes whatever. 800 00:51:51,104 --> 00:51:59,104 Like, I mean, I was there in the early days of like the block size debate and like the whole community ripped itself apart over like a one number. 801 00:51:59,104 --> 00:52:03,104 Right. Like it's like it is just the way that it is. Right. 802 00:52:03,104 --> 00:52:04,944 And if we accept that as a reality. 803 00:52:04,992 --> 00:52:08,812 Like, I think, I mean, I totally understand Dan's points, right? 804 00:52:08,872 --> 00:52:15,012 Like, if you have a purely technical discussion, you know, there's great arguments for lattice-based signatures because they're smaller. 805 00:52:15,392 --> 00:52:21,092 But I just

don't see that, like, this is not for Bitcoin. 806 00:52:21,632 --> 00:52:26,132 Like, Bitcoin will not, especially as the first step, right? 807 00:52:26,172 --> 00:52:29,832 Like, you could also support multiple signature schemes, right? 808 00:52:29,832 --> 00:52:33,992 Like, I think that's a very reasonable future, you know. 809 00:52:33,992 --> 00:52:37,932 and maybe, you know, we gain the trust in the lattice base signature schemes. 810 00:52:38,172 --> 00:52:42,532 And like I personally like would trust them, but this is not what matters, right? 811 00:52:42,592 --> 00:52:46,112 It's like, you know, does the whole project do all of these, you know, 812 00:52:46,112 --> 00:52:50,632 like this incredible diversity of people who use Bitcoin, do they trust lattice base schemes? 813 00:52:51,452 --> 00:52:53,352 Probably that's a tough pill to swallow. 814 00:52:53,552 --> 00:52:57,452 So we should like, you know, sort of just go by the easiest thing to swallow 815 00:52:57,452 --> 00:52:59,192 and then deal with the consequences. 816 00:52:59,192 --> 00:53:09,772 And then later on, especially if we update our processes of how difficult it is to upgrade to technological changes, then later on we can still have lattice-based signatures. 817 00:53:09,952 --> 00:53:14,432 And I think it's tremendously important also to do research in lattice-based cryptography. 818 00:53:15,772 --> 00:53:20,232 But I think as a first step, what is the benefit of hash-based signatures? 819 00:53:20,672 --> 00:53:26,312 The benefit is they're simple and you don't have to introduce any new assumptions. 820 00:53:26,312 --> 00:53:34,712 You can build them from SHA256, which is a hash function that's already built in Bitcoin, that's used for proof of work, that Bitcoin already relies on. 821 00:53:35,332 --> 00:53:39,532 So you suddenly, like, have, you don't need any new assumptions. 822 00:53:39,952 --> 00:53:41,892 It's, you know, they're fairly well understood. 823 00:53:42,592 --> 00:53:43,672 We know how to build them. 824 00:53:44,492 --> 00:53:49,312 The only downside, and it's a big downside, is that the signatures get significantly larger. 825 00:53:50,412 --> 00:53:52,832 So then we need to deal with that problem. 826 00:53:52,832 --> 00:54:17,652 But as a first step, I just think it's like, like, I rather like agree on hash base signatures should be added to Bitcoin as a first step. Like, if we want anything in post-quantum and if we care about security really, really fundamentally, and if we care about minimal assumptions, we're not going to get anything better. So we should just add them. Period. Full stop. 827 00:54:17,652 --> 00:54:30,612 Okay, so let's drill down into the signature scheme conversation. And then I promise we're going to get to zero knowledge proofs for post-quantum as the second step, as you mentioned. But there's so much to go into like right here in this conversation. 828 00:54:31,332 --> 00:54:33,492 Okay, so first of all, you said signature size. 829 00:54:34,092 --> 00:54:35,692 Hash-based signatures are bigger. 830 00:54:35,932 --> 00:54:37,032 This is a big issue. 831 00:54:37,752 --> 00:54:52,772 I think, obviously, Jonas Nick is working really tirelessly with Ethan Heilman and a bunch of other people at Blockstream and Conduition and others on reducing the size of hash-based signatures and trying to create the smallest possible hash-based signature shrinks. 832 00:54:53,632 --> 00:54:59,292 I think I read on the website for a local host that you guys are going to be doing sort of a review of this scheme. 833 00:54:59,292 --> 00:55:05,552 What are your sort of general thoughts about shrinks as a solution to the size problem? 834 00:55:05,832 --> 00:55:12,132 I think shrinks is a great scheme. 835 00:55:12,372 --> 00:55:17,092 I think there's especially like so there's one major choice that you need to make with these hash based signatures. 836 00:55:17,652 --> 00:55:20,692 It's called stateful or stateless. 837 00:55:20,692 --> 00:55:24,052 and sort of stateful signatures 838 00:55:24,052 --> 00:55:28,552 are ones that where basically you need to sign 839 00:55:28,552 --> 00:55:30,812 and you need to remember how many messages you've signed. 840 00:55:31,312 --> 00:55:33,772 And you get shorter signatures if you do that. 841 00:55:34,412 --> 00:55:36,992 The problem is if your computer dies 842 00:55:36,992 --> 00:55:39,892 or your memory burns out, right? 843 00:55:40,052 --> 00:55:42,552 Then like, I don't know, 844 00:55:42,612 --> 00:55:45,632 you secure hardware device where you sort how many, 845 00:55:45,752 --> 00:55:47,712 like if you somehow fooled about 846 00:55:47,712 --> 00:55:50,572 how many messages you've signed, 847 00:55:50,692 --> 00:55:52,772 like you signed a message, but you forgot about it, 848 00:55:53,432 --> 00:55:54,732 you didn't increment the counter, 849 00:55:55,412 --> 00:55:57,632 then that could have catastrophic consequences. 850 00:55:58,192 --> 00:55:59,872 Like leakage of your private key level. 851 00:55:59,892 --> 00:56:00,972 Leakage of your private key level. 852 00:56:01,132 --> 00:56:01,752 Exactly that. 853 00:56:03,392 --> 00:56:05,572 So how do you deal with that? 854 00:56:05,832 --> 00:56:06,892 Well, there's two solutions. 855 00:56:06,892 --> 00:56:10,992 The traditional solution is you could develop a stateless scheme 856 00:56:10,992 --> 00:56:13,552 where you don't need to remember anything. 857 00:56:14,252 --> 00:56:18,272 The problem with stateless schemes is that the signatures are much, much larger. 858 00:56:18,272 --> 00:56:22,632 So regular Sphinx is basically that stateless scheme, right? 859 00:56:22,632 --> 00:56:22,892 Exactly. 860 00:56:23,192 --> 00:56:23,392 Okay. 861 00:56:24,472 --> 00:56:27,532 Yeah, so there's Sphinx and then there's XMSS. 862 00:56:28,592 --> 00:56:31,272 XMSS is, I think, the state full one. 863 00:56:32,952 --> 00:56:35,672 I think Sphinx is the state less one. 864

00:56:36,112 --> 00:56:37,772 I mean, they all have like slightly different names. 865 00:56:37,972 --> 00:56:39,472 But basically, there's stateless and stateful. 866 00:56:39,572 --> 00:56:40,512 Like the names don't really matter. 867 00:56:41,092 --> 00:56:44,092 And what shrinks is, is basically a hybrid. 868 00:56:44,092 --> 00:56:50,532 So shrinks just says we have the stateful scheme for short signatures. 869 00:56:51,372 --> 00:56:59,712 And then we basically have, so we have like one fallback mechanism like, oh shit, I lost my keys. 870 00:57:00,112 --> 00:57:02,112 You know, I lost my counter, right? 871 00:57:02,612 --> 00:57:03,492 I like shut down. 872 00:57:03,592 --> 00:57:04,752 I have some like red flag. 873 00:57:04,812 --> 00:57:05,972 I have some corrupted state. 874 00:57:06,152 --> 00:57:07,412 I don't want to trust this. 875 00:57:07,932 --> 00:57:10,552 I just need one basically like parachute. 876 00:57:10,552 --> 00:57:16,392 It's like a parachute thing where I can transfer my funds to a new address, all of them. 877 00:57:18,292 --> 00:57:22,232 And then, yeah, all of them. 878 00:57:22,372 --> 00:57:26,912 And then, you know, that's it. 879 00:57:27,212 --> 00:57:33,692 I think, and that one, like, basically, the idea is that you basically get, try to get the best of both worlds. 880 00:57:33,692 --> 00:57:37,132 where you get the short signatures from stateful, 881 00:57:37,272 --> 00:57:41,052 but you also have the parachute from stateless 882 00:57:41,052 --> 00:57:42,172 that if your state is corrupted, 883 00:57:42,292 --> 00:57:43,812 you can still transfer out of the address. 884 00:57:43,812 --> 00:57:47,012 This is adding, though, like a fair level of complexity 885 00:57:47,012 --> 00:57:50,372 to the whole like signing process in Bitcoin. 886 00:57:50,592 --> 00:57:53,092 Like, is there concern that the additional complexity 887 00:57:53,092 --> 00:57:55,912 associated with this might even outperform 888 00:57:55,912 --> 00:57:57,912 the complexity of using lattice-based signatures, 889 00:57:58,052 --> 00:57:58,492 for instance? 890 00:57:58,652 --> 00:58:00,592 Or I mean, like, are you concerned about 891 00:58:00,592 --> 00:58:07,312 like how this could be implemented in a way that actually ends up being more dangerous than just 892 00:58:07,312 --> 00:58:13,012 using a different signature scheme? Yeah, but like, I just we have to deal with it. 893 00:58:13,932 --> 00:58:18,532 Because of the politics, we have to deal with that. Yeah, I think I just don't see like, 894 00:58:19,292 --> 00:58:23,632 like, I just, I don't know, I don't want to spend, you know, like 10 years fighting about 895 00:58:23,632 --> 00:58:30,572 lattice-based signatures. Like, I mean, in my ideal world, we do both. Like, we definitely 896 00:58:30,572 --> 00:58:31,292 Right up front. 897 00:58:31,912 --> 00:58:38,312 Yeah, just like, go ahead, do, you know, do the hash base first, do the transition, you know, do that as quickly as possible. 898 00:58:38,312 --> 00:58:44,472 And then immediately after, do lattice base signatures, you know, whatever the most vetted best scheme is at that point in time. 899 00:58:44,712 --> 00:58:48,392 With the idea there that people could choose what they want to use, essentially. 900 00:58:49,112 --> 00:58:52,952 Are there any risks associated with, like, letting people choose which signature scheme? 901 00:58:53,032 --> 00:58:56,992 Does that introduce any weird vulnerabilities, letting people choose which signature scheme? 902 00:58:56,992 --> 00:59:02,192 I think it's like it's like the good thing is, I mean, well, let's say one of them is broken. 903 00:59:03,152 --> 00:59:04,612 Obviously, that's not good. 904 00:59:04,852 --> 00:59:05,012 Right. 905 00:59:05,192 --> 00:59:08,392 Like that's bad if you are using the one that's broken. 906 00:59:09,272 --> 00:59:15,252 But it's not the level of vulnerability that like, you know, we talked about for private coins. 907 00:59:15,332 --> 00:59:20,752 It's not suddenly if you chose the bad signature scheme that I'm screwed. 908 00:59:21,132 --> 00:59:21,392 Right. 909 00:59:21,532 --> 00:59:21,692 Right. 910 00:59:21,692 --> 00:59:21,952 Right. 911 00:59:21,952 --> 00:59:34,652 So that's, you know, like, I think that that's why I'm not as concerned about it, where like, you know, you would have a fee market, right? 912 00:59:34,672 --> 00:59:42,192 Like you would say that lattice-based signatures maybe are cheaper, but, you know, in some world they're more risky. 913 00:59:43,132 --> 00:59:47,792 But if you want to use lattice-based signatures, go ahead and use lattice-based signatures. 914 00:59:47,792 --> 00:59:55,832 And there's another world where maybe they're not less risky because of the user error associated with these stateful schemes or whatever. I mean, you just let people pick their poison, basically. 915 00:59:55,832 --> 01:00:17,052 Right. This is I mean, I think like that, you know, this is like, I mean, and I'm not deciding that. And that's probably also good. But like, in my mind, this is just do both. You know, it's far better to do both than to do none. I mean, I think the biggest risk is sitting around and not doing anything. 916 01:00:17,052 --> 01:00:20,092 and I would rather do both. 917 01:00:20,212 --> 01:00:22,492 I think the more natural one to start with 918 01:00:22,492 --> 01:00:25,892 is the minimal signature size, 919 01:00:26,372 --> 01:00:27,632 sorry, minimal assumptions, 920 01:00:27,892 --> 01:00:28,932 which is hash-based ones. 921 01:00:29,812 --> 01:00:30,912 By the way, just on hash-based, 922 01:00:30,992 --> 01:00:32,232 there is a third variant, 923 01:00:33,172 --> 01:00:35,072 which like for good reasons 924 01:00:35,072 --> 01:00:36,092 people are not proposing, 925 01:00:36,092 --> 01:00:37,692 but it is, you know, 926 01:00:37,852 --> 01:00:39,732 which is to say that, 927 01:00:39,912 --> 01:00:41,112 so you can also use something 928

01:00:41,112 --> 01:00:42,252 called a one-time signature. 929 01:00:42,712 --> 01:00:44,532 So which means that you can literally 930 01:00:44,532 --> 01:00:46,592 only sign one transaction ever. 931 01:00:47,052 --> 01:00:47,372 Right. 932 01:00:47,932 --> 01:00:49,972 And if you screw up, then you're toast. 933 01:00:50,332 --> 01:00:51,672 If you screw up, you're toast, right? 934 01:00:52,232 --> 01:00:56,372 The benefit is those are the shortest ones, shortest hash-based signatures you could possibly get. 935 01:00:56,692 --> 01:00:58,752 But you can never reuse an address. 936 01:00:59,192 --> 01:01:05,212 So it also, in some ways, helps with the privacy because you force people to not reuse addresses. 937 01:01:05,432 --> 01:01:05,892 That's right. 938 01:01:06,512 --> 01:01:08,252 Like you cannot reuse an address. 939 01:01:09,512 --> 01:01:15,112 The problem, of course, is like if someone sends money to your old address. 940 01:01:15,632 --> 01:01:16,572 That money is lost forever. 941 01:01:16,572 --> 01:01:22,692 You are screwed. You're kind of screwed, you know, which. 942 01:01:23,092 --> 01:01:28,052 And it also means like you can't test like if you want to receive, you know, 100 million dollars to an address. 943 01:01:28,252 --> 01:01:30,632 Yeah. Like how do you do that? 944 01:01:30,752 --> 01:01:35,852 This is not a serious like there's good reasons why people are not doing that one. 945 01:01:35,852 --> 01:01:48,232 But I'm just saying those are really like kind of stateless, stateful, hybrid, which shrinks and one time are kind of the four major like variants that you could have. 946 01:01:49,192 --> 01:01:54,332 I think basically shrinks is stateful and one time combined. 947 01:01:54,532 --> 01:01:56,632 Like it's shrinks and then the one time parachute. 948 01:01:57,652 --> 01:01:59,972 You think that's the best option that we have on the table? 949 01:02:00,072 --> 01:02:00,992 I think it's a very good. 950 01:02:01,072 --> 01:02:02,932 I mean, I would like to, you know, review it more. 951 01:02:03,292 --> 01:02:03,732 Right. 952 01:02:03,732 --> 01:02:06,472 this is exactly what we're, you know, want to do with Justin. 953 01:02:06,592 --> 01:02:10,312 But I think that's a very good option. 954 01:02:11,752 --> 01:02:13,092 Yeah, on the table. 955 01:02:13,592 --> 01:02:15,632 I want to say this on signature size. 956 01:02:15,812 --> 01:02:20,572 So, you know, you can spend time and effort 957 01:02:20,572 --> 01:02:23,192 into reducing the signature size 958 01:02:23,192 --> 01:02:25,852 and the big conversation there is stateful versus stateless. 959 01:02:26,312 --> 01:02:28,232 Once you've picked one of these things, 960 01:02:29,612 --> 01:02:32,552 like, there's kind of limits to it. 961 01:02:32,552 --> 01:02:35,792 Like we know, you know, how short these signatures can get. 962 01:02:36,312 --> 01:02:41,752 And there has been, you know, outside of Bitcoin, like cryptographers have worried about this beforehand. 963 01:02:42,812 --> 01:02:45,792 You're not going to get it's not going to get 10 times smaller. 964 01:02:46,372 --> 01:02:50,212 It's not even going to get twice smaller from like different things. 965 01:02:50,772 --> 01:02:52,392 Maybe you can shave a 5%. 966 01:02:52,392 --> 01:02:56,592 There is a fundamental limit to how efficient there's a fundamental limit. 967 01:02:56,592 --> 01:03:02,372 And the whole thing in cryptography is oftentimes, especially with size, 968 01:03:02,592 --> 01:03:05,932 is why are lattice-based signatures smaller and better? 969 01:03:06,032 --> 01:03:07,792 Because they have a bit more structure. 970 01:03:08,592 --> 01:03:12,612 And we can exploit that structure to make shorter signatures. 971 01:03:13,772 --> 01:03:21,432 But there's also potentially, at least in theory, more structure to exploit for an attacker. 972 01:03:22,072 --> 01:03:26,072 We don't think an attacker can fundamentally exploit the structure. 973 01:03:26,592 --> 01:03:34,492 Like elliptic curve-based signatures, what Bitcoin uses today, are much smaller, but they also have a lot more structure. 974 01:03:34,692 --> 01:03:39,892 And it's exactly that structure that quantum computers use to attack it. 975 01:03:40,612 --> 01:03:48,592 So that's versus hash-based signatures fundamentally have the least structure, which means the largest signatures. 976 01:03:48,592 --> 01:03:50,352 but yeah 977 01:03:50,352 --> 01:03:51,612 so I do think 978 01:03:51,612 --> 01:03:54,132 maybe there is some more innovation 979 01:03:54,132 --> 01:03:56,072 that can happen on hash-based signatures 980 01:03:56,072 --> 01:03:57,592 I think that 981 01:03:57,592 --> 01:04:00,092 you know the innovation that 982 01:04:00,092 --> 01:04:02,332 I'm especially excited 983 01:04:02,332 --> 01:04:04,332 about is can we get 984 01:04:04,332 --> 01:04:05,592 like 985 01:04:05,592 --> 01:04:08,292 what I think where there's more 986 01:04:08,292 --> 01:04:10,332 innovation is not necessarily the size 987 01:04:10,332 --> 01:04:11,692 I think the size we're like 988 01:04:11,692 --> 01:04:14,612 you know close-ish to lower limits 989 01:04:14,612 --> 01:04:16,492 but 990 01:04:16,492 --> 01:04:17,632 it's on 991 01:04:17,632 --> 01:04:22,732 like can we get more advanced signatures like multi signatures threshold signatures 992 01:04:22,732 --> 01:04:27,012 well this was going to be the next question because this was the exact point that Dan made 993 01:04:27,012 --> 01:04:31,492 when he came on the show was that if you want more functionality in Bitcoin or you want to 994 01:04:31,492 --> 01:04:36,892 maintain even just what we consider to be regular old functionality today you know lattice based 995 01:04:36,892 --> 01:04:41,412 would be a lot easier to do that with lattices than it would be with hashes are there solutions 996 01:04:41,412 --> 01:04:47,512 to getting something like threshold signatures or adapter signatures with hash based so it's I mean

997 01:04:47,512 --> 01:04:53,952 this would be part of this, you know, research project. I think that there's been less research 998 01:04:53,952 --> 01:05:07,270 on that I mean I fully agree with Dan that it fundamentally easier with lattices You never going to get something that as good as with lattices or as good as with elliptic curves with 999 01:05:07,270 --> 01:05:14,410 hash-based signatures on these advanced schemes. But I also think that there is, you know, and like 1000 01:05:14,410 --> 01:05:20,670 I've been working with Dan and Justin already on, you know, like, you know, it's like steps in that 1001 01:05:20,670 --> 01:05:26,330 direction? Can we get, you know, a threshold scheme for lattices that's better than what 1002 01:05:26,330 --> 01:05:30,350 existed beforehand? I've never heard anyone describe it that way. I thought that was 1003 01:05:30,350 --> 01:05:36,410 particularly useful that, you know, there's sort of a potentially a fundamental tradeoff between 1004 01:05:36,410 --> 01:05:43,730 structure and, you know, attack surface area. So, I mean, I guess in that situation is the idea that 1005 01:05:43,730 --> 01:05:49,130 Bitcoiners will always or maybe should always preference, you know, keeping attack surface 1006 01:05:49,130 --> 01:05:53,690 as minimal as possible and then, you know, just kind of do what we can about the structural, 1007 01:05:54,050 --> 01:05:56,210 you know, the structure issues or the functionality issues. 1008 01:05:56,210 --> 01:05:58,090 I think certainly as the first step, right? 1009 01:05:58,090 --> 01:06:05,930 I mean, this is again why, like, I think as the first step to like a post-quantum transition, 1010 01:06:07,290 --> 01:06:09,490 you know, this is what makes sense to me. 1011 01:06:09,890 --> 01:06:16,590 Like, is, you know, choose something that's very low on the structure thing. 1012 01:06:16,590 --> 01:06:19,530 and then we can kind of venture out 1013 01:06:19,530 --> 01:06:21,650 and obviously it should always be opt-in. 1014 01:06:22,670 --> 01:06:26,150 And you can opt to use a post-quantum, 1015 01:06:26,490 --> 01:06:28,990 you can opt to use a lattice-based public key, 1016 01:06:29,230 --> 01:06:30,390 lattice-based signature scheme. 1017 01:06:30,690 --> 01:06:32,550 For example, if you want to use a threshold, 1018 01:06:33,590 --> 01:06:38,510 like if you want to have lower fees, transaction fees. 1019 01:06:40,330 --> 01:06:43,830 I think that's kind of, yeah, that's how I view it 1020 01:06:43,830 --> 01:06:45,350 is that kind of the first step, 1021 01:06:45,350 --> 01:06:51,950 It just makes sense to, you know, first degree, we need to transition to something that's post-quantum. 1022 01:06:52,750 --> 01:06:58,830 And then let's choose the thing that's like the least structure, the easiest to swallow. 1023 01:06:59,490 --> 01:07:04,450 This word like cryptographic agility, you know, I feel like this is like the term du jour right now. 1024 01:07:04,550 --> 01:07:06,150 This is what like everyone's talking about. 1025 01:07:06,750 --> 01:07:11,410 And I'm curious like how that kind of like plays out actually in practice. 1026 01:07:11,410 --> 01:07:21,930 So, like, is the idea that, you know, we upgrade to hash-based signatures first, everyone migrates, and then, you know, there's a new, you know, lattice-based option that pops onto the scene. 1027 01:07:22,010 --> 01:07:23,790 And if you want that, you can upgrade again. 1028 01:07:23,910 --> 01:07:27,730 And this just goes on forever and ever into isogenies or, you know, whatever. 1029 01:07:28,170 --> 01:07:28,290 Yeah. 1030 01:07:28,370 --> 01:07:31,890 I mean, I don't think, you know, it needs to go on forever and ever, right? 1031 01:07:33,250 --> 01:07:37,410 But, you know, I think that, like... 1032 01:07:38,030 --> 01:07:39,210 But that's the idea, essentially. 1033 01:07:39,210 --> 01:07:48,670 Yeah, I mean, I think like, you know, probably like in my mind, you know, I think hopefully two is enough. But yeah, exactly. Yeah. 1034 01:07:49,150 --> 01:07:59,270 Do you think that there's a universe where we'll be able to add both hash based and lattice based in this just one ultimate, you know, PQ upgrade and then people just migrate once and that's that? 1035 01:07:59,270 --> 01:08:01,010 or will happen in stages. 1036 01:08:01,010 --> 01:08:01,770 I mean, that is, I don't know, 1037 01:08:01,810 --> 01:08:03,090 that's much more in the, like, 1038 01:08:03,150 --> 01:08:05,750 how difficult are upgrades, right, conversation. 1039 01:08:06,110 --> 01:08:07,470 Like, I think, yeah, the question is, like, 1040 01:08:07,490 --> 01:08:09,990 do we either remove the scariness of upgrades? 1041 01:08:10,770 --> 01:08:12,390 Like, you know, right now upgrades 1042 01:08:12,390 --> 01:08:14,490 are, like, the scariest thing ever. 1043 01:08:15,410 --> 01:08:17,670 And if that's the case, 1044 01:08:17,710 --> 01:08:20,630 then maybe it's better to put two things into one. 1045 01:08:21,630 --> 01:08:24,530 Or we're, like, you know, saying sort of, 1046 01:08:24,630 --> 01:08:27,830 we want to do one step and then another step. 1047 01:08:27,830 --> 01:08:33,410 I think, yeah, that's not really a technical discussion. 1048 01:08:34,050 --> 01:08:38,950 So I don't really have a position on how you see this playing out politically. 1049 01:08:39,270 --> 01:08:39,430 Yeah. 1050 01:08:40,790 --> 01:08:43,330 How do you feel about isogenies by any chance? 1051 01:08:43,430 --> 01:08:45,930 Just to give you like a wild card question on the cryptography side. 1052 01:08:45,930 --> 01:08:55,950 I think isogenies are, you know, definitely far more like risky. 1053 01:08:55,950 --> 01:08:58,750 and, you know, there was a couple years ago, 1054 01:08:59,210 --> 01:09:04,410 there was a pretty severe break of a popular isogeny scheme. 1055 01:09:05,090 --> 01:09:07,750 I mean, I think they're beautiful mathematically, 1056 01:09:08,030 --> 01:09:09,670 like very

interesting to study. 1057 01:09:10,070 --> 01:09:13,230 And, you know, we should always devote resources 1058 01:09:13,230 --> 01:09:15,670 to studying, you know, these advanced schemes 1059 01:09:15,670 --> 01:09:18,250 and they can, you know, give us much shorter signatures 1060 01:09:18,250 --> 01:09:19,930 and they do have advantages. 1061 01:09:20,850 --> 01:09:25,670 I would probably not advocate for having them deployed 1062 01:09:25,670 --> 01:09:27,630 quite yet. Because they're just too new 1063 01:09:27,630 --> 01:09:29,810 and they've had recent breaks 1064 01:09:29,810 --> 01:09:31,630 and they're just not secure enough 1065 01:09:31,630 --> 01:09:32,950 to secure the money in the world. 1066 01:09:33,210 --> 01:09:35,090 Yeah, I think exactly. Bottom line. 1067 01:09:35,090 --> 01:09:37,070 I think that lattices are 1068 01:09:37,070 --> 01:09:39,510 we do have 1069 01:09:39,510 --> 01:09:43,210 they are already 1070 01:09:43,210 --> 01:09:44,590 being deployed, they're 1071 01:09:44,590 --> 01:09:46,010 getting standardized, 1072 01:09:47,290 --> 01:09:49,550 we have pretty good 1073 01:09:49,550 --> 01:09:51,310 understanding of 1074 01:09:51,310 --> 01:09:52,990 the fundamental 1075 01:09:52,990 --> 01:09:55,270 mathematical problems 1076 01:09:55,270 --> 01:09:57,710 behind it and why we believe. 1077 01:09:59,850 --> 01:10:03,210 Lattices, it seems incredibly unlikely 1078 01:10:03,210 --> 01:10:06,570 that lattices will ever be fundamentally broken, 1079 01:10:06,710 --> 01:10:07,950 even by a quantum computer. 1080 01:10:08,630 --> 01:10:10,710 The problem with lattices is more, 1081 01:10:11,270 --> 01:10:13,330 it's something called you need to pick some parameters 1082 01:10:13,330 --> 01:10:16,710 and how to pick these parameters right. 1083 01:10:17,470 --> 01:10:19,770 It's like, I mean, you need to pick 1084 01:10:19,770 --> 01:10:21,230 basically your public key size. 1085 01:10:21,230 --> 01:10:24,310 and you know 1086 01:10:24,310 --> 01:10:25,310 like there's like a couple parameters 1087 01:10:25,310 --> 01:10:27,470 like the inputs have to be more constrained 1088 01:10:27,470 --> 01:10:28,270 like yeah 1089 01:10:28,270 --> 01:10:31,130 is it public use size specific? 1090 01:10:31,450 --> 01:10:32,470 yeah let's get more granular 1091 01:10:32,470 --> 01:10:33,830 yeah no I mean there's like 1092 01:10:33,830 --> 01:10:37,910 like with all of these cryptography 1093 01:10:37,910 --> 01:10:39,570 like even with hash functions 1094 01:10:39,570 --> 01:10:42,350 you have to say like the output of the hash 1095 01:10:42,350 --> 01:10:44,910 like for SHA-256 it's 256 bytes 1096 01:10:44,910 --> 01:10:45,330 okay 1097 01:10:45,330 --> 01:10:47,950 but you could also use SHA-512 1098 01:10:47,950 --> 01:10:49,510 where the output is 1099 01:10:49,510 --> 01:10:53,650 or 256 bits where the output is 512 bits. 1100 01:10:53,910 --> 01:10:56,410 Or there's even SHA-128, which you shouldn't use. 1101 01:10:56,710 --> 01:10:57,770 But, you know, there's like, 1102 01:10:58,110 --> 01:11:02,070 basically there's like different parameterizations 1103 01:11:02,070 --> 01:11:03,330 for the same problem. 1104 01:11:04,230 --> 01:11:05,530 And for hash functions, 1105 01:11:05,530 --> 01:11:07,450 we have a very, very good understanding 1106 01:11:07,450 --> 01:11:14,130 of like what the parameters is that we should choose. 1107 01:11:14,270 --> 01:11:15,210 Like what's secure, basically. 1108 01:11:15,210 --> 01:11:17,690 Like 128 isn't enough kind of thing. 1109 01:11:17,690 --> 01:11:28,290 Like sort of or, you know, in some situations you can even like we even have like, you know, some situations where it's OK to use 128 and then others where it's not OK to use 128. 1110 01:11:28,670 --> 01:11:36,590 So it's like we have a really good, you know, understanding of like we could be wrong. 1111 01:11:36,690 --> 01:11:45,890 Like you can always be wrong in these things, but it would be sort of very surprising, you know, to be really, really wrong about, you know, these things. 1112 01:11:45,890 --> 01:11:47,870 Breaking 256 would be very difficult. 1113 01:11:48,110 --> 01:11:48,330 Yeah. 1114 01:11:48,450 --> 01:11:56,710 And even like reducing, you know, kind of the 256 security to like something that's as secure as 200 bit security. 1115 01:11:56,710 --> 01:12:03,950 Like that would be like a major, major, major breakthrough and is fairly unlikely to happen even with a quantum computer. 1116 01:12:04,470 --> 01:12:07,110 So, yeah, some caveats to that. 1117 01:12:07,190 --> 01:12:10,210 But like the, you know, we have a very good understanding of it. 1118 01:12:11,430 --> 01:12:13,290 With Lattice, we don't have that understanding. 1119 01:12:13,450 --> 01:12:14,730 There's more research to be done there. 1120 01:12:14,730 --> 01:12:16,690 Yeah, it's just a bit more complicated. 1121 01:12:17,270 --> 01:12:24,610 So this is just this, you know, like, now suddenly there's two parameters and it's a bit more, there's a couple more parameters to pick. 1122 01:12:24,750 --> 01:12:26,750 And, you know, we have some understanding. 1123 01:12:26,870 --> 01:12:28,930 There's definitely research going into that. 1124 01:12:29,130 --> 01:12:34,790 If it's broken, you know, then it's like, okay, you know, maybe our parameters weren't quite good enough. 1125 01:12:35,090 --> 01:12:39,470 Which is also good because, like, we would get a warning sign for it, right? 1126 01:12:39,470 --> 01:12:45,170 Like we would be like, ooh, the security has been reduced by, you know, 10 bits, which isn't enough to break it. 1127 01:12:45,270 --> 01:12:48,630 But like, you know, now our margin of error is getting smaller. 1128 01:12:49,770 --> 01:12:51,810 So, you know, that's a better situation. 1129 01:12:51,930 --> 01:12:54,510 And with isogenies, there was suddenly like a full break. 1130 01:12:55,150 --> 01:12:58,590 Like it was like from one day, you know, people thought it was secure to

the next day. 1131 01:12:58,850 --> 01:13:01,550 It really was like you could extract the private key. 1132 01:13:01,650 --> 01:13:03,290 You just couldn't use the scheme at all anymore. 1133 01:13:03,290 --> 01:13:16,590 So that's, you know, that's the that's the that's why I would say that lattices are, you know, they're definitely much more trustworthy today than isogenies. 1134 01:13:18,010 --> 01:13:20,090 But there's still some open questions. 1135 01:13:20,090 --> 01:13:33,190 That's actually also very helpful to understand that there are still some open questions about, like, what are the specifics of how we're using lattices do impact security in a way that, like, we've just done that research with hashes already. 1136 01:13:33,290 --> 01:14:01,710 Yeah, I mean, I wouldn't quite call it the interesting part about it, which is also why, you know, why it's an interesting discussion, is that, you know, with all of this cryptography, the reason why, like, it's, you will never get, like, sort of, we will never, there will never be a day where it's like, okay, I can go here on this podcast and say that now we know lattices are secure. 1137 01:14:01,710 --> 01:14:09,210 like i mean again math can always be broken okay like it's it's you know not quite true but like 1138 01:14:09,210 --> 01:14:14,670 it's it's we will most likely you know maybe you know with our new ai overlords like they will be 1139 01:14:14,670 --> 01:14:22,550 able to prove that lattices are secure but that would be like uh the biggest breakthrough in math 1140 01:14:22,550 --> 01:14:29,570 in like uh yeah like proving that lattices or even hashbee signatures are 100 secure would be 1141 01:14:29,570 --> 01:14:31,370 a moon math breakthrough by AI, 1142 01:14:31,650 --> 01:14:33,050 like, it would be nuts. 1143 01:14:33,170 --> 01:14:34,070 It would be a Nobel Prize. 1144 01:14:34,690 --> 01:14:35,070 Yeah, yeah. 1145 01:14:35,290 --> 01:14:36,490 There's literally a million dollar 1146 01:14:36,490 --> 01:14:37,270 prize for it, 1147 01:14:37,370 --> 01:14:38,350 but really it's like, 1148 01:14:39,010 --> 01:14:39,650 you would get, 1149 01:14:39,990 --> 01:14:41,610 like, the million dollar prize 1150 01:14:41,610 --> 01:14:42,790 is just, you know, 1151 01:14:42,870 --> 01:14:44,630 sort of one sign of it. 1152 01:14:44,670 --> 01:14:45,370 Like, you would get 1153 01:14:45,370 --> 01:14:46,410 an immediate, like, 1154 01:14:46,470 --> 01:14:47,090 Turing Award, 1155 01:14:47,390 --> 01:14:50,390 like, if you prove that, 1156 01:14:50,590 --> 01:14:52,110 you know, hash-based signatures 1157 01:14:52,110 --> 01:14:53,350 are secure. 1158 01:14:53,690 --> 01:14:54,690 Is there any, like, 1159 01:14:54,730 --> 01:14:56,550 100% provable cryptography? 1160 01:14:57,550 --> 01:14:57,730 No. 1161 01:14:57,850 --> 01:14:58,050 No, no. 1162 01:14:58,110 --> 01:14:58,330 Yeah. 1163 01:14:58,330 --> 01:14:59,730 This is the whole point. 1164 01:14:59,810 --> 01:15:00,590 This is

the whole point. 1165 01:15:00,670 --> 01:15:03,530 So this is the fundamental question is called P versus NP. 1166 01:15:04,570 --> 01:15:09,010 So this is the fundamental question in computer science. 1167 01:15:09,850 --> 01:15:16,330 And basically the question is, is there anything that's, 1168 01:15:17,290 --> 01:15:19,070 or it's very related to the question to, 1169 01:15:19,410 --> 01:15:21,890 so in cryptography we need something called a one-way function. 1170 01:15:22,490 --> 01:15:26,810 So a function that's easy to compute one way, but hard to invert. 1171 01:15:27,510 --> 01:15:28,810 So proof of work is that, right? 1172 01:15:29,230 --> 01:15:35,930 It's easy to check the proof of work, but it's hard to find it, right? 1173 01:15:36,210 --> 01:15:42,350 So it's, you know, one way is easy, the other one is hard. 1174 01:15:42,350 --> 01:15:51,810 And we assume that for hash functions, you know, it's easy to check that they're correct, but it's hard to compute it. 1175 01:15:51,810 --> 01:16:02,230 But we cannot prove that this is fundamental because maybe, maybe, maybe there exists an algorithm that can suddenly like in one shot find your proof of work solution. 1176 01:16:03,130 --> 01:16:05,550 And then all of cryptography would be broken. 1177 01:16:06,490 --> 01:16:07,750 All of cryptography. 1178 01:16:07,790 --> 01:16:09,010 All of cryptography would be broken. 1179 01:16:09,470 --> 01:16:10,850 Nobody believes this to be true. 1180 01:16:11,250 --> 01:16:13,530 Like no serious person believes this to be true. 1181 01:16:13,670 --> 01:16:13,870 Right. 1182 01:16:13,870 --> 01:16:24,790 We basically assume there's a proof that P is not equal to NP, but we have no angle of, we have no concept of how we would prove this. 1183 01:16:24,870 --> 01:16:34,770 If somebody was able to prove that any of these cryptographic schemes were 100% unbreakable, verifiably, that would be a Nobel Prize situation right away. 1184 01:16:34,770 --> 01:16:42,150 Incredible. Like out of this world breakthrough. We're not even remotely close to it. 1185 01:16:42,150 --> 01:16:47,570 So basically closing the loop, we just feel more comfortable with hashes than we do with lattice base. 1186 01:16:47,570 --> 01:16:49,050 There's no such thing as proof. 1187 01:16:49,150 --> 01:16:50,730 There's no such thing as proof and security. 1188 01:16:50,730 --> 01:16:57,990 It's always only about comfort and how long have things been deployed and, you know, how much structure do these things have? 1189 01:16:58,170 --> 01:17:00,770 So it's always like more of a probability. 1190 01:17:01,130 --> 01:17:03,490 It's a bit of a wishy-washy, you know, discussion. 1191 01:17:03,610 --> 01:17:05,190 That's why it's feels so wishy-washy, right? 1192 01:17:05,190 --> 01:17:21,230 Like, which is, you know, you get all of these, you know, you get that M&A, like, and you get all of these mathematicians and computer science talking and like so on certain terms, because like I'm very certain, but I can never say I'm 100 percent certain. 1193 01:17:21,510 --> 01:17:31,010 Interesting. Well, yeah. So that'll be a fun debate. But yeah, I'm glad to hear that. I know there's some really interesting folks who are very excited about isogenies, I think, because the math is so beautiful and because. 1194 01:17:31,130 --> 01:17:31,850 Yeah, it's very exciting. 1195 01:17:31,850 --> 01:17:33,050 You know, yeah, exactly. 1196 01:17:33,150 --> 01:17:34,310 There's so much interesting thing. 1197 01:17:34,310 --> 01:17:42,470 And am I right that isogenies are sort of also based on some sort of elliptic curve-esque thing, which would be convenient? 1198 01:17:43,690 --> 01:17:48,010 But, yeah, it sounds like in talking to you like that is just not good. 1199 01:17:48,130 --> 01:17:59,628 That decades away potentially isogenies Yeah I would say And hopefully we won even need it because lattices and hash signatures will just be enough Yeah and zero proofs on top of it 1200 01:17:59,748 --> 01:18:00,688 Okay, so let's get into that. 1201 01:18:01,008 --> 01:18:03,808 So why do we need zero-knowledge proofs for post-quantum? 1202 01:18:04,048 --> 01:18:08,688 So the problem is that these hash-based signatures are huge. 1203 01:18:09,808 --> 01:18:13,728 So even, like, the best ones, like, even, you know, stateful best ones, like... 1204 01:18:13,728 --> 01:18:15,148 Even shrinks is too big? 1205 01:18:15,568 --> 01:18:17,828 Yeah, two, three kilobytes per signature, right? 1206 01:18:17,828 --> 01:18:22,288 versus like for elliptic curve-based signatures, 1207 01:18:22,508 --> 01:18:25,968 we're talking like less than 100 bytes, right? 1208 01:18:26,048 --> 01:18:27,908 It's like 20x basically, something like that. 1209 01:18:27,908 --> 01:18:30,088 20x, for every single transaction. 1210 01:18:30,288 --> 01:18:30,448 Right. 1211 01:18:31,228 --> 01:18:32,188 So like, you know. 1212 01:18:32,228 --> 01:18:33,548 So throughput reduces a lot. 1213 01:18:34,348 --> 01:18:37,688 Reduces, well, if you just put them in the block, 1214 01:18:37,788 --> 01:18:39,008 it reduces a lot, right? 1215 01:18:39,368 --> 01:18:41,408 So what can zero-knowledge proofs do? 1216 01:18:41,648 --> 01:18:43,548 Well, I told you that, you know, 1217 01:18:43,608 --> 01:18:45,228 that you can, they're a certificate 1218 01:18:45,228 --> 01:18:46,968 that I executed a transaction correctly. 1219 01:18:47,688 --> 01:18:54,248 So what you could have is a situation where, you know, if you don't want to increase, like one solution is increasing the block size. 1220 01:18:55,688 --> 01:18:59,808 The other one is, and, you know, we're already with SegWit. 1221 01:18:59,968 --> 01:19:03,448 We don't really count the witness data like quite the same way. 1222 01:19:03,508 --> 01:19:06,748 But still, you know, these things are huge and everybody needs to get them. 1223 01:19:06,828 --> 01:19:09,348 So this is like it's a fundamental issue, right? 1224 01:19:09,348 -->

01:19:10,288 I need to send them around. 1225 01:19:10,868 --> 01:19:13,788 It's like producing them and verifying them is actually fast. 1226 01:19:13,868 --> 01:19:14,748 That's not really the issue. 1227 01:19:14,748 --> 01:19:15,888 It's really the size. 1228 01:19:15,888 --> 01:19:31,728 So what I can do is that, you know, let's say the miner could be some other party, but just for simplicity, let's say the miner, when it produces a block, it also produces, it collects these transactions with all of the signatures. 1229 01:19:31,728 --> 01:19:39,208 And then it produces a snark, a post-quantum snark, so one that's secure against post-quantum adversaries. 1230 01:19:39,868 --> 01:19:45,848 And the snark basically asserts that this block had only valid signatures. 1231 01:19:46,668 --> 01:19:47,228 Okay. 1232 01:19:47,348 --> 01:19:52,928 So when you download the block, you download the block without the signatures and the snark, 1233 01:19:53,508 --> 01:19:59,128 and you just check the snark, and you're like, I don't see the signatures, but I know they must have been there. 1234 01:19:59,128 --> 01:20:01,268 so I don't really care 1235 01:20:01,268 --> 01:20:03,268 it's good enough 1236 01:20:03,268 --> 01:20:05,008 and this block is valid 1237 01:20:05,008 --> 01:20:07,428 and suddenly you've basically 1238 01:20:07,428 --> 01:20:09,428 removed, so you add the snark 1239 01:20:09,428 --> 01:20:11,808 let's say it's like 200 kilobytes in size 1240 01:20:11,808 --> 01:20:13,528 we can get them that low 1241 01:20:13,528 --> 01:20:15,788 but it's 200 kilobytes 1242 01:20:15,788 --> 01:20:17,728 in size no matter how big the block is 1243 01:20:17,728 --> 01:20:19,868 so as soon as I'm aggregating 1244 01:20:19,868 --> 01:20:21,368 more than 1245 01:20:21,368 --> 01:20:23,528 let's say 100 signatures, more than 100 1246 01:20:23,528 --> 01:20:25,508 transactions, this is suddenly worth it 1247 01:20:25,508 --> 01:20:27,128 because the 1248 01:20:27,128 --> 01:20:32,188 The proof is going to be smaller than 100 signatures combined. 1249 01:20:32,188 --> 01:20:38,288 Okay, so this is, so then are you just aggregating on transactions that have already been mined into blocks? 1250 01:20:38,328 --> 01:20:41,828 Or is this aggregation happening when you're putting transactions into blocks? 1251 01:20:42,048 --> 01:20:43,448 So it can happen either way. 1252 01:20:44,408 --> 01:20:49,148 So, I mean, the miner knows which transactions they're putting into the block. 1253 01:20:49,768 --> 01:20:53,048 They can even start, there's ways that they can start producing the proof 1254 01:20:53,048 --> 01:20:58,088 while they're constructing the block templates 1255 01:20:58,088 --> 01:20:59,628 or while they're collecting transactions. 1256 01:21:00,308 --> 01:21:02,268 They produce a proof that basically says, 1257 01:21:02,268 --> 01:21:04,708 this is the set of transactions that I've included. 1258 01:21:05,848 --> 01:21:10,088 And then when I send out the

block, I send out the proof along with it. 1259 01:21:10,508 --> 01:21:14,328 Would this require a soft fork or is this something? 1260 01:21:14,688 --> 01:21:16,488 Like what would need to happen? 1261 01:21:16,488 --> 01:21:19,568 Well, I mean, adding a new signature scheme requires a soft work. 1262 01:21:19,668 --> 01:21:20,148 Sure. 1263 01:21:20,608 --> 01:21:27,068 But like, yeah, like what consensus level changes would be added onto this PQ upgrade in order to do this? 1264 01:21:27,068 --> 01:21:32,528 So it's a question of whether basically I think the only question is, do you want to make it mandatory or optional? 1265 01:21:33,408 --> 01:21:40,308 So if you make it optional, so maybe it's not the miner producing it or it's someone else, 1266 01:21:40,308 --> 01:21:41,988 then you know 1267 01:21:41,988 --> 01:21:45,188 you basically the miner has the option 1268 01:21:45,188 --> 01:21:46,728 do I send all of the signatures 1269 01:21:46,728 --> 01:21:47,928 or do I send the snark 1270 01:21:47,928 --> 01:21:51,428 for them it also makes sense to send the snark 1271 01:21:51,428 --> 01:21:54,648 because suddenly everybody hears about their block faster 1272 01:21:54,648 --> 01:21:56,668 which is what miners care about 1273 01:21:56,668 --> 01:21:58,688 right like they want everybody to hear their block 1274 01:21:58,688 --> 01:22:00,768 like the incentives are already there 1275 01:22:00,768 --> 01:22:04,428 so for them it kind of makes sense to send the snark 1276 01:22:04,428 --> 01:22:06,248 especially 1277 01:22:06,248 --> 01:22:07,808 and here's a huge caveat 1278 01:22:07,808 --> 01:22:11,268 if the snark is fast enough to produce, right? 1279 01:22:11,328 --> 01:22:12,568 If I can produce it quickly, 1280 01:22:12,588 --> 01:22:15,388 then I really want to send the snark along with it. 1281 01:22:16,468 --> 01:22:20,508 So, but yeah, I don't think this needs to really be like, 1282 01:22:20,868 --> 01:22:22,288 you don't, in my opinion, 1283 01:22:22,288 --> 01:22:25,428 and there's other people who I would trust more 1284 01:22:25,428 --> 01:22:26,828 on this particular question, 1285 01:22:27,348 --> 01:22:29,048 but in my opinion, it doesn't necessarily, 1286 01:22:29,128 --> 01:22:31,128 I don't see why it needs to be enshrined in the protocol. 1287 01:22:31,288 --> 01:22:34,008 You don't need a consensus change necessarily for this. 1288 01:22:34,148 --> 01:22:35,608 No, because it could be optional. 1289 01:22:35,608 --> 01:22:42,088 you could still have basically the normal path where you send the signatures. 1290 01:22:42,568 --> 01:22:47,668 But if we make the other path good enough, then everybody is incentivized to follow the other path. 1291 01:22:48,048 --> 01:22:52,888 So this is basically exactly what we were talking about earlier in the episode, earlier in this interview. 1292 01:22:53,188 --> 01:22:56,908 But it's just that there's now this new reason, basically, to do it. 1293 01:22:57,608 --> 01:23:01,648 This, like, signature batching with zero-knowledge proofs because the signatures are so much bigger. 1294 01:23:01,648 --> 01:23:16,968 Yeah. I mean, just sort of, let's do some back of the envelope math. Like, I think the biggest blocks are like 5,000 transactions. We rarely see that. That's more like 4,000, 3,000 impactors. 1295 01:23:16,968 --> 01:23:32,968 But 5,000 transactions times 2 kilobytes per signature, so that's 5 is, I think that's 10 megabytes of signature data. 1296 01:23:33,568 --> 01:23:35,268 That's more than the block can hold, right? 1297 01:23:35,388 --> 01:23:39,668 I mean, that's more than 2x would a block reasonably hold. 1298 01:23:40,988 --> 01:23:44,948 And for standard transactions, it's like even substantively less than that. 1299 01:23:44,948 --> 01:23:45,228 Yeah. 1300 01:23:45,448 --> 01:23:50,828 So this is, you know, like, that seems like a problem, right? 1301 01:23:51,088 --> 01:23:51,928 Yeah, yeah, yeah. 1302 01:23:52,208 --> 01:23:56,968 So that's why I'm saying suddenly zero-knowledge proofs are not nice to have. 1303 01:23:57,968 --> 01:24:07,308 I feel like they must have because instead I can just add the zero-knowledge proof, 200 kilobytes, and boom. 1304 01:24:08,008 --> 01:24:08,308 Boom. 1305 01:24:08,868 --> 01:24:11,008 So do you think there's a universe? 1306 01:24:11,008 --> 01:24:17,028 So, yeah, so optional or required is sort of the difference between whether or not this has to be like a consensus level change. 1307 01:24:17,388 --> 01:24:18,308 Do you have an opinion? 1308 01:24:18,448 --> 01:24:24,388 I mean, is there what are the implications of like if it's optional and some people don't opt into this, then? 1309 01:24:24,988 --> 01:24:27,568 Yeah, I don't really I don't think I'm the best person. 1310 01:24:28,688 --> 01:24:30,948 Like the game theory is not your. 1311 01:24:31,288 --> 01:24:34,228 Yeah, no, I mean, I've thought about it, but I'm sure other people have thought about it more. 1312 01:24:36,188 --> 01:24:40,308 So I don't want to give like an uninformed opinion on that particular question. 1313 01:24:40,308 --> 01:24:44,048 I think, again, it's probably easiest to start with opt-in. 1314 01:24:44,608 --> 01:24:48,508 Like, I think it's, you know, very nice changes are the ones where you can opt-in first. 1315 01:24:48,988 --> 01:24:53,188 And then maybe we see, okay, well, you know, not everybody's doing it. 1316 01:24:53,248 --> 01:24:54,408 Let's force them to do it. 1317 01:24:55,068 --> 01:24:56,448 So we do it, you know. 1318 01:24:56,548 --> 01:25:05,128 And the good thing is the beauty of these zero knowledge groups is that one person needs to create it and everybody can verify it. 1319 01:25:05,328 --> 01:25:09,248 So it doesn't even need to be, you know, a minor. 1320 01:25:09,248 --> 01:25:15,028 It could be, you know, some friendly, like someone could stand up a server somewhere that does it. 1321 01:25:15,468 --> 01:25:17,288 Right. And that's all it needs.

1322 01:25:17,408 --> 01:25:19,428 And that server can be quite powerful. 1323 01:25:19,948 --> 01:25:22,128 Right. Because it only needs to be one. 1324 01:25:22,788 --> 01:25:29,248 Right. Like we can even, you know, I've done research with folks at NYU on like developing ASICs for snark generation. 1325 01:25:30,088 --> 01:25:35,368 I do want to talk about like, you know, how easy it is to produce these things. 1326 01:25:35,368 --> 01:25:40,968 But yeah, so you can like, you know, you can throw things at it. 1327 01:25:41,708 --> 01:25:44,728 And for everybody else, one person has to work harder. 1328 01:25:45,688 --> 01:25:46,808 Everybody else works. 1329 01:25:47,408 --> 01:25:48,248 It's easier. 1330 01:25:48,708 --> 01:25:49,288 It's like interesting. 1331 01:25:49,388 --> 01:25:54,868 I want to ask you like a million like game theoretical questions that you might not want to ask because essentially what we're to answer. 1332 01:25:55,228 --> 01:26:03,688 What we're talking about is you're you're potentially adding in this other player into the whole system, this prover player. 1333 01:26:03,688 --> 01:26:27,788 Yeah, I mean, I think that the beauty of it would be, I think the best design would be one where miners are incentivized to do it. And in my mind, if, you know, we transition to post-quantum anyway, and, you know, sending around, you know, I mean, I think that like the incentives are sort of naturally there. 1334 01:26:27,788 --> 01:26:29,348 Because they want to shave time. 1335 01:26:29,548 --> 01:26:38,508 They want to shave time or maybe they want to, you know, like if we like one way to implement this is to say you can do whatever you want, but we still have the block size limit. 1336 01:26:39,168 --> 01:26:42,768 And if they want to include more transactions, they will need a snark. 1337 01:26:42,768 --> 01:26:45,788 I mean, there is, you know, sort of I can tell you what concerns are. 1338 01:26:46,128 --> 01:26:53,388 Like probably what someone would say is that, you know, it's like now bigger miners for them. 1339 01:26:53,488 --> 01:26:55,108 It's easier to produce these snarks. 1340 01:26:55,108 --> 01:27:06,508 I think what's really important for this to work is that the time to produce the snark becomes really, really small. 1341 01:27:06,508 --> 01:27:16,188 If you want to put a proof of transactions instead of the actual transaction data into an actual block, though, that would not be an optional software. 1342 01:27:16,588 --> 01:27:18,628 That would be like a full consensus change. 1343 01:27:18,648 --> 01:27:21,868 So I think you definitely need to still transmit the transaction data. 1344 01:27:22,568 --> 01:27:25,488 Like there's no way that you can get rid of the transaction data. 1345 01:27:25,488 --> 01:27:33,608 Right now I'm just talking about the signatures because some people, as we discussed before, some people need to have the transaction data. 1346 01:27:34,388 --> 01:27:42,608 There can be some nodes like my phone, right, which was never going to have the transaction data anyway. 1347 01:27:42,888 --> 01:27:43,108 Sure. 1348 01:27:43,128 --> 01:27:45,228 Because it's already running out of battery, right? 1349 01:27:45,228 --> 01:27:56,388 But for them, it might be good enough to get sort of an insurance that the block is valid and I can get the data from someone else. 1350 01:27:56,608 --> 01:27:59,108 And I don't again, I don't have to trust that the data is correct. 1351 01:27:59,768 --> 01:28:05,228 I just have to like one honest note has to has to give it to me. 1352 01:28:05,548 --> 01:28:07,408 So that's yeah. 1353 01:28:07,408 --> 01:28:14,808 But you cannot like like sort of the miner cannot say I have a new block with a new transaction, but I'm not going to tell anybody what the transactions are. 1354 01:28:15,228 --> 01:28:17,068 That's never going to work. 1355 01:28:17,148 --> 01:28:22,788 But if you have 10 megabytes worth of data, worth of transactions, like you still will not be able to get. 1356 01:28:23,128 --> 01:28:24,948 No, but you don't have 10 megabytes of transactions. 1357 01:28:25,168 --> 01:28:26,288 It's 10 megabytes of signatures. 1358 01:28:26,848 --> 01:28:28,128 You can prune the signatures. 1359 01:28:28,368 --> 01:28:29,028 Got it, got it, got it. 1360 01:28:29,028 --> 01:28:30,348 The signatures are not important. 1361 01:28:30,348 --> 01:28:31,168 OK, right, right, right. 1362 01:28:31,288 --> 01:28:33,428 It's secret to the extreme. 1363 01:28:33,648 --> 01:28:34,508 I see, I see. 1364 01:28:34,508 --> 01:28:34,688 Right? 1365 01:28:34,808 --> 01:28:37,168 The witness, the transaction witness is segregated. 1366 01:28:37,768 --> 01:28:41,208 Nobody needs to store or remember what the signatures are. 1367 01:28:41,208 --> 01:28:42,148 That's the key. 1368 01:28:42,508 --> 01:28:43,468 OK, that makes sense. 1369 01:28:43,548 --> 01:28:44,028 That makes sense. 1370 01:28:44,028 --> 01:28:51,828 This is why I'm saying this is why it doesn't require a software because you can just prune out the signature piece and then you just only put the transaction data into the blocks. 1371 01:28:51,828 --> 01:28:57,268 Yes. I mean, I don't know, you know, like it probably is still a software. 1372 01:28:57,668 --> 01:29:00,168 Like this is now we're really getting into the mechanics. 1373 01:29:00,608 --> 01:29:07,728 I don't know what happens if I now send a block that suddenly doesn't create contain signatures, but it contains a proof. 1374 01:29:08,268 --> 01:29:09,548 Probably it's still a software. 1375 01:29:09,728 --> 01:29:12,048 So that's why I don't, you know, I don't want to talk about it. 1376 01:29:12,388 --> 01:29:13,408 Fair, fair, fair. 1377 01:29:13,408 --> 01:29:15,388 I won't drill too hard on that. 1378 01:29:15,488 --> 01:29:16,588 I just don't know, right? 1379 01:29:16,648 --> 01:29:21,128 Like maybe then I would need to send the signatures to some nodes, but the proof to others. 1380

01:29:21,468 --> 01:29:25,068 So probably you need some sort of fork. 1381 01:29:26,728 --> 01:29:31,648 I just, yeah, this is much, it's much more of a mechanical question than even an incentive question at that point. 1382 01:29:31,828 --> 01:29:39,188 So just on the cryptography side or like on the zero knowledge proof side, does this require like a specific kind of zero knowledge proof? 1383 01:29:39,488 --> 01:29:42,028 Yeah, so we want one that's post-quantum. 1384 01:29:42,028 --> 01:29:46,128 Right. Which is an open question because like old snarks were not post-quantum. 1385 01:29:46,208 --> 01:29:47,188 Yeah, but the new ones are. 1386 01:29:47,268 --> 01:29:49,448 The new ones all are. They're all hash-based snarks. 1387 01:29:49,648 --> 01:29:50,588 Hash-based snarks. 1388 01:29:50,768 --> 01:29:53,208 Yeah, they're hash-based snarks. So we want a hash-based snark. 1389 01:29:53,208 --> 01:29:53,588 Okay. 1390 01:29:56,268 --> 01:29:59,208 Especially if it's optional, you could think about lattice-based snarks. 1391 01:29:59,808 --> 01:30:04,328 But I think the simplest, again, first to start, we should go with hash-based snarks. 1392 01:30:04,328 --> 01:30:05,488 Hash-based snarks. All right. 1393 01:30:06,148 --> 01:30:08,628 Let's keep it sort of, keep it simple, stupid. 1394 01:30:08,848 --> 01:30:09,088 Okay. 1395 01:30:09,088 --> 01:30:13,088 And I think that I want to... 1396 01:30:14,248 --> 01:30:16,428 So the other big, big requirement, 1397 01:30:16,588 --> 01:30:20,708 so the reason why this also doesn't exist quite yet today is, 1398 01:30:21,368 --> 01:30:23,448 well, you want to prove that all of these transactions 1399 01:30:23,448 --> 01:30:24,728 and these signatures are valid. 1400 01:30:25,388 --> 01:30:27,368 These signatures are probably going to use, let's say, 1401 01:30:27,428 --> 01:30:30,368 a SHA-256-based hash function. 1402 01:30:31,568 --> 01:30:32,888 It turns out... 1403 01:30:32,888 --> 01:30:36,008 So, by the way, Ethereum is trying to do the same thing, right? 1404 01:30:36,008 --> 01:30:40,508 Ethereum sort of said, although maybe they're changing their mind on it, 1405 01:30:40,968 --> 01:30:53,746 that they willing to change their hash function So why do they want to change their hash function Well because it turns out that proving hash signatures or proving other hashes is much 1406 01:30:53,746 --> 01:30:58,026 easier. There's new hash functions called Poseidon, which are 1407 01:30:58,026 --> 01:31:01,926 specifically designed to be 1408 01:31:01,926 --> 01:31:05,686 you know, they're still a hash function, but they're specifically designed 1409 01:31:05,686 --> 01:31:08,206 to be friendly towards 1410 01:31:08,206 --> 01:31:10,566 towards snarks. 1411 01:31:10,946 --> 01:31:14,006 So it's much easier to prove, basically, 1412 01:31:14,246 --> 01:31:16,006 that a Poseidon hash was correct 1413 01:31:16,006 --> 01:31:18,106 than that a SHA-256 hash was correct. 1414 01:31:18,106 --> 01:31:18,746 So what does that do? 1415 01:31:18,766 --> 01:31:20,706 Does that make, like, verification time 1416 01:31:20,706 --> 01:31:21,526 more efficiency? 1417 01:31:21,526 --> 01:31:21,646 No, it's about proving time. 1418 01:31:21,866 --> 01:31:22,426 Oh, proving time. 1419 01:31:22,426 --> 01:31:23,566 It's all about proving time. 1420 01:31:23,726 --> 01:31:25,886 The verification time is sort of inherently small. 1421 01:31:26,586 --> 01:31:28,546 The proof size is also inherently, like, 1422 01:31:28,606 --> 01:31:30,046 it's a constant, it's fixed, 1423 01:31:30,146 --> 01:31:32,086 it's 200 kilobytes, no matter what you do. 1424 01:31:32,406 --> 01:31:33,646 What really matters is, like, 1425 01:31:34,026 --> 01:31:35,726 let's say, you know, because the problem is, 1426 01:31:35,826 --> 01:31:36,746 let's say I do this, 1427 01:31:36,746 --> 01:31:43,986 And if I use the snark from 2016, then, you know, I could have gone on the show in 2016. 1428 01:31:44,226 --> 01:31:47,746 I don't know if it existed, but, you know, I could have said like, OK, we can do this. 1429 01:31:47,826 --> 01:31:49,326 You know, in theory, we knew how to do this. 1430 01:31:49,806 --> 01:31:51,006 There's one big problem. 1431 01:31:52,286 --> 01:31:59,526 Producing the proof takes like, I don't know, it would take 10 hours or something like this. 1432 01:31:59,646 --> 01:32:03,406 Right. So it's like you get your blog and then you wait 10 hours. 1433 01:32:03,466 --> 01:32:05,206 Yeah. Then the miners are not incentivized. 1434 01:32:05,206 --> 01:32:08,166 Then the miners are very much not incentivized, non-starter, right? 1435 01:32:08,226 --> 01:32:08,906 Doesn't work. 1436 01:32:09,026 --> 01:32:09,226 Right. 1437 01:32:09,386 --> 01:32:10,446 Like, you can't do this. 1438 01:32:10,566 --> 01:32:10,806 I'm glad. 1439 01:32:11,106 --> 01:32:16,686 So what's, you know, sort of, A, these things have gotten faster, 1440 01:32:16,846 --> 01:32:19,666 and then Bitcoin, you know, Ethereum says, like, you know, 1441 01:32:19,706 --> 01:32:23,786 we use a hash function that's, like, maybe, think about it, 1442 01:32:23,786 --> 01:32:30,566 like, 100 times more efficient than, like, 1443 01:32:30,646 --> 01:32:35,046 it's 100 times more efficient than Shato 56, in particular for proving. 1444 01:32:35,206 --> 01:32:39,366 Again, this might be an okay choice for Ethereum. 1445 01:32:39,586 --> 01:32:40,966 I don't think Bitcoin would do this. 1446 01:32:41,246 --> 01:32:44,306 I was just going to ask, like, are there security trade-offs associated with this? 1447 01:32:44,426 --> 01:32:45,766 Again, same thing, right? 1448 01:32:45,766 --> 01:32:46,586 More structure. 1449 01:32:47,186 --> 01:32:48,466 More structure and new. 1450 01:32:49,146 --> 01:32:49,326 Right. 1451 01:32:49,506 --> 01:32:51,506 Exactly like the same thing as lattices. 1452 01:32:52,326 --> 01:32:55,926 There's even lattice-based hash functions, which are also cool. 1453 01:32:56,006 -->

01:32:57,006 But again, same problem. 1454 01:32:57,006 --> 01:33:04,346 Would it be fair to describe that problem as, like, we don't have evidence necessarily to say that they're less secure, 1455 01:33:04,346 --> 01:33:12,026 but we also don't have as much information to suggest that they are secure, basically. 1456 01:33:12,426 --> 01:33:13,086 Like, there's just... 1457 01:33:13,086 --> 01:33:16,006 Yeah. I mean, we do know that they have more structure. 1458 01:33:16,826 --> 01:33:19,066 Which is a vulnerability in general. 1459 01:33:19,306 --> 01:33:20,346 Yeah. I mean, it could in theory be. 1460 01:33:20,686 --> 01:33:24,206 And there have been, especially in recent years, I think the Ethereum, 1461 01:33:24,906 --> 01:33:30,046 like, chicken and egg, the Ethereum Foundation put out the price of, like, breaking Poseidon. 1462 01:33:31,306 --> 01:33:33,006 And so there have been attacks. 1463 01:33:33,006 --> 01:33:34,086 They're battle-testing it. 1464 01:33:34,086 --> 01:33:35,066 They're battle testing it. 1465 01:33:35,306 --> 01:33:39,266 And there are like, you know, it's getting scrapes. 1466 01:33:39,346 --> 01:33:42,046 It's not being broken, but there's some scrapes to it. 1467 01:33:42,246 --> 01:33:44,226 Okay, so Bitcoiners will not go for this. 1468 01:33:44,306 --> 01:33:46,426 Bitcoin winners will almost certainly not go for this. 1469 01:33:46,466 --> 01:33:48,386 And Ethereum even is probably like an... 1470 01:33:48,386 --> 01:33:51,226 So, and Ethereum is also, so I was talking with them on Friday. 1471 01:33:52,126 --> 01:33:55,626 And so, but they were like, well, but we, like, do we need to? 1472 01:33:55,626 --> 01:34:03,566 So, we actually, so some exciting news, like, is, so we just developed a new zero knowledge proof 1473 01:34:03,566 --> 01:34:06,086 that is specifically good for hash functions. 1474 01:34:06,346 --> 01:34:10,266 And it's specifically good for kind of standard hash functions. 1475 01:34:10,266 --> 01:34:14,246 So SHA2, SHA3, Blake is another one. 1476 01:34:14,706 --> 01:34:17,646 But, you know, SHA2 is the one that Bitcoin would care about. 1477 01:34:18,306 --> 01:34:21,286 So what we showed is with this new proof system, 1478 01:34:21,546 --> 01:34:22,626 you know, which is all like, 1479 01:34:23,306 --> 01:34:25,706 so I can prove SHA2 signatures, 1480 01:34:26,006 --> 01:34:30,426 which is exactly what I need for proving hash-based snarks. 1481 01:34:30,426 --> 01:34:34,346 so what we showed is that we can prove 1482 01:34:34,346 --> 01:34:37,666 I think for Bitcoin 1483 01:34:37,666 --> 01:34:39,746 like for Shad 2 it's like 1484 01:34:39,746 --> 01:34:43,106 I think it's about 300,000 hashes per second 1485 01:34:43,106 --> 01:34:45,346 on like a consumer laptop 1486 01:34:45,346 --> 01:34:47,026 on a powerful consumer laptop 1487 01:34:47,026 --> 01:34:48,446 so what does that mean? 1488 01:34:49,166 --> 01:34:50,586 sounds good, whatever 1489 01:34:50,586 --> 01:34:53,686 a hash based signature 1490 01:34:53,686 --> 01:34:58,866 has about 160 hashes 1491 01:34:58,866 --> 01:35:00,186 per signature 1492 01:35:00,186 --> 01:35:03,106 So it's roughly the ratio. 1493 01:35:03,626 --> 01:35:09,186 So if we do some back-of-the-envelope math, I think it basically means that I can do... 1494 01:35:10,966 --> 01:35:20,026 I think in the end it worked out that I can prove a block with 5,000 signatures in like one and a half seconds. 1495 01:35:20,846 --> 01:35:25,806 So it takes one and a half seconds to prove on a consumer laptop. 1496 01:35:26,346 --> 01:35:28,206 Okay. On the face of it, that sounds great. 1497 01:35:28,206 --> 01:35:45,346 Yeah, right. So this is, I mean, it's like 10 times better than the prior state of the art. So it's just like to say how practical these things, right? Like from, you know, taking hours in 2016 to 2026, taking like one and a half seconds on a consumer laptop. 1498 01:35:45,346 --> 01:35:47,146 if we really want to 1499 01:35:47,146 --> 01:35:50,426 we could throw a bigger 1500 01:35:50,426 --> 01:35:52,186 this is an 8 core server 1501 01:35:52,186 --> 01:35:53,706 8 core laptop 1502 01:35:53,706 --> 01:35:56,406 if you throw a 16 core laptop in it 1503 01:35:56,406 --> 01:35:58,026 you get it down to 0.75 seconds 1504 01:35:58,026 --> 01:35:59,546 these things are paralyzable 1505 01:35:59,546 --> 01:36:01,406 there's more things you can do 1506 01:36:01,406 --> 01:36:02,726 there's even tricks 1507 01:36:02,726 --> 01:36:06,666 you can do things where you generate the proof 1508 01:36:06,666 --> 01:36:09,106 already while you're collecting the block 1509 01:36:09,106 --> 01:36:11,106 so it's not 1.5 seconds 1510 01:36:11,106 --> 01:36:12,306 after you found the block 1511 01:36:12,306 --> 01:36:15,106 it's maybe like half a second after you found the block 1512 01:36:15,106 --> 01:36:16,626 or 0.25 seconds. 1513 01:36:17,126 --> 01:36:18,726 So I think we can really, you know, 1514 01:36:18,806 --> 01:36:21,366 and more research to be done 1515 01:36:21,366 --> 01:36:22,866 and more engineering to be done. 1516 01:36:23,706 --> 01:36:25,506 But there is like, you know, 1517 01:36:25,566 --> 01:36:27,166 I think that this notion 1518 01:36:27,166 --> 01:36:29,686 and especially with this new research 1519 01:36:29,686 --> 01:36:33,746 and, you know, we heavily use AI 1520 01:36:33,746 --> 01:36:34,666 to implement this, 1521 01:36:34,766 --> 01:36:37,206 which is like there's a huge benefit of that. 1522 01:36:37,466 --> 01:36:40,266 Like, you know, it's sort of research in that 1523 01:36:40,266 --> 01:36:42,546 and engineering that is absolutely accelerating. 1524 01:36:42,546 --> 01:37:00,546 So I think that today, like, I'm pretty confident to say that, yeah, I think technically we can prove that a Bitcoin block, even a Bitcoin block with post-quantum transactions is correct in a time that's hopefully not a major bottleneck. 1525 01:37:01,426 --> 01:37:11,386 Like, right, where, you

know, you find the block and then like half a second later, you have the proof that it's correct and you can, you know, send that out along with the block. 1526 01:37:11,386 --> 01:37:21,686 Is there any other interesting research that's happening in the Ethereum ecosystem related to PQ that you think Bitcoiners should be paying attention to or that you think, you know? 1527 01:37:21,686 --> 01:37:35,666 Yeah, I mean, I think there's a lot of, I think that a lot of this post-quantum snark research is sort of, you know, driven by like the Ethereum Foundation and folks in that. 1528 01:37:35,966 --> 01:37:42,586 So there's a lot of research going on there, especially also around libraries and actually implementing this. 1529 01:37:42,586 --> 01:37:45,046 I think that 1530 01:37:45,046 --> 01:37:47,706 yeah I think there's definitely 1531 01:37:47,706 --> 01:37:48,746 you know I think that 1532 01:37:48,746 --> 01:37:51,686 like the frenemies should work together 1533 01:37:51,686 --> 01:37:53,446 on this like because it's 1534 01:37:53,446 --> 01:37:55,606 I mean the thing that's 1535 01:37:55,606 --> 01:37:57,746 so unique with post-quantum 1536 01:37:57,746 --> 01:37:59,726 is that like if you look 1537 01:37:59,726 --> 01:38:01,526 at the presentations 1538 01:38:01,526 --> 01:38:03,186 of these quantum companies 1539 01:38:03,186 --> 01:38:05,226 which are trying to justify their 1540 01:38:05,226 --> 01:38:07,726 multi-million dollar 1541 01:38:07,726 --> 01:38:09,406 sometimes billion dollar valuations 1542 01:38:09,406 --> 01:38:11,586 they legitimately talk 1543 01:38:11,586 --> 01:38:18,246 about Bitcoin and Ethereum and like breaking that as a value proposition for quantum computers. 1544 01:38:18,566 --> 01:38:21,466 Like the funny thing is that I can't believe they say that out loud. 1545 01:38:21,986 --> 01:38:22,126 Yeah. 1546 01:38:22,166 --> 01:38:26,986 I mean, the funny thing is that we don't really have good use cases for quantum computers. 1547 01:38:27,206 --> 01:38:29,986 Except for breaking cryptography and destroying the world. 1548 01:38:29,986 --> 01:38:30,266 Yeah. 1549 01:38:31,186 --> 01:38:31,626 Yeah. 1550 01:38:32,006 --> 01:38:37,646 So, you know, it's not like we're not. 1551 01:38:37,646 --> 01:38:46,206 But I mean, like I would say I would have said, you know, 10 years ago, it's like, oh, you know, like, yeah, Bitcoin needs to worry about this maybe. 1552 01:38:46,546 --> 01:38:51,646 But like, so does the traditional financial banking system and so on. 1553 01:38:51,966 --> 01:38:55,366 But no, like the big target is now Bitcoin. 1554 01:38:55,626 --> 01:38:58,686 I don't really understand even though how they make money off of breaking Bitcoin. 1555 01:38:58,686 --> 01:39:05,986 I mean, like, I guess like there's like a short term play there, but I just cannot believe how much money they're raising off of just breaking cryptography. 1556 01:39:05,986 --> 01:39:25,526 Yeah, I mean, I'm not going to talk about the valuations, but it's, yeah, I mean, I think the idea is, you know, you would, like, okay, if you're fully malicious, right, and you have a quantum computer in your basement, you can just, you know, all the funds, all the coins that are lost, right? 1557 01:39:25,546 --> 01:39:29,846 Like, you would still first steal the coins that are lost and slowly peel them off into the market. 1558 01:39:29,846 --> 01:39:35,406 Slowly peel them off, sell them for dollars, like maybe, you know, short Bitcoin at the same time. 1559 01:39:35,406 --> 01:39:35,646 Yeah, right. 1560 01:39:35,646 --> 01:39:36,926 to protect your earnings. 1561 01:39:37,266 --> 01:39:40,546 And yeah, like... 1562 01:39:40,546 --> 01:39:40,946 That's it. 1563 01:39:41,206 --> 01:39:41,606 That's it. 1564 01:39:41,786 --> 01:39:42,586 And that's like... 1565 01:39:42,586 --> 01:39:42,906 That's the risk. 1566 01:39:42,906 --> 01:39:44,266 And you can be in North Korea, right? 1567 01:39:44,506 --> 01:39:44,646 Yeah. 1568 01:39:44,646 --> 01:39:46,246 Like if North Korea is a quantum computer, 1569 01:39:46,426 --> 01:39:48,646 that is 100% what they're going to do. 1570 01:39:49,086 --> 01:39:51,326 And it's like more or less untraceable, 1571 01:39:51,506 --> 01:39:52,866 you know, if you can sell them. 1572 01:39:54,446 --> 01:39:55,806 And if you can peel them off quietly, 1573 01:39:55,926 --> 01:39:57,886 like maybe they don't go after Satoshi's coins first. 1574 01:39:57,966 --> 01:39:59,746 Maybe they go after reused addresses first. 1575 01:39:59,766 --> 01:40:00,566 That's my guess. 1576 01:40:00,826 --> 01:40:03,126 Yeah, you would go after like lost coins 1577 01:40:03,126 --> 01:40:04,946 where people are not going to notice it. 1578 01:40:04,966 --> 01:40:05,126 Right. 1579 01:40:05,646 --> 01:40:11,866 plausible deniability plausible deniability right like you're gonna you know like uh and and 1580 01:40:11,866 --> 01:40:20,646 that's that's how you're going to do it and and uh bitcoin is absolutely the biggest and first 1581 01:40:20,646 --> 01:40:27,746 target and uh ethereum is probably the second target and uh so you know they need to work 1582 01:40:27,746 --> 01:40:35,326 together. And I think there's, you know, Ethereum is putting money and funds and research and 1583 01:40:35,326 --> 01:40:38,206 thinking time into this. And I think so should Bitcoin. 1584 01:40:38,566 --> 01:40:45,486 Fair enough. I had one other question that maybe I wanted to ask you as a final question. 1585 01:40:46,686 --> 01:40:53,346 Oh, I remember. Using zero knowledge proofs for seed phrases. Have you looked into that at all? 1586 01:40:53,346 --> 01:41:01,286 like for using for proving seed freezes for, you know, if we burn Satoshi's coins and then we want people to be able to retrieve those coins. 1587 01:41:01,846 --> 01:41:08,586 Did Lalu, I forgot. I think it was I think somebody put out a proposal for this for Bitcoin. 1588 01:41:08,866 --> 01:41:09,786 Yeah. What are your

thoughts on that? 1589 01:41:10,026 --> 01:41:13,266 I mean, I think that's that's very cool. 1590 01:41:13,406 --> 01:41:17,746 Like, I mean, I think that comes after having post-quantum signatures. 1591 01:41:18,006 --> 01:41:18,406 Yeah. Yeah. 1592 01:41:18,406 --> 01:41:22,006 Like, it's just like sort of a it's like way in the, you know, the Titanic is sinking. 1593 01:41:22,006 --> 01:41:24,426 like your sort of last lifeboat. 1594 01:41:25,066 --> 01:41:25,346 Right. 1595 01:41:26,446 --> 01:41:27,446 I mean... 1596 01:41:27,446 --> 01:41:29,266 But that would be a different kind of proof. 1597 01:41:29,426 --> 01:41:31,426 So if we were going to create a proof... 1598 01:41:31,426 --> 01:41:34,226 Yeah, but no, the technology translates over. 1599 01:41:34,506 --> 01:41:34,786 It does. 1600 01:41:34,886 --> 01:41:37,006 It totally translates over, and I think this is... 1601 01:41:37,786 --> 01:41:40,506 There's no technical problems or challenges associated with that. 1602 01:41:40,506 --> 01:41:43,126 Yeah, I mean, it would definitely need a soft fork. 1603 01:41:43,566 --> 01:41:43,746 Sure. 1604 01:41:43,766 --> 01:41:45,006 It would definitely need like... 1605 01:41:45,526 --> 01:41:47,146 You'd need a ZK verifier in Bitcoin. 1606 01:41:47,146 --> 01:41:51,006 Yeah, it's, you know, like sort of anything... 1607 01:41:52,006 --> 01:42:00,826 So like anything where, you know, I have like a hash somewhere in the chain, I can use that for security sort of. 1608 01:42:01,786 --> 01:42:03,006 Yeah, that I need that. 1609 01:42:04,066 --> 01:42:04,806 Exactly right. 1610 01:42:04,906 --> 01:42:05,846 It doesn't just need. 1611 01:42:06,266 --> 01:42:16,566 So what I was talking about, like it might need a soft fork, but like it's really just, you know, on the consensus side, on the minor side, this would be a transaction level thing. 1612 01:42:16,566 --> 01:42:17,706 You would need an opcode. 1613 01:42:17,866 --> 01:42:21,046 You would need an op-stark or whatever, like people op-snark. 1614 01:42:21,746 --> 01:42:21,926 Right. 1615 01:42:22,006 --> 01:42:24,646 You need a proper verifier in Bitcoin script. 1616 01:42:24,986 --> 01:42:27,226 You need a proper verifier in Bitcoin script. 1617 01:42:28,166 --> 01:42:28,966 Which I think is cool. 1618 01:42:29,146 --> 01:42:30,326 I would totally vote for that. 1619 01:42:30,586 --> 01:42:31,346 You would vote for that. 1620 01:42:31,706 --> 01:42:32,846 Yeah, you're like, of course. 1621 01:42:33,086 --> 01:42:34,626 People are terrified of this. 1622 01:42:34,806 --> 01:42:38,146 People are very scared of OP verifiers in script. 1623 01:42:38,326 --> 01:42:41,366 But again, you think that that's just old trauma from the past. 1624 01:42:42,106 --> 01:42:50,326 Yeah, I think, I mean, I'm like my philosophy in general and, you know, the beauty of Bitcoin is that no single person makes the decision. 1625 01:42:50,326 --> 01:42:54,166 and no single person, like, you know, 1626 01:42:54,886 --> 01:42:55,906 I can have my opinion 1627 01:42:55,906 --> 01:42:57,886 and people don't need to agree with me. 1628 01:42:58,466 --> 01:43:00,226 I'm probably more, you know, 1629 01:43:01,026 --> 01:43:02,726 like just by my job in nature, 1630 01:43:02,906 --> 01:43:05,086 more, you know, a bit more adventurous 1631 01:43:05,086 --> 01:43:06,046 and more forward thinking. 1632 01:43:06,246 --> 01:43:07,386 Like, of course, like we should have, 1633 01:43:07,386 --> 01:43:08,646 you know, these NARCs 1634 01:43:08,646 --> 01:43:10,346 and it would open great possibilities. 1635 01:43:10,346 --> 01:43:14,366 And like, I would love to see that. 1636 01:43:15,046 --> 01:43:17,426 And like, I would love for Bitcoin 1637 01:43:17,426 --> 01:43:19,966 to sort of move technologically forward. 1638 01:43:20,326 --> 01:43:26,706 I think it's too beautiful of a project and too beautiful of an idea to be technologically stale. 1639 01:43:27,426 --> 01:43:30,866 I understand the reasons for it, but yeah, that's kind of my opinion. 1640 01:43:31,266 --> 01:43:33,146 A great place for us to wind down. 1641 01:43:33,246 --> 01:43:34,246 Thank you so much for coming. 1642 01:43:34,386 --> 01:43:36,406 This was really fun and juicy, so thank you.