1
00:00:00,000 --> 00:00:09,920
You've had a dynamic where money has become freer than free.

2
00:00:10,780 --> 00:00:13,040
You talk about a Fed just gone nuts.

3
00:00:13,500 --> 00:00:15,700
All the central banks going nuts.

4
00:00:16,380 --> 00:00:17,880
So it's all acting like safe haven.

5
00:00:18,360 --> 00:00:23,500
I believe that in a world where central bankers are tripping over themselves to devalue their

6
00:00:23,500 --> 00:00:25,260
currency, Bitcoin wins.

7
00:00:25,360 --> 00:00:28,480
In the world of fiat currencies, Bitcoin is the victor.

8
00:00:28,480 --> 00:00:31,360
I mean, that's part of the bull case for Bitcoin.

9
00:00:31,800 --> 00:00:34,240
If you're not paying attention, you probably should be.

10
00:00:36,600 --> 00:00:38,520
Jonas McHale, welcome to the show.

11
00:00:38,640 --> 00:00:39,380
Thank you for joining me.

12
00:00:40,080 --> 00:00:41,060
Thank you for having us.

13
00:00:42,520 --> 00:00:44,000
Been a big week.

14
00:00:44,460 --> 00:00:45,500
You guys wrote a paper.

15
00:00:45,640 --> 00:00:49,500
There's a lot of discussion on it, on X and other platforms.

16
00:00:49,700 --> 00:00:54,280
The paper is hash-based signature schemes for Bitcoin.

17
00:00:54,280 --> 00:01:17,600
You guys are in this paper trying to tackle the question of, okay, if quantum computers do manifest and people need to protect their Bitcoin, what is the optimal sort of solution to that problem to make sure that Bitcoiners are storing their Bitcoin in addresses that can't be attacked by quantum computers, among other things.

18
00:01:17,600 --> 00:01:24,960
But first, I think we should start thinking of someone who doesn't have a cryptography background.

19
00:01:25,300 --> 00:01:35,160
Can you just explain what hash-based signatures are, why they might be important for Bitcoin's futures, and why hash-based signatures in the first place?

20
00:01:36,060 --> 00:01:42,220
I think I can start and then Mike can fill in the details that I'm missing.

21
00:01:43,840 --> 00:01:47,280
So where do we use signatures in Bitcoin?

22
00:01:47,280 --> 00:01:49,920
we use it to authorize transactions.

23
00:01:51,180 --> 00:01:54,360
And the current signatures that we use,

24
00:01:54,500 --> 00:02:00,360
they are based on the security of an elliptic curve

25
00:02:00,360 --> 00:02:02,860
that's called SECP256K1 in Bitcoin.

26
00:02:03,060 --> 00:02:05,160
It was chosen by Satoshi.

27
00:02:06,740 --> 00:02:09,560
There are alternative signature schemes

28
00:02:09,560 --> 00:02:12,040
that depend on different assumptions.

29
00:02:12,040 --> 00:02:21,580
and one of those alternatives are hash-based signature schemes and all of these alternatives

30
00:02:21,580 --> 00:02:29,460
they have different trade-offs we started looking at hash-based signature schemes because

31
00:02:29,460 --> 00:02:37,460
the assumptions that they use they are relatively conservative compared to other signature schemes

32
00:02:37,460 --> 00:02:39,140
and

33
00:02:39,140 --> 00:02:42,360
hash base signature schemes

34
00:02:42,360 --> 00:02:44,200
that just means that the signature

35
00:02:44,200 --> 00:02:46,280
scheme is the security

36
00:02:46,280 --> 00:02:47,980
of the signature scheme is based

37
00:02:47,980 --> 00:02:50,220
on the security of

38
00:02:50,220 --> 00:02:51,480
the hash function

39
00:02:51,480 --> 00:02:54,540
why is that attractive for Bitcoin specifically

40
00:02:54,540 --> 00:02:55,580
well we already

41
00:02:55,580 --> 00:02:58,560
are relying on the security

42
00:02:58,560 --> 00:03:00,220
of SHA-256

43
00:03:00,220 --> 00:03:02,080
for example this is how we

44
00:03:02,080 --> 00:03:04,100
refer to previous blocks

45
00:03:04,100 --> 00:03:05,760
in the blockchain this is how

46
00:03:05,760 --> 00:03:12,240
transactions get committed to a block in the Merkle tree. And from that perspective,

47
00:03:12,240 --> 00:03:16,800
we started looking at these hash-based signatures first.

48
00:03:19,280 --> 00:03:27,600
Essentially, it's also important to say for most of the other approaches that one can consider,

49
00:03:27,600 --> 00:03:35,280
whether there is one popular or lattice-based schemes that require some other assumptions.

50
00:03:35,760 --> 00:03:38,760
most of them still rely on hash functions.

51
00:03:38,760 --> 00:03:44,760
So this is essentially as minimal as you can get in terms of like security

52
00:03:44,760 --> 00:03:52,940
assumptions and requirements from a scheme is requiring just a hash function to be secure.

53
00:03:53,700 --> 00:03:58,760
This is a very conservative approach and I guess

54
00:03:58,760 --> 00:04:02,600
arguably the most secure

55
00:04:02,600 --> 00:04:06,220
way the possibilities is.

56
00:04:06,220 --> 00:04:10,020
It has the least amount of attack vectors in that regard.

57
00:04:11,120 --> 00:04:13,180
So, Janice, you referenced it.

58
00:04:13,260 --> 00:04:16,740
So, Bitcoin already relies on SHA-256 for mining and transaction IDs.

59
00:04:17,040 --> 00:04:19,420
So, this is just sort of a doubling down

60
00:04:19,420 --> 00:04:23,200
on what's already worked to date and what we know to be pretty secure.

61
00:04:23,200 --> 00:04:24,000
Right, right.

62
00:04:24,100 --> 00:04:27,500
So, hash-based means we can use any hash.

63
00:04:27,500 --> 00:04:33,040
there are also different hash functions we could choose also with different trade-offs

64
00:04:33,040 --> 00:04:39,080
with respect to performance or even proving in zero-knowledge snarks

65
00:04:39,080 --> 00:04:44,780
but the natural choice for the hash function would just be SHA-256

66
00:04:44,780 --> 00:04:50,240
because if SHA-256 is broken then arguably we have even bigger problems

67
00:04:50,240 --> 00:04:53,780
than just transaction authorization not working

68
00:04:53,780 --> 00:04:56,100
the blockchain doesn't really work anymore

69
00:04:56,100 --> 00:05:01,680
we don't know what the truth is we we don't have consensus on the blockchain anymore so

70
00:05:01,680 --> 00:05:08,160
yeah from that perspective makes sense to look at these hash-based signature schemes

71
00:05:08,160 --> 00:05:16,160
but they have a reputation for being quite large in terms of size so that is that is a consideration

72
00:05:16,160 --> 00:05:23,000
that that one needs to look into when when considering hash-based interests

73
00:05:23,000 --> 00:05:28,780
and before we get to that because i think that's exactly what your paper focused on like okay

74
00:05:28,780 --> 00:05:33,360
if we want to be quantum resistant we're going to use hash base how do we basically weigh the

75
00:05:33,360 --> 00:05:38,700
trade-offs and make sure that bitcoin is still usable and scalable at the end of the day but

76
00:05:38,700 --> 00:05:44,140
before we get to that even like we've all heard the term post-quantum thrown around what does

77
00:05:44,140 --> 00:05:49,440
that actually mean like what is the quantum we're supposed to be afraid of and supposed to be

78
00:05:49,440 --> 00:05:57,960
preparing for yeah so i think so from my perspective if we if we as cryptographers do

79
00:05:57,960 --> 00:06:05,280
security proofs so for example for schnor signatures or music or frost or signature

80
00:06:05,280 --> 00:06:13,680
aggregation dahlias etc we have these little theorems they are a paragraph or two contain some

81
00:06:13,680 --> 00:06:20,920
numbers and they very precisely state what the assumptions are under which these signatures are

82
00:06:20,920 --> 00:06:29,080
secure and in the case of schnor signatures it tells you directly when you read it or write it

83
00:06:29,080 --> 00:06:36,640
down it relies on the security of this curve that you're choosing sec p256k1 in the case of bitcoin

84
00:06:36,640 --> 00:06:48,020
and we know that this assumption that secp256k1 is not broken is actually wrong

85
00:06:48,020 --> 00:06:55,080
it is broken you just the challenge is just to build a machine that exploits quantum mechanics

86
00:06:55,080 --> 00:07:01,200
enough to break it but this is different from other types of cryptography we can also do

87
00:07:01,200 --> 00:07:06,000
cryptography where we don't have assumptions like that so just writing this down this statement

88
00:07:06,000 --> 00:07:16,740
personally makes makes me a little bit uneasy as well so a quantum computer would be able to break

89
00:07:16,740 --> 00:07:22,860
our curve and therefore would be able to break shore signatures now the challenge

90
00:07:22,860 --> 00:07:30,760
of post-quantum cryptography is to find cryptographic schemes that are secure

91
00:07:30,760 --> 00:07:34,320
even in the presence of quantum computers.

92
00:07:35,320 --> 00:07:46,280
And that requires also some sort of guesswork or some research as to what problems quantum computers are actually good at.

93
00:07:46,340 --> 00:07:50,000
We know that they are very good at breaking our elliptic curve.

94
00:07:50,780 --> 00:07:57,040
And it's very unlikely that they are good at breaking hashes, let's say.

95
00:07:57,040 --> 00:08:03,640
They are better than classical computer, but they won't be able to break it in a way that they can break elliptic curves.

96
00:08:05,200 --> 00:08:18,300
And essentially what I can add here is that we are even sure that the quantum computers cannot do certain tasks good enough to break the security of that.

97
00:08:18,300 --> 00:08:31,620
For example, if we have a database, a random database, and we ask quantum computer to search for a specific input in that database, we don't know where it is.

98
00:08:32,420 --> 00:08:38,940
We know that it is a hard problem for quantum computer and you cannot do better than certain complexity.

99
00:08:38,940 --> 00:08:46,380
And the hash function is essentially is this random database because we take an

100
00:08:46,380 --> 00:08:54,480
input, we hash it, we get a arguably random looking output. And our assumption

101
00:08:54,480 --> 00:08:59,840
here is that we will not find an algorithm that can exploit the actual

102
00:08:59,840 --> 00:09:05,580
description of the hash function. But one can view this very similar to how

103
00:09:05,580 --> 00:09:14,620
classical analysis of hash functions works because classically we also rely on that we cannot find

104
00:09:14,620 --> 00:09:20,620
an algorithm that can exploit the actual description of the hash function the actual algorithm that

105
00:09:20,620 --> 00:09:27,420
does the hashing and so far shadow 156 was not

106
00:09:27,420 --> 00:09:38,460
under good attacks there it proved its security and there was no significant improvement in terms

107
00:09:38,460 --> 00:09:46,540
of exploiting the structure so for any quantum advances there there must be a structure in the

108
00:09:46,540 --> 00:09:54,540
hash function that y can exploit and so far we couldn't find anything like that okay and so let's

109
00:09:54,540 --> 00:10:02,620
Let's dive back into the paper and run with the assumption that quantum computers could exploit that hash function at some point in the future.

110
00:10:02,880 --> 00:10:05,020
And talk about the tradeoffs in the paper.

111
00:10:05,320 --> 00:10:10,400
It seems like you guys settled on Sphinx Plus as a standardized solution because it already exists.

