Latest / TFTC: A Bitcoin Podcast / #700: Preparing Bitcoin for the Quantum Era with Jonas Nick & Mikhail Kudinov

Transcript

#700: Preparing Bitcoin for the Quantum Era with Jonas Nick & Mikhail Kudinov · TFTC: A Bitcoin Podcast

0:00
You've had a dynamic where money has become freer than free.
0:10
You talk about a Fed just gone nuts.
0:13
All the central banks going nuts.
0:16
So it's all acting like safe haven.
0:18
I believe that in a world where central bankers are tripping over themselves to devalue their
0:23
currency, Bitcoin wins.
0:25
In the world of fiat currencies, Bitcoin is the victor.
0:28
I mean, that's part of the bull case for Bitcoin.
0:31
If you're not paying attention, you probably should be.
0:36
Jonas McHale, welcome to the show.
0:38
Thank you for joining me.
0:40
Thank you for having us.
0:42
Been a big week.
0:44
You guys wrote a paper.
0:45
There's a lot of discussion on it, on X and other platforms.
0:49
The paper is hash-based signature schemes for Bitcoin.
0:54
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.
1:17
But first, I think we should start thinking of someone who doesn't have a cryptography background.
1:25
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?
1:36
I think I can start and then Mike can fill in the details that I'm missing.
1:43
So where do we use signatures in Bitcoin?
1:47
we use it to authorize transactions.
1:51
And the current signatures that we use,
1:54
they are based on the security of an elliptic curve
2:00
that's called SECP256K1 in Bitcoin.
2:03
It was chosen by Satoshi.
2:06
There are alternative signature schemes
2:09
that depend on different assumptions.
2:12
and one of those alternatives are hash-based signature schemes and all of these alternatives
2:21
they have different trade-offs we started looking at hash-based signature schemes because
2:29
the assumptions that they use they are relatively conservative compared to other signature schemes
2:37
and
2:39
hash base signature schemes
2:42
that just means that the signature
2:44
scheme is the security
2:46
of the signature scheme is based
2:47
on the security of
2:50
the hash function
2:51
why is that attractive for Bitcoin specifically
2:54
well we already
2:55
are relying on the security
2:58
of SHA-256
3:00
for example this is how we
3:02
refer to previous blocks
3:04
in the blockchain this is how
3:05
transactions get committed to a block in the Merkle tree. And from that perspective,
3:12
we started looking at these hash-based signatures first.
3:19
Essentially, it's also important to say for most of the other approaches that one can consider,
3:27
whether there is one popular or lattice-based schemes that require some other assumptions.
3:35
most of them still rely on hash functions.
3:38
So this is essentially as minimal as you can get in terms of like security
3:44
assumptions and requirements from a scheme is requiring just a hash function to be secure.
3:53
This is a very conservative approach and I guess
3:58
arguably the most secure
4:02
way the possibilities is.
4:06
It has the least amount of attack vectors in that regard.
4:11
So, Janice, you referenced it.
4:13
So, Bitcoin already relies on SHA-256 for mining and transaction IDs.
4:17
So, this is just sort of a doubling down
4:19
on what's already worked to date and what we know to be pretty secure.
4:23
Right, right.
4:24
So, hash-based means we can use any hash.
4:27
there are also different hash functions we could choose also with different trade-offs
4:33
with respect to performance or even proving in zero-knowledge snarks
4:39
but the natural choice for the hash function would just be SHA-256
4:44
because if SHA-256 is broken then arguably we have even bigger problems
4:50
than just transaction authorization not working
4:53
the blockchain doesn't really work anymore
4:56
we don't know what the truth is we we don't have consensus on the blockchain anymore so
5:01
yeah from that perspective makes sense to look at these hash-based signature schemes
5:08
but they have a reputation for being quite large in terms of size so that is that is a consideration
5:16
that that one needs to look into when when considering hash-based interests
5:23
and before we get to that because i think that's exactly what your paper focused on like okay
5:28
if we want to be quantum resistant we're going to use hash base how do we basically weigh the
5:33
trade-offs and make sure that bitcoin is still usable and scalable at the end of the day but
5:38
before we get to that even like we've all heard the term post-quantum thrown around what does
5:44
that actually mean like what is the quantum we're supposed to be afraid of and supposed to be
5:49
preparing for yeah so i think so from my perspective if we if we as cryptographers do
5:57
security proofs so for example for schnor signatures or music or frost or signature
6:05
aggregation dahlias etc we have these little theorems they are a paragraph or two contain some
6:13
numbers and they very precisely state what the assumptions are under which these signatures are
6:20
secure and in the case of schnor signatures it tells you directly when you read it or write it
6:29
down it relies on the security of this curve that you're choosing sec p256k1 in the case of bitcoin
6:36
and we know that this assumption that secp256k1 is not broken is actually wrong
6:48
it is broken you just the challenge is just to build a machine that exploits quantum mechanics
6:55
enough to break it but this is different from other types of cryptography we can also do
7:01
cryptography where we don't have assumptions like that so just writing this down this statement
7:06
personally makes makes me a little bit uneasy as well so a quantum computer would be able to break
7:16
our curve and therefore would be able to break shore signatures now the challenge
7:22
of post-quantum cryptography is to find cryptographic schemes that are secure
7:30
even in the presence of quantum computers.
7:35
And that requires also some sort of guesswork or some research as to what problems quantum computers are actually good at.
7:46
We know that they are very good at breaking our elliptic curve.
7:50
And it's very unlikely that they are good at breaking hashes, let's say.
7:57
They are better than classical computer, but they won't be able to break it in a way that they can break elliptic curves.
8:05
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.
8:18
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.
8:32
We know that it is a hard problem for quantum computer and you cannot do better than certain complexity.
8:38
And the hash function is essentially is this random database because we take an
8:46
input, we hash it, we get a arguably random looking output. And our assumption
8:54
here is that we will not find an algorithm that can exploit the actual
8:59
description of the hash function. But one can view this very similar to how
9:05
classical analysis of hash functions works because classically we also rely on that we cannot find
9:14
an algorithm that can exploit the actual description of the hash function the actual algorithm that
9:20
does the hashing and so far shadow 156 was not
9:27
under good attacks there it proved its security and there was no significant improvement in terms
9:38
of exploiting the structure so for any quantum advances there there must be a structure in the
9:46
hash function that y can exploit and so far we couldn't find anything like that okay and so let's
9:54
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.
10:02
And talk about the tradeoffs in the paper.
10:05
It seems like you guys settled on Sphinx Plus as a standardized solution because it already exists.
10:10
It's already standardized by the NIST.
10:14
Why do we need this research?
10:16
What's the gap that you guys are trying to fill by applying this to Bitcoin specifically?
10:21
yeah so nist has looked at which post-quantum signature schemes to standardize and they picked
10:31
so they picked multiple one of them was sphinx plus that they standardized but
10:39
so sphinx plus exists we could use it there exists in bitcoin i mean there exists high
10:46
quality implementations with formal verification and proof etc so we could just use it
10:53
but the kind of research question that we had when we started the the paper was
11:00
the kind of goal of signatures usually outside of of bitcoin or blockchains is to sign software
11:10
and to sign certificates for the web.
11:15
And this is a very different application
11:17
to what we're doing in Bitcoin with signatures.
11:21
So what we were asking was,
11:25
can we adapt this standardized scheme
11:28
or also other schemes that exist in the literature
11:31
that have not been standardized
11:33
and see how, in what way we could change them
11:39
to better fit to this Bitcoin application.
11:46
And again, one of the trade-offs
11:48
that we're trying to solve for here
11:50
is the size of the signatures.
11:54
In the paper you mentioned,
11:55
going from about 7,800 bytes
11:57
down to around 3,400 to 4,000 bytes
11:59
with optimizations.
12:01
I think for the listeners out there,
12:04
getting them to understand,
12:05
why does the size of these signatures matter?
12:08
what's the trade-off that you're making yeah i think mike can speak best to that
12:12
yeah so first of all the size determines how many signatures can fit in the block
12:19
and then the bigger the signatures the fewer transactions you can you can fit and that
12:25
so in the current block that is right we have these maximum four megabyte blocks and then if
12:33
your signatures are suddenly huge then you can of course fit fewer transactions in the block unless
12:40
you increase the block size as well. Which is another topic. It has its own ups and downs.
12:50
But yeah if we consider that for now that the block stays the same, the size matters on the
12:57
the band this is one thing another thing is that the sphinx plus was designed to support
13:06
a lot of signing operations so the requirement for the nist was for the people to be able to
13:15
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
13:33
You don't have to worry about it.
13:35
It's 2 to the 64.
13:37
It's huge for all practical applications.
13:41
You just don't need to think about it.
13:43
There's no problem.
13:43
and this requirement for hatch-based signatures actually determines a lot in terms of the size
13:53
and the first observation that we can make is that if we set this par lower and we actually can
14:02
have a limit on less number of signing operations we can significantly decrease the signature size
14:12
moreover with the signature size
14:15
the verification time can also
14:17
be decreased
14:18
and verification
14:19
determines how fast
14:23
can we validate the block
14:25
how fast we then can propagate
14:27
it and so on
14:28
so this is one
14:31
of the core observations here
14:33
if we speak of another
14:37
improvement is that Sphinx Plus
14:39
there was a process
14:41
of standardization and the ideas were coming and the certain improvements were made, but
14:48
they had their own timeline.
14:50
And so they had to decide at a certain point what we accept and what we standardize.
14:57
But the research didn't stop there and there were different modifications and different
15:02
improvements also suggested.
15:04
And we can use those as well in the Bitcoin environment.
15:14
When NIST sets these standards, do they ever change?
15:17
Can you have updates to the specific standards on Sphinx Plus?
15:20
Or if you're going to go use the other ideas that were suggested but not included in the standard.
15:30
is obviously if you include those are you out of this standard and is that frowned upon or
15:36
just considered experimental so if we deviate from the standard now then yeah we're we're
15:44
using a different one uh theoretically uh modifications uh can be done to the standard
15:52
and there can be an update there can be a different standard or just just a new version of that
15:58
there are different also like modifications that we can do one can just use different parameters
16:06
and for example this way it will be easy to reuse some other implementation but the some
16:16
modifications that we discussed in the paper also affect some of the structure of the signature
16:21
a scheme that will have to adjust the implementation as well so this there are various options that we
16:29
can use that give us a certain performance boosts or sizes boosts or other trade-offs
16:39
and they come also in the cost of like varying further from the standard or sticking more with it
16:45
and so we already said about one trade-off which is the size of the signatures i think the other one
16:54
one of the other ones that you discussed um in the papers if you if you have um like heavier
17:02
signature sizes and bytes in terms of bytes um you could sort of limit the amount of signatures that
17:09
any public key
17:12
can be associated with any public key?
17:14
What's the trick?
17:15
I think this is a strange technical thing
17:18
that one needs to get his head around.
17:21
Right now, in our world of signatures,
17:24
we don't care how many signatures we do.
17:27
It's just a technicality of these hash-based signatures
17:31
that when you design such a scheme,
17:35
there is a limit of signatures
17:37
you can make per public key.
17:40
And to be clear, we were not the first to come up with reducing the number of supported signatures.
17:48
This is a pretty obvious idea when you look at those schemes, how they are structured.
17:55
But one of the insights that you might have when trying to apply this to Bitcoin is just that
18:01
And in Bitcoin, specifically in Bitcoin, we don't need that many signatures, right?
18:09
We create an address.
18:11
Usually we only want to use it once.
18:13
We don't want address reuse.
18:14
And then we sign, produce a transaction.
18:17
That's it.
18:19
Then you might have to do RBF to bump fees.
18:23
Then you have to sign again.
18:24
How often does that happen?
18:26
maybe it happens more often
18:28
if there's a more competitive
18:30
block space market
18:31
it doesn't happen often right now
18:34
and it certainly doesn't happen
18:35
to the 64 times
18:36
there are other things
18:40
where you need to sign more often
18:41
for example in layer 2s
18:43
so lightning so that payment shows
18:46
that's sort of a different discussion
18:48
perhaps but you still won't sign
18:51
that many times
18:51
there's still going to be an upper bound
18:53
that is below to the 64
18:55
and using those ideas we can get down the signature size.
19:04
As I said, this is quite a technical thing, very peculiar to these hash-based signatures.
19:12
Lower number of supported signatures means you can get a smaller signature.
19:18
And what happens if you sign more often? I think that's important to explain.
19:23
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.
19:36
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.
19:48
So you should really, if you have that limit of supported signatures, you should not exceed it.
19:53
You must not exceed it.
19:55
So, Freaks, this rip of TFTC was brought to you by our good friends at BitKey.
19:59
BitKey makes Bitcoin easy to use and hard to lose.
20:02
It is a hardware wallet that natively embeds into a two or three multi-sig.
20:06
You have one key on the hardware wallet, one key on your mobile device, and Block stores
20:11
a key in the cloud for you.
20:13
This is an incredible hardware device for your friends and family, or maybe yourself,
20:18
who have Bitcoin on exchanges and have for a long time, but haven't taken a step to self-custody
20:23
because they're worried about the complications
20:24
of setting up a private public key pair,
20:27
securing that seed phrase,
20:28
setting up a pin, setting up a passphrase.
20:30
Again, BitKey makes it easy to use, hard to lose.
20:33
It's the easiest zero to one step,
20:35
your first step to self-custody.
20:37
If you have friends and family on the exchanges
20:38
who haven't moved it off,
20:39
tell them to pick up a BitKey.
20:40
Go to BitKey.world, use the key TFTC20
20:44
at checkout for 20% off your order.
20:46
That's BitKey.world, code TFTC20.
20:49
What's up, Freaks?
20:50
Have you noticed that governments
20:51
have become more despotic.
20:54
They want to surveil more.
20:55
They want to take more of your data.
20:56
They want to follow you around the internet
20:57
as much as possible
20:58
so that they can control your speech,
20:59
control what you do.
21:00
It's imperative in times like this
21:02
to make sure that you're running a VPN
21:04
as you're surfing the web,
21:06
as we used to say back in the 90s.
21:08
And it's more imperative
21:09
that you use the right VPN,
21:10
a VPN that cannot log
21:12
because of the way that it's designed.
21:14
And that's why we have partnered with Obscura.
21:16
That is our official VPN here at TFTC
21:19
built by a Bitcoiner, Carl Dung,
21:21
for Bitcoiners focused on privacy.
21:23
You can pay in Bitcoin over the Lightning.
21:25
So not only are you private
21:26
while you're perusing the web with Obscura,
21:30
but when you actually set up an account,
21:31
you can acquire that account privately
21:33
by paying in Bitcoin over the Lightning network.
21:35
Do not be complacent
21:37
when it comes to protecting your privacy on the internet.
21:40
Go to Obscura.net,
21:42
set up an Obscura account,
21:44
use the code TFTC for 25% off.
21:48
When I say account, you just get a token.
21:50
It's a string of token.
21:50
It's not connected to your identity at all.
21:54
Token sign up, pay with Bitcoin, completely private.
21:57
Turn on Obscura, surf the web privately.
21:59
Obscura.net, use the code TFTC for 25% off.
22:02
Yeah, it's funny.
22:05
Again, I say this a lot, especially when I talk to developers and cryptographers like yourself.
22:11
is like so many people take for granted that the system just works
22:15
and not understanding these deep cryptographic primitives that exist.
22:20
But it is always infinitely fascinating diving into these details
22:25
because I think it's important, even if you're not technical,
22:27
to have a rough understanding of what's happening under the hood.
22:33
But obviously we talked about Sphinx Plus, some of the optimizations there.
22:36
We also talked about Watts plus C, Fours plus C, Pours plus FP,
22:40
with potential optimizations, I guess,
22:44
without getting too far into the weeds?
22:46
What are the ideas with these optimizations?
22:51
I think I can do some already here.
22:55
So the core idea here is we can make the signer
23:03
to work a little bit more on finding
23:10
certain inputs. So except we don't only include the message, but some extra seed or
23:17
an extra
23:18
random number or a counter
23:21
and that allows us to
23:23
search for better values that we can then sign and
23:29
this requires some extra work from the signer
23:31
but because we have these extra properties from what we are signing, this
23:38
can reduce the signature size and this also helps the verifier. So by doing extra
23:46
work on the signer part, we reduce the size and we reduce the verification
23:53
time. Sometimes this extra work also comes in the cost kind of, yes, we search
24:01
for this nice value to sign afterwards. But because this value is nice, this also
24:08
eases the further work for the sign. So we had these different parameters choices
24:15
in the paper. And for most of them, we make the signing time a little bit more
24:22
than the original Sphinx Plus, because we want more effort from the signer, but
24:28
but really smaller signatures.
24:31
And on the other hand, we can still balance this out
24:34
while keeping the signature size small.
24:38
And so this would affect wallet software, right?
24:40
Because I'm thinking of,
24:42
I played around with some DLC apps, Atomic, Finance,
24:45
and when you go and you're doing like a rollover transaction
24:48
with DLCs that take a lot of signatures,
24:50
it sometimes takes like a minute or two
24:52
to actually sign and then broadcast the transaction.
24:55
So this wouldn't necessarily affect the nodes, right?
25:01
And bandwidth propagation and things like that.
25:03
It's just literally on the setup to sign and then broadcast, correct?
25:08
Yes, I think so, yes.
25:10
I think this is a very interesting point that you're making right now
25:14
that I hadn't really considered before.
25:17
So I think this kind of trade-off between increasing the signing time
25:24
while reducing signature size and verification time
25:28
makes a lot of sense in Bitcoin
25:29
because at least on the Bitcoin blockchain,
25:32
we have a natural limit of the number of transactions
25:35
that are supported per second, right?
25:37
We can at most like whatever,
25:40
10 transactions per second
25:41
and few more signatures than that, whatever,
25:44
but it's not thousands of signatures per second
25:47
that you need to make.
25:49
On the other hand, we also have hardware wallets
25:52
that are, of course, lower powered and that might take longer.
25:57
And I think what you're pointing out is an interesting thing.
26:00
You might have a situation where you are pre-signing a lot of transactions.
26:06
And this is what is happening naturally in DLCs right now.
26:11
And this would be affected by a change like this,
26:16
by a change to hash-based signatures,
26:19
because producing these signatures, depending on which parameters you pick,
26:24
which is, I think, the biggest part of our work,
26:27
trying to figure out what are reasonable parameters,
26:30
it might take much longer to sign them than it takes currently.
26:37
Yeah, and that's the trade-off you have to weigh.
26:39
Are you willing to wait more to broadcast a transaction?
26:42
Right.
26:42
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
26:58
because they are asking, why haven't you done anything right now already?
27:03
Perhaps we would have changed to more conservative assumptions in terms of signatures,
27:11
if it was for free, but that's not the case.
27:14
whenever we want to add post-quantum security to Bitcoin,
27:20
we get very significant downsides,
27:23
be it new assumptions, signature sizes,
27:27
verification time, signing time, statefulness.
27:31
So there's no, we can't just,
27:34
there's a big risk, I think,
27:37
to just try to switch something
27:41
which we later figure out wasn't the right choice
27:44
because it picks the wrong trade-offs.
27:46
So what we are doing mainly in this paper
27:48
is to explore the trade-off space,
27:50
particularly with respect to hash-based signatures,
27:53
to inform the community
27:55
as to what are reasonable parameters to pick.
28:00
Yeah, that makes a lot of sense.
28:02
I mean, you mentioned statefulness.
28:04
You guys touched on it on the paper.
28:07
Stateful versus stateless signature schemes.
28:10
Why is being stateless so important to Bitcoin specifically?
28:14
So, yes, stateless versus statelessness is a good topic as well.
28:20
Here, what does stateless versus stateful mean?
28:25
Is that, again, now we don't have to think about it.
28:29
ECDSA is essentially stateless.
28:32
And what does mean is that when you sign, you don't have to touch your secret key in
28:39
terms of changes and updated.
28:42
stays the same and you can kind of in more or less implementations you can separate it you can
28:47
backup it as it is there is no problem everything again stays the same when we say stateful a stateful
28:54
hash based scheme means every signing operation must update the secret key and if there is a
29:03
misuse of this secret key or the update didn't go through or you lost some key and you run a
29:10
backup that has an older state of the key that will compromise the security of the scheme
29:19
but it comes from the other side with benefits of having again better performance and better sizes
29:26
with a stateful scheme if you if you if you're happy with this secret key manipulations you can
29:32
have better performance but it's important to mention yes this this can be very quick for example
29:39
if you have just two separate devices and you want to run them with the same key pair if they
29:45
don't communicate with each other maybe you can separate the states but that will limit the the
29:52
number of signatures that they can provide but there is much involved there in that regard with
30:00
managing your your key pair yeah so the state management thing i think is another very
30:07
technical thing but that is kind of important when trying to pick these schemes i think state
30:14
fullness is pretty fragile and it's one of those things that won't work for every signer
30:20
so another example is so you run bitcoin core on your node let's say you produce a backup you
30:30
backup your wallet.dat you make a few transactions perhaps and your machine crashes whatever it break
30:39
your machine breaks you need to restore the backup that you've created including the wallet.dat
30:44
and if you do that and the state would be stored in the wallet.dat which of course no one would do
30:51
but if you did that then essentially you would allow an attacker to produce forgeries steal
30:59
steal your Bitcoin. So that is why it's very fragile and it won't work for everyone.
31:03
So for example, it probably won't easily work for share care.
31:07
Okay. I guess another thing that this affects too, though, is like HD wallets, hierarchical,
31:15
deterministic wallets. And you mentioned the backup system that we rely on. Again,
31:20
they don't work the same way with hash-based signatures either. So what do we do with HD?
31:25
yeah i think this is one of the the other uh sort of downsides of hash based signatures is that
31:34
they don't have this nice mathematical structure that we currently enjoy on our elliptic curve
31:41
which means that we cannot use any of the tricks that we've developed over the past
31:48
years in Bitcoin.
31:51
And that includes HD wallets.
31:53
It includes
31:54
multi-signatures, threshold
31:56
signatures, silent payments,
31:59
aggregate signatures,
32:01
and
32:02
taproot, I guess,
32:04
taproot commitments.
32:06
So that was one of
32:08
the other research questions
32:10
that we also had when we started
32:12
this entire project is
32:14
is there anything we can do with hash-based signatures in the past it was sort of
32:21
it was intuitive that it wouldn't work but i thought maybe we could do something here or there
32:29
and improve improve on at least the trivia of things i think the answer is mostly we can't
32:39
really do anything fancy there we described some methods in in the paper that would reduce the size
32:49
of multi-signatures by a little bit but it makes the signing protocol very complicated and there
32:55
are other techniques like that that you could use especially for multi and threshold signatures
32:59
it's not maybe there are some scenarios where you could use them but right now it doesn't seem
33:05
it doesn't seem to make a lot of sense to base the entire standardization effort
33:14
and picking specific schemes just to make it work a little bit better
33:19
with these multi-signature schemes because they don't really work that well.
33:25
Yeah, they don't give much there.
33:28
And for HD wallets, there we have...
33:32
So HD is multiple things.
33:35
One is private derivation and public derivation.
33:42
So what you can have still with hash-based signatures,
33:44
that works very straightforwardly.
33:47
You have a seed that you can generate many addresses from it.
33:52
Perfectly fine.
33:54
Works well.
33:55
What you can't have is this kind of XPub
33:58
where some other person would,
34:00
or some other entity would derive new public keys
34:05
from some given XPub.
34:08
That does not work.
34:10
And this XPub system,
34:13
the XPub setup is particularly important today
34:15
in hardware, software wallet setups.
34:18
If you have your hardware wallet,
34:20
export your XPub from the hardware wallet
34:23
to the software wallet.
34:24
Software wallet is then able to derive new addresses
34:28
and scan the chain in that way.
34:32
And that wouldn't be possible anymore
34:34
with hash-based signatures.
34:36
What you need to do instead,
34:38
so the only thing we know of
34:39
is you have your XPub is not a short public key,
34:44
but rather a long list of public keys
34:49
that you give to the software wallet.
34:52
And once this list is exceeded,
34:54
the software wallet needs to talk to the hardware wallet
34:57
and ask for more public keys again.
35:01
So it's not impossible,
35:03
but it doesn't work as well with the infrastructure
35:06
that we've created with descriptors in the past.
35:11
And there is also this kind of worry
35:15
that because it's a little bit harder to make this work,
35:18
that people would or wallet developers
35:21
might decide to just reuse addresses, for example,
35:26
instead of building this system.
35:32
That would bork a lot of things there.
35:34
Yep.
35:35
Yeah.
35:36
So if you're a listener,
35:40
I think one of the examples that Jonas just walked through,
35:43
like say you have a cold card
35:44
and you want to set up the private public e-pair offline
35:47
using the wallet,
35:49
and then you want to put it in a safe or something,
35:51
but you want to be able to receive Bitcoin to it.
35:53
So you download Sparrow, you export.
35:56
the xpub to sparrow and then from there you can get these addresses this would be made
36:00
harder you'd have to do it a different way with these hash based then similarly with multi-sig
36:06
you share xpubs with your quorum partners to make the multi-sig xpub and that would be made
36:13
impossible to hash based signatures right right this is another another kind of scenario that
36:21
sort of wouldn't work as well anymore.
36:24
That seems like a pretty big change.
36:26
Maybe something we should talk through.
36:28
At first.
36:31
Well, it might be.
36:33
I mean, there are other...
36:35
We said it's not only hash base signatures.
36:37
There are other assumptions we can pay.
36:40
They might support these kind of scenarios better,
36:44
but they have other downsides.
36:46
What's up, Freaks?
36:47
Have you noticed that governments have become more despotic?
36:51
They want to surveil more.
36:52
They want to take more of your data.
36:53
They want to follow you around the internet as much as possible so they can control your
36:56
speech, control what you do.
36:57
It's imperative in times like this to make sure that you're running a VPN as you're surfing
37:02
the web, as we used to say back in the 90s.
37:05
And it's more imperative that you use the right VPN, a VPN that cannot log because of
37:10
the way that it's designed.
37:11
And that's why we have partnered with Obscura.
37:13
That is our official VPN here at TFTC, built by a Bitcoiner, Carl Dung, for Bitcoiners
37:19
focused on privacy.
37:20
You can pay in Bitcoin over the Lightning. So not only are you private while you're perusing
37:24
the web with Obscura, but when you actually set up an account, you can acquire that account
37:29
privately by paying in Bitcoin over the Lightning network. Do not be complacent when it comes to
37:35
protecting your privacy on the internet. Go to Obscura.net, set up an Obscura account,
37:41
use the code TFTC for 25% off. When I say account, you just get a token. It's a string
37:47
a token. It's not connected to your identity at all. Token sign up, pay with Bitcoin, completely
37:52
private. Turn on Obscura, surf the web privately. Obscura.net, use the code TFTC for 25% off.
37:59
What's up, freaks? I've been seeing a lot of YouTube comments. Marty, your skin looks so good.
38:03
You're looking fit these days. How are you doing it? Well, number one, I'm going to the gym more,
38:09
trying to get my swell on, trying to be a good example for my young son to fit,
38:15
healthy dad, but part of that is having a good regimen, particularly staying hydrated,
38:19
making sure I have the right electrolytes and salts in my body. That is why I use salt of the
38:24
earth. I drink probably three of these a day with one packet of salt of the earth. I'm liking the
38:31
pink lemonade right now. It's my flavor of choice. This is their creatine. I've added this to my
38:36
regimen. They have it in these packets as well. It makes it extremely convenient if you're traveling.
38:41
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.
38:47
It's very, very nerve wracking at times.
38:50
You have to explain hates.
38:51
It's not what you think it is.
38:52
It's creatine.
38:52
I'm trying to get my swell on.
38:55
Make sure you're staying hydrated.
38:57
I have become addicted to these.
38:59
It's made my life a lot better.
39:02
I can supplement this for coffee in the morning and be energized right away.
39:07
I can supplement.
39:08
I can bring the creatine wherever I need to.
39:10
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.
39:19
Go to drinksauté.com, use the code TFTC, and you'll get 15% off anything in the store.
39:25
That's drinksauté.com, code TFTC.
39:28
Well, that was going to be my next question.
39:29
Obviously, this research paper was focused on hash-based signature schemes.
39:35
Do you guys plan on doing more research on different signature schemes moving forward?
39:40
Yes, so our current plan is also to look at lattice-based schemes.
39:45
As exactly Jonas mentioned, although the lattice-based, they introduce extra assumptions,
39:54
this is called lattice-based, so they're based on lattices and the structure and with certain heart problems.
40:02
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
40:23
But this is a whole lot that we would have learned to working at.
40:28
Yeah.
40:29
And I also think it's important to note that this entire post-quantum story for Bitcoin is a spectrum.
40:37
from what do we do in an emergency
40:40
if it happens now, let's say.
40:43
It might not even be a quantum computer.
40:45
It could be just our curve is broken classically.
40:48
That's a scenario that some people bring up.
40:52
And how can Bitcoin really work in a post-quantum future?
40:56
And those are different questions, I think.
40:59
Because when we want Bitcoin to work in a post-quantum future,
41:03
we need to make sure that people can still make transactions
41:06
and they are not just like a few transactions
41:09
that can make it into the chain
41:11
because the blocks are so small
41:13
compared to the signature sizes.
41:17
So those are different questions.
41:18
And then there's a spectrum in between
41:20
where we look at, okay,
41:21
maybe this won't be the perfect solution,
41:24
but at least it doesn't rely on these crazy assumptions.
41:29
And I think this hash-based signature schemes
41:31
is more on the sort of emergency,
41:34
something we could get consensus on relatively easily,
41:40
whereas the lattice-based stuff is a little bit further away on that spectrum.
41:48
Yeah, there would be a lot of reshuffling if we had to do,
41:51
if and potentially when we had to do this transition,
41:55
so being prepared for it.
41:57
Also, it's also possible to add multiple signature schemes to Bitcoin
42:03
and even just looking at hash-based signatures,
42:07
this might be a viable path forward
42:10
because there are just so many different types of signers.
42:13
There are these, I don't know,
42:16
Kleb hardware wallets
42:18
and there are Kleb lightning nodes
42:24
and there are also big exchanges
42:26
and they have different requirements.
42:29
and even just for hash-based signature schemes this might mean that it makes sense to add
42:37
hash-based signature schemes with different parameters this has downsides as well of course
42:43
it increases the complexity of the of the bitcoin protocol which we want to keep relatively small
42:49
because this might result in chain splits or other vulnerabilities in bugs if we have
42:55
if there actually is something that goes wrong.
43:01
And so another downside would be that it reduces privacy.
43:11
One of the big advantages of introducing Taproot, right,
43:18
was that every transaction should look like every other transaction,
43:22
even at least in the best case and to improve privacy and if we introduce these many different
43:31
signature schemes now this might be a problem because now you can look at the blockchain and
43:36
just follow certain passive transactions and maybe certain wallets they have identifiable
43:42
fingerprints and so on so these are the downsides if you add multiple signature schemes but it's
43:49
certainly possible so you get degradation and privacy via process of elimination of yep different
43:56
people using different signature schemes so yes yeah that makes sense well i guess this all comes
44:03
back to like how how real is this rats how imminent is it or far away is it how much time
44:09
do we have to prepare obviously jonas you mentioned like there is a potential for
44:14
classical means so you don't even need a quantum computer just to break the curve but i think a lot
44:19
of discussion is on quantum specifically and obviously early this year you had google's willow
44:24
chip uh made a lot of hot headlines i think the um the sort of advancement there was 105 qubits
44:31
uh computations that would take supercomputers 10 septillion years to to perform um and is that
44:41
advancement enough to to make bitcoin bitcoiners wary and then another thing which is i'm trying
44:46
to wrap my head around reading people's reactions to the quantum discussion this week is like
44:54
how much signal is in these advancements, whether it's Willow or other quantum advancements
45:02
that have been made recently.
45:03
I've read people explaining that some of these advancements have sort of hard-coded variables
45:10
or assumptions in them, which are sort of cheating in a way.
45:14
and even if Willow got to 105 qubits
45:21
and it was legitimate,
45:23
I think there's a very good case to be made that it was,
45:26
Bitcoin's cryptography would require around 13 million qubits
45:29
working in parallel to break the curve.
45:33
And so how viable is that?
45:35
How realistic is that in a timeline of 5, 10, 15 years?
45:41
So I'm not a quantum engineer
45:44
And I think there is no consensus, at least among the experts, when this will happen.
45:52
My angle on this is that I told you, we write these theorems.
45:58
They rely on the elliptic curve.
46:00
We know the elliptic curve is broken.
46:02
This makes me uneasy.
46:04
I want Bitcoin to be secure.
46:07
And that includes my own little stash.
46:08
I want it to be secure against very, very powerful adversaries.
46:14
And I don't want it to only remain secure if some random guy on Twitter turns out to be right.
46:21
So I think the Bitcoin community should certainly look at this problem.
46:27
And this is why we are working on it.
46:30
Right now, I wouldn't lose my sleep over it for sure as well.
46:35
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.
46:46
You said it yourself, the HD wallet stuff, for example, that would completely be broken.
46:51
So we would need to have an ecosystem update for that.
46:55
Maybe that doesn't take 10 years, but people migrating their coins, the more time they have, the better.
47:03
Yeah. Yeah. I mean, it's very hard to just say, okay, this will be five years, 10 years,
47:13
or whatever years, because the advancement goes from every possible direction. As you said,
47:20
for example, counting the number of cubits, there is a very interesting point in terms of,
47:26
uh it's a little bit different from how the classical computers work in terms of we need
47:34
several physical qubits to encode a one logical means one logical is that we actually actually
47:42
performs like we expected it to perform because there is a lot of noise in the quantum computations
47:49
and one need to eliminate that noise to actually do proper computations one can increase the number
47:56
of those qubits, one can improve the noise cancellation algorithms. Then it's also very
48:04
important in terms of the quantum algorithms that actually solving the problem. And for example,
48:12
there was a recent advancement that reduced, I think, by 20 times the number of qubits that
48:19
required the algorithms there. So the advancement go from different directions. I would agree with
48:27
Jonas in terms of I wouldn't lose sleep today but we have to work towards the solutions to be ready.
48:35
If we just delay delay delay and we never come there but now we have to work and progress and see
48:43
what what possible uh solutions we have and prepare for for the downsides uh and change
48:51
that that these solutions bring how would uh how would you two describe your um this is what i'm
49:01
looking for are you uh are you happy with the amount of focus on this obviously pip 360 um
49:09
has been talked about for the last, I mean, before it was BIP360 even,
49:15
people have been talking about this Hunter and his work.
49:19
People have been looking at that and discussing it for what seems like over a year now.
49:25
At this point, obviously, you two have done a ton of research.
49:29
We had the quantum meeting at Presidio Bitcoin in July.
49:34
Is there enough discussion, in your opinion, on this topic right now?
49:37
are enough people focused on it and taking it seriously
49:40
and of course it would always be better if there was more quality discussions but i think the
49:48
type of discussions that we have right now is is pretty good and has also increased quite a bit
49:54
especially over uh over the last year so like you you like on twitter there there was not only noise
50:02
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.
50:12
And on the Bitcoin mailing list, there's always a bunch of discussions.
50:16
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.
50:28
nothing ever happens, right?
50:29
It's a pretty standard thing that happens in Bitcoin.
50:33
But I'm also not too worried about that, to be honest,
50:38
because I think if it really, if it was really,
50:43
if the quantum computer was imminent,
50:47
then I think the Bitcoin community would find consensus
50:50
on some sort of upgrade.
50:52
What is, of course, going to be really, really painful,
50:55
and there's no way to sugarcoat it is what happens with the coins that don't migrate
51:01
and i think this will be extremely painful but that's not something that that cryptography can
51:07
solve unfortunately what's your take there i'm a i'm a don't do anything with them let them let
51:14
the treasure hunts begin that's i think that's my stance because you always have to think of the man
51:20
in the coma right which is if you were to change or make their coins unspendable and the guy wakes
51:29
up and he's like hey i have five bitcoin here that i can't move anymore because you did something
51:35
and quant computers haven't stolen it yet um you're sort of screwing that guy over
51:41
i think there are reasonable uh arguments for or both for both positions that's what makes it
51:50
painful and um i don't know i guess my opinion right now is that if i look at it extremely
51:57
selfishly what code would i run on my node then i think it would be the one that uh that freezes
52:03
the coins because that at least i think in the mid to long term it would probably result in a
52:10
better outcome for the world for the bitcoin network but yeah you could fight counter arguments
52:15
to that i'm sure yeah i thought um i followed the uh the discussion on the mailing list
52:23
i've been following it i thought earlier this year i think there's still a lot of
52:27
assumptions baked into this but i thought ethan haleman's post on this was interesting
52:33
how you could essentially throttle the transition and only make a certain amount of transactions from
52:40
quantum exposed signatures possible per block.
52:47
Is this this hourglass idea?
52:50
I think so.
52:51
I'm pretty sure.
52:54
Let me see.
52:55
It goes all the way up.
52:58
I think it is.
53:02
He also said it was a way to solve the JPEG spam as well.
53:07
But this idea that...
53:08
And that's the other thing.
53:09
Maybe we should just dive into the trade-offs that exist with what you do with the coins that haven't transitioned.
53:18
What are the solutions that are being thrown out there right now or the trade-offs that exist?
53:25
I mean, I personally haven't looked too much into this.
53:30
I know that there is a discussion on the mailing list, and there probably should be more discussion.
53:36
I don't know but as I said there's no no easy answer to this I wouldn't be
53:42
able to reproduce all the pros and cons there.
53:46
All right.
53:47
Well, then taking it in a different direction,
53:50
like how, like, obviously you guys are doing research.
53:52
There's a lot of discussion about this.
53:54
In terms of like a first step beyond research
53:58
and having the discussions,
53:59
what would a transition to a post-quantum signature scheme look like?
54:07
Like how do you prep the market?
54:10
How do you begin moving?
54:11
how do you set up the node software to make this stuff viable
54:16
as for the next steps that we envision after this paper so one thing that is a contribution
54:26
of this paper is that we have this script a python script where you can explore the parameter space
54:34
or you can say okay i want to support that many signatures and the tree to look like this and then
54:40
it spits out the signature size verification time etc and we also have tables in in the paper
54:47
that do show some of these values already for the parameters that we that we pick so like
54:54
explore the parameter space and then next what um what is the next step there is implementations
55:03
benchmarking yes implementations and actual benchmarks we just estimate through some crude
55:12
proxy what the performance would be but we haven't really measured actual performance and at least
55:20
from my experience implementations usually they inform specifications quite a bit because you find
55:27
things that you wouldn't notice just going from the from the research direction and it's nice that
55:36
actually there are people actively participating in that regard and also on the mailing list there
55:42
were several posts of people trying to implement hash-based schemes either sphinx plus or sphinx
55:50
plus with lower number of signatures now they're also looking at possible modifications that we
55:55
also discussed in this paper and i think this will significantly help with the with the decision
56:03
that we will have to make so uh yeah i think that's very good to point out because they
56:11
have really so there's specifically i want to give a shout out to conduition he wrote this
56:16
awesome blog post where he optimized hash base signatures like crazy and certainly worth worth
56:23
to read um but for the for the bigger discussion how do we actually migrate um now that this this
56:31
research um exists um or even before that just with the standardized nist schemes um so one thing
56:41
that could happen that is uh i think a relatively reasonable upgrade path that unfortunately does
56:49
not have a catchy name i think so matt corello he was the first one to uh popularize it on the
56:58
on the mailing list but uh others i think have discussed it before which is um let's say we just
57:07
introduce a uh a hash based signature opcode like check sick verify that we have for uh for
57:16
our elliptic curve based signatures we just introduce one for hash based signatures doesn't
57:22
matter how it looks like something like that and what people could do today already
57:28
wallets could do generate a post-quantum public key a hash based public key and then add this
57:38
public key along with this new opcode in a taproot merkle tree that already exists
57:48
so this would be a soft fork so we add this opcode and there's no cost for a wallet except
57:57
implementation complexity to add this additional spending path if they already use taproot to the
58:05
the taproot tree and so they do that and of course taproot itself is not secure some the
58:15
full taproot not secure against a break of the elliptic curve because we have these key spins
58:21
as well which just require a an elliptic curve short signature for the public key that is directly
58:30
in the output. So that's a keypad, but there's also the taproot tree.
58:34
Now, what our colleague Tim Rufing at Blockstream proved is that
58:41
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
58:57
So what you can do is at a certain point, you disable the key spends from Taproot.
59:06
And then you still, hopefully many wallets have done that.
59:09
They have these additional post-quantum public keys in the tree.
59:15
So they will be able to spend those coins with a hash-based signature.
59:21
and the advantage of this is you can use taproot as you do right now you have these very official
59:29
keyspins you have the taproot path you have music frost whatever only once the bitcoin community does
59:38
this upgrade to disable uh keyspins hypothetically then you need to use these new script paths in the
59:49
Merkle tree, in the taproot tree.
59:52
This will be one variant.
59:53
Actually, a very important benefit of a Bitcoin system in that regard is that, for example,
1:00:02
other systems that were looking like, I don't know, DLS or whatever, a lot of time we want
1:00:10
encryption.
1:00:11
And people that are also scared of quantum computers today, they're also worried about
1:00:16
this attack called store now decrypt later. So they also
1:00:22
urge in the migrating in terms of encryption. So for example,
1:00:26
now, the post quantum scope encapsulation mechanism that
1:00:31
help you to actually encrypt your messages and encrypt your
1:00:35
communications are already getting deployed. While the
1:00:39
signatures can wait a little bit later because for most use
1:00:44
cases you are scared of your signatures broken up you don't care if they i don't know they see
1:00:50
your public key that you don't use anymore 10 years later and so this scripting pass that you
1:00:58
are described exactly we can migrate closer when we see the actual thread while the solution is
1:01:05
already there you just want to use the solution when when we're actually needed
1:01:12
and this may be a dumb question but uh jonas you mentioned like music and frost
1:01:20
is there a way to just leverage those on top of
1:01:24
like your your private public key pair to harden that private key even more from a quantum attack
1:01:32
does that make sense even just like obscure like the spending conditions like make it harder
1:01:37
without introducing uh hash-based signatures or any post-quantum assumption just yes no no the
1:01:46
problem is that in the whenever the adversary sees a public key they can run their quantum
1:01:55
computer and compute the the private key that's corresponding to it so music or frost or any
1:02:02
obfuscation attempts like this will will fail okay that's good to know
1:02:08
fascinating stuff so
1:02:11
what are the dangers if we move too fast on this i mean you mentioned them earlier
1:02:16
with like if we because that's what i worry about that was the uh the most disheartening
1:02:23
thing about the conversation last week i think it's good the conversation is happening but
1:02:27
The idea that the community of developers working on Bitcoin
1:02:32
haven't been thinking about this.
1:02:33
Obviously, you two spend a lot of time on your research.
1:02:36
Blockstream does a ton of research,
1:02:37
and there's plenty of others outside of your organization
1:02:40
working on this stuff.
1:02:43
What I worry about most, I agree,
1:02:45
I think we should want Bitcoin to be as secure as possible,
1:02:49
and if it's a threat of quantum computing
1:02:51
or even classical elliptic curve breaking computers are to manifest.
1:02:58
We should prepare for this.
1:02:59
But what could be just as dangerous is moving too fast, right?
1:03:04
And so trying to have a level-headed discussion about what to do.
1:03:09
And obviously you can't use the fear of moving too fast forever
1:03:14
because then you're complacent.
1:03:15
But there's this sort of trade-off between urgency and complacency.
1:03:18
how do you view it i think it's i mean first of all yeah there's a lot of value in the bitcoin
1:03:28
protocol being as simple as possible um because yeah we we want bitcoin to be secure and that
1:03:37
requires a relatively simple protocol whenever we add something to bitcoin there is a risk
1:03:43
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
1:04:02
consensus relevant issues, which is a specific problem that is specific to Bitcoin. It doesn't
1:04:08
exist in non-blockchain or non-consensus systems. So there's a risk in that. And then
1:04:15
If you add something and no one uses it, I think that's just a lot of wasted effort.
1:04:21
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.
1:04:42
Is at least my impression.
1:04:43
And as you said, we want to explore in full what are our options.
1:04:53
And as we said before, the next topic would be to look at lattice-based, how they affect,
1:05:01
what are the assumptions, what are the benefits, and doing a proper comparison of what are
1:05:06
the options gives us uh i guess the best the best outcome here so crushing it uh also like
1:05:16
this with the fear in the ice is also not the best way to go no and again who knows that's
1:05:25
that's the thing about this quantum uh risk is it's hard to know it's like a big unknown it's
1:05:31
like climate change almost where it's like it's just around the corner but it's been said for some
1:05:36
time and obviously there are some advancements but again as a layman it's not easy to understand
1:05:41
where the signal in these advancements are you can talk to some quantum physicists they say to
1:05:46
your point like this doesn't scale literally you need more um physical qubits to create
1:05:52
logical qubits and if you need thousands of logical qubits to attack bitcoin that's an
1:06:00
exponential amount of physical qubits this is the way i understand it i'm speaking out of my ass but
1:06:04
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.
1:06:20
And for my master's, I studied computer science with a focus on artificial intelligence.
1:06:25
if i had told anyone that i believe we would have chat gpt3 by 2022 they would have
1:06:34
ridiculed me forever at that time people uh they not not only that they thought maybe i think one
1:06:45
of or a lot of people thought that something like chat gpt3 would never be possible it's just so
1:06:51
much intelligence coming from a machine and look at where where we where we are now i actually
1:06:59
sort of thought when i studied this i thought uh this ai stuff is going nowhere it's not not
1:07:06
going to be a breakthrough i'm i'm focusing all my time on bitcoin back when i was a student
1:07:12
right so i am just very skeptical of people oh first of all i want to say of course this analogy
1:07:20
fails in many ways, quantum computing
1:07:22
very different to AI, of course.
1:07:24
But I am skeptical
1:07:26
of people saying or confidently
1:07:28
claiming there's no clear path
1:07:30
towards a cryptographically
1:07:32
relevant quantum computer. Maybe there's not
1:07:34
one right now, but I think
1:07:36
there could be one any time.
1:07:40
And you have to prepare.
1:07:42
If you don't prepare
1:07:43
and then
1:07:45
suddenly you find out you were wrong,
1:07:50
Yep.
1:07:50
Yeah.
1:07:52
No, that goes back to like measuring and balancing complacency versus urgency.
1:08:00
Because again, to my point, like I think this is a discussion that's been taken seriously for many years now.
1:08:08
And it's like brush to fix it right now.
1:08:11
It's like, whoa, hey, there's good conversations going on.
1:08:14
There's good research being done.
1:08:15
Let's make sure we get this right because it's critically important.
1:08:18
Yep.
1:08:20
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.
1:08:28
It's been incredibly illuminating for me.
1:08:32
And again, like I said earlier, a lot of people take for granted the technical details of the Bitcoin protocol.
1:08:41
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.
1:08:49
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
1:09:02
between all those individual actors within the system.
1:09:08
Yes, but one thing I want to add there is that what we're doing is also not rocket science
1:09:16
in the sense that it's impossible to understand or anything like that.
1:09:21
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.
1:09:33
If that is the case, then that is very bad.
1:09:36
And I think everyone in the Bitcoin community agrees that it will be very bad.
1:09:40
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.
1:09:50
At least this is the system we want to have.
1:09:54
And we want to have the best people working on Bitcoin.
1:09:59
And this was also our intention, writing this paper.
1:10:02
We tried to give a good introduction into this hash-based solution.
1:10:08
Right.
1:10:08
And slowly building up from very basic, from WEMPR signatures,
1:10:13
which probably we will not use, but just to build the intuition.
1:10:17
so go take a look at the at the paper we're trying to introduce the stuff slowly there and moving
1:10:24
on and on and showing what are the solutions what are the trade-offs what can be done and yeah
1:10:32
let's have a discussion and uh if i could read your research have a conversation with you and
1:10:42
know enough to like understand what's happening in the background with like verification
1:10:45
signature verification its effect on the protocol anybody can do it uh that's uh that's to say the
1:10:53
least but gentlemen any uh any parting notes anything um that you want to leave the audience
1:10:59
with right before we wrap up here i think i would encourage further discussions uh more technical
1:11:11
discussions uh reading into what we've done doing your own stuff suggest and yeah this is
1:11:19
let's have it with a good pace not rushing but also not not putting it away and saying like that
1:11:28
this will never happen yep i i agree i mean there's uh there's still a lot of uh feedback
1:11:37
that would be interesting for us in particular from from wallet developers um that that is sort
1:11:45
of an open question how um if maybe there are one of developers for example that can deal
1:11:52
with a state issue and we have a we have a scheme that we describe which is very efficient
1:11:58
if you can hold state securely so that will be interesting feedback then there is this
1:12:06
benchmarking question um especially with respect to siding on on low power devices
1:12:13
and uh yeah i think those those were the the the main open questions and the big question is like
1:12:21
what is the most interesting parameter set to choose from the set that we provide and um
1:12:28
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.
1:12:51
so that is I think also
1:12:54
one of the big open
1:12:56
questions with respect to hash based
1:12:58
signatures specifically
1:13:00
could you
1:13:01
propose a new standard
1:13:04
and get it
1:13:06
I mean we could propose
1:13:08
but would it be
1:13:10
accepted as the bigger
1:13:12
question
1:13:12
we make our own standards right
1:13:15
we have the BIPS process and maybe
1:13:18
we can get Apple to adopt
1:13:20
our standards that would of course be uh the most preferable path
1:13:26
yeah well gentlemen thank you this was uh again incredibly illuminating thank you for your work
1:13:32
and uh hopefully we can do this again maybe uh when you finish your research on lattice base
1:13:39
signatures we can uh we can catch up then or maybe not maybe we won't have to wait that long but
1:13:44
Thank you.
1:13:45
And I hope you guys enjoy the end of the year here.
1:13:49
Thank you for joining me so close to Christmas and the holidays.
1:13:53
So this was awesome.
1:13:56
Yeah.
1:13:56
Thank you very much.
1:13:57
It was fun.
1:13:58
All right.
1:13:59
Peace and love, freaks.
1:14:00
Okay.