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

1
00:00:00,000 --> 00:00:04,100
The newest generation of zero-knowledge proofs just uses hash functions.
2
00:00:04,440 --> 00:00:05,880
It doesn't have a trusted setup.
3
00:00:06,200 --> 00:00:07,700
It's become much, much faster.
4
00:00:07,920 --> 00:00:09,620
We need to open our minds.
5
00:00:09,760 --> 00:00:13,840
We need to open our, you know, engineering, our, you know, sort of research.
6
00:00:14,200 --> 00:00:16,960
And the vehicle for it will be the post-quantum transition.
7
00:00:17,120 --> 00:00:19,580
Because there, it's not suddenly a nice-to-have.
8
00:00:19,820 --> 00:00:21,620
In my opinion, it's a necessity.
9
00:00:22,320 --> 00:00:26,540
Benedict, thank you so much for coming and chatting with me today.
10
00:00:26,540 --> 00:00:29,860
This will be sort of an interesting interview.
11
00:00:30,080 --> 00:00:33,300
We've been covering quantum a bunch on the show lately.
12
00:00:33,760 --> 00:00:43,320
And you just announced a new PQ effort with Dan Benet and local host recently, if I'm getting that correctly.
13
00:00:43,400 --> 00:00:43,800
Is that right?
14
00:00:44,160 --> 00:00:45,320
Yeah. Thanks for having me.
15
00:00:45,440 --> 00:00:46,620
Very excited to be here.
16
00:00:47,340 --> 00:00:47,520
Yeah.
17
00:00:47,680 --> 00:00:49,180
So I think so.
18
00:00:49,440 --> 00:00:52,360
I'm a professor at New York University.
19
00:00:53,160 --> 00:00:55,500
I work on cryptography.
20
00:00:55,500 --> 00:00:58,000
applied cryptography.
21
00:00:58,260 --> 00:00:59,840
So cryptography is
22
00:00:59,840 --> 00:01:01,500
like a very broad, so not
23
00:01:01,500 --> 00:01:03,660
crypto blockchain necessarily,
24
00:01:03,840 --> 00:01:05,280
but cryptography, the underlying
25
00:01:05,280 --> 00:01:07,920
technology, hash functions,
26
00:01:09,360 --> 00:01:09,860
zero knowledge
27
00:01:09,860 --> 00:01:11,560
proofs, snarks, that kind of thing,
28
00:01:12,000 --> 00:01:13,600
especially with applications
29
00:01:13,600 --> 00:01:14,420
to blockchains.
30
00:01:15,480 --> 00:01:17,640
And yeah, so we, you know,
31
00:01:17,660 --> 00:01:19,660
sort of, we're not the only
32
00:01:19,660 --> 00:01:21,680
ones to realize, but we sort of all
33
00:01:21,680 --> 00:01:23,400
you know, sort of see that
34
00:01:23,400 --> 00:01:29,140
quantum computers are coming, we'll get into that, and that blockchains need to do something
35
00:01:29,140 --> 00:01:33,860
about it and that there needs to be a transition happening. But that especially, there's obviously
36
00:01:33,860 --> 00:01:41,600
a lot of research going on about that. But I think there's not as much research. I think
37
00:01:41,600 --> 00:01:45,400
academics have sort of tuned out to Bitcoin a little bit.
38
00:01:47,520 --> 00:01:52,300
Academics in the cryptography area specifically. Why do you think that is?
39
00:01:52,300 --> 00:02:11,820
Oh, it's just harder to get things done. Like it's, you know, sort of much harder to, to like deploy a new protocol, get things done. There's a very specific culture that I think academics don't really get, right? Like Bitcoin has, I mean, that's what makes Bitcoin so special, but it is a very unique and special culture.
40
00:02:11,820 --> 00:02:14,520
and I think also in general
41
00:02:14,520 --> 00:02:16,300
academics like
42
00:02:16,300 --> 00:02:18,520
very clean
43
00:02:18,520 --> 00:02:20,400
isolated problems
44
00:02:20,400 --> 00:02:22,800
that they can think about
45
00:02:22,800 --> 00:02:26,700
and I think
46
00:02:26,700 --> 00:02:28,660
that Bitcoin is
47
00:02:28,660 --> 00:02:29,380
a bit more messy
48
00:02:29,380 --> 00:02:31,860
there's a lot of legacy
49
00:02:31,860 --> 00:02:32,720
a lot of
50
00:02:32,720 --> 00:02:35,740
some things that
51
00:02:35,740 --> 00:02:38,600
if you started anew you would do things very
52
00:02:38,600 --> 00:02:40,540
differently but some things
53
00:02:40,540 --> 00:02:44,500
are like, you know, very specifically the way that they are because they've always been that way.
54
00:02:45,040 --> 00:02:50,640
And it's sort of inherent to sort of this conservatism, like this technical conservatism
55
00:02:50,640 --> 00:02:55,920
is very inherent to Bitcoin, right? Like it's supposed to be as stable as it possibly can be.
56
00:02:56,100 --> 00:03:01,380
It's both a feature and at some times it can be a bug, right? And I think that's,
57
00:03:02,220 --> 00:03:06,060
you know, what makes Bitcoin unique. But I think it's also from my point of view,
58
00:03:06,060 --> 00:03:08,240
it makes it very interesting
59
00:03:08,240 --> 00:03:10,560
because it sort of means
60
00:03:10,560 --> 00:03:11,780
that you need to come up with
61
00:03:11,780 --> 00:03:14,040
new solutions that are specific
62
00:03:14,040 --> 00:03:16,180
to Bitcoin that
63
00:03:16,180 --> 00:03:18,220
specifically address and there's a lot of
64
00:03:18,220 --> 00:03:20,440
still like I said
65
00:03:20,440 --> 00:03:22,380
academics are working less in it
66
00:03:22,380 --> 00:03:24,300
but there's still a lot of smart people
67
00:03:24,300 --> 00:03:24,940
in Bitcoin
68
00:03:24,940 --> 00:03:28,220
and I think
69
00:03:28,220 --> 00:03:30,440
that this new initiative
70
00:03:30,440 --> 00:03:32,380
with local
71
00:03:32,380 --> 00:03:34,380
hosts and between NYU and Stanford
72
00:03:34,380 --> 00:03:40,900
kind of what we saw is like especially with respect to post-quantum we need some more you
73
00:03:40,900 --> 00:03:46,480
know innovation and and the first thing that we need is a bit more both research and then also
74
00:03:46,480 --> 00:03:52,740
kind of the the practical angle of trying to deploy it trying to implement code and that and
75
00:03:52,740 --> 00:03:57,880
so that's kind of why we formed this alliance and and you know are specifically raising funds
76
00:03:57,880 --> 00:04:04,620
trying to raise funds for it in order to move that forward and make progress on that.
77
00:04:05,100 --> 00:04:10,100
When you 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.