112
00:10:10,920 --> 00:10:13,380
It's already standardized by the NIST.

113
00:10:14,600 --> 00:10:16,080
Why do we need this research?

114
00:10:16,080 --> 00:10:21,280
What's the gap that you guys are trying to fill by applying this to Bitcoin specifically?

115
00:10:21,280 --> 00:10:31,420
yeah so nist has looked at which post-quantum signature schemes to standardize and they picked

116
00:10:31,420 --> 00:10:39,320
so they picked multiple one of them was sphinx plus that they standardized but

117
00:10:39,320 --> 00:10:46,860
so sphinx plus exists we could use it there exists in bitcoin i mean there exists high

118
00:10:46,860 --> 00:10:53,100
quality implementations with formal verification and proof etc so we could just use it

119
00:10:53,100 --> 00:11:00,020
but the kind of research question that we had when we started the the paper was

120
00:11:00,020 --> 00:11:10,320
the kind of goal of signatures usually outside of of bitcoin or blockchains is to sign software

121
00:11:10,320 --> 00:11:14,960
and to sign certificates for the web.

122
00:11:15,640 --> 00:11:17,240
And this is a very different application

123
00:11:17,240 --> 00:11:20,260
to what we're doing in Bitcoin with signatures.

124
00:11:21,760 --> 00:11:25,280
So what we were asking was,

125
00:11:25,880 --> 00:11:28,520
can we adapt this standardized scheme

126
00:11:28,520 --> 00:11:31,400
or also other schemes that exist in the literature

127
00:11:31,400 --> 00:11:33,660
that have not been standardized

128
00:11:33,660 --> 00:11:39,300
and see how, in what way we could change them

129
00:11:39,300 --> 00:11:43,080
to better fit to this Bitcoin application.

130
00:11:46,560 --> 00:11:48,920
And again, one of the trade-offs

131
00:11:48,920 --> 00:11:50,920
that we're trying to solve for here

132
00:11:50,920 --> 00:11:53,980
is the size of the signatures.

133
00:11:54,100 --> 00:11:54,880
In the paper you mentioned,

134
00:11:55,580 --> 00:11:57,460
going from about 7,800 bytes

135
00:11:57,460 --> 00:11:59,980
down to around 3,400 to 4,000 bytes

136
00:11:59,980 --> 00:12:01,300
with optimizations.

137
00:12:01,780 --> 00:12:04,560
I think for the listeners out there,

138
00:12:04,560 --> 00:12:05,620
getting them to understand,

139
00:12:05,760 --> 00:12:08,360
why does the size of these signatures matter?

140
00:12:08,360 --> 00:12:12,760
what's the trade-off that you're making yeah i think mike can speak best to that

141
00:12:12,760 --> 00:12:19,540
yeah so first of all the size determines how many signatures can fit in the block

142
00:12:19,540 --> 00:12:25,760
and then the bigger the signatures the fewer transactions you can you can fit and that

143
00:12:25,760 --> 00:12:33,820
so in the current block that is right we have these maximum four megabyte blocks and then if

144
00:12:33,820 --> 00:12:40,940
your signatures are suddenly huge then you can of course fit fewer transactions in the block unless

145
00:12:40,940 --> 00:12:49,500
you increase the block size as well. Which is another topic. It has its own ups and downs.

146
00:12:50,140 --> 00:12:57,900
But yeah if we consider that for now that the block stays the same, the size matters on the

147
00:12:57,900 --> 00:13:06,360
the band this is one thing another thing is that the sphinx plus was designed to support

148
00:13:06,360 --> 00:13:15,280
a lot of signing operations so the requirement for the nist was for the people to be able to

149
00:13:15,280 --> 00:13:32,645
sign two to the 64 different messages so that just to add to that that a number with 19 digits So it a huge number It practically infinite That was exactly the idea It like okay we set up this bar that will be never reached

150
00:13:33,065 --> 00:13:34,825
You don't have to worry about it.

151
00:13:35,265 --> 00:13:36,305
It's 2 to the 64.

152
00:13:37,105 --> 00:13:40,845
It's huge for all practical applications.

153
00:13:41,325 --> 00:13:43,025
You just don't need to think about it.

154
00:13:43,065 --> 00:13:43,785
There's no problem.

155
00:13:43,785 --> 00:13:53,345
and this requirement for hatch-based signatures actually determines a lot in terms of the size

156
00:13:53,345 --> 00:14:02,005
and the first observation that we can make is that if we set this par lower and we actually can

157
00:14:02,005 --> 00:14:12,045
have a limit on less number of signing operations we can significantly decrease the signature size

158
00:14:12,045 --> 00:14:15,025
moreover with the signature size

159
00:14:15,025 --> 00:14:17,505
the verification time can also

160
00:14:17,505 --> 00:14:18,285
be decreased

161
00:14:18,285 --> 00:14:19,885
and verification

162
00:14:19,885 --> 00:14:23,425
determines how fast

163
00:14:23,425 --> 00:14:25,045
can we validate the block

164
00:14:25,045 --> 00:14:27,405
how fast we then can propagate

165
00:14:27,405 --> 00:14:28,725
it and so on

166
00:14:28,725 --> 00:14:31,605
so this is one

167
00:14:31,605 --> 00:14:33,125
of the core observations here

168
00:14:33,125 --> 00:14:37,185
if we speak of another

169
00:14:37,185 --> 00:14:39,425
improvement is that Sphinx Plus

170
00:14:39,425 --> 00:14:41,325
there was a process

171
00:14:41,325 --> 00:14:48,465
of standardization and the ideas were coming and the certain improvements were made, but

172
00:14:48,465 --> 00:14:50,345
they had their own timeline.

173
00:14:50,345 --> 00:14:57,345
And so they had to decide at a certain point what we accept and what we standardize.

174
00:14:57,345 --> 00:15:02,125
But the research didn't stop there and there were different modifications and different

175
00:15:02,125 --> 00:15:04,925
improvements also suggested.

176
00:15:04,925 --> 00:15:14,105
And we can use those as well in the Bitcoin environment.

177
00:15:14,605 --> 00:15:17,605
When NIST sets these standards, do they ever change?

178
00:15:17,725 --> 00:15:20,865
Can you have updates to the specific standards on Sphinx Plus?

179
00:15:20,865 --> 00:15:30,005
Or if you're going to go use the other ideas that were suggested but not included in the standard.

180
00:15:30,005 --> 00:15:36,145
is obviously if you include those are you out of this standard and is that frowned upon or

181
00:15:36,145 --> 00:15:44,405
just considered experimental so if we deviate from the standard now then yeah we're we're

182
00:15:44,405 --> 00:15:52,445
using a different one uh theoretically uh modifications uh can be done to the standard

183
00:15:52,445 --> 00:15:58,185
and there can be an update there can be a different standard or just just a new version of that

184
00:15:58,185 --> 00:16:06,725
there are different also like modifications that we can do one can just use different parameters

185
00:16:06,725 --> 00:16:16,045
and for example this way it will be easy to reuse some other implementation but the some

186
00:16:16,045 --> 00:16:21,925
modifications that we discussed in the paper also affect some of the structure of the signature

187
00:16:21,925 --> 00:16:29,845
a scheme that will have to adjust the implementation as well so this there are various options that we

188
00:16:29,845 --> 00:16:38,485
can use that give us a certain performance boosts or sizes boosts or other trade-offs

189
00:16:39,125 --> 00:16:45,765
and they come also in the cost of like varying further from the standard or sticking more with it

190
00:16:45,765 --> 00:16:54,305
and so we already said about one trade-off which is the size of the signatures i think the other one

191
00:16:54,305 --> 00:17:02,105
one of the other ones that you discussed um in the papers if you if you have um like heavier

192
00:17:02,105 --> 00:17:09,805
signature sizes and bytes in terms of bytes um you could sort of limit the amount of signatures that

193
00:17:09,805 --> 00:17:12,085
any public key

194
00:17:12,085 --> 00:17:14,545
can be associated with any public key?

195
00:17:14,825 --> 00:17:15,545
What's the trick?

196
00:17:15,705 --> 00:17:18,885
I think this is a strange technical thing

197
00:17:18,885 --> 00:17:21,285
that one needs to get his head around.

198
00:17:21,765 --> 00:17:24,765
Right now, in our world of signatures,

199
00:17:24,945 --> 00:17:27,705
we don't care how many signatures we do.

200
00:17:27,705 --> 00:17:31,865
It's just a technicality of these hash-based signatures

201
00:17:31,865 --> 00:17:35,485
that when you design such a scheme,

202
00:17:35,605 --> 00:17:37,365
there is a limit of signatures

203
00:17:37,365 --> 00:17:40,125
you can make per public key.

204
00:17:40,925 --> 00:17:48,645
And to be clear, we were not the first to come up with reducing the number of supported signatures.

205
00:17:48,645 --> 00:17:53,665
This is a pretty obvious idea when you look at those schemes, how they are structured.

206
00:17:55,425 --> 00:18:01,845
But one of the insights that you might have when trying to apply this to Bitcoin is just that

207
00:18:01,845 --> 00:18:08,165
And in Bitcoin, specifically in Bitcoin, we don't need that many signatures, right?

208
00:18:09,005 --> 00:18:10,485
We create an address.

209
00:18:11,125 --> 00:18:13,105
Usually we only want to use it once.

210
00:18:13,225 --> 00:18:14,405
We don't want address reuse.

211
00:18:14,885 --> 00:18:17,745
And then we sign, produce a transaction.

212
00:18:17,985 --> 00:18:18,465
That's it.

213
00:18:19,325 --> 00:18:23,025
Then you might have to do RBF to bump fees.

214
00:18:23,225 --> 00:18:24,505
Then you have to sign again.

215
00:18:24,945 --> 00:18:26,065
How often does that happen?

216
00:18:26,065 --> 00:18:28,305
maybe it happens more often

217
00:18:28,305 --> 00:18:30,485
if there's a more competitive

218
00:18:30,485 --> 00:18:31,885
block space market

219
00:18:31,885 --> 00:18:34,105
it doesn't happen often right now

220
00:18:34,105 --> 00:18:35,405
and it certainly doesn't happen

221
00:18:35,405 --> 00:18:36,845
to the 64 times

222
00:18:36,845 --> 00:18:40,485
there are other things

223
00:18:40,485 --> 00:18:41,965
where you need to sign more often

224
00:18:41,965 --> 00:18:43,925
for example in layer 2s

225
00:18:43,925 --> 00:18:46,405
so lightning so that payment shows

226
00:18:46,405 --> 00:18:48,705
that's sort of a different discussion

227
00:18:48,705 --> 00:18:51,005
perhaps but you still won't sign

228
00:18:51,005 --> 00:18:51,965
that many times

229
00:18:51,965 --> 00:18:53,525
there's still going to be an upper bound

230
00:18:53,525 --> 00:18:55,245
that is below to the 64

231
00:18:55,245 --> 00:19:03,005
and using those ideas we can get down the signature size.

232
00:19:04,285 --> 00:19:11,965
As I said, this is quite a technical thing, very peculiar to these hash-based signatures.

233
00:19:12,685 --> 00:19:18,205
Lower number of supported signatures means you can get a smaller signature.

234
00:19:18,205 --> 00:19:23,645
And what happens if you sign more often? I think that's important to explain.

235
00:19:23,645 --> 00:19:36,225
So if you have a signature scheme, hash-based signature scheme that supports, let's say, a thousand signatures and you do more, then the security sort of degrades.

236
00:19:36,545 --> 00:19:48,065
So it will make it easier and easier for an attacker to actually forge a signature, which in Bitcoin would mean that they could be able to steal your coins, make a malicious transaction to steal your coins.

237
00:19:48,065 --> 00:19:53,525
So you should really, if you have that limit of supported signatures, you should not exceed it.

238
00:19:53,645 --> 00:19:55,025
You must not exceed it.

239
00:19:55,025 --> 00:19:58,705
So, Freaks, this rip of TFTC was brought to you by our good friends at BitKey.

240
00:19:59,005 --> 00:20:02,025
BitKey makes Bitcoin easy to use and hard to lose.

241
00:20:02,345 --> 00:20:06,425
It is a hardware wallet that natively embeds into a two or three multi-sig.

242
00:20:06,525 --> 00:20:11,905
You have one key on the hardware wallet, one key on your mobile device, and Block stores

243
00:20:11,905 --> 00:20:13,305
a key in the cloud for you.

244
00:20:13,605 --> 00:20:18,005
This is an incredible hardware device for your friends and family, or maybe yourself,

245
00:20:18,265 --> 00:20:23,205
who have Bitcoin on exchanges and have for a long time, but haven't taken a step to self-custody

246
00:20:23,205 --> 00:20:24,945
because they're worried about the complications

247
00:20:24,945 --> 00:20:27,025
of setting up a private public key pair,

248
00:20:27,145 --> 00:20:28,505
securing that seed phrase,

249
00:20:28,725 --> 00:20:30,205
setting up a pin, setting up a passphrase.

250
00:20:30,325 --> 00:20:33,045
Again, BitKey makes it easy to use, hard to lose.

251
00:20:33,245 --> 00:20:35,045
It's the easiest zero to one step,

252
00:20:35,225 --> 00:20:37,005
your first step to self-custody.

253
00:20:37,145 --> 00:20:38,805
If you have friends and family on the exchanges

254
00:20:38,805 --> 00:20:39,765
who haven't moved it off,

255
00:20:39,885 --> 00:20:40,785
tell them to pick up a BitKey.

256
00:20:40,785 --> 00:20:44,045
Go to BitKey.world, use the key TFTC20

257
00:20:44,045 --> 00:20:46,405
at checkout for 20% off your order.

258
00:20:46,885 --> 00:20:49,545
That's BitKey.world, code TFTC20.

259
00:20:49,945 --> 00:20:50,385
What's up, Freaks?

260
00:20:50,725 --> 00:20:51,925
Have you noticed that governments

261
00:20:51,925 --> 00:20:54,165
have become more despotic.

262
00:20:54,365 --> 00:20:55,325
They want to surveil more.

263
00:20:55,385 --> 00:20:56,345
They want to take more of your data.

264
00:20:56,685 --> 00:20:57,825
They want to follow you around the internet

265
00:20:57,825 --> 00:20:58,805
as much as possible

266
00:20:58,805 --> 00:20:59,905
so that they can control your speech,

267
00:20:59,985 --> 00:21:00,645
control what you do.

268
00:21:00,845 --> 00:21:02,965
It's imperative in times like this

269
00:21:02,965 --> 00:21:04,045
to make sure that you're running a VPN

270
00:21:04,045 --> 00:21:05,865
as you're surfing the web,

271
00:21:06,425 --> 00:21:07,745
as we used to say back in the 90s.

272
00:21:08,245 --> 00:21:09,685
And it's more imperative

273
00:21:09,685 --> 00:21:10,625
that you use the right VPN,

274
00:21:10,985 --> 00:21:12,245
a VPN that cannot log

275
00:21:12,245 --> 00:21:14,425
because of the way that it's designed.

276
00:21:14,585 --> 00:21:16,365
And that's why we have partnered with Obscura.

277
00:21:16,485 --> 00:21:19,485
That is our official VPN here at TFTC

278
00:21:19,485 --> 00:21:21,405
built by a Bitcoiner, Carl Dung,

279
00:21:21,405 --> 00:21:23,345
for Bitcoiners focused on privacy.

280
00:21:23,705 --> 00:21:25,345
You can pay in Bitcoin over the Lightning.

281
00:21:25,625 --> 00:21:26,585
So not only are you private

282
00:21:26,585 --> 00:21:30,285
while you're perusing the web with Obscura,

283
00:21:30,425 --> 00:21:31,565
but when you actually set up an account,

284
00:21:31,705 --> 00:21:33,425
you can acquire that account privately

285
00:21:33,425 --> 00:21:35,985
by paying in Bitcoin over the Lightning network.

286
00:21:35,985 --> 00:21:37,565
Do not be complacent

287
00:21:37,565 --> 00:21:39,965
when it comes to protecting your privacy on the internet.

288
00:21:40,105 --> 00:21:41,205
Go to Obscura.net,

289
00:21:42,045 --> 00:21:44,365
set up an Obscura account,

290
00:21:44,765 --> 00:21:47,605
use the code TFTC for 25% off.

291
00:21:48,605 --> 00:21:50,005
When I say account, you just get a token.

292
00:21:50,225 --> 00:21:50,845
It's a string of token.

293
00:21:50,845 --> 00:21:53,385
It's not connected to your identity at all.

294
00:21:54,405 --> 00:21:56,545
Token sign up, pay with Bitcoin, completely private.

295
00:21:57,145 --> 00:21:59,085
Turn on Obscura, surf the web privately.

296
00:21:59,585 --> 00:22:02,345
Obscura.net, use the code TFTC for 25% off.

297
00:22:02,825 --> 00:22:04,425
Yeah, it's funny.

298
00:22:05,225 --> 00:22:11,705
Again, I say this a lot, especially when I talk to developers and cryptographers like yourself.

299
00:22:11,705 --> 00:22:15,425
is like so many people take for granted that the system just works

300
00:22:15,425 --> 00:22:20,885
and not understanding these deep cryptographic primitives that exist.

301
00:22:20,985 --> 00:22:25,285
But it is always infinitely fascinating diving into these details

302
00:22:25,285 --> 00:22:27,505
because I think it's important, even if you're not technical,

303
00:22:27,725 --> 00:22:32,065
to have a rough understanding of what's happening under the hood.

304
00:22:33,725 --> 00:22:36,725
But obviously we talked about Sphinx Plus, some of the optimizations there.

305
00:22:36,725 --> 00:22:40,465
We also talked about Watts plus C, Fours plus C, Pours plus FP,

306
00:22:40,465 --> 00:22:44,245
with potential optimizations, I guess,

307
00:22:44,305 --> 00:22:45,805
without getting too far into the weeds?

308
00:22:46,025 --> 00:22:49,045
What are the ideas with these optimizations?

309
00:22:51,285 --> 00:22:55,745
I think I can do some already here.

310
00:22:55,745 --> 00:23:03,745
So the core idea here is we can make the signer

311
00:23:03,745 --> 00:23:07,365
to work a little bit more on finding

312
00:23:10,165 --> 00:23:16,365
certain inputs. So except we don't only include the message, but some extra seed or

313
00:23:17,165 --> 00:23:18,725
an extra

314
00:23:18,725 --> 00:23:20,725
random number or a counter

315
00:23:21,145 --> 00:23:23,145
and that allows us to

316
00:23:23,845 --> 00:23:27,465
search for better values that we can then sign and

317
00:23:29,125 --> 00:23:31,425
this requires some extra work from the signer

318
00:23:31,425 --> 00:23:38,445
but because we have these extra properties from what we are signing, this

319
00:23:38,445 --> 00:23:46,425
can reduce the signature size and this also helps the verifier. So by doing extra

320
00:23:46,425 --> 00:23:53,025
work on the signer part, we reduce the size and we reduce the verification

321
00:23:53,025 --> 00:24:01,005
time. Sometimes this extra work also comes in the cost kind of, yes, we search

322
00:24:01,005 --> 00:24:08,685
for this nice value to sign afterwards. But because this value is nice, this also

323
00:24:08,685 --> 00:24:15,945
eases the further work for the sign. So we had these different parameters choices

324
00:24:15,945 --> 00:24:22,365
in the paper. And for most of them, we make the signing time a little bit more

325
00:24:22,365 --> 00:24:28,965
than the original Sphinx Plus, because we want more effort from the signer, but

326
00:24:28,965 --> 00:24:30,585
but really smaller signatures.

327
00:24:31,405 --> 00:24:34,025
And on the other hand, we can still balance this out

328
00:24:34,025 --> 00:24:37,005
while keeping the signature size small.

329
00:24:38,585 --> 00:24:40,805
And so this would affect wallet software, right?

330
00:24:40,865 --> 00:24:41,705
Because I'm thinking of,

331
00:24:42,465 --> 00:24:45,405
I played around with some DLC apps, Atomic, Finance,

332
00:24:45,485 --> 00:24:48,625
and when you go and you're doing like a rollover transaction

333
00:24:48,625 --> 00:24:50,705
with DLCs that take a lot of signatures,

334
00:24:50,705 --> 00:24:52,605
it sometimes takes like a minute or two

335
00:24:52,605 --> 00:24:55,505
to actually sign and then broadcast the transaction.

336
00:24:55,505 --> 00:25:01,325
So this wouldn't necessarily affect the nodes, right?

337
00:25:01,425 --> 00:25:03,825
And bandwidth propagation and things like that.

338
00:25:03,845 --> 00:25:07,905
It's just literally on the setup to sign and then broadcast, correct?

339
00:25:08,525 --> 00:25:10,305
Yes, I think so, yes.

340
00:25:10,325 --> 00:25:14,845
I think this is a very interesting point that you're making right now

341
00:25:14,845 --> 00:25:16,345
that I hadn't really considered before.

342
00:25:17,165 --> 00:25:24,365
So I think this kind of trade-off between increasing the signing time

343
00:25:24,365 --> 00:25:28,185
while reducing signature size and verification time

344
00:25:28,185 --> 00:25:29,485
makes a lot of sense in Bitcoin

345
00:25:29,485 --> 00:25:32,505
because at least on the Bitcoin blockchain,

346
00:25:32,765 --> 00:25:35,225
we have a natural limit of the number of transactions

347
00:25:35,225 --> 00:25:37,625
that are supported per second, right?

348
00:25:37,985 --> 00:25:40,505
We can at most like whatever,

349
00:25:40,645 --> 00:25:41,885
10 transactions per second

350
00:25:41,885 --> 00:25:44,665
and few more signatures than that, whatever,

351
00:25:44,665 --> 00:25:47,605
but it's not thousands of signatures per second

352
00:25:47,605 --> 00:25:48,525
that you need to make.

353
00:25:49,325 --> 00:25:52,385
On the other hand, we also have hardware wallets

354
00:25:52,385 --> 00:25:56,685
that are, of course, lower powered and that might take longer.

355
00:25:57,845 --> 00:26:00,405
And I think what you're pointing out is an interesting thing.

356
00:26:00,465 --> 00:26:06,245
You might have a situation where you are pre-signing a lot of transactions.

357
00:26:06,245 --> 00:26:10,845
And this is what is happening naturally in DLCs right now.

358
00:26:11,585 --> 00:26:16,005
And this would be affected by a change like this,

359
00:26:16,565 --> 00:26:19,465
by a change to hash-based signatures,

360
00:26:19,465 --> 00:26:24,405
because producing these signatures, depending on which parameters you pick,

361
00:26:24,845 --> 00:26:27,405
which is, I think, the biggest part of our work,

362
00:26:27,445 --> 00:26:29,905
trying to figure out what are reasonable parameters,

363
00:26:30,425 --> 00:26:35,105
it might take much longer to sign them than it takes currently.

364
00:26:37,565 --> 00:26:39,525
Yeah, and that's the trade-off you have to weigh.

365
00:26:39,625 --> 00:26:42,125
Are you willing to wait more to broadcast a transaction?

366
00:26:42,485 --> 00:26:42,665
Right.

367
00:26:42,665 --> 00:26:57,930
More generally perhaps important to say that in this post world we always have to deal with downsides This is also something that I feel like people on Twitter sometimes misunderstand

368
00:26:58,210 --> 00:27:02,010
because they are asking, why haven't you done anything right now already?

369
00:27:03,230 --> 00:27:11,010
Perhaps we would have changed to more conservative assumptions in terms of signatures,

370
00:27:11,010 --> 00:27:14,790
if it was for free, but that's not the case.

371
00:27:14,790 --> 00:27:20,370
whenever we want to add post-quantum security to Bitcoin,

372
00:27:20,850 --> 00:27:23,630
we get very significant downsides,

373
00:27:23,750 --> 00:27:27,490
be it new assumptions, signature sizes,

374
00:27:27,770 --> 00:27:30,310
verification time, signing time, statefulness.

375
00:27:31,450 --> 00:27:33,850
So there's no, we can't just,

376
00:27:34,850 --> 00:27:37,150
there's a big risk, I think,

377
00:27:37,690 --> 00:27:41,170
to just try to switch something

378
00:27:41,170 --> 00:27:44,150
which we later figure out wasn't the right choice

379
00:27:44,150 --> 00:27:45,930
because it picks the wrong trade-offs.

380
00:27:46,430 --> 00:27:48,270
So what we are doing mainly in this paper

381
00:27:48,270 --> 00:27:50,430
is to explore the trade-off space,

382
00:27:50,510 --> 00:27:53,250
particularly with respect to hash-based signatures,

383
00:27:53,510 --> 00:27:55,590
to inform the community

384
00:27:55,590 --> 00:27:59,310
as to what are reasonable parameters to pick.

385
00:28:00,730 --> 00:28:02,370
Yeah, that makes a lot of sense.

386
00:28:02,630 --> 00:28:04,270
I mean, you mentioned statefulness.

387
00:28:04,890 --> 00:28:06,410
You guys touched on it on the paper.

388
00:28:07,070 --> 00:28:10,110
Stateful versus stateless signature schemes.

389
00:28:10,590 --> 00:28:12,910
Why is being stateless so important to Bitcoin specifically?

390
00:28:14,150 --> 00:28:20,390
So, yes, stateless versus statelessness is a good topic as well.

391
00:28:20,390 --> 00:28:25,350
Here, what does stateless versus stateful mean?

392
00:28:25,350 --> 00:28:29,230
Is that, again, now we don't have to think about it.

393
00:28:29,230 --> 00:28:32,550
ECDSA is essentially stateless.

394
00:28:32,550 --> 00:28:39,270
And what does mean is that when you sign, you don't have to touch your secret key in

395
00:28:39,270 --> 00:28:42,110
terms of changes and updated.

396
00:28:42,110 --> 00:28:47,230
stays the same and you can kind of in more or less implementations you can separate it you can

397
00:28:47,230 --> 00:28:54,750
backup it as it is there is no problem everything again stays the same when we say stateful a stateful

398
00:28:54,750 --> 00:29:03,230
hash based scheme means every signing operation must update the secret key and if there is a

399
00:29:03,230 --> 00:29:10,590
misuse of this secret key or the update didn't go through or you lost some key and you run a

400
00:29:10,590 --> 00:29:17,150
backup that has an older state of the key that will compromise the security of the scheme

401
00:29:19,150 --> 00:29:25,630
but it comes from the other side with benefits of having again better performance and better sizes

402
00:29:26,270 --> 00:29:32,510
with a stateful scheme if you if you if you're happy with this secret key manipulations you can

403
00:29:32,510 --> 00:29:39,550
have better performance but it's important to mention yes this this can be very quick for example

404
00:29:39,550 --> 00:29:45,950
if you have just two separate devices and you want to run them with the same key pair if they

405
00:29:45,950 --> 00:29:52,990
don't communicate with each other maybe you can separate the states but that will limit the the

406
00:29:52,990 --> 00:30:00,430
number of signatures that they can provide but there is much involved there in that regard with

407
00:30:00,430 --> 00:30:07,310
managing your your key pair yeah so the state management thing i think is another very

408
00:30:07,310 --> 00:30:14,210
technical thing but that is kind of important when trying to pick these schemes i think state

409
00:30:14,210 --> 00:30:20,530
fullness is pretty fragile and it's one of those things that won't work for every signer

410
00:30:20,530 --> 00:30:30,030
so another example is so you run bitcoin core on your node let's say you produce a backup you

411
00:30:30,030 --> 00:30:39,750
backup your wallet.dat you make a few transactions perhaps and your machine crashes whatever it break

412
00:30:39,750 --> 00:30:44,890
your machine breaks you need to restore the backup that you've created including the wallet.dat

413
00:30:44,890 --> 00:30:51,370
and if you do that and the state would be stored in the wallet.dat which of course no one would do

414
00:30:51,370 --> 00:30:59,210
but if you did that then essentially you would allow an attacker to produce forgeries steal

415
00:30:59,210 --> 00:31:02,970
steal your Bitcoin. So that is why it's very fragile and it won't work for everyone.

416
00:31:03,330 --> 00:31:06,610
So for example, it probably won't easily work for share care.

417
00:31:07,930 --> 00:31:14,890
Okay. I guess another thing that this affects too, though, is like HD wallets, hierarchical,

418
00:31:15,110 --> 00:31:20,550
deterministic wallets. And you mentioned the backup system that we rely on. Again,

419
00:31:20,570 --> 00:31:25,830
they don't work the same way with hash-based signatures either. So what do we do with HD?

420
00:31:25,830 --> 00:31:34,170
yeah i think this is one of the the other uh sort of downsides of hash based signatures is that

421
00:31:34,170 --> 00:31:41,490
they don't have this nice mathematical structure that we currently enjoy on our elliptic curve

422
00:31:41,490 --> 00:31:48,510
which means that we cannot use any of the tricks that we've developed over the past

423
00:31:48,510 --> 00:31:50,870
years in Bitcoin.

424
00:31:51,130 --> 00:31:53,010
And that includes HD wallets.

425
00:31:53,690 --> 00:31:54,450
It includes

426
00:31:54,450 --> 00:31:56,930
multi-signatures, threshold

427
00:31:56,930 --> 00:31:58,790
signatures, silent payments,

428
00:31:59,090 --> 00:32:00,290
aggregate signatures,

429
00:32:01,830 --> 00:32:02,270
and

430
00:32:02,270 --> 00:32:03,810
taproot, I guess,

431
00:32:04,090 --> 00:32:05,330
taproot commitments.

432
00:32:06,730 --> 00:32:08,890
So that was one of

433
00:32:08,890 --> 00:32:10,670
the other research questions

434
00:32:10,670 --> 00:32:12,390
that we also had when we started

435
00:32:12,390 --> 00:32:14,730
this entire project is

436
00:32:14,730 --> 00:32:21,750
is there anything we can do with hash-based signatures in the past it was sort of

437
00:32:21,750 --> 00:32:29,890
it was intuitive that it wouldn't work but i thought maybe we could do something here or there

438
00:32:29,890 --> 00:32:39,510
and improve improve on at least the trivia of things i think the answer is mostly we can't

439
00:32:39,510 --> 00:32:49,330
really do anything fancy there we described some methods in in the paper that would reduce the size

440
00:32:49,330 --> 00:32:55,690
of multi-signatures by a little bit but it makes the signing protocol very complicated and there

441
00:32:55,690 --> 00:32:59,370
are other techniques like that that you could use especially for multi and threshold signatures

442
00:32:59,370 --> 00:33:05,730
it's not maybe there are some scenarios where you could use them but right now it doesn't seem

443
00:33:05,730 --> 00:33:14,570
it doesn't seem to make a lot of sense to base the entire standardization effort

444
00:33:14,570 --> 00:33:19,690
and picking specific schemes just to make it work a little bit better

445
00:33:19,690 --> 00:33:25,090
with these multi-signature schemes because they don't really work that well.

446
00:33:25,770 --> 00:33:27,090
Yeah, they don't give much there.

447
00:33:28,550 --> 00:33:32,610
And for HD wallets, there we have...

448
00:33:32,610 --> 00:33:35,350
So HD is multiple things.

449
00:33:35,750 --> 00:33:41,470
One is private derivation and public derivation.

450
00:33:42,290 --> 00:33:44,870
So what you can have still with hash-based signatures,

451
00:33:44,870 --> 00:33:46,670
that works very straightforwardly.

452
00:33:47,050 --> 00:33:52,310
You have a seed that you can generate many addresses from it.

453
00:33:52,910 --> 00:33:53,870
Perfectly fine.

454
00:33:54,390 --> 00:33:55,230
Works well.

455
00:33:55,850 --> 00:33:58,550
What you can't have is this kind of XPub

456
00:33:58,550 --> 00:34:00,870
where some other person would,

457
00:34:00,870 --> 00:34:05,750
or some other entity would derive new public keys

458
00:34:05,750 --> 00:34:07,390
from some given XPub.

459
00:34:08,050 --> 00:34:10,130
That does not work.

460
00:34:10,530 --> 00:34:12,890
And this XPub system,

461
00:34:13,250 --> 00:34:15,890
the XPub setup is particularly important today

462
00:34:15,890 --> 00:34:18,650
in hardware, software wallet setups.

463
00:34:18,650 --> 00:34:19,990
If you have your hardware wallet,

464
00:34:20,350 --> 00:34:23,450
export your XPub from the hardware wallet

465
00:34:23,450 --> 00:34:24,370
to the software wallet.

466
00:34:24,450 --> 00:34:28,510
Software wallet is then able to derive new addresses

467
00:34:28,510 --> 00:34:31,950
and scan the chain in that way.

468
00:34:32,510 --> 00:34:34,430
And that wouldn't be possible anymore

469
00:34:34,430 --> 00:34:35,810
with hash-based signatures.

470
00:34:36,230 --> 00:34:37,590
What you need to do instead,

471
00:34:38,030 --> 00:34:39,850
so the only thing we know of

472
00:34:39,850 --> 00:34:44,950
is you have your XPub is not a short public key,

473
00:34:44,950 --> 00:34:49,490
but rather a long list of public keys

474
00:34:49,490 --> 00:34:51,870
that you give to the software wallet.

475
00:34:52,350 --> 00:34:54,230
And once this list is exceeded,

476
00:34:54,890 --> 00:34:57,390
the software wallet needs to talk to the hardware wallet

477
00:34:57,390 --> 00:35:01,150
and ask for more public keys again.

478
00:35:01,290 --> 00:35:03,630
So it's not impossible,

479
00:35:03,630 --> 00:35:06,610
but it doesn't work as well with the infrastructure

480
00:35:06,610 --> 00:35:10,810
that we've created with descriptors in the past.

481
00:35:11,170 --> 00:35:15,750
And there is also this kind of worry

482
00:35:15,750 --> 00:35:18,550
that because it's a little bit harder to make this work,

483
00:35:18,550 --> 00:35:21,870
that people would or wallet developers

484
00:35:21,870 --> 00:35:26,190
might decide to just reuse addresses, for example,

485
00:35:26,190 --> 00:35:29,650
instead of building this system.

486
00:35:32,030 --> 00:35:33,590
That would bork a lot of things there.

487
00:35:34,670 --> 00:35:34,850
Yep.

488
00:35:35,530 --> 00:35:35,730
Yeah.

489
00:35:36,490 --> 00:35:39,510
So if you're a listener,

490
00:35:40,070 --> 00:35:43,070
I think one of the examples that Jonas just walked through,

491
00:35:43,210 --> 00:35:44,510
like say you have a cold card

492
00:35:44,510 --> 00:35:47,910
and you want to set up the private public e-pair offline

493
00:35:47,910 --> 00:35:49,230
using the wallet,

494
00:35:49,470 --> 00:35:51,390
and then you want to put it in a safe or something,

495
00:35:51,390 --> 00:35:53,950
but you want to be able to receive Bitcoin to it.

496
00:35:53,990 --> 00:35:56,010
So you download Sparrow, you export.

497
00:35:56,190 --> 00:36:00,190
the xpub to sparrow and then from there you can get these addresses this would be made

498
00:36:00,190 --> 00:36:06,250
harder you'd have to do it a different way with these hash based then similarly with multi-sig

499
00:36:06,250 --> 00:36:13,510
you share xpubs with your quorum partners to make the multi-sig xpub and that would be made

500
00:36:13,510 --> 00:36:21,030
impossible to hash based signatures right right this is another another kind of scenario that

501
00:36:21,030 --> 00:36:23,290
sort of wouldn't work as well anymore.

502
00:36:24,970 --> 00:36:26,490
That seems like a pretty big change.

503
00:36:26,650 --> 00:36:28,590
Maybe something we should talk through.

504
00:36:28,930 --> 00:36:29,310
At first.

505
00:36:31,770 --> 00:36:32,970
Well, it might be.

506
00:36:33,110 --> 00:36:35,010
I mean, there are other...

507
00:36:35,010 --> 00:36:37,130
We said it's not only hash base signatures.

508
00:36:37,350 --> 00:36:40,050
There are other assumptions we can pay.

509
00:36:40,050 --> 00:36:44,350
They might support these kind of scenarios better,

510
00:36:44,910 --> 00:36:46,310
but they have other downsides.

511
00:36:46,830 --> 00:36:47,190
What's up, Freaks?

512
00:36:47,530 --> 00:36:50,970
Have you noticed that governments have become more despotic?

513
00:36:51,330 --> 00:36:52,130
They want to surveil more.

514
00:36:52,210 --> 00:36:53,130
They want to take more of your data.

515
00:36:53,490 --> 00:36:56,530
They want to follow you around the internet as much as possible so they can control your

516
00:36:56,530 --> 00:36:57,450
speech, control what you do.

517
00:36:57,670 --> 00:37:02,090
It's imperative in times like this to make sure that you're running a VPN as you're surfing

518
00:37:02,090 --> 00:37:04,550
the web, as we used to say back in the 90s.

519
00:37:05,050 --> 00:37:10,170
And it's more imperative that you use the right VPN, a VPN that cannot log because of

520
00:37:10,170 --> 00:37:11,250
the way that it's designed.

521
00:37:11,390 --> 00:37:13,190
And that's why we have partnered with Obscura.

522
00:37:13,190 --> 00:37:19,310
That is our official VPN here at TFTC, built by a Bitcoiner, Carl Dung, for Bitcoiners

523
00:37:19,310 --> 00:37:20,150
focused on privacy.

524
00:37:20,150 --> 00:37:24,270
You can pay in Bitcoin over the Lightning. So not only are you private while you're perusing

525
00:37:24,270 --> 00:37:29,830
the web with Obscura, but when you actually set up an account, you can acquire that account

526
00:37:29,830 --> 00:37:35,150
privately by paying in Bitcoin over the Lightning network. Do not be complacent when it comes to

527
00:37:35,150 --> 00:37:41,170
protecting your privacy on the internet. Go to Obscura.net, set up an Obscura account,

528
00:37:41,570 --> 00:37:47,330
use the code TFTC for 25% off. When I say account, you just get a token. It's a string

529
00:37:47,330 --> 00:37:52,970
a token. It's not connected to your identity at all. Token sign up, pay with Bitcoin, completely

530
00:37:52,970 --> 00:37:59,170
private. Turn on Obscura, surf the web privately. Obscura.net, use the code TFTC for 25% off.

531
00:37:59,530 --> 00:38:03,590
What's up, freaks? I've been seeing a lot of YouTube comments. Marty, your skin looks so good.

532
00:38:03,830 --> 00:38:08,750
You're looking fit these days. How are you doing it? Well, number one, I'm going to the gym more,

533
00:38:09,530 --> 00:38:15,010
trying to get my swell on, trying to be a good example for my young son to fit,

534
00:38:15,010 --> 00:38:19,550
healthy dad, but part of that is having a good regimen, particularly staying hydrated,

535
00:38:19,710 --> 00:38:24,890
making sure I have the right electrolytes and salts in my body. That is why I use salt of the

536
00:38:24,890 --> 00:38:31,230
earth. I drink probably three of these a day with one packet of salt of the earth. I'm liking the

537
00:38:31,230 --> 00:38:36,630
pink lemonade right now. It's my flavor of choice. This is their creatine. I've added this to my

538
00:38:36,630 --> 00:38:41,650
regimen. They have it in these packets as well. It makes it extremely convenient if you're traveling.

539
00:38:41,650 --> 00:38:46,870
You want to work out while you're traveling, but you don't want to be carrying a white bag of powder going through TSA.

540
00:38:47,190 --> 00:38:50,030
It's very, very nerve wracking at times.

541
00:38:50,110 --> 00:38:50,890
You have to explain hates.

542
00:38:51,070 --> 00:38:52,250
It's not what you think it is.

543
00:38:52,290 --> 00:38:52,810
It's creatine.

544
00:38:52,890 --> 00:38:53,930
I'm trying to get my swell on.

545
00:38:55,290 --> 00:38:56,430
Make sure you're staying hydrated.

546
00:38:57,170 --> 00:38:59,190
I have become addicted to these.

547
00:38:59,290 --> 00:39:02,290
It's made my life a lot better.

548
00:39:02,690 --> 00:39:06,710
I can supplement this for coffee in the morning and be energized right away.

549
00:39:07,150 --> 00:39:07,990
I can supplement.

550
00:39:08,510 --> 00:39:10,670
I can bring the creatine wherever I need to.

551
00:39:10,670 --> 00:39:19,330
I just put a couple packets in here before I head to the gym, bring this to the gym, drink it out of a glass bottle, make sure I'm not injecting any microplastics into my body.

552
00:39:19,330 --> 00:39:25,430
Go to drinksauté.com, use the code TFTC, and you'll get 15% off anything in the store.

553
00:39:25,630 --> 00:39:27,850
That's drinksauté.com, code TFTC.

554
00:39:28,370 --> 00:39:29,610
Well, that was going to be my next question.

555
00:39:29,810 --> 00:39:34,410
Obviously, this research paper was focused on hash-based signature schemes.

556
00:39:35,110 --> 00:39:40,250
Do you guys plan on doing more research on different signature schemes moving forward?

557
00:39:40,670 --> 00:39:45,950
Yes, so our current plan is also to look at lattice-based schemes.

558
00:39:45,950 --> 00:39:53,170
As exactly Jonas mentioned, although the lattice-based, they introduce extra assumptions,

559
00:39:54,170 --> 00:40:02,070
this is called lattice-based, so they're based on lattices and the structure and with certain heart problems.

560
00:40:02,070 --> 00:40:23,135
but they can potentially offer these upsets in terms of hardware wallets public key derivation multi signatures and stuff like this so for now I think it a little bit early to talk in details about that

561
00:40:23,135 --> 00:40:27,415
But this is a whole lot that we would have learned to working at.

562
00:40:28,775 --> 00:40:28,915
Yeah.

563
00:40:29,395 --> 00:40:37,375
And I also think it's important to note that this entire post-quantum story for Bitcoin is a spectrum.

564
00:40:37,375 --> 00:40:40,975
from what do we do in an emergency

565
00:40:40,975 --> 00:40:43,595
if it happens now, let's say.

566
00:40:43,995 --> 00:40:45,435
It might not even be a quantum computer.

567
00:40:45,575 --> 00:40:48,275
It could be just our curve is broken classically.

568
00:40:48,875 --> 00:40:51,375
That's a scenario that some people bring up.

569
00:40:52,135 --> 00:40:56,515
And how can Bitcoin really work in a post-quantum future?

570
00:40:56,615 --> 00:40:59,515
And those are different questions, I think.

571
00:40:59,955 --> 00:41:03,335
Because when we want Bitcoin to work in a post-quantum future,

572
00:41:03,335 --> 00:41:06,715
we need to make sure that people can still make transactions

573
00:41:06,715 --> 00:41:09,735
and they are not just like a few transactions

574
00:41:09,735 --> 00:41:11,175
that can make it into the chain

575
00:41:11,175 --> 00:41:13,875
because the blocks are so small

576
00:41:13,875 --> 00:41:16,555
compared to the signature sizes.

577
00:41:17,035 --> 00:41:18,275
So those are different questions.

578
00:41:18,435 --> 00:41:20,315
And then there's a spectrum in between

579
00:41:20,315 --> 00:41:21,555
where we look at, okay,

580
00:41:21,555 --> 00:41:24,055
maybe this won't be the perfect solution,

581
00:41:24,355 --> 00:41:28,375
but at least it doesn't rely on these crazy assumptions.

582
00:41:29,375 --> 00:41:31,755
And I think this hash-based signature schemes

583
00:41:31,755 --> 00:41:34,255
is more on the sort of emergency,

584
00:41:34,255 --> 00:41:40,095
something we could get consensus on relatively easily,

585
00:41:40,095 --> 00:41:45,635
whereas the lattice-based stuff is a little bit further away on that spectrum.

586
00:41:48,295 --> 00:41:50,915
Yeah, there would be a lot of reshuffling if we had to do,

587
00:41:51,635 --> 00:41:55,355
if and potentially when we had to do this transition,

588
00:41:55,475 --> 00:41:56,575
so being prepared for it.

589
00:41:57,055 --> 00:42:03,215
Also, it's also possible to add multiple signature schemes to Bitcoin

590
00:42:03,215 --> 00:42:07,595
and even just looking at hash-based signatures,

591
00:42:07,855 --> 00:42:10,415
this might be a viable path forward

592
00:42:10,415 --> 00:42:13,815
because there are just so many different types of signers.

593
00:42:13,955 --> 00:42:15,815
There are these, I don't know,

594
00:42:16,735 --> 00:42:18,235
Kleb hardware wallets

595
00:42:18,235 --> 00:42:24,615
and there are Kleb lightning nodes

596
00:42:24,615 --> 00:42:26,735
and there are also big exchanges

597
00:42:26,735 --> 00:42:29,115
and they have different requirements.

598
00:42:29,115 --> 00:42:37,755
and even just for hash-based signature schemes this might mean that it makes sense to add

599
00:42:37,755 --> 00:42:43,115
hash-based signature schemes with different parameters this has downsides as well of course

600
00:42:43,115 --> 00:42:49,395
it increases the complexity of the of the bitcoin protocol which we want to keep relatively small

601
00:42:49,395 --> 00:42:55,815
because this might result in chain splits or other vulnerabilities in bugs if we have

602
00:42:55,815 --> 00:43:00,935
if there actually is something that goes wrong.

603
00:43:01,815 --> 00:43:10,975
And so another downside would be that it reduces privacy.

604
00:43:11,215 --> 00:43:18,575
One of the big advantages of introducing Taproot, right,

605
00:43:18,615 --> 00:43:22,635
was that every transaction should look like every other transaction,

606
00:43:22,635 --> 00:43:31,895
even at least in the best case and to improve privacy and if we introduce these many different

607
00:43:31,895 --> 00:43:36,655
signature schemes now this might be a problem because now you can look at the blockchain and

608
00:43:36,655 --> 00:43:42,955
just follow certain passive transactions and maybe certain wallets they have identifiable

609
00:43:42,955 --> 00:43:49,275
fingerprints and so on so these are the downsides if you add multiple signature schemes but it's

610
00:43:49,275 --> 00:43:56,435
certainly possible so you get degradation and privacy via process of elimination of yep different

611
00:43:56,435 --> 00:44:03,275
people using different signature schemes so yes yeah that makes sense well i guess this all comes

612
00:44:03,275 --> 00:44:09,135
back to like how how real is this rats how imminent is it or far away is it how much time

613
00:44:09,135 --> 00:44:14,075
do we have to prepare obviously jonas you mentioned like there is a potential for

614
00:44:14,075 --> 00:44:19,215
classical means so you don't even need a quantum computer just to break the curve but i think a lot

615
00:44:19,215 --> 00:44:24,075
of discussion is on quantum specifically and obviously early this year you had google's willow

616
00:44:24,075 --> 00:44:31,875
chip uh made a lot of hot headlines i think the um the sort of advancement there was 105 qubits

617
00:44:31,875 --> 00:44:41,175
uh computations that would take supercomputers 10 septillion years to to perform um and is that

618
00:44:41,175 --> 00:44:46,895
advancement enough to to make bitcoin bitcoiners wary and then another thing which is i'm trying

619
00:44:46,895 --> 00:44:54,815
to wrap my head around reading people's reactions to the quantum discussion this week is like

620
00:44:54,815 --> 00:45:02,635
how much signal is in these advancements, whether it's Willow or other quantum advancements

621
00:45:02,635 --> 00:45:03,495
that have been made recently.

622
00:45:03,695 --> 00:45:10,755
I've read people explaining that some of these advancements have sort of hard-coded variables

623
00:45:10,755 --> 00:45:14,815
or assumptions in them, which are sort of cheating in a way.

624
00:45:14,815 --> 00:45:21,195
and even if Willow got to 105 qubits

625
00:45:21,195 --> 00:45:22,695
and it was legitimate,

626
00:45:23,035 --> 00:45:25,655
I think there's a very good case to be made that it was,

627
00:45:26,175 --> 00:45:29,475
Bitcoin's cryptography would require around 13 million qubits

628
00:45:29,475 --> 00:45:33,155
working in parallel to break the curve.

629
00:45:33,155 --> 00:45:35,915
And so how viable is that?

630
00:45:35,975 --> 00:45:40,295
How realistic is that in a timeline of 5, 10, 15 years?

631
00:45:41,355 --> 00:45:44,275
So I'm not a quantum engineer

632
00:45:44,275 --> 00:45:52,835
And I think there is no consensus, at least among the experts, when this will happen.

633
00:45:52,975 --> 00:45:57,895
My angle on this is that I told you, we write these theorems.

634
00:45:58,175 --> 00:45:59,955
They rely on the elliptic curve.

635
00:46:00,175 --> 00:46:01,695
We know the elliptic curve is broken.

636
00:46:02,115 --> 00:46:03,775
This makes me uneasy.

637
00:46:04,555 --> 00:46:06,915
I want Bitcoin to be secure.

638
00:46:07,095 --> 00:46:08,935
And that includes my own little stash.

639
00:46:08,935 --> 00:46:13,755
I want it to be secure against very, very powerful adversaries.

640
00:46:14,755 --> 00:46:20,695
And I don't want it to only remain secure if some random guy on Twitter turns out to be right.

641
00:46:21,175 --> 00:46:27,235
So I think the Bitcoin community should certainly look at this problem.

642
00:46:27,355 --> 00:46:29,435
And this is why we are working on it.

643
00:46:30,735 --> 00:46:35,115
Right now, I wouldn't lose my sleep over it for sure as well.

644
00:46:35,115 --> 00:46:46,495
But on the other hand, 10 years in Bitcoin even is not such a long time if we need to prepare for an upgrade like that.

645
00:46:46,955 --> 00:46:51,375
You said it yourself, the HD wallet stuff, for example, that would completely be broken.

646
00:46:51,475 --> 00:46:55,075
So we would need to have an ecosystem update for that.

647
00:46:55,155 --> 00:47:03,155
Maybe that doesn't take 10 years, but people migrating their coins, the more time they have, the better.

648
00:47:03,155 --> 00:47:13,695
Yeah. Yeah. I mean, it's very hard to just say, okay, this will be five years, 10 years,

649
00:47:13,755 --> 00:47:20,295
or whatever years, because the advancement goes from every possible direction. As you said,

650
00:47:20,375 --> 00:47:26,715
for example, counting the number of cubits, there is a very interesting point in terms of,

651
00:47:26,715 --> 00:47:33,595
uh it's a little bit different from how the classical computers work in terms of we need

652
00:47:34,235 --> 00:47:42,315
several physical qubits to encode a one logical means one logical is that we actually actually

653
00:47:42,315 --> 00:47:49,355
performs like we expected it to perform because there is a lot of noise in the quantum computations

654
00:47:49,355 --> 00:47:56,475
and one need to eliminate that noise to actually do proper computations one can increase the number

655
00:47:56,475 --> 00:48:04,395
of those qubits, one can improve the noise cancellation algorithms. Then it's also very

656
00:48:04,395 --> 00:48:12,235
important in terms of the quantum algorithms that actually solving the problem. And for example,

657
00:48:12,235 --> 00:48:19,835
there was a recent advancement that reduced, I think, by 20 times the number of qubits that

658
00:48:19,835 --> 00:48:27,835
required the algorithms there. So the advancement go from different directions. I would agree with

659
00:48:27,835 --> 00:48:35,355
Jonas in terms of I wouldn't lose sleep today but we have to work towards the solutions to be ready.

660
00:48:35,355 --> 00:48:43,435
If we just delay delay delay and we never come there but now we have to work and progress and see

661
00:48:43,435 --> 00:48:51,915
what what possible uh solutions we have and prepare for for the downsides uh and change

662
00:48:51,915 --> 00:49:01,915
that that these solutions bring how would uh how would you two describe your um this is what i'm

663
00:49:01,915 --> 00:49:09,275
looking for are you uh are you happy with the amount of focus on this obviously pip 360 um

664
00:49:09,275 --> 00:49:15,355
has been talked about for the last, I mean, before it was BIP360 even,

665
00:49:15,715 --> 00:49:19,795
people have been talking about this Hunter and his work.

666
00:49:19,915 --> 00:49:24,475
People have been looking at that and discussing it for what seems like over a year now.

667
00:49:25,155 --> 00:49:29,215
At this point, obviously, you two have done a ton of research.

668
00:49:29,215 --> 00:49:34,155
We had the quantum meeting at Presidio Bitcoin in July.

669
00:49:34,315 --> 00:49:37,455
Is there enough discussion, in your opinion, on this topic right now?

670
00:49:37,455 --> 00:49:40,415
are enough people focused on it and taking it seriously

671
00:49:40,415 --> 00:49:48,175
and of course it would always be better if there was more quality discussions but i think the

672
00:49:48,175 --> 00:49:54,595
type of discussions that we have right now is is pretty good and has also increased quite a bit

673
00:49:54,595 --> 00:50:02,095
especially over uh over the last year so like you you like on twitter there there was not only noise

674
00:50:02,095 --> 00:50:11,315
I think there was also a bunch of signal and it was good that even the wider Bitcoin community also talked about this and talked this through.

675
00:50:12,055 --> 00:50:16,395
And on the Bitcoin mailing list, there's always a bunch of discussions.

676
00:50:16,555 --> 00:50:28,295
Of course, there's always this kind of Bitcoin thing that might happen where just there is some discussion and then there's no follow up.

677
00:50:28,295 --> 00:50:29,895
nothing ever happens, right?

678
00:50:29,995 --> 00:50:32,955
It's a pretty standard thing that happens in Bitcoin.

679
00:50:33,615 --> 00:50:38,215
But I'm also not too worried about that, to be honest,

680
00:50:38,215 --> 00:50:43,355
because I think if it really, if it was really,

681
00:50:43,895 --> 00:50:46,575
if the quantum computer was imminent,

682
00:50:47,195 --> 00:50:50,095
then I think the Bitcoin community would find consensus

683
00:50:50,095 --> 00:50:51,935
on some sort of upgrade.

684
00:50:52,375 --> 00:50:55,835
What is, of course, going to be really, really painful,

685
00:50:55,835 --> 00:51:01,395
and there's no way to sugarcoat it is what happens with the coins that don't migrate

686
00:51:01,395 --> 00:51:07,595
and i think this will be extremely painful but that's not something that that cryptography can

687
00:51:07,595 --> 00:51:14,735
solve unfortunately what's your take there i'm a i'm a don't do anything with them let them let

688
00:51:14,735 --> 00:51:20,915
the treasure hunts begin that's i think that's my stance because you always have to think of the man

689
00:51:20,915 --> 00:51:29,015
in the coma right which is if you were to change or make their coins unspendable and the guy wakes

690
00:51:29,015 --> 00:51:35,355
up and he's like hey i have five bitcoin here that i can't move anymore because you did something

691
00:51:35,355 --> 00:51:41,715
and quant computers haven't stolen it yet um you're sort of screwing that guy over

692
00:51:41,715 --> 00:51:50,435
i think there are reasonable uh arguments for or both for both positions that's what makes it

693
00:51:50,435 --> 00:51:57,295
painful and um i don't know i guess my opinion right now is that if i look at it extremely

694
00:51:57,295 --> 00:52:03,875
selfishly what code would i run on my node then i think it would be the one that uh that freezes

695
00:52:03,875 --> 00:52:10,675
the coins because that at least i think in the mid to long term it would probably result in a

696
00:52:10,675 --> 00:52:15,875
better outcome for the world for the bitcoin network but yeah you could fight counter arguments

697
00:52:15,875 --> 00:52:23,095
to that i'm sure yeah i thought um i followed the uh the discussion on the mailing list

698
00:52:23,095 --> 00:52:27,655
i've been following it i thought earlier this year i think there's still a lot of

699
00:52:27,655 --> 00:52:33,695
assumptions baked into this but i thought ethan haleman's post on this was interesting

700
00:52:33,695 --> 00:52:40,235
how you could essentially throttle the transition and only make a certain amount of transactions from

701
00:52:40,235 --> 00:52:44,995
quantum exposed signatures possible per block.

702
00:52:47,035 --> 00:52:49,715
Is this this hourglass idea?

703
00:52:50,455 --> 00:52:51,395
I think so.

704
00:52:51,695 --> 00:52:52,595
I'm pretty sure.

705
00:52:54,595 --> 00:52:55,715
Let me see.

706
00:52:55,955 --> 00:52:56,655
It goes all the way up.

707
00:52:58,535 --> 00:53:00,155
I think it is.

708
00:53:02,295 --> 00:53:06,035
He also said it was a way to solve the JPEG spam as well.

709
00:53:07,155 --> 00:53:08,435
But this idea that...

710
00:53:08,435 --> 00:53:09,155
And that's the other thing.

711
00:53:09,155 --> 00:53:17,635
Maybe we should just dive into the trade-offs that exist with what you do with the coins that haven't transitioned.

712
00:53:18,055 --> 00:53:21,915
What are the solutions that are being thrown out there right now or the trade-offs that exist?

713
00:53:25,335 --> 00:53:30,535
I mean, I personally haven't looked too much into this.

714
00:53:30,655 --> 00:53:36,815
I know that there is a discussion on the mailing list, and there probably should be more discussion.

715
00:53:36,815 --> 00:53:42,415
I don't know but as I said there's no no easy answer to this I wouldn't be

716
00:53:42,432 --> 00:53:45,112
able to reproduce all the pros and cons there.

717
00:53:46,712 --> 00:53:47,372
All right.

718
00:53:47,412 --> 00:53:49,492
Well, then taking it in a different direction,

719
00:53:50,212 --> 00:53:52,552
like how, like, obviously you guys are doing research.

720
00:53:52,632 --> 00:53:54,172
There's a lot of discussion about this.

721
00:53:54,832 --> 00:53:58,812
In terms of like a first step beyond research

722
00:53:58,812 --> 00:53:59,992
and having the discussions,

723
00:53:59,992 --> 00:54:07,712
what would a transition to a post-quantum signature scheme look like?

724
00:54:07,812 --> 00:54:10,672
Like how do you prep the market?

725
00:54:10,992 --> 00:54:11,872
How do you begin moving?

726
00:54:11,872 --> 00:54:16,572
how do you set up the node software to make this stuff viable

727
00:54:16,572 --> 00:54:26,712
as for the next steps that we envision after this paper so one thing that is a contribution

728
00:54:26,712 --> 00:54:34,972
of this paper is that we have this script a python script where you can explore the parameter space

729
00:54:34,972 --> 00:54:40,352
or you can say okay i want to support that many signatures and the tree to look like this and then

730
00:54:40,352 --> 00:54:47,252
it spits out the signature size verification time etc and we also have tables in in the paper

731
00:54:47,252 --> 00:54:54,392
that do show some of these values already for the parameters that we that we pick so like

732
00:54:54,392 --> 00:55:03,892
explore the parameter space and then next what um what is the next step there is implementations

733
00:55:03,892 --> 00:55:12,912
benchmarking yes implementations and actual benchmarks we just estimate through some crude

734
00:55:12,912 --> 00:55:20,072
proxy what the performance would be but we haven't really measured actual performance and at least

735
00:55:20,072 --> 00:55:27,032
from my experience implementations usually they inform specifications quite a bit because you find

736
00:55:27,032 --> 00:55:36,532
things that you wouldn't notice just going from the from the research direction and it's nice that

737
00:55:36,532 --> 00:55:42,112
actually there are people actively participating in that regard and also on the mailing list there

738
00:55:42,112 --> 00:55:50,592
were several posts of people trying to implement hash-based schemes either sphinx plus or sphinx

739
00:55:50,592 --> 00:55:55,852
plus with lower number of signatures now they're also looking at possible modifications that we

740
00:55:55,852 --> 00:56:03,132
also discussed in this paper and i think this will significantly help with the with the decision

741
00:56:03,132 --> 00:56:11,032
that we will have to make so uh yeah i think that's very good to point out because they

742
00:56:11,032 --> 00:56:16,892
have really so there's specifically i want to give a shout out to conduition he wrote this

743
00:56:16,892 --> 00:56:23,332
awesome blog post where he optimized hash base signatures like crazy and certainly worth worth

744
00:56:23,332 --> 00:56:31,592
to read um but for the for the bigger discussion how do we actually migrate um now that this this

745
00:56:31,592 --> 00:56:41,712
research um exists um or even before that just with the standardized nist schemes um so one thing

746
00:56:41,712 --> 00:56:49,972
that could happen that is uh i think a relatively reasonable upgrade path that unfortunately does

747
00:56:49,972 --> 00:56:58,012
not have a catchy name i think so matt corello he was the first one to uh popularize it on the

748
00:56:58,012 --> 00:57:07,272
on the mailing list but uh others i think have discussed it before which is um let's say we just

749
00:57:07,272 --> 00:57:16,172
introduce a uh a hash based signature opcode like check sick verify that we have for uh for

750
00:57:16,172 --> 00:57:22,992
our elliptic curve based signatures we just introduce one for hash based signatures doesn't

751
00:57:22,992 --> 00:57:28,532
matter how it looks like something like that and what people could do today already

752
00:57:28,532 --> 00:57:38,932
wallets could do generate a post-quantum public key a hash based public key and then add this

753
00:57:38,932 --> 00:57:48,732
public key along with this new opcode in a taproot merkle tree that already exists

754
00:57:48,732 --> 00:57:57,072
so this would be a soft fork so we add this opcode and there's no cost for a wallet except

755
00:57:57,072 --> 00:58:05,212
implementation complexity to add this additional spending path if they already use taproot to the

756
00:58:05,212 --> 00:58:15,372
the taproot tree and so they do that and of course taproot itself is not secure some the

757
00:58:15,372 --> 00:58:21,632
full taproot not secure against a break of the elliptic curve because we have these key spins

758
00:58:21,632 --> 00:58:30,192
as well which just require a an elliptic curve short signature for the public key that is directly

759
00:58:30,192 --> 00:58:34,492
in the output. So that's a keypad, but there's also the taproot tree.

760
00:58:34,492 --> 00:58:41,052
Now, what our colleague Tim Rufing at Blockstream proved is that

761
00:58:41,052 --> 00:58:57,307
the taproot script spans so the Merkle trees inside the Taproot they are still secure even if a quantum computer arrives a cryptographically relevant quantum computer

762
00:58:57,307 --> 00:59:05,727
So what you can do is at a certain point, you disable the key spends from Taproot.

763
00:59:06,307 --> 00:59:09,307
And then you still, hopefully many wallets have done that.

764
00:59:09,687 --> 00:59:15,287
They have these additional post-quantum public keys in the tree.

765
00:59:15,407 --> 00:59:21,107
So they will be able to spend those coins with a hash-based signature.

766
00:59:21,107 --> 00:59:29,687
and the advantage of this is you can use taproot as you do right now you have these very official

767
00:59:29,687 --> 00:59:38,007
keyspins you have the taproot path you have music frost whatever only once the bitcoin community does

768
00:59:38,007 --> 00:59:49,487
this upgrade to disable uh keyspins hypothetically then you need to use these new script paths in the

769
00:59:49,487 --> 00:59:51,047
Merkle tree, in the taproot tree.

770
00:59:52,007 --> 00:59:53,247
This will be one variant.

771
00:59:53,667 --> 01:00:02,827
Actually, a very important benefit of a Bitcoin system in that regard is that, for example,

772
01:00:02,827 --> 01:00:10,147
other systems that were looking like, I don't know, DLS or whatever, a lot of time we want

773
01:00:10,147 --> 01:00:10,847
encryption.

774
01:00:11,427 --> 01:00:16,827
And people that are also scared of quantum computers today, they're also worried about

775
01:00:16,827 --> 01:00:22,067
this attack called store now decrypt later. So they also

776
01:00:22,227 --> 01:00:26,427
urge in the migrating in terms of encryption. So for example,

777
01:00:26,547 --> 01:00:31,647
now, the post quantum scope encapsulation mechanism that

778
01:00:31,667 --> 01:00:35,967
help you to actually encrypt your messages and encrypt your

779
01:00:35,967 --> 01:00:39,307
communications are already getting deployed. While the

780
01:00:39,307 --> 01:00:44,427
signatures can wait a little bit later because for most use

781
01:00:44,427 --> 01:00:50,987
cases you are scared of your signatures broken up you don't care if they i don't know they see

782
01:00:50,987 --> 01:00:58,587
your public key that you don't use anymore 10 years later and so this scripting pass that you

783
01:00:58,587 --> 01:01:05,227
are described exactly we can migrate closer when we see the actual thread while the solution is

784
01:01:05,227 --> 01:01:12,747
already there you just want to use the solution when when we're actually needed

785
01:01:12,747 --> 01:01:20,327
and this may be a dumb question but uh jonas you mentioned like music and frost

786
01:01:20,327 --> 01:01:24,327
is there a way to just leverage those on top of

787
01:01:24,327 --> 01:01:32,847
like your your private public key pair to harden that private key even more from a quantum attack

788
01:01:32,847 --> 01:01:37,807
does that make sense even just like obscure like the spending conditions like make it harder

789
01:01:37,807 --> 01:01:46,667
without introducing uh hash-based signatures or any post-quantum assumption just yes no no the

790
01:01:46,667 --> 01:01:55,487
problem is that in the whenever the adversary sees a public key they can run their quantum

791
01:01:55,487 --> 01:02:02,887
computer and compute the the private key that's corresponding to it so music or frost or any

792
01:02:02,887 --> 01:02:08,807
obfuscation attempts like this will will fail okay that's good to know

793
01:02:08,807 --> 01:02:11,667
fascinating stuff so

794
01:02:11,667 --> 01:02:16,887
what are the dangers if we move too fast on this i mean you mentioned them earlier

795
01:02:16,887 --> 01:02:23,967
with like if we because that's what i worry about that was the uh the most disheartening

796
01:02:23,967 --> 01:02:27,047
thing about the conversation last week i think it's good the conversation is happening but

797
01:02:27,047 --> 01:02:32,667
The idea that the community of developers working on Bitcoin

798
01:02:32,667 --> 01:02:33,827
haven't been thinking about this.

799
01:02:33,927 --> 01:02:36,307
Obviously, you two spend a lot of time on your research.

800
01:02:36,427 --> 01:02:37,907
Blockstream does a ton of research,

801
01:02:37,907 --> 01:02:40,847
and there's plenty of others outside of your organization

802
01:02:40,847 --> 01:02:43,087
working on this stuff.

803
01:02:43,707 --> 01:02:45,587
What I worry about most, I agree,

804
01:02:45,667 --> 01:02:49,347
I think we should want Bitcoin to be as secure as possible,

805
01:02:49,347 --> 01:02:51,647
and if it's a threat of quantum computing

806
01:02:51,647 --> 01:02:58,407
or even classical elliptic curve breaking computers are to manifest.

807
01:02:58,607 --> 01:02:59,867
We should prepare for this.

808
01:02:59,867 --> 01:03:04,327
But what could be just as dangerous is moving too fast, right?

809
01:03:04,787 --> 01:03:09,787
And so trying to have a level-headed discussion about what to do.

810
01:03:09,847 --> 01:03:14,087
And obviously you can't use the fear of moving too fast forever

811
01:03:14,087 --> 01:03:15,767
because then you're complacent.

812
01:03:15,827 --> 01:03:18,947
But there's this sort of trade-off between urgency and complacency.

813
01:03:18,947 --> 01:03:28,907
how do you view it i think it's i mean first of all yeah there's a lot of value in the bitcoin

814
01:03:28,907 --> 01:03:37,607
protocol being as simple as possible um because yeah we we want bitcoin to be secure and that

815
01:03:37,607 --> 01:03:43,147
requires a relatively simple protocol whenever we add something to bitcoin there is a risk

816
01:03:43,147 --> 01:04:02,402
I think adding a hash base signature scheme to Bitcoin I think that risk is manageable but still it will require resources to maintain it to make sure that the versions are all compatible with each other and there are no

817
01:04:02,402 --> 01:04:08,222
consensus relevant issues, which is a specific problem that is specific to Bitcoin. It doesn't

818
01:04:08,222 --> 01:04:15,862
exist in non-blockchain or non-consensus systems. So there's a risk in that. And then

819
01:04:15,862 --> 01:04:21,222
If you add something and no one uses it, I think that's just a lot of wasted effort.

820
01:04:21,222 --> 01:04:41,962
But I also don't think right now, looking at the discussion on the mailing list and people I had in person, even on Twitter, I don't really think that it is realistic that we will have a post-quantum upgrade very soon in Bitcoin.

821
01:04:42,562 --> 01:04:43,922
Is at least my impression.

822
01:04:43,922 --> 01:04:53,362
And as you said, we want to explore in full what are our options.

823
01:04:53,362 --> 01:05:01,782
And as we said before, the next topic would be to look at lattice-based, how they affect,

824
01:05:01,782 --> 01:05:06,982
what are the assumptions, what are the benefits, and doing a proper comparison of what are

825
01:05:06,982 --> 01:05:16,822
the options gives us uh i guess the best the best outcome here so crushing it uh also like

826
01:05:16,822 --> 01:05:25,782
this with the fear in the ice is also not the best way to go no and again who knows that's

827
01:05:25,782 --> 01:05:31,142
that's the thing about this quantum uh risk is it's hard to know it's like a big unknown it's

828
01:05:31,142 --> 01:05:36,102
like climate change almost where it's like it's just around the corner but it's been said for some

829
01:05:36,102 --> 01:05:41,102
time and obviously there are some advancements but again as a layman it's not easy to understand

830
01:05:41,102 --> 01:05:46,622
where the signal in these advancements are you can talk to some quantum physicists they say to

831
01:05:46,622 --> 01:05:52,922
your point like this doesn't scale literally you need more um physical qubits to create

832
01:05:52,922 --> 01:06:00,182
logical qubits and if you need thousands of logical qubits to attack bitcoin that's an

833
01:06:00,182 --> 01:06:04,902
exponential amount of physical qubits this is the way i understand it i'm speaking out of my ass but

834
01:06:04,902 --> 01:06:20,382
Yeah, I mean, if I'm allowed to tell a personal anecdote, I actually studied cognitive science for my bachelor, which is right at the intersection of AI and human intelligence.

835
01:06:20,882 --> 01:06:25,882
And for my master's, I studied computer science with a focus on artificial intelligence.

836
01:06:25,882 --> 01:06:34,222
if i had told anyone that i believe we would have chat gpt3 by 2022 they would have

837
01:06:34,222 --> 01:06:45,822
ridiculed me forever at that time people uh they not not only that they thought maybe i think one

838
01:06:45,822 --> 01:06:51,942
of or a lot of people thought that something like chat gpt3 would never be possible it's just so

839
01:06:51,942 --> 01:06:59,122
much intelligence coming from a machine and look at where where we where we are now i actually

840
01:06:59,122 --> 01:07:06,762
sort of thought when i studied this i thought uh this ai stuff is going nowhere it's not not

841
01:07:06,762 --> 01:07:12,322
going to be a breakthrough i'm i'm focusing all my time on bitcoin back when i was a student

842
01:07:12,322 --> 01:07:20,182
right so i am just very skeptical of people oh first of all i want to say of course this analogy

843
01:07:20,182 --> 01:07:22,162
fails in many ways, quantum computing

844
01:07:22,162 --> 01:07:23,782
very different to AI, of course.

845
01:07:24,282 --> 01:07:26,042
But I am skeptical

846
01:07:26,042 --> 01:07:28,362
of people saying or confidently

847
01:07:28,362 --> 01:07:30,162
claiming there's no clear path

848
01:07:30,162 --> 01:07:32,422
towards a cryptographically

849
01:07:32,422 --> 01:07:34,282
relevant quantum computer. Maybe there's not

850
01:07:34,282 --> 01:07:36,342
one right now, but I think

851
01:07:36,342 --> 01:07:38,342
there could be one any time.

852
01:07:40,542 --> 01:07:42,102
And you have to prepare.

853
01:07:42,662 --> 01:07:43,622
If you don't prepare

854
01:07:43,622 --> 01:07:45,062
and then

855
01:07:45,062 --> 01:07:48,102
suddenly you find out you were wrong,

856
01:07:50,182 --> 01:07:50,382
Yep.

857
01:07:50,942 --> 01:07:51,122
Yeah.

858
01:07:52,302 --> 01:07:58,462
No, that goes back to like measuring and balancing complacency versus urgency.

859
01:08:00,022 --> 01:08:06,822
Because again, to my point, like I think this is a discussion that's been taken seriously for many years now.

860
01:08:08,362 --> 01:08:11,382
And it's like brush to fix it right now.

861
01:08:11,462 --> 01:08:14,182
It's like, whoa, hey, there's good conversations going on.

862
01:08:14,242 --> 01:08:15,402
There's good research being done.

863
01:08:15,742 --> 01:08:18,022
Let's make sure we get this right because it's critically important.

864
01:08:18,982 --> 01:08:19,502
Yep.

865
01:08:20,182 --> 01:08:28,962
And on that note, I want to thank you, gentlemen, not only for joining me, but for doing the research on the subject and coming to to explain it to everybody.

866
01:08:28,962 --> 01:08:32,082
It's been incredibly illuminating for me.

867
01:08:32,742 --> 01:08:41,742
And again, like I said earlier, a lot of people take for granted the technical details of the Bitcoin protocol.

868
01:08:41,882 --> 01:08:49,402
It just works for them at the end of the day due to the work research that individuals like yourself and other developers have done.

869
01:08:49,402 --> 01:09:02,817
and it pretty insane sci tech once you look under the hood and trying to upgrade that tech is not an easy feat especially when you have a distributed protocol and you need coordination

870
01:09:02,817 --> 01:09:06,397
between all those individual actors within the system.

871
01:09:08,797 --> 01:09:16,317
Yes, but one thing I want to add there is that what we're doing is also not rocket science

872
01:09:16,317 --> 01:09:21,077
in the sense that it's impossible to understand or anything like that.

873
01:09:21,517 --> 01:09:32,657
Because there's also this impression that I see sometimes on Bitcoin that there is this closed group of perhaps Bitcoin core people, high priests or whatever.

874
01:09:33,397 --> 01:09:36,817
If that is the case, then that is very bad.

875
01:09:36,997 --> 01:09:40,337
And I think everyone in the Bitcoin community agrees that it will be very bad.

876
01:09:40,397 --> 01:09:50,017
Well, we want to have a system based on merit and there's no secret knowledge that needs to be obtained to be part of any sort of group.

877
01:09:50,017 --> 01:09:54,697
At least this is the system we want to have.

878
01:09:54,697 --> 01:09:58,897
And we want to have the best people working on Bitcoin.

879
01:09:59,497 --> 01:10:02,937
And this was also our intention, writing this paper.

880
01:10:02,937 --> 01:10:07,857
We tried to give a good introduction into this hash-based solution.

881
01:10:08,137 --> 01:10:08,377
Right.

882
01:10:08,377 --> 01:10:13,217
And slowly building up from very basic, from WEMPR signatures,

883
01:10:13,217 --> 01:10:17,417
which probably we will not use, but just to build the intuition.

884
01:10:17,417 --> 01:10:24,557
so go take a look at the at the paper we're trying to introduce the stuff slowly there and moving

885
01:10:24,557 --> 01:10:32,137
on and on and showing what are the solutions what are the trade-offs what can be done and yeah

886
01:10:32,137 --> 01:10:42,317
let's have a discussion and uh if i could read your research have a conversation with you and

887
01:10:42,317 --> 01:10:45,697
know enough to like understand what's happening in the background with like verification

888
01:10:45,697 --> 01:10:53,857
signature verification its effect on the protocol anybody can do it uh that's uh that's to say the

889
01:10:53,857 --> 01:10:59,977
least but gentlemen any uh any parting notes anything um that you want to leave the audience

890
01:10:59,977 --> 01:11:11,117
with right before we wrap up here i think i would encourage further discussions uh more technical

891
01:11:11,117 --> 01:11:18,877
discussions uh reading into what we've done doing your own stuff suggest and yeah this is

892
01:11:19,757 --> 01:11:28,237
let's have it with a good pace not rushing but also not not putting it away and saying like that

893
01:11:28,237 --> 01:11:37,997
this will never happen yep i i agree i mean there's uh there's still a lot of uh feedback

894
01:11:37,997 --> 01:11:45,777
that would be interesting for us in particular from from wallet developers um that that is sort

895
01:11:45,777 --> 01:11:52,477
of an open question how um if maybe there are one of developers for example that can deal

896
01:11:52,477 --> 01:11:58,157
with a state issue and we have a we have a scheme that we describe which is very efficient

897
01:11:58,157 --> 01:12:06,057
if you can hold state securely so that will be interesting feedback then there is this

898
01:12:06,057 --> 01:12:13,097
benchmarking question um especially with respect to siding on on low power devices

899
01:12:13,097 --> 01:12:21,357
and uh yeah i think those those were the the the main open questions and the big question is like

900
01:12:21,357 --> 01:12:28,977
what is the most interesting parameter set to choose from the set that we provide and um

901
01:12:28,977 --> 01:12:51,717
Then there's also the question, I think some people would also argue that just using the standard versus our optimized thing would be preferable because then it would be supported by the secure element on your iPhone or whatever.

902
01:12:51,717 --> 01:12:54,177
so that is I think also

903
01:12:54,177 --> 01:12:56,217
one of the big open

904
01:12:56,217 --> 01:12:58,597
questions with respect to hash based

905
01:12:58,597 --> 01:13:00,237
signatures specifically

906
01:13:00,237 --> 01:13:01,717
could you

907
01:13:01,717 --> 01:13:04,197
propose a new standard

908
01:13:04,197 --> 01:13:06,377
and get it

909
01:13:06,377 --> 01:13:08,857
I mean we could propose

910
01:13:08,857 --> 01:13:10,457
but would it be

911
01:13:10,457 --> 01:13:12,337
accepted as the bigger

912
01:13:12,337 --> 01:13:12,797
question

913
01:13:12,797 --> 01:13:15,837
we make our own standards right

914
01:13:15,837 --> 01:13:18,257
we have the BIPS process and maybe

915
01:13:18,257 --> 01:13:20,097
we can get Apple to adopt

916
01:13:20,097 --> 01:13:24,097
our standards that would of course be uh the most preferable path

917
01:13:26,497 --> 01:13:32,417
yeah well gentlemen thank you this was uh again incredibly illuminating thank you for your work

918
01:13:32,417 --> 01:13:38,097
and uh hopefully we can do this again maybe uh when you finish your research on lattice base

919
01:13:39,137 --> 01:13:44,337
signatures we can uh we can catch up then or maybe not maybe we won't have to wait that long but

920
01:13:44,337 --> 01:13:44,837
Thank you.

921
01:13:45,517 --> 01:13:48,957
And I hope you guys enjoy the end of the year here.

922
01:13:49,357 --> 01:13:53,357
Thank you for joining me so close to Christmas and the holidays.

923
01:13:53,697 --> 01:13:55,477
So this was awesome.

924
01:13:56,277 --> 01:13:56,437
Yeah.

925
01:13:56,737 --> 01:13:57,517
Thank you very much.

926
01:13:57,677 --> 01:13:58,077
It was fun.

927
01:13:58,837 --> 01:13:59,077
All right.

928
01:13:59,257 --> 01:13:59,917
Peace and love, freaks.

929
01:14:00,377 --> 01:14:00,557
Okay